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

[Tony Hosking]

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/20100206/bd7844f7/attachment-0002.html>