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
