value range propagation for _bitwise_ OR

Fawzi Mohamed fawzi at gmx.ch
Thu Apr 15 03:20:32 PDT 2010


On 14-apr-10, at 21:55, bearophile wrote:

> Sorry for the slow answer, I have some things to catch up.
>
> Fawzi Mohamed:
>
>> integral overflow are helpful only if you have automatic conversion  
>> to a larger type,<
>
> I don't understand what you mean here. There are various ways to  
> detect overflows, from the simple ones like using a long to compute  
> operations on int, and then looking for int overflows, to looking at  
> CPU overflow and carry flags, and so on. Such strategies to don't  
> change the size of the variables on the stack or on the heap, it's  
> mostly a matter of different operations done inside CPU registers.

well having an operation that detects overflow and is as efficient as  
possible would indeed be useful to have without resorting to asm could  
be useful indeed in some cases.

Please note that I (and probably you too) use overflow very often when  
you subtract unsigned values.
-d is equivalent to 2^32-d for uint, uint work modulo 2^32 (and ulong  
modulo 2^64).
Thus it *can* happen that you have a partial result that is equivalent  
to a very large number.
you need to ditch the conversion signed->unsigned + handling unsigned  
without checking overflow for this to work.
Indeed Delphi comes from Pascal and does not share the automatic  
casting of C.
C# does not applies it everywhere, as it is costly, and wrong in some  
cases.

D should also introduce the checked and uncheked statements to use it.

With it then it can be introduced.

>> but that breaks the compile time knowledge of the size of such an  
>> integer,<
>
> Nope, the compiler knows statically the variable sizes, returns the  
> same values regardless integral overflow is used or not.
>

>> so that you have to assume that it might need to be pushed to the  
>> heap.<
>
> It requires no heap activity.
>
>> Yes you might use some tricks (like using size_t.sizeof*8-1 bits,  
>> or a pointer to spare some place), but I don't think that D wants  
>> to go that way for the basic integers...<
>
> Tagging values is almost a science, it's not a trick :-)
> Tagged values have some advantages over the C-style fixnums.
> (Related: Bigint can use a similar tagging scheme to avoid heap  
> allocation when the integer is small.)
> But you don't need tagged values to perform overflow tests, both  
> Dephi and C# use normal untagged values.

I had misunderstood what you wanted, I thought about a python 3 like,  
"never overflow".
Not just an exception in the case of overflow.
Yes tagging could be used by Bigint, and that would improve its  
usability for "small" numbers

I agree that checking can be useful sometime, but i is not a "small"  
change.
Having a checked addition/subtraction would be much easier, and would  
be nice to have, one could define a Checked!(T) type implementing it  
for all integers...

ciao
Fawzi



More information about the Digitalmars-d mailing list