On Wednesday, 18 May 2016 at 11:46:37 UTC, Era Scarecrow wrote:
On Wednesday, 18 May 2016 at 10:25:10 UTC, tsbockman wrote:
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.
The functions in druntime's `core.checkedint` are intrinsics that
map directly to the hardware overflow/carry instructions.
The DUB package I linked provides various wrapper functions and
data structures to make it easier to use the `core.checkedint`
intrinsics (among other things). The performance cost of the
wrappers is low with proper inlining, which GDC and LDC are able
to provide. (DMD is another story...)
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).
I agree that intrinsics for this would be nice. I doubt that any
current D platform is actually computing the full 128 bit result
for every 64 bit multiply though - that would waste both power
and performance, for most programs.
