[M3commit] CVS Update: cm3

[Jay K]

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/75c6638f/attachment-0002.html>