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

[Theodore A. Roth]

I can't comment on every thing here since I don't quite understand it
all...

On Fri, 19 Nov 2004, Paul Schlie wrote:

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

Is this really useful? If you need to know the size and signed-ness of
variable, you should just be using the [u]int{8,16,32,64}_t types. Those
are defined by the C standard and gauranteed to work on all
platforms/arches.

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

Some people have found 64-bit ints useful. If you don't use them, it
costs you nothing in your app.

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

I'm a bit ignorant here: would this diverge from IEEE floats?

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

See above.

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

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden