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.


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

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

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

brgds, H-P


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