On 11/18/12 13:58, Manu wrote:
> On 18 November 2012 14:51, Artur Skawina <[email protected]
> <mailto:[email protected]>> 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.
artur
