[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