[M3devel] front end function about a "virtual stack"

[Jay K]

 > But, there have always been calls for mod/div


Not on NT386.

 

 - Jay
 


Subject: Re: front end function about a "virtual stack"
From: hosking at cs.purdue.edu
Date: Sat, 6 Feb 2010 13:07:23 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu


The front-end does do that for known calls.  But not for arithmetic ops.  You will need to cope in the backend.  But, there have always been calls for mod/div, so I think it really comes down to the back-end needing to do the right thing.



On 6 Feb 2010, at 07:29, Jay K wrote:

Tony, can you confirm something?
It's hard to explain.
 

The NT36 backend of course maintains
a bunch of information as to which registers are in use.

 
For example, at the start of the function, it
marks all registers as not in use.
  (It always preserves all volatile registers I believe.
  Obviously it could do better. It should only
  mark non-volatile registers as in use, see
  which registers it uses in the function, and
  then only preserve/restore the nonvolatile ones
  that it uses.)

 
As well when it generates a function call it
marks them as all not in use too.
But in that case, it checks itself.
Again, it is a bit dumb -- nonvolatile registers
 would be ok to still be in use.
 

Now, all is ok.
But then, I've introduced function calls where
they weren't before -- multiply, divide, mod etc.
 

Upon generating the call to mod (for example),
I get an assertion failure, because registers
are still in use. In this case it is a nonvolatile
register, but I think that's largely luck.
 

In particular I think the location that
will be stored to after the mod is in a register.
That is reasonable.
You know..as a compiler, given:
 *(a + b) = f();

 
you might generate code to evaluate a + b first,
put it in a (non volatile) register, then call f(),
or you might call f() first.
 

A simpler approach is to call all the functions first,
so you have more easy use of registers.
 

But then imagine
 *(a + b) = (c % d);

 
is there a function call in there or not?
It depends.

 
So then my question is, like, when does the
frontend assume a "stack based code generator"'s
stack can/should/will be empty?
Does it endeavor to make it so?
 

That is, is it very reasonable to for the NT386
backend to assume its stack is empty when
it calls a function, because the front end
colludes to make it so, but then
the front end doesn't do similar for things
like multiply/divide?
 

I can deal with this pretty easily either way.
Around function calls I introduce that weren't
previously there I can save whatever volatile
registers are in use.
 

But I'd like to understand.
 

Thanks,
 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100207/15b8f3a4/attachment-0002.html>