On 6/29/2014 8:22 PM, Manu via Digitalmars-d wrote:
Well, here's the thing then. Consider that 'real' is only actually supported on only a single (long deprecated!) architecture.
It's news to me that x86, x86-64, etc., are deprecated, despite being used to run pretty much all desktops and laptops and even servers. The 80 bit reals are also part of the C ABI for Linux, OSX, and FreeBSD, 32 and 64 bit.
I think it's reasonable to see that 'real' is not actually an fp type.
I find that a bizarre statement.
It's more like an auxiliary type, which just happens to be supported via a completely different (legacy) set of registers on x64 (most arch's don't support it at all).
The SIMD registers are also a "completely different set of registers".
In x64's case, it is deprecated for over a decade now, and may be removed from the hardware at some unknown time. The moment that x64 processors decide to stop supporting 32bit code, the x87 will go away, and those opcodes will likely be emulated or microcoded. Interacting real<->float/double means register swapping through memory. It should be treated the same as float<->simd; they are distinct (on most arch's).
Since they are part of the 64 bit C ABI, that would seem to be in the category of "nevah hoppen".
It's the same situation with SIMD; on x64, the SIMD unit and the FPU are the same unit, but I don't think it's reasonable to design all the API's around that assumption. Most processors separate the SIMD unit from the FPU, and the language decisions reflect that. We can't make the language treat SIMD just like an FPU extensions on account of just one single architecture... although in that case, the argument would be even more compelling since x64 is actually current and active.
Intel has yet to remove any SIMD instructions.
