www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Reading few CPU flags from D code

One of the things I miss from Delphi is the ranged types of integral values,
they actually increase the safety of programs, restricting a variable in a sub
range.

So I can create a struct template as this that implements a ranged integral
value:

Ranged!(1, 1001, int) foo;
alias Ranged!('a', 'z'+1, char) Lowercase;

(In theory the type used by the struct of the can be omitted, so for a range in
[1, 1000] it can chose to use an int.)

I have seen that I am not the only one that has this idea, see the range_type
here (C++):
http://www.richherrick.com/software/herrick_library.html

Multiplications are quite less common on ranged variables, + and - == and
assigns are the most common operations done on them.

The preconditions of the methods of that struct can test for the out of range
conditions. In release mode they are removed (or I can use a debug statement).
But it's better to keep those tests when possible, so I'd like that Ranged to
be efficient.

Delphi ranges are fast also because the compiler can remove some unnecessary
checks, I can't do this in a simple way (template expressions are overkill
here).

The struct has to test for out-of-range and true overflows of the int/ubyte/etc
they are implemented on.

Checking for overflow in D with no inline assembly can be a little slow. I
don't know much assembly yet, and it's more error-prone and less portable than
D code, baseline D (with no LDC extensions) doesn't inline the structs methods
that contain the asm code (and maybe the prologue-epilogue of the asm code can
kill any performance improvement given by reading the overflow bit from asm).

A solution is to make the backend smarter, so I can hope it will recognize
patterns in my code and compile it into good asm, but llvm doesn't currently
perform well here. I have filed few enhancement requests:

http://llvm.org/bugs/show_bug.cgi?id=4916
http://llvm.org/bugs/show_bug.cgi?id=4917
http://llvm.org/bugs/show_bug.cgi?id=4918

But even if the gentle Chris Lattner implements those tiny optimizations for
me, that's not a full solution, because the bad thing with compiler
optimizations is that you can't rely on them.

So, as a possible solution, that's portable on many CPU types (CPUs aren't
forced have them, but they are common), and gives some performance, can
std.intrinsic grow few ways to test for Overflow, Zero and Carry flags? I am
not sure if and how this can be implemented.

Bye,
bearophile
Mar 18 2010