Always false float comparisons

[Era Scarecrow via Digitalmars-d]

On Wednesday, 18 May 2016 at 07:56:58 UTC, Ethan Watson wrote:
> Not in the standards, no. But older gaming hardware was never 
> known to be standards-conformant.
>
> As it turns out, the original hardware manuals can be found on 
> the internet.

  Hmmm... I can't help but look at this and think about x86 
instructions of old, and how they aren't utilized usually fully 
or properly in language specs to take advantage of them, like the 
jump carry, overflow bits/checks, or the nature of how the CPUs 
handle arithmetic. I'm referring more to multiplication where the 
result of 2 16-bit multiplies will result in a 32bit output 
(AX&DX, is the same for 32/64bit instructions), but most likely 
the upper 32bits are just outright ignored rather than making use 
of those possible features.

  Heh, I'd love to see more hardware level abstraction that's 
built into the language. Almost like:

  try {}    // Considers the result of 1 line of basic math to be 
caught by:
  carry     {} //only activates if carry is set
  overflow  {} //if overflowed during some math
  modulus(m){} //get the remainder as m after a division operation
  mult(dx)  {} //get upper 32/64/whatever after a multiply and set 
as dx

  Of course I'd understand if some hardware doesn't offer such 
support, so the else could be thrown in to allow a workaround 
code to detect such an event, or only allow it if it's a 
compliant architecture. Although workaround detection is always 
possible, just not as fast as hardware supplied.

  Although I'm not fully familiar with all the results a FPU 
result could give, or if such a system would be beneficial to the 
current discussion on floats. I would prefer not to inject fixed 
x86 instructions if I can avoid it.