half and quad

[Nathan Reed]

Bill Baxter wrote:
> Anders F Björklund wrote:
>> Olifant wrote:
>>
>>> The keyword "cent" is reserved for 128-bit integers. Could "half" and 
>>> "quad" be reserved for respectively 16-bit and 128-bit floating point 
>>> numbers?
>>
>> I don't think there is any hope for quad or cent, until they're
>> implemented on standard processors... (i.e ones that run Windows)
>>
>> But I do have a port of "half" (from OpenEXR) kicking around here
>> somewhere, it's basically using ushort and converts over to float.
>>
>> See http://www.digitalmars.com/d/archives/digitalmars/D/31899.html
> 
> I wonder if 'half' is really worth it though.  It seems like more of a 
> temporary stop-gap measure to deal with memory and throughput problems 
> on a GPU.  In 5 years maybe people will look at 'half' and laugh about 
> how primitive the architectures were back in the 00's.  Also since D 
> isn't going to run on a GPU any time soon, and CPUs aren't going to 
> implement 'half' any time soon (AFAIK), maybe this doesn't make too much 
> sense.
> 
> 'quad' on the other hand, seems at least as likely to have a future as 
> 'cent' does, so seems reasonable to reserve it to me.
> 
> --bb

More useful than these, I suspect, would be some language support for 
vectorized types, e.g. a 128 bit value consisting of four 32-bit floats, 
which you can then use to write SIMD code.

Of course, this can be done in the current language using structs, and 
operator overloading with some asm blocks to actually call the 
vectorized instructions for your specific architecture (or fall back to 
serial computation on architectures without SIMD support).  But it would 
be much nicer if the compiler's back-end could do that for us, 
especially since it could then do proper register allocation and so forth.

Thanks,
Nathan Reed