[Oberon] Assumed issue in the Lola-2 compiler

[Skulski, Wojciech]

Rochus and Paul:

hardware programming should allow for unsigned bit fields. The unsigned representation is far more fundamental in hardware than signed arithmetic. In FPGAs, all wires and flip flops represent bits. Twos complement or other formats belong to interpretation, while their hardware representation is just bits, all of them being equal. 

Rochus' finding illustrates the deficiency of the Oberon Language when applied to a an application area where unsigned numbers are both needed and necessary. 

Wojtek
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of rochus.keller at bluewin.ch [rochus.keller at bluewin.ch]
Sent: Sunday, April 14, 2019 11:09 AM
To: oberon at lists.inf.ethz.ch
Subject: Re: [Oberon] Assumed issue in the Lola-2 compiler

>> There are two other issues though:
>> - In MouseP.v line 27 column 45 the hex value was not properly generated

I found the problem.

The original LSV.WriteHex has a signature of (x: LONGINT) with the comment "x >= 0". But in MouseP.Lola line 26 there is a constant 0FFFFFFFFH'32 which seems to be valid Lola-2 and which is internally stored in LSB.ItemDesc.val, also a LONGINT.

As far as I understood the Oberon Language Report 1990 the LONGINT is a signed 32 bit integer type. The type doesn't show up in Oberon-07 anymore, but in this forum I learned that it is still used with the original definition for backward compatibility.  According to this definition 0FFFFFFFFH corresponds to -1.

I would prefer to make the fix in the Oberon source code if possible and to not change the translated C++ code.

@ Paul Reed: Can you confirm this reasoning? Is there an "authorized fix" of LSV.WriteHex to also handle negative x?

Best
R.K.