http://d.puremagic.com/issues/show_bug.cgi?id=10763



--- Comment #10 from Iain Buclaw <ibuclaw@ubuntu.com> 2013-08-19 07:44:59 PDT ---
(In reply to comment #9)
> 
> I veto any new addition that is x87 specific - or, more accurately endian specific.
> 
> Remember its:
> 
> version(BigEndian)
>   short sign_exp = (cast(ushort*)&x)[0];
> else
>   short sign_exp = (cast(ushort*)&x)[5];

Wrote a quick toy routine to paint real->ushort[real.sizeof/2] (based on backend routine that interprets a value as a vector).

--- pseudo code ---
Expression* e = RealExp(42.0L);
size_t len = native_encode_expr(e, buffer);

(gdb) p buffer
"\000\000\000\000\000\000\000\250\004@\000\000\000\000\000\000`\365f\001\000\000\000\000\300\341\377\377\377\177\000\000\000\000\000\000\00
0\000\000\000\023\340Z\000\000\000\000\000`As\001\000\000\000\000\006\000\000\000\000\000\000"


tree cst = native_interpret_array (TypeSArray(ushort, 8), buffer, len);

(gdb) p debug_tree(cst)
{[0]=0, [1]=0, [2]=0, [3]=43008, [4]=16388, [5]=0, [6]=0, [7]=0}
---


OK, lets check this output against run-time results.
---
writeln(*cast(ushort[8]*)(&x));

=> [0, 0, 0, 43008, 16388, 0, 32672, 0]


Which looks like at a first glance that the real->ushort[real.sizeof/2] conversion isn't correct... up until the point you realise that the '32672' value is just garbage in padding.


So... this might be very well doable, but will have to be *extremely* careful about it.  Also, I'm assuming that CTFE is able to get values from constant static arrays?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10763



--- Comment #11 from Iain Buclaw <ibuclaw@ubuntu.com> 2013-08-19 10:22:55 PDT ---
(In reply to comment #10)
> 
> So... this might be very well doable, but will have to be *extremely* careful about it.  Also, I'm assuming that CTFE is able to get values from constant static arrays?

Adapted code so that it does the following:

real <-> ushort[8]:
RealExp <-> VectorExp(ushort[8]) <-> ArrayLiteralExp(ushort[8])


Result?
---
ushort[8] foo(real x)
{  return *cast(ushort[8]*)(&x);
}

real bar(ushort[8] x)
{  return *cast(real*)(&x);
}

pragma(msg, foo(42.0L));
pragma(msg, bar(foo(42.0L)));

static assert(foo(42.0L) == [0,0,0,43008,16388,0,0,0]);
static assert(bar(foo(42.0L)) == 42.0L);

pragma(msg, "Success!");
---

$ gdc -c paint.d
[cast(ushort)0u, cast(ushort)0u, cast(ushort)0u, cast(ushort)43008u,
cast(ushort)16388u, cast(ushort)0u, cast(ushort)0u, cast(ushort)0u]
4.2e+1
Success!


Only downside is that it is restricted to T[x].sizeof == real.sizeof.
So real<->ulong[2] only works with 128bit reals on 64bit, but could look into
getting around that later...

Don, I think I'm ready to test trial this in GDC if you are willing to implement this in DMD?

Regards
Iain.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10763



--- Comment #12 from Iain Buclaw <ibuclaw@ubuntu.com> 2013-10-10 04:26:12 PDT ---
(In reply to comment #11)
> 
> Don, I think I'm ready to test trial this in GDC if you are willing to implement this in DMD?
> 

Added support in GDC (but no front-end support) in case you want to go down
this route.

https://github.com/D-Programming-GDC/GDC/commit/262a5bd22754e0fa8176c1cef523bde33d1559df

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------