On Wednesday, 18 May 2016 at 10:25:10 UTC, tsbockman wrote:
On Wednesday, 18 May 2016 at 08:38:07 UTC, Era Scarecrow wrote:
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.
https://code.dlang.org/packages/checkedint
https://dlang.org/phobos/core_checkedint.html
Glancing at the checkedInt I really don't see it as being the
same as what I'm talking about. Overflow/carry for add perhaps,
but unless it breaks down to a single instruction for the
compiler to determine if it needs to do something, I see it as a
failure (at best, a workaround).
That's just my thoughts. CheckedInt simply _doesn't_ cover what
I was talking about. Obtaining the modulus for 0
cost/instructions after doing a division which is in the
hardware's opcode side effects (unless the compiler recognizes
the pattern and offers it as an optimization), or having the full
result of a multiply on hand (that exceeds it's built-in size,
long.max*long.max = 128bit result, which the hardware hands to
you if you check the register it stores the other half of the
result in).
Perhaps what I want is more limited to handling certain tasks
(making software math libraries) but I'd still like/want to see
access to the other effects of these opcodes.
