[avr-libc-dev] soliciting feedback/thoughts on potential value of a few gcc 4.0 tweaks.

[Paul Schlie]

Hi All, Upon having the opportunity to fool around with GCC sources a
little, it appears that there are a few things that are fairly easy to
accomplish, although may not be generally desirable for various reasons;
but was curious about the avr community's thoughts on the subject with
reference to an attempt to seek the following's inclusion into gcc 4.0:

- defining short = signed-8-bit QI mode, and default unsigned char, which
  seems more typically appropriate than not these days, which then also
  requires the elimination of the export of small-machine definition in
  avr.h to fpbit.c or a tweak to fpbit.c as it defines an exp-size structure
  variable  to be short, which would then too small to hold the exponent
  range, which should likely be fixed anyway, as a small machine likely
  requires the declaration of a wider type to hold a given fixed size range
  than a larger machine would. (although it's been pointed out it needs to
  be done in a way not to affect other targets, as does the below.)

- removing units-per-word = 4 trick to get libgcc2 to generate the desired
  fp code? Which correspondingly means tweaking libgcc2 to enable fp types
  to be defined correctly based on type-size not units-per-word definitions.

- although I personally don't see much value of 64-bit long longs on avr,
  it's been suggested that supporting them isn't harmful; by analogy,
  any interest in 64-bit doubles although their practical usefulness may
  also be somewhat questionable (and/or any interest in smaller hypothetical
  1-bit sign, 5-bit exp, 10(+1-hidden)-bit 16-bit floats, w/32-bit doubles,
  which would seem more typically useful for this class of machine, although
  not standard per-se. (including integrating support for avr's multiplier,
  and possibly to further speed things up to make fp more practically
  useful in embedded systems, drop infinities/nan/expensive-rounding-modes
  and simply saturate values upon over/underflows, just as dsp's typically
  behave, as a best approximate answer is typically more useful than an
  infinity or nan is.

- my personal preference:

   size   8-bit   16-bit 32-bit | 64-bit
          ------  ------ ------ | ------
unsigned  char                  |
  signed  short   int    long   | long-lon
  floats          float  double | long-double

And a few questions to anyone who may be reasonably familiar with avr-gcc's
present implementation:

- any insight as to if there's any value to getting libgcc2 to generate all
 utilized type-size support function variants; as unless I'm misunderstand,
 it seems to only generates them for the two largest type-sizes as presently
 defined, but as I said, I may be missing something?

- any insight as to why the compiler (3.4.3 for the sake of argument) first
  load variable into one set of registers to just then passes them to the
  function's parameter registers, as opposed to loading them there
  initially, which seems like a waste of cycles? happens for example with:

  volatile float f;
  f = f * f; // or most any other multi-byte libgcc defined function.

Thanks, -paul-