[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?
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, (continued)
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, Paul Schlie, 2005/02/06
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, Joerg Wunsch, 2005/02/07
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, Paul Schlie, 2005/02/07
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, Joerg Wunsch, 2005/02/07
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, Joerg Wunsch, 2005/02/07
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, Paul Schlie, 2005/02/07
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, Joerg Wunsch, 2005/02/07
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, Paul Schlie, 2005/02/07
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, E. Weddington, 2005/02/07
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, Paul Schlie, 2005/02/07
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers,
Paul Schlie <=
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, E. Weddington, 2005/02/07