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

[Paul Schlie]

From: "Theodore A. Roth" <address@hidden>
> 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.

- "really useful?", not if (as you point out) you choose to explicitly
  declare the type-sizes you desire; but nor does it seem really useful to
  not enable the generic specification of short to be smaller than int,
  which in avr's default case would enable short to be the smallest generic
  signed int, which tends to be helpful if char defaults to unsigned, as
  typically desirable, as otherwise char operations tend to want to be
  promoted to int if mixed with unsigned character operands, and then
  need to rely on optimizations to de-promote them back, which GCC is
  occasionally misses the opportunity to do. So overall, basically agree
  that it's not strictly necessary, but seems generally more flexible
  and consistent to do so. (suspect it's mostly an aesthetic thing).

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

Yes, but as IEEE float semantics are basically inappropriate for embedded
signal processing and control algorithm use, which is why all floating point
signal processing architectures have adopted the use of floating point
semantics which don't generate and propagate the exception value behavior
which IEEE defines, and simply yield vanilla values for all computations,
although may only be as accurate as the specified precision allows. Where
infinities and nan's never require special handing, which 99.99 percent of
code never tends to handle properly, if at all), so thought it may simpler
and most useful if the floating point behavior for avr were defined to be
more similar to that adopted for dsp's than not? (not to mentions speeding
things up would likely help more than hurt in most cases, although at the
expense of some IEEE runtime behaviors. Another one of which is rounding
as maintaining full compliance is also expensive, and often typically
doubles the cost of floating-point arithmetic, with little arguable benefit,
as similar desired behavior can be obtained much less expensively.)

Thoughts?