On Thu, Mar 31, 2011 at 6:43 AM, JMGross <msp...@grossibaer.de> wrote:
> > ----- Ursprüngliche Nachricht ----- > Von: Peter Bigot > Gesendet am: 30 Mrz 2011 18:30:31 > > > SF 3260589 proposes that uniarch mspgcc change the value of r4 when used > as > > a frame pointer to be value [A] described below. Please provide comments > on > > this change. This is probably only relevant to you if you believe you > need > > to decode frame contents in your code. > > Which is true for functions like printf which use stack parameters (or even > forward them > to other functions, like the different printf variants do). > No; there you should be using stdarg, which the compiler handles for you. I'm looking for people who use asm statements referring to r4 or the old GET_FRAME_ADDR* macros, or who want to use __builtin_frame_address to do something tricky in their code. > > [A] and [B] are different for interrupts. > yes, but then, MSPGCC usually knows that it is in an interrupt function. > And for modifying the saved SR there's already an intrinsic. > > > 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. uniarch provides builtins to read and write the status register without using the IRQ solution, but you could always do this with asm statements too. asm statements lead people to try things---like what you describe---that end up conflicting with what the compiler does. Of course, that assumes you aren't using a "naked" function which doesn't support local variables. Then you're SOL, which is why I've cleaned that up in uniarch so you can use "task" instead. > (Workaround: I use a global counter that is incremented and decremented by > a macro surrounding the critical section, and only set GIE again if the > counter > reaches zero. Any better ideas?) 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. 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. > > 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 >
------------------------------------------------------------------------------ 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
