(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
