<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
>> I think what I see now -- just use the machine stack.<BR><BR>
I'm not sure this works so easily if you consider function calls.<BR>
Taking a mix of LONGINT and non-LONGINT parameters.<BR>
<BR>
There'd be a series of load_integer and pop_param calls.<BR>
Normally all the machine stack pushes are in pop_param.<BR>
Now they'd be in a mix of load_integer and pop_param.<BR>
If pop_param is called as each parameter is computed, ok.<BR>
If they are all computed and then all popped, not ok.<BR>
<BR>
<BR>
- Jay<BR> <BR>
<HR id=stopSpelling>
From: jay.krell@cornell.edu<BR>To: hosking@cs.purdue.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: RE: [M3devel] thoughts on NT386/LONGINT?<BR>Date: Sat, 23 Jan 2010 15:31:38 +0000<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
> You might easily just push/pop operands and return values on the stack<BR><BR>I don't think I understood you.<BR>My "worst case" was to store everything in temporaries.<BR>But I think I see now.<BR>Some sort of stack is required.<BR>There is the "virtual stack" already in use. (I assume "v" = "virtual").<BR> It should already handle constant folding, but its register manipulation isn't right for 64bit values.<BR>I think what I see now -- just use the machine stack.<BR>Even to push immediate values.<BR>And, to be really lame, most/all operations can be function calls.<BR> And not even in the "normal" way, but like:<BR><BR><BR>#ifdef _WIN32<BR><BR><BR>void __stdcall m3_add64(__int64 a)<BR>{<BR> (&a)[1] += a;<BR>}<BR><BR><BR>void __cdecl m3_neg64(__int64 a)<BR>{<BR> a = -a;<BR>}<BR><BR><BR>where we convince the C compiler to do the right stack maintenance.<BR>We'd just generate parameter-less calls.<BR>For actually passing longint parameters to real Modula-3 functions,<BR>I'd have to look, but, like, pop_param would do nothing.<BR><BR><BR> - Jay<BR><BR><BR>
<HR id=ecxstopSpelling>
From: jay.krell@cornell.edu<BR>To: hosking@cs.purdue.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: RE: [M3devel] thoughts on NT386/LONGINT?<BR>Date: Fri, 22 Jan 2010 22:53:41 +0000<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
I'll see what I can figure out.
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>I considered pushings pairs of operands in m3x86.m3 but I think</DIV>
<DIV>that won't work.</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>Noticing how integer vs. floating point is handled</DIV>
<DIV>is perhaps useful, as this is another way in which m3cg</DIV>
<DIV>is "homogenous" but backends have to act differently</DIV>
<DIV>based on type.</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV> - Jay<BR><BR><BR><BR>
<HR id=ecxecxstopSpelling>
From: hosking@cs.purdue.edu<BR>Date: Fri, 22 Jan 2010 09:49:28 -0500<BR>To: jay.krell@cornell.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] thoughts on NT386/LONGINT?<BR><BR>
<DIV>That's a very good question. I suspect allocating register pairs as needed would make for a fairly difficult implementation. I would err on the side of simplicity for LONGINT code generation rather than complexity. You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers. i.e., worry about correctness first and performance later.</DIV>
<DIV><BR></DIV>
<DIV>
<DIV>On 22 Jan 2010, at 07:39, Jay K wrote:</DIV><BR class=ecxecxecxApple-interchange-newline>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxecxecxhmmessage>Anyone have any thoughts on how to implement LONGINT on NT386?<BR> <BR><BR>The code is setup to do pretty good constant folding and enregistration.<BR> <BR><BR>I did the work so that constant folding should work for LONGINT.<BR> <BR><BR>However I think doing good enregistration is maybe still<BR>too much work. In particular, I think every LONGINT<BR>operation will do a load, operation, store.<BR>Typical of unoptimized code, but not typical<BR>of the Modula-3/NT386 quality.</DIV></SPAN></BLOCKQUOTE>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxecxecxhmmessage><BR> <BR>In particular, there is still this notion of an "operand"<BR>that might be held in one register.<BR><BR> <BR>I'd have to make it a register pair, or array of registers,<BR>or invent "psuedo registers" that are register pairs.<BR>An array of registers is the obvious best choice, but<BR>none of these are a small change.<BR> <BR><BR>96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,<BR>would probably all have to change.<BR>63 in Codex86.m3 unsure.<BR> It is the lowest level and might need to only deal with single<BR> registers.<BR><BR> <BR>Returning LONGINT from a function also needs separate attention.<BR>Maybe I really should go ahead and use an array of registers?<BR> <BR><BR> - Jay<BR><BR></DIV></SPAN></BLOCKQUOTE></DIV><BR></DIV> </body>
</html>