[C++11] Reclaiming fixed-point suffixes for user-defined literals.

[David Brown]

On 08/11/2011 15:24, Hans-Peter Nilsson wrote:
> (Not CC:ing the quoted newsgroup, sorry.)
>
> On Tue, 8 Nov 2011, David Brown wrote:
>> If the compiler can generate fractional arithmetic code directly from such
>> expressions, then it is indeed a good step towards implementing such types as
>> a pure C++ class without needing to use compiler extensions.
>
> Right, but don't hold your breath.  Getting a native type in
> place for all targets seems to be more important.

Agreed.

>
>> The guts of gcc already know about types like "signed short _Fract", and can
>> handle them well (at least for some targets).
>
> By default too few to matter, it seems, MIPS and ARM.  Not even
> sure any of it works elsewhere.  Missing from the AVR port too
> (yes, that's you cue. :)  For acceptance, IMHO better get it
> working universally by open-coding the implementation without
> requiring --enable-* options.
>

Agreed.

I had actually thought the fixed point types were part of the 
up-and-coming C1x standard, but it seems they are not - they are just 
part of a draft "TR 18037".  Maybe that will make it into the C 
standards eventually.

I had been thinking that since they are in a C standard, it's only a 
matter of time before gcc supports them on all targets.

>>   It is always easier for the
>> compiler when it has more knowledge than if it has to guess based on code
>> patterns - so using "signed short _Fract" means it can see the real type early
>> in the process rather than in a later "combine" pass.
>
> Certainly.
>
>>> Looks like a pretty typical Q7 (or Q1.7) multiplication to me
>>> unless I miss something...  Would be a nice thing to have those
>>> Q1.<N-1>   formats as native GCC-extension types including
>>> vectorized versions.  No, not planning it.
>>>
>>
>> Yes, it is Q1.7 multiplication.  And there is already a type for it in C,
>> though gcc doesn't (yet) support it for all targets (I haven't checked recent
>> versions).
>
> I checked my tree above (up-to-date modulo a few hours).
>
>>   It is "signed short _Fract" from TR 18037.
>> <http://gcc.gnu.org/onlinedocs/gcc/Fixed_002dPoint.html>
>
> There you go!  I thought it had other semantics.  Actually the
> type would be target-dependent, but all the targets (both ARM
> and MIPS :) have it that way.  Somewhat awkward: the intuitive
> choice would have been "signed char _Fract" IMHO.
>

I can understand why you say that - but from my point of view, "signed 
char _Fract" is as horrible as "signed short _Fract".  What is really 
needed is an equivalent to "stdint.h" to give specific, fixed sizes to 
these - then programmers can rely on them.  Something like

typedef signed short _Fract fract1q7;
typedef unsigned short _Fract ufract0q7;

Otherwise there will be more madness in the ranks of embedded programmers...


Actually, I suspect that the reality of the situation is that the time 
for these types has gone.  They will be useful to a few, but people will 
continue to use their ugly, type-unsafe, macro-ridden, target-specific 
fixed point libraries - either written themselves or by the manufacturer 
of the target chip.  Steadily more chips support single-precision 
floating point in hardware, making fixed point redundant for many uses. 
  I still think it would be nice to see full support in gcc - both for C 
and C++.  But I think that by the time they are well supported on a 
range of compilers and targets, and therefore useful for general 
portable embedded code, most code that could use them will use floating 
point in stead.


> brgds, H-P
>