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

[Joerg Wunsch]

As Paul Schlie wrote:

> - actually, global register variables are likely typically more
> useful than setjump/longjump typically is, as being able to specify
> global registers which the compiler leaves alone, is critical to
> enabling the development of small fast interrupt routings,
> impossible otherwise;

Quite possible, but unrelated.  It only means you cannot mix both,
globally assigned registers, and setjmp/longjmp.

Still, as setjmp/longjmp are standard C features, they must not break
for standard C code, otherwise they're useless.  If we cannot get
both, setjmp/longjmp *and* globally assigned registers to work
simultaneously, I'm going to document the incompatibility in favor of
at least allowing compliant programs to work correctly.

>   (and indirectly another reason that unless someone can figure out
>   how to make 64-bit operations significantly more register
>   efficient, 64 bit type support should likely be intentionally
>   removed, as otherwise the definition of a even a few global
>   registers would prevent the compiler from being able to allocate
>   enough registers to execute basic 64-bit operations.)

IAR even ships with 64-bit floating point support.

> > There have been rumours though (by Ted Roth) that GCC 4.0 might
> > break the ABI which would force us to ship an avr-libc 2.x version
> > for it.

> - possibly a valid reason to consider newlib,

Apples and oranges?

> and alternatively investing effort in improving avr target code
> generation, rather than attempting to develop/maintain what may
> become a version specific asm based C library?

Sorry.  I'm still not convinced that newlib is the right thing for us.
Their release schedule tends to be settled for one release per year
(or less), which is not enough for us.  So we'd have to maintain the
AVR-specific packaging etc. outside newlib anyway, but in that case, I
cannot see any benefit from moving to newlib.  We could still cvs
import interesting pieces of code from newlib, and just carry it along
with the AVR library distribution, albeit I'm currently reluctant to
do this, as this would completely void Eric's tremendous effort to
unify the copyright statement for avr-libc (which btw. was an item
requested by the user base).  OK, we could import those parts that
carry a plain BSD license (as this *is* the current avr-libc license),
but then I don't need newlib at all, I can directly cvs import that
code from 4.4BSD if I want.  (I've already done this in the past, our
random() & Co. implementation is based on FreeBSD's code, and
incidentally, it seems to do a lot better in terms of randomness than
some competitive products. ;-)

In order to allow for the option of frequent updates, I'd be really
grateful if we could break out the strict MCU-type dependency from
GCC's code itself into something like the GCC specs file (so GCC only
needs to be updated for new AVR device classes, not for each single
MCU type), likewise for binutils (i.e. basically for gas).

I'd rather have 2...3 avr-libc releases per year, maybe even 4.

I'd also like to hear which of the reentrant functions the RTEMS folks
are so sorely missing, so we could see which options we have to
provide them.  So far, I haven't seen a single request for one, other
than ``You should really move to newlib.''

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)