On 18 November 2012 14:13, Dmitry Olshansky <span dir="ltr"><<a href="mailto:dmitry.olsh@gmail.com" target="_blank">dmitry.olsh@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
11/18/2012 3:21 PM, Manu пишет:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
I've often wondered about having an official 'half' type.<br>
It's very common in rendering/image processing, supported by most video<br>
cards (so compression routines interacting with this type are common),<br>
and it's also supported in hardware by some cpu's.<br>
<br>
ARM for instance supports 'half's in hardware, and GCC has an __fp16<br>
type which would map nicely if D supported the type in the front end.<br>
<br></div><div class="im">
The alternative us to use ushort everywhere, which is awkward, because<br>
it is neither unsigned, nor is it an integer, and it's not typesafe<br>
(allows direct assignment to ints and stuff)...<br></div><div class="im">
It would be nice if: cast(half)someFloat would yield the proper value,<br>
even if it is performed in software in most architectures, it could be<br>
mapped to hardware for those that do it.<br>
</div></blockquote>
<br>
I guess half(someFloat) will do for conversion.</blockquote><div><br></div><div>How do you define 'will do'? It still behaves differently than proper types.</div><div>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.<br>
</div><div>someHalf = someFloat should require an explicit cast too, or use a 1.0h literal ;)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It could be done in a library, but then GCC couldn't map it properly to<br>
the hardware type, and since D has no way to describe implicit casts<br>
(that I know of?) it becomes awkward to use.<br>
</blockquote>
<br></div>
alias this should work.<br>
Just tried it, works wonders:<br>
<br>
import std.math;<br>
<br>
struct half{<br>
ushort data; //this one should be __fp16 where it works<br>
//other overloaded ops, etc.<br>
<br>
alias getFloat this;<br>
//***only for the purpose of showing implicit conversion ***<br>
float getFloat(){ return data * 0.1; }<br>
}<br>
<br>
void main(){<br>
float x = half(12);<br>
assert(abs(x - 1.2) < 1e-6);<div class="im"><br>
}<br></div></blockquote><div><br></div><div>Yup, that solves the up-cast problem perfectly! I didn't think of that trick.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">someFloat = someHalf <- doesn't work, because a cast operator expects an<br>
explicit cast, even though this is a lossless conversion and should be<br>
exactly the same as someDouble = someFloat.<br>
<br>
Thoughts?<br>
</blockquote>
<br></div>
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.<br>
<br>
The easiest path seems to be:<br>
- convince GDC to add __fp16 type as an extension that maps to GCC's one<br>
- use it on GDC, and fallback to emulation on DMD<br>
<br>
That being said I personally have no objections to add half type to built-ins in DMD.</blockquote><div><br></div><div>I'm sure it's already accessible in GDC, but it's not portable unless it gets a proper name in the front end.</div>
<div>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.</div></div></div>