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