[Oberon] Negative integer literals in Oberon

dave at brownsmeet.com dave at brownsmeet.com
Sun Apr 26 09:27:47 CEST 2020

((Lapsed) VOC maintainer here.) 

In both VOC and Oberon 2013, integer literals are parsed in the symbol
parser (VOC :OPS.Mod or 2013:ORS.MOD) and stored in the symbol table as
signed integer values. 

Later, during expression compilation, their size is determined by the
magnitude of their signed integer value. 

The difference between Oberon 2013 and VOC is the largest integer type,
which is 32 bit on Oberon 2013 and 64 bit in VOC. 

The special handling that allows a hex literal with top bit set to be
treated as a signed value happens at the time the literal is parsed as a
symbol independent of what context it is being used in. (Consider e.g.
'CONST mask = 90909090H' - CONST parsing does not know whether this
constant will be used in a 64 bit, 32 bit, 16bit or other context.) 

VOC and Oberon 2013 do both allow the hex special case top bit set
parsing behaviour, the difference being the integer literal size. 

Thus VOC accepts myint64 := 9090909090909090H because 9090909090909090H
is parsed as a negative 64 bit signed integer. 

But VOC does not accept myint32 := 90909090H because 90909090H is parsed
as a positive 64 bit signed integer.  

VOC has no way to parse 90909090H as a negative 32 bit signed integer. 

 - I did wonder about adding a further suffix letter to indicate the
intended size, but I couldn't satisfy myself that any solution was
simple enough to be easy to understand. 

 - Note that this is independent of VOC's -Ox compatibility setting:
that sets the default INTEGER size, not integer literal size - integer
literals always support the largest available integer size which is

-- Dave 

On 2020-04-25 22:52, Chris Burrows wrote:

> It all depends on what size (i.e. number of bits) INTEGER is defined as on the system you are using as to what range of numbers are valid INTEGERs. Since 2011, the range of INTEGER values is no longer defined in the Language Report; it is implementation-dependent. 
> In the Project Oberon (2013) RISC5 compiler, INTEGER is 32 bit so 90909090H is a valid INTEGER. Maybe you used the default (-O2) option in VOC? If so, INTEGER is 16 bit so 90909090H would be too large. Make sure you are compiling with the VOC -OC option instead if you want INTEGER to be treated as a 32 bit quantity. 
> Note that 9090H would be a negative number on a 16-bit INTEGER system but a positive number on a 32-bit INTEGER system. 
> Regards, 
> Chris Burrows 
> CFB Software 
> https://www.astrobe.com 
> FROM: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] ON BEHALF OF Arthur Yefimov
> SENT: Sunday, 26 April 2020 12:38 AM
> TO: oberon at lists.inf.ethz.ch
> SUBJECT: [Oberon] Negative integer literals in Oberon 
> While developing the compiler[1], we got a question
> whether it is possible to write the following:
> ...
> 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]): 
> 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/20200426/4712ac3c/attachment.html>

More information about the Oberon mailing list