[Oberon] Negative integer literals in Oberon

[Jörg]

I think the root cause of this discussion is that the Oberon language does not clearly define the semantic of the H suffix.

Let me try to explain what I mean. In my point of view we have to differentiate two conceptionally different layers. Let me call it
the red Oberon layer, as defined by the Oberon report.
the blue implementation layer, as defined by the target CPU and the Oberon compiler.
 

In the red Oberon layer you might write

CONST

Int = -1869574000;

Real = -5.702072E-29;

Let’s assume the compiler has a 32bit CPU as target. The CPU represents INTEGERs as two’s complement (that’s quite common but not a given) then the red Oberon value -1869574000 is represented by the blue 32bit pattern 90909090.

If the floating point unit chooses to represent REALs as IEEE754 (that’s quite common but not a given) the red Oberon value -5.702072E-29 is represented by the blue 32 bit pattern 90909090.

 

With these two layers in mind, the H suffix can have two totally different semantics
is H purely working in the red Oberon layer and just be another notation to define an INTEGER?
Then, the decimal notation 2425393296 and hex notation 90909090H are absolutely identical.
Or does H do a type cast of the blue 32bit pattern 90909090 into a red INTEGER value -1869574000?
 

Looking at the Oberon-07 report the semantic of H looks more like a).

NW’s Oberon-07 compiler behaves like b). Another hint that NW most probably had semantic b) in mind is the fact that a suffix R exists. 90909090R type casts the 32 bit pattern 90909090 into a REAL.

The semantic of H should be better described in the Oberon report.

 

br

Jörg

 

Am 01.05.20, 20:00 schrieb "Jörg" <joerg.straube at iaeth.ch>:

 

    SHORT(90909090H) should generate an error, as 2.4 billion is big for a 32 bit integer.

    Jörg

    

    > Am 01.05.2020 um 18:46 schrieb dave at brownsmeet.com:

    > 

    > Hi Oleg,

    > 

    > Re 1 - Personally I really dislike '90909090H - 100000000H' because it is more confusing to read than the alternatives.

    > 

    > Instead of SYSTEM.VAL(INTEGER, 90909090H) you may prefer SHORT(90909090H). It's a bit more concise, avoids the dependency on SYSTEM, and works whatever the 32 bit integer type is called (i.e. INTEGER or LONGINT).

    > 

    > (If you are adding support for LONGINT then you will almost certainly be adding support for SHORT() and LONG()).

    > 

    > ---

    > 

    > Re 2 - Yes, this fixes 32 bit hex literals. But it doesn't fix 16 or 8 bit hex literals. I think these should be considered too. It's also difficult to explain the use of the H vs L suffix - the description in the component pascal documentation is correct but very confusing.

    > 

    > ---

    > 

    > Re 3 - Yes, in this case (assuming you have added support for 64 bit integers) all arithmetic is 64 bit, and assignments to smaller int variables are simply clipped at the time they are stored. You don't need SHORT() or LONG().

    > 

    > If you do this I'd like to see a compilation option to do range checking at run time on every store to < 64 bits.

    > 

    > ---

    > 

    > Re 4 - Oberon already has casting under another name (type guard) for extended types - with the type name in  brackets following the variable name. Maybe keep the syntax similar.

    > 

    > 

    > -- Dave.

    > 

    > 

    >> On 2020-05-01 11:26, Oleg N. Cher wrote:

    >> Dear Dave,

    >> After all, the question: is the literal 90909090H considered 64-bit

    >> unsigned or 32-bit signed? We have four solutions:

    >> 1. Consider it as a 64-bit literal, by context. And if we need to

    >> declare it as a 32-bit literal, we'll write it like this:

    >>  myint := 90909090H - 100000000H;

    >> If we don't like writing code this way, we'll write it differently:

    >>  myint := SYSTEM.VAL(INTEGER, 90909090H);

    >> , quite in the spirit of the Oberon paradigm. So, Artur, this is what

    >> I suggest you do in your compiler.

    >> 2. Consider it as a 32-bit literal. And for 64-bit use the postfix

    >> modifier like 0FFFFFFFFL, as in Component Pascal. Ofront+ also

    >> implements this option (in -C mode).

    >> 3. Pretend that we have all integer literals of the same size. In this

    >> case, all the hexadecimal digits allowed as a bitfield value of the

    >> literal. This way is implemented in most Oberon-07 compilers, which is

    >> justified by the lack of integer arithmetic of different bits in them.

    >> (BYTE is a non-arithmeric type in Oberon-07, and its size does not

    >> used in operations, always casted to INTEGER).

    >> 4. Explicitly specifying the constant type, as there was in Turbo Pascal:

    >> CONST MyConst = INTEGER(90909090H);

    >> As in Active Oberon, Delphi and Turbo Pascal. But then it is necessary

    >> to allow the same (note, non-system) casting in expressions - and

    >> rushed.

    >> I would suggest two ways. The non-system way:

    >>  CONST MyConst = 90909090H - 100000000H;

    >> This will be our payment for the fact that there are no unsigned types

    >> in Oberon. This is a simplification that I think is very useful, but

    >> has a cost. So now we have all integer constants as signed numbers.

    >> And the system way. Ofront+ supports:

    >>  myint := SYSTEM.VAL(INTEGER, 90909090H);

    >> And in constants too:

    >>  CONST MyConst = SYSTEM.VAL(INTEGER, 90909090H);

    >> The disadvantage here is the compatibility problem, because old

    >> sources may contain literals that rely on the size of 32 bits. But

    >> this is mitigated by the fact that Ofront+ supports 5 Oberon dialects,

    >> and we can choose any of it at our discretion.

    > --

    > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems

    > https://lists.inf.ethz.ch/mailman/listinfo/oberon

    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200502/48603a08/attachment.html>