On 30 June 2014 14:15, Walter Bright via Digitalmars-d <[email protected]> wrote: > 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.
x86_64 and x86 are different architectures, and they have very different ABI's. Nobody is manufacturing x86 (exclusive) cpu's. Current x86_64 cpu's maintain a backwards compatibility mode, but that's not a part of the x86-64 spec, and may go away when x86_64 is deemed sufficiently pervasive and x86 sufficiently redundant. >> I think it's reasonable to see that 'real' is not actually an fp type. > > > I find that a bizarre statement. Well, it's not an fp type as implemented by the standard fp architecture of any cpu except x86, which is becoming less relevant with each passing day. >> 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". Correct, so they are deliberately treated separately. I argued for strong separation between simd and float, and you agreed. >> 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". Not in windows. You say they are in linux? I don't know. "Intel started discouraging the use of x87 with the introduction of the P4 in late 2000. AMD deprecated x87 since the K8 in 2003, as x86-64 is defined with SSE2 support; VIA’s C7 has supported SSE2 since 2005. In 64-bit versions of Windows, x87 is deprecated for user-mode, and prohibited entirely in kernel-mode." How do you distinguish x87 double and xmm double in C? The only way I know to access x87 is with inline asm. >> 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. Huh? I think you misunderstood my point. I'm saying that fpu/simd units are distinct, and they are distanced by the type system in order to respect that separation.
