<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'><talking to myelf...><BR>
<BR>
Ok, I have a plan. It might work or not, it might be easy or not, elegant or not.<BR>
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).<BR>
<BR>
<BR>
I'm thinking the changes will mostly be in codex86.<BR>
And stackx86's find function will know to allocate two registers sometimes.<BR>
<BR>
This had some drawbacks.<BR>
For inline coded things like add/adc, good.<BR>
For register based functions like shift, it makes sense for, I think at the level of m3x86.m3, to force certain register allocation.<BR>
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.<BR>
And I'm not sure..hm..yeah...shifting shows this to be wrong. The changes for shifting must be in stackx86.<BR>
<BR>
The original method I suggested..might work in any of the levels..special casing and all..<BR>
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.<BR>
<BR>
- Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Subject: x86 int64 guidance?<BR>Date: Wed, 24 Oct 2007 10:21:52 +0000<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass EC_body.hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
I'm looking for guidance on the 64 bit integer support in the x86 code generator.<BR>What level does it belong in?<BR><BR>The code appears to be in three primary files, that are layered mostly like so:<BR>M3x86.m3<BR> Stackx86.m3<BR> Codex86.m3<BR><BR>Stackx86 implements, I guess, a "virtual stack" which, I guess, makes<BR> certain optimizations easy, stuff like avoiding redundant moves,<BR> because the stack knows which register corresponds to which variable.<BR><BR>M3x86 does call directly into Codex86, a lot actually.<BR>And so of course does Stackx86 (per the layering).<BR><BR>There is trafficing in:<BR><BR> Operand = RECORD<BR> loc: OLoc;<BR> mvar: MVar := NoStore;<BR> reg: Regno := 0;<BR> reg2: Regno := 0; << maybe add this??<BR> imm: INTEGER := 0;<BR> stackp: INTEGER := 0;<BR> opcode := FALSE;<BR> END;<BR><BR>notice just one register.<BR>These are x86 registers, not some abtract thing.<BR>That is what the virtual stack contains.<BR><BR>One might imagine the support going one level higher even,<BR>implement int64 as a record/struct, but add some notion of<BR>add-with-carry, sub-with-carry, multiply64, divide64,<BR>multiply64x64to32, etc.?<BR><BR>You know, when doing add, there's no canonical required<BR>register pair to use, they all work, and the upper 32 bits might even<BR>be thrown out, so don't even necessarily compute them.<BR><BR>I'd be a bit wary of the carry surviving though.<BR><BR>Or maybe a pseudo register eax_edx should be defined?<BR><BR>I'm thinking add reg2 might be easiest, though it seems wrong -- unclean.<BR>And always compute the full add/sub/mult/div.<BR><BR>Maybe an array of registers?<BR><BR> - Jay<BR><BR>
<HR>
Peek-a-boo FREE Tricks & Treats for You! <A href="http://www.reallivemoms.com/?ocid=TXT_TAGHM&loc=us" target=_blank>Get 'em!</A> </BLOCKQUOTE><br /><hr />Windows Live Hotmail and Microsoft Office Outlook – together at last. <a href='http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033' target='_new'>Get it now!</a></body>
</html>