avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global


From: Paul Schlie
Subject: Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers
Date: Mon, 07 Feb 2005 12:48:02 -0500
User-agent: Microsoft-Entourage/11.1.0.040913

> From: Joerg Wunsch <address@hidden>>
>> As Paul Schlie wrote:
>> - almost, the compiler can/will avoid using compile-time declared
>> reserved global registers; asm routines can't, therefore must
>> restrict their their use in anticipation of the possibility,
>> regardless if they're used or not. (as in fact the ABI is actually
>> somewhat soft, not hard)
> 
> This cannot work when linking against *any* pre-compiled object from
> the library, as these files always risk to use one of the registers
> the application might use as a fixed register variable.

- which is why if one wants to reserve a global they compile both with
  the same switches, and the C code's register usage is automatically
  taken care of, as since avr apps don't have shared runtime linked
  libraries as part of the os, no problem takes all of a minute and your
  done. (but the asm code needs to avoid their use without any assistance
  from the compiler, as register allocation is done manually in the code.)

> I don't see
> where it would make the slightest difference whether these library
> objects result from C or asm source files.  Both source files follow
> exactly the same ABI, and there's exactly the same policy which
> registers need to be saved, and which don't.  If the compiler needs
> more registers in C code than it could use freely,

- nope, that's what the address@hidden global registers switch does,
  it disables it from being allocated, and not supposed to be touched
  by anything other than the routines that know about it.

>                                               it needs to push
> them onto the stack, the same is implemented in the asm files.

- no, its excluded from allocation all together, it's state must be
  static, and always be interrupt safe, therefore left alone, that's
  it's purpose, as otherwise one could simply define a global static
  variable in C.
  
> If you don't link against any external object files, no need to worry
> at all, as you don't have any external files it must not bother you
> whether you don't have files compiled from C nor from assembler code.
> ;-)

- yes but what's your point with respect to the likely necessity of c
  library routine when compiling c code?







reply via email to

[Prev in Thread] Current Thread [Next in Thread]