<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Hm. I guess it would be more like:<BR>
push 1 <BR>
push 3 <BR>
mov ecx, [esp+4] <BR> mov eax, [esp+8] <BR>
add eax, ecx <BR>
mov [esp+4], eax <BR>
add esp,4<BR>
mov eax, [esp + 4] <BR>
mov foo, eax <BR>
add esp,4 <BR>
<BR>
and function calling isn't so hard.<BR>
imagine the function int add(int a, int b).<BR>
<BR>
It'd go:<BR>
push/eval a <BR>
push/eval b <BR>
mov eax, [esp + 4]<BR>
push eax<BR>
mov eax, [esp + 8]<BR>
push eax <BR>
call add<BR>
add esp,16<BR>
<BR>
<BR>
That is, you would:<BR>
1) not "discard" from the "virtual stack" (merged with the machine stack) until after the call, cleaning up both it and the machine stack (for __cdecl) <BR>
2) As you build up the parameters, you'd maintain an offset to adjust virtual stack references by <BR>
<BR>
However, I still think you'd have to change all this for 32bit types as well, somewhat of a "rewrite" of the NT386 backend.<BR>
(Not that I haven't changed it a bunch now to deal with types that don't fit in a single register.)<BR>
You can't just do it for 64bit types. I think.<BR>
<BR>
- Jay<BR> <BR>
<HR id=stopSpelling>
From: jay.krell@cornell.edu<BR>To: hosking@cs.purdue.edu; jkrell@elego.de<BR>Date: Sun, 7 Feb 2010 06:56:39 +0000<BR>CC: m3commit@elegosoft.com<BR>Subject: Re: [M3commit] CVS Update: cm3<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
The generated code is simple.<BR>The "problem" is that the "virtual stack" is used for constant folding too.<BR>Surely it is faster, much smaller, to say:<BR> mov foo, 3<BR> <BR>than <BR> push 1 <BR> push 2 <BR> pop eax <BR> pop ecx <BR> add eax, ecx <BR> mov foo, eax <BR> <BR>tempting though.<BR> <BR>Really, a lot of what the NT386 backend does is target-independent and could be<BR>moved either to the frontend or an in-between "cg" layer that is always present.<BR> <BR>It also presents a problem for calling functions.<BR>You can't trivially combine the stacks and still call functions.<BR>Evaluation of the parameters and actually passing them on the stack<BR>gets confused. At least in my head.<BR>Maybe it isn't so hard.<BR> <BR> <BR> - Jay<BR><BR> <BR>> From: hosking@cs.purdue.edu<BR>> Date: Sat, 6 Feb 2010 13:15:37 -0500<BR>> To: jkrell@elego.de<BR>> CC: m3commit@elegosoft.com<BR>> Subject: Re: [M3commit] CVS Update: cm3<BR>> <BR>> Realise also that on modern x86 machines the stack ends up in internal registers anyway. x86 processors these days don't actually execute x86 instructions... ;-)<BR>> <BR>> So, it may not be such a performance loss simply to push/pop on the machine stack. Generating simple code is probably better than more complicated code, because the hardware will still do a good job of executing it.<BR>> <BR>> <BR>> On 6 Feb 2010, at 17:19, Jay Krell wrote:<BR>> <BR>> > CVSROOT: /usr/cvs<BR>> > Changes by: jkrell@birch. 10/02/06 17:19:41<BR>> > <BR>> > Modified files:<BR>> > cm3/m3-sys/m3back/src/: M3x86.m3 <BR>> > <BR>> > Log message:<BR>> > save all registers that are in use to memory (temporaries on the stack) around int64 helper functions; this is not ideal though in practise, the few times I have looked, it isn't many registers, like one; it is probably reasonable to alter the frontend to generate the code in a different order?<BR>> <BR> </body>
</html>