On 18 November 2012 12:41, Manu <turkey...@gmail.com> wrote: > On 18 November 2012 14:13, Dmitry Olshansky <dmitry.o...@gmail.com> wrote: >> >> 11/18/2012 3:21 PM, Manu пишет: >>> >>> I've often wondered about having an official 'half' type. >>> It's very common in rendering/image processing, supported by most video >>> cards (so compression routines interacting with this type are common), >>> and it's also supported in hardware by some cpu's. >>> >>> ARM for instance supports 'half's in hardware, and GCC has an __fp16 >>> type which would map nicely if D supported the type in the front end. >>> >>> The alternative us to use ushort everywhere, which is awkward, because >>> it is neither unsigned, nor is it an integer, and it's not typesafe >>> (allows direct assignment to ints and stuff)... >>> It would be nice if: cast(half)someFloat would yield the proper value, >>> even if it is performed in software in most architectures, it could be >>> mapped to hardware for those that do it. >> >> >> I guess half(someFloat) will do for conversion. > > > How do you define 'will do'? It still behaves differently than proper types. > someFloat = someDouble without a cast is a compile error, likewise should be > true in this case, but I don't know how to do that. > someHalf = someFloat should require an explicit cast too, or use a 1.0h > literal ;) > >>> It could be done in a library, but then GCC couldn't map it properly to >>> the hardware type, and since D has no way to describe implicit casts >>> (that I know of?) it becomes awkward to use. >> >> >> alias this should work. >> Just tried it, works wonders: >> >> import std.math; >> >> struct half{ >> ushort data; //this one should be __fp16 where it works >> //other overloaded ops, etc. >> >> alias getFloat this; >> //***only for the purpose of showing implicit conversion *** >> float getFloat(){ return data * 0.1; } >> } >> >> void main(){ >> float x = half(12); >> assert(abs(x - 1.2) < 1e-6); >> >> } > > > Yup, that solves the up-cast problem perfectly! I didn't think of that > trick. > >>> someFloat = someHalf <- doesn't work, because a cast operator expects an >>> explicit cast, even though this is a lossless conversion and should be >>> exactly the same as someDouble = someFloat. >>> >>> Thoughts? >> >> >> Everything but hardware support is doable as is. I'm not sure if it's >> possible and/or feasible to make _efficient_ wrapper type that uses hardware >> support. >> >> The easiest path seems to be: >> - convince GDC to add __fp16 type as an extension that maps to GCC's one >> - use it on GDC, and fallback to emulation on DMD >> >> That being said I personally have no objections to add half type to >> built-ins in DMD. > > > I'm sure it's already accessible in GDC, but it's not portable unless it > gets a proper name in the front end. > The point would be to name the type, add the conversion functions to > druntime for fallback/portability, and a literal 1.0h would be handy to > identify the type to templates.
The two modes guaranteed to exist in GDC are single and double (reals could be a vagarity of sizes). Half I believe is only defined (internally) for ARM. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';