[Oberon] Negative integer literals in Oberon

Joerg joerg.straube at iaeth.ch
Sat Apr 25 18:56:38 CEST 2020


I have a clear opinion on this: it is allowed. But we had a kind of similar case a few days back when I was attacked to allow b := -1;

Strictly speaking negative numbers do not exist in Oberon-07. 
-1 is syntactically not a negative number but a SimpleExpression. You can see this as a kind of shortcut for 0 - 1.
Another proof of this view is, you can‘t write
CASE i OF
-2: 
END;
as case labels can only be numbers, no (const) expression.

You can think of decimal values as signed and hex values as unsigned. If you look at Texts.WriteHex(W, -1) you‘ll see what I mean.

So, I see 9090909090H as a kind of (low level) way to fill up 32 bit. No notion of sign.

However, if you do calculations with these 32 bit you have to be aware that the calculation is done signed. And the comparisons are signed as well.

A side topic: this signed comparison thingy is the reason why a timer should better be coded like
  start := Kernel.Time();
  WHILE Kernel.Time() - start < delay DO END;

instead of the often found
  end := Kernel.Time() + delay;
  WHILE Kernel.Time() < end DO END;

br
Jörg

> Am 25.04.2020 um 17:09 schrieb Arthur Yefimov <artur.efimov at gmail.com>:
> 
> 
> While developing the compiler[1], we got a question
> whether it is possible to write the following:
> 
> PROCEDURE DWord(n: INTEGER);
> ...
> DWord (90909090H)
> 
> (where INTEGER is 32-bit).
> 
> Some compilers give an error (i.e. VOC), while this works in the
> Project Oberon (2013) compiler. This would turn out to be quite convenient,
> because the purpose of DWord in our code was to write 4 bytes to the file
> given as INTEGER (using little-endian byte order).
> 
> DWord has the following implementation (module Generator[2]):
> 
> PROCEDURE DWord (n: INTEGER);
> BEGIN
>   Files.Write (r, CHR (n MOD 100H));
>   Files.Write (r, CHR (n DIV 100H MOD 100H));
>   Files.Write (r, CHR (n DIV 10000H MOD 100H));
>   Files.Write (r, CHR (n DIV 1000000H))
> END DWord;
> 
> The Oberon language report does not indicate that literal 90909090H
> should be considered an error if INTEGER has 32 bits.
> 
> In this experiment, an online RISC emulator[3] was used.
> 
> References:
> [1] https://github.com/kekcleader/oberon
> [2] https://github.com/kekcleader/oberon/blob/master/Mod/Generator.Mod
> [3] http://schierlm.github.io/OberonEmulator/emu-wasm.html?image=FullDiskImage&width=1024&height=768
> --
> 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/20200425/f06ce260/attachment.html>


More information about the Oberon mailing list