[M3commit] CVS Update: cm3
Jay K
jay.krell at cornell.edu
Sun Feb 7 08:33:28 CET 2010
Hm. I guess it would be more like:
push 1
push 3
mov ecx, [esp+4]
mov eax, [esp+8]
add eax, ecx
mov [esp+4], eax
add esp,4
mov eax, [esp + 4]
mov foo, eax
add esp,4
and function calling isn't so hard.
imagine the function int add(int a, int b).
It'd go:
push/eval a
push/eval b
mov eax, [esp + 4]
push eax
mov eax, [esp + 8]
push eax
call add
add esp,16
That is, you would:
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)
2) As you build up the parameters, you'd maintain an offset to adjust virtual stack references by
However, I still think you'd have to change all this for 32bit types as well, somewhat of a "rewrite" of the NT386 backend.
(Not that I haven't changed it a bunch now to deal with types that don't fit in a single register.)
You can't just do it for 64bit types. I think.
- Jay
From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; jkrell at elego.de
Date: Sun, 7 Feb 2010 06:56:39 +0000
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3
The generated code is simple.
The "problem" is that the "virtual stack" is used for constant folding too.
Surely it is faster, much smaller, to say:
mov foo, 3
than
push 1
push 2
pop eax
pop ecx
add eax, ecx
mov foo, eax
tempting though.
Really, a lot of what the NT386 backend does is target-independent and could be
moved either to the frontend or an in-between "cg" layer that is always present.
It also presents a problem for calling functions.
You can't trivially combine the stacks and still call functions.
Evaluation of the parameters and actually passing them on the stack
gets confused. At least in my head.
Maybe it isn't so hard.
- Jay
> From: hosking at cs.purdue.edu
> Date: Sat, 6 Feb 2010 13:15:37 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
> 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... ;-)
>
> 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.
>
>
> On 6 Feb 2010, at 17:19, Jay Krell wrote:
>
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/02/06 17:19:41
> >
> > Modified files:
> > cm3/m3-sys/m3back/src/: M3x86.m3
> >
> > Log message:
> > 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100207/7fe2c5ef/attachment-0002.html>
More information about the M3commit
mailing list