[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 16:28:04 -0500 |
User-agent: |
Microsoft-Entourage/11.1.0.040913 |
> From: Joerg Wunsch <address@hidden>
>> As Paul Schlie wrote:
>> - yes and no, asm routines would need to manually exclude their use,
>> compiled code would automatically use them or not depending on if
>> the registers were declared as being reserved or not at compile
>> time.
>
> But only if you recompile the entire library together with your own
> sources. I haven't heard of anyone else but you who even considered
> that a useful feature.
- has nothing to do with tasteful, it's simply necessary if the result
is desired. (would be pleased if an alternative exited, but doesn't
as far as I can tell, short of modifying the target's header file,
and recompiling the compiler, which would still then necessitate
the asm routines not to touch the registers being reserved otherwise)
>>> But again, no additional problems for asm sources, they just had
>>> to follow the very same ABI only.
>
>> - yes. (as long as it defines a hole in the caller-saved register
>> set which asm routines were excluded from being able to use).
>
> I didn't make an exhaustive test, but so far, I think none of the asm
> code ever uses r2 through r5, so these would be fine candidates (but
> only if you also recompile all the C library functions). It's kinda
> recommended practice to start allocating global register variables at
> r2 anyway, as the compiler tends to allocate registers ``top down''.
- those are callee (call) saved (globals), they can't be used, it must
be registers designated as caller-saved (i.e. The local ones that aren't
saved restored by set/longjump) r18-r27, which I know are generally
precious, but they're the only ones which would work. (implying that if
it's a feature that you want to support, likely two of these (I'd
guess r18/r19 are less painful to loose than than r24-r27) couldn't
be used by asm support library routines (which I know is likely more
painful than you may have been expecting). (although C library routines
wouldn't be excluded if not designated as being reserved)
> As you're the only one requesting this, I wouldn't want to make this
> a formal committment to the ABI though.
- actually there was a bug filed against winavr I believe, but it's
not a compiler problem.
> Of course, back to the subject, *if* you recompile the entire library
> with your own compiler switch preventing the compiler from ever using
> some register, then just go ahead, and also edit setjmp.S accordingly.
> That should be a trivial job for anyone who considers linking against
> their own specific compilation of the library. By this, you've simply
> chosen to run your own ABI which might be fine for you, even though
> it's nothing the majority of the users would consider useful -- after
> all, that's why you've got the source code.
- although further complicated by the fact that the asm coded c library
routines which use those same registers would also need to be recoded,
again. I won't worry about it, just tried to point out the solution
to the problem if it were a desired feature, and note that it's not
a compiler problem, although could be made less painful to support if
the compiler were tweaked to enable reserved registers to be visible
to asm routines somehow (or something along those lines).
- 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/06
- 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 <=
- 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, 2005/02/07
- Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers, E. Weddington, 2005/02/07