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.
