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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
