Always false float comparisons

[Era Scarecrow via Digitalmars-d]

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.