[fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?

[Hans-Peter Diettrich]

Ewald schrieb:

> Talking about principles: If hexadecimal is actually used to
> represent bit patterns (as Hans-Peter Diettrich wrote), then the
> decision to use a signed type here seems to violate this (represent
> bitpatterns) principle, since the highest bit in a signed number has
> a different meaning than the other bits, where in a bitpattern all
> bits have equal meaning.

That's correct.

> It seems like sticking to one principle (signed integer as much as
> possible) actually breaks another principle (bitpattern).

Wirth and his Pascal language are well designed with signed types above 
all, and unsigned types being subranges. In so far one could consider 
hex constants with the sign bit set as syntactical errors.

>> You do care about the signedness, because the only way to represent
>> int64(-1) in hexadecimal is as $ffffffffffffffff.

Negative numbers never should be expressed in hex.

> And what about -$1? Or is that too far fetched?

That's correct, because -$1 is -1 is a valid integral expression, 
without signedness problems.

>> Numbers in two's complement do no consist of a single sign bit
>> followed by a magnitude. Those top 63 '1' bits together form the
>> "-" sign in this number.
> 
> Yes, but this can all be solved by parsing the string and storing it
> with one extra MSBit (if there is a `-` in front of the constant it
> must be negative, otherwise it should be positive).

This is why Wirth considers all types being signed, without such problems.


> This highest bit then reflects the sign.

The sign representation is machine specific, as you know. On 1's 
complement machines there exist two representation of zero, as +0 and 
-0, and you cannot express both as hexadecimal constants in an portable 
way. That's why high level languages, like Pascal, forbid hex 
representations of (possibly) negative numerical values.

> `-1` would then be $1 FFFF FFFF FFFF FFFF,
> whereas $FFFF FFFF FFFF FFFF would be $0 FFFF FFFF FFFF FFFF. It
> really is quite easy to store it like that and `fix` things [picking
> a fitting datatype] afterwards.

The datatype has to be constructed/determined first, and *if* there 
exists a type with more than 64 bits, then it will be a signed type, 
with a 65 bit (unsigned) subrange matching your needs. But if no such 
type exists, you are lost.

> Anyway, then you have got backwards
> compatibility to take care of, since there will be someone out there
> who's code actually depends on this behaviour.

When we agree that a bitpattern of $FFFF FFFF FFFF FFFF can be 
interperted differently on different 32 bit machines, as -1 or -MaxInt, 
then it's obvious that such a textual representation should cause an 
compilation error "not portable...". We know that such an error message 
has not yet been implemented, but if you insist on writing unportable 
code... :-]

DoDi