[M3devel] x86 int64 guidance?

[Jay]

<talking to myelf...>
 
Ok, I have a plan. It might work or not, it might be easy or not, elegant or not.
I will add reg2 and I will put in checks at the start of some functions, like binOp, and if they are given 64 bit operands, call out to something that forms two 32 bit operands and acts on them "appropriately" (it will vary).
 
 
I'm thinking the changes will mostly be in codex86.
And stackx86's find function will know to allocate two registers sometimes.
 
This had some drawbacks.
For inline coded things like add/adc, good.
For register based functions like shift, it makes sense for, I think at the level of m3x86.m3, to force certain register allocation.
You know -- if you compile C code to do these operations, add/subtract/compare are inlined and shift/mult/divide are calls out to functions.
And I'm not sure..hm..yeah...shifting shows this to be wrong. The changes for shifting must be in stackx86.
 
The original method I suggested..might work in any of the levels..special casing and all..
It just seems like there's a mix of "levels". m3x86 operates on a virtual stack of operands, high level stuff, and passes operands down to codex86.m3, low level stuff.
 
 - Jay


From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: x86 int64 guidance?Date: Wed, 24 Oct 2007 10:21:52 +0000


I'm looking for guidance on the 64 bit integer support in the x86 code generator.What level does it belong in?The code appears to be in three primary files, that are layered mostly like so:M3x86.m3 Stackx86.m3   Codex86.m3Stackx86 implements, I guess, a "virtual stack" which, I guess, makes certain optimizations easy, stuff like avoiding redundant moves, because the stack knows which register corresponds to which variable.M3x86 does call directly into Codex86, a lot actually.And so of course does Stackx86 (per the layering).There is trafficing in:  Operand = RECORD    loc: OLoc;    mvar: MVar := NoStore;    reg: Regno := 0;    reg2: Regno := 0; << maybe add this??    imm: INTEGER := 0;    stackp: INTEGER := 0;    opcode := FALSE;  END;notice just one register.These are x86 registers, not some abtract thing.That is what the virtual stack contains.One might imagine the support going one level higher even,implement int64 as a record/struct, but add some notion ofadd-with-carry, sub-with-carry, multiply64, divide64,multiply64x64to32, etc.?You know, when doing add, there's no canonical requiredregister pair to use, they all work, and the upper 32 bits might evenbe thrown out, so don't even necessarily compute them.I'd be a bit wary of the carry surviving though.Or maybe a pseudo register eax_edx should be defined?I'm thinking add reg2 might be easiest, though it seems wrong -- unclean.And always compute the full add/sub/mult/div.Maybe an array of registers? - Jay

Peek-a-boo FREE Tricks & Treats for You! Get 'em! 
_________________________________________________________________
Windows Live Hotmail and Microsoft Office Outlook – together at last.  Get it now.
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20071024/77b048ea/attachment-0002.html>