This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]