[M3commit] CVS Update: cm3

[Tony Hosking]

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/739d3e7b/attachment-0002.html>