[Oberon] Negative integer literals in Oberon
Jörg
joerg.straube at iaeth.ch
Mon Apr 27 15:12:25 CEST 2020
Hi
INTEGER is a black box; Oberon does not state, how to implement this: You are free to implement it as 32 bit value, as 64 bit value, as linked list, as array, as record with separate sign field...
INTEGERs - where you don't have any idea, how they are implemented - are normally written in decimal notation. You can calculate with them, compare them etc. Oberon-07 allows to enter INTEGER literals in hex form. This kind of hex digits should obey the same rule as INTEGERs. I mean: if the implementation choses to represent INTEGERs as 31 bit and the MSB builds the sign, only values upto 2'147'483'647 or 7FFFFFFFH should be allowed.
A totally other use case is, when a (low level) programmer wants to use 32 bits, independent on the way how the underlying CPU happens to implement INTEGERs. Often programmers have this in mind, when they use the hex notation. These two different use cases where suffix H is used clash obviously.
Puristically speaking, Oberon can't be used for low level programming as too much things are left to the implementation. An abstraction like "BITFIELD" or "BIT32" or so is missing.
This new base type is not identical to INTEGER as it does not leave the implementation open, but defines exactly how bits are numbered, and how many bits there are.
If you use the base type INTEGER where you basically want to manipulate bits, these two concepts clash.
On this bit type you can use bitwise AND, OR, XOR, can shift etc.
When I talked to NW about this, he said, the only abstraction he came up with for this type of low level bit usage was SETs. SET is almost there but SET has the same "issue" as INTEGER: the presentation layer of SET is left to the implementation!!
In my point of view Oberon report should slightly redefine SETs by defining its internal presentation: define its bit numbering (= define its endianness) allow hex notation only for SETs (as alternative notation to { } ), drop hex notation for INTEGERs as I don't see a real use case for hex notation on INTEGERs yet.
br
Jörg
Am 27.04.20, 10:18 schrieb "Oberon im Auftrag von Jörg" <oberon-bounces at lists.inf.ethz.ch im Auftrag von joerg.straube at iaeth.ch>:
The whole discussion is based on the assumption that the MSB of a 32 bit value is the sign of an INTEGER.
That is not defined in the report. This is left to the implementation.
The only means in the Oberon-07 language to influence the sign bit is by using calculations involving "-".
0FFFFFFFFH has no sign operation, so can't be negative.
-6AB3H has a "-", so is negative
br
Jörg
Am 27.04.20, 10:04 schrieb "Oberon im Auftrag von Jörg" <oberon-bounces at lists.inf.ethz.ch im Auftrag von joerg.straube at iaeth.ch>:
How the sign bit for INTEGER values have to be stored is NOT defined in the report. This is part of the presentation layer that is deliberately left to the implementation.
1. Should the following assertion be successful?
ASSERT(ABS(0FFFFFFFFH) = 0FFFFFFFFH);
No, on a 32 bit machine with simple presentation layer implementation
Yes, on a 32 bit machine with clever presentation layer implementation.
Yes, on a 64 bit machine.
2. Should the compiler accept the following statement?
i := i DIV 0FFFFFFFFH;
Yes, why not? Just look at the case where INTEGER is 8 bytes.
But be aware: as I said H has two different flavors: one H usage is used in INTEGER arithmetic (just use decimal notation and hexadecimal notions for the same INTEGER values, there I wonder why you would do that anyway). And the second H usage (and this is in my experience the usage most have in mind when they use H: low-level programming where you need bit patterns and don't care about the internal presentation layer of INTEGERs that is - as we know - not defined in the Oberon report.
Jörg
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon
More information about the Oberon
mailing list