[M3commit] CVS Update: cm3

[Tony Hosking]

Yes, someone can pass the function as a parameter.

I don't understand the rest of what you are saying.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 10 Mar 2010, at 17:27, Jay K wrote:

> 
> 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>
>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100310/9aadb343/attachment-0002.html>