Always false float comparisons

tsbockman via Digitalmars-d digitalmars-d at puremagic.com
Wed May 18 12:36:59 PDT 2016


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.



More information about the Digitalmars-d mailing list