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

[Paul Schlie]

> From: Joerg Wunsch <address@hidden>
>> 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.

- didn't mean to necessarily "favor" one over the other; but acknowledge
  any interaction should be documented. (but note that it's not clear
  to me that there need be an incompatibility between the two?)

>>   (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.
  
- simply noting that as things presently stand, there is also an
  interdependence between global register variable use, and the
  necessity to develop more register efficient 64-bit md instruction
  specifications if these things are ever to work simultaneously.

>>> 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?

- not really, a C source library need just be re-compiled, not re-written.
  (where the tradeoff is likely some efficiency, which may be alternatively
  addressed by improving the quality of avr code generations for example)

>> 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.

- no need to be sorry, just observing the above.

> 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,

- sounds like that may be worth further consideration.

>                                  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).

- although somewhat messier, I don't believe there to be any use or
  distribution complications with the use of newlib, if it had merit.

>                                 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 don't personally see a major problem with the way things are now,
  as regardless of which file info is stored in, it will still need to
  be corrected on a device by device basis as bugs may be discovered?
  (and aggregating some of this data on a group basis as done now,
  would seem to be less error prone than not?)

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

- I'd like to see it get down to 0 as quickly as possible (presumably,
  because it contains no remaining bugs).

> 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.''

- fundamentally, an asm coded C support library assuming a fixed abi, isn't
  a good idea, it should be expected to break as it becomes more clear how
  to more efficiently define gcc's avr machine description; and under no
  circumstances should it's existence be argued as the basis of maintaining
  an old abi if it impedes the refinement of gcc's generalized avr target
  code generation generation and/or performance.