[M3commit] CVS Update: cm3

[Jay K]

Fair enough.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Mon, 8 Mar 2010 10:29:00 -0500
To: jay.krell at cornell.edu
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3




You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word.  It is the library representative of the front-end compiler-generated (inlined) Long.Extract.


On 8 Mar 2010, at 07:30, Jay K wrote:

diff attached
 
 
If folks really want to use tables or function calls here, let me know.
 
 
The data was historically problematic, though we worked out the problems.
 -  It was initialized at runtime which has a race condition, fixed years ago.
 - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked.
 
The data is still used by Word.Insert and Long.Insert is still a function, but those
are my next targets.
 
 
This is a case where the user does write a function call. Word.Extract or Long.Extract.
(So the function should have been called Long__Extract.)
 
 
  - Jay
 
> Date: Mon, 8 Mar 2010 13:26:36 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/03/08 13:26:36
> 
> Modified files:
> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 
> 
> Log message:
> "rewrite" extract to not use tables and always be inlined for 64bit
> 
> equivalent C code:
> 
> UT __stdcall extract(UT x, uint32 offset, uint32 count)
> {
> x >>= offset;
> x &= ~((~(UT)0) << count);
> return x;
> }
> 
> extract32
> 00000729: 8B4DEC MOV ECX tv.126[_m]
> 0000072C: 8B5DF4 MOV EBX tv.124[_a32]
> 0000072F: D3EB SHR EBX
> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove.
> 00000733: 8B4DE4 MOV ECX tv.128[_n]
> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1?
> 0000073B: D3E6 SHL ESI
> 0000073D: F7D6 NOT ESI
> 0000073F: 23DE AND EBX ESI
> 
> extract64
> 000008E4: 8B4DD8 MOV ECX tv.134[_m]
> 000008E7: 8B5DE8 MOV EBX tv.131[_a64]
> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4
> 000008ED: 0FADD3 SHRD EBX EDX ECX
> 000008F0: D3EA SHR EDX
> 000008F2: F6C120 TEST ECX $32
> 000008F5: 7400 JE rel8 L.107
> 000008F7: 8BDA MOV EBX EDX
> 000008F9: 33D2 XOR EDX EDX
> set_label L.107
> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove.
> 000008FD: 8B4DD0 MOV ECX tv.136[_n]
> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1?
> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax)
> 0000090A: 0FA5F8 SHLD EAX EDI ECX
> 0000090D: D3E7 SHL EDI
> 0000090F: F6C120 TEST ECX $32
> 00000912: 7400 JE rel8 L.108
> 00000914: 8BC7 MOV EAX EDI
> 00000916: 33FF XOR EDI EDI
> set_label L.108
> 00000918: F7D7 NOT EDI
> 0000091A: F7D0 NOT EAX
> 0000091C: 23DF AND EBX EDI
> 0000091E: 23D0 AND EDX EAX
> 
> having n or m and n (or just m? I think so.) be constant leads to better code
> 
> some other small cleanup, like avoiding calling find twice,
> I don't see why it was that way
> 
<1.txt>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100308/45c1709e/attachment-0002.html>