----- Ursprüngliche Nachricht -----
Von: Peter Bigot
Gesendet am: 31 Mrz 2011 15:00:15

> > > mspgcc puts the frame pointer in r4 when it's used, but gcc eliminates
> > > the use by substituting references based on sp where possible.
> > And this badly corrupts the code if you
> > 1) try to save the status register, clear GIE, do somethign that includes
> > access to
> > local variables and then restore SR. Between the push and pop,
> > all local variables are accessed wrong.

> So don't save the status register with asm push/pop.  Store it in a stack
> local variable that you've declared. 

This does not allow nesting of critical sections. Unless you build
a second software stack.

>  asm statements lead people to try
> things---like what you describe---that end up conflicting with what the
> compiler does.

Yes, that's why the asm instruction contains parts to tell teh compiler
that certain registers are clobbered during the asm or such things.
However, in case of frame and stack pointer, the compiler ignores this.
(Don't think I didn't try), while it works well for all 'normal' registers.


> > 2) have a function with parameters passed on stack and local
> > variables that won't fit into registers completely. Then everything
> > is messed-up. At least on mspgcc3 up to the latest version.
> > (Workaround: don't do such functions)

> Irrelevant in uniarch where these things do work, and if they don't it's a
> bug that needs to be fixed in the compiler.  Make sure you use "task"
> instead of "naked", though, if you still have some need to muck with the
> prologue and epilogue.  My expectation is that should be extremely rare,
> probably limited to people who are writing context switch routines.

No, simple plain code. It only happened with optimization on, and
it was reproducable with simple functions without any fancy coding. 
Just parameters on the stack (e.g. three long parameters), some local
variables, and the code produces nonsense. IIRC, it was topic of a
thread in this list some time ago.
It has nothing to do with 'task' or 'naked'. Just with the 'optimization'
of R4 to SP as frame pointer.

> All this should be supported by the compiler either automatically or with
> intrinsics.  As long as that works---or even if it doesn't---I'm not seeing
> any reason to preserve the existing semantics of the frame pointer.

Well, 'should' is always the keyword :)

JMGross


------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Reply via email to