[M3commit] CVS Update: cm3

[Jay K]

Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call?
You know, that'd be a great hint to:
 
  - definitely definitely definitely definitely inline
  - if we know this thing existed, we could use it instead of a .c file.
    - along with the function's name for the invocations that aren't the function?
 
 
Why provide the function anyway? In case someone takes the address?
 
 
 
 - Jay


________________________________
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Mon, 8 Mar 2010 16:04:45 +0000
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
>
>
>
>
>
>
>
> 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>
>