On 11/18/12 16:32, Manu wrote: > On 18 November 2012 16:33, Artur Skawina <art.08...@gmail.com > <mailto:art.08...@gmail.com>> wrote: > > On 11/18/12 13:58, Manu wrote: > > On 18 November 2012 14:51, Artur Skawina <art.08...@gmail.com > <mailto:art.08...@gmail.com> <mailto:art.08...@gmail.com > <mailto:art.08...@gmail.com>>> wrote: > > > > On 11/18/12 12:21, Manu wrote: > > > 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. > > > > > > 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. > > > 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? > > > > version (GNU) alias half = @gcc[mode(HF)] float; > > > > But of course this won't work right now, cause that kind of type > attributes > > aren't supported yet. 'pragma' can't be used on types either > (otherwise > > something like "alias half = pragma(attribute, mode("HF")) float;" > could be > > made to work). > > > > And - yes - the /proper/ way would be eg > > > > alias half = @core[size=2] float; > > // or '@core.size(2)' or any other syntax. > > > > For now, a struct + alias-this-getter might be enough, for a s/w > implementation. > > > > > > Yes, that's what I and everyone else does, but that's not the point of > the topic... > > I think it's a fundamental datatype, and it deserves the same > casting/type conversion/type safety rules as ints and floats, and it would > also be useful to map it to hardware (which GDC can easily do). > > All of the 'half' definitions above would give you a 'fundamental' > datatype -- > -- there is no reason to make it a /language/-defined type. The work > required > to implement things like implicit conversions can be done more > generically; > right now the problem is the lack of a way to define such types. > > alias fp24 = @core[exp=7, mant=16] float; // It's only a matter of > time until > // someone asks for it&co... > > Also, *every* user- (or in this case more likely lib-) defined data type > deserves > the same control over casting and conversions as built-in types. No, D > doesn't > have that and yes - it is a problem. > > I actually think these types /should/ be done as structs, but > a) it isn't currently possible (also for reasons other than the above > mentioned ones) > and > b) such aliases would /still/ be useful for mapping to "magic" > compiler-supported > h/w types. > > > I don't necessarily disagree, but you can take that logic and run with it as > far as you like. > long can easily be implemented as a struct with 2 ints, why bother with a > builtin type for that? Any answer or counter argument you can possibly give > me applies equally to half.
alias long = @core[size(int.sizeof*2)] int; I'm saying that there's no point in defining '__fp16' when '@core[size(2)] float' will also do the job. Just as "string" is not a built-in type in D. Now, this can't be done today, so until it /is/ possible, the struct solution is an option. No, it isn't perfect. But is it unusable? (honest question) Would exposing the raw __fp16 type in GDC really be a better long-term solution? [Of course that 'long' D definition is not a good one, but that's another topic] > D needs quite a few tweaks to be able to create a user defined type that is > capable of performing like a builtin type. The main limiters are custom > implicit conversion, and literal syntax definition, I know, and I'm not sure I'd use the words 'a few tweaks". :) > but it also seems really nasty to hook a library, suppress it, and alias it > to a hardware type in the case of GDC for instance. Who's to say the GDC type > behaves in exactly the same way as those defined by the D front end? The types MUST be compatible - this is also true for any "built-in" type. Any operation that isn't portable, compiler- or h/w-wise, must be either disallowed, emulated or specced as undefined behavior. Which is actually part of the reason why I'd like it wrapped in a struct - that way the compiler doesn't have to handle all the special cases and the *user* can choose between "raw" (hw-supported) versions and more generic ones that may fallback to s/w on platforms that require that. > Point is, this type should behave in EXACTLY the same way as expected when > dealing with builtin float types, it's not just some user type, it's an > established, industry-recognised precision of float. In reality it's probably > significantly easier to define it wherever the others are defined rather than > in a new library all on its own. > I'd also argue that 'half' is far more valuable to modern computing than > 'real'. > > Anyway, the point is, we all already use libraries for half, offering library > solutions misses the point of the topic. > The question I raised is: SHOULD half be a builtin type? Well, no - it shouldn't. For a simple reason - it's not universally available. And the people using it won't usually be ok with pure s/w emulation. But, yes - it should be accessible on platforms that do support it. artur
