[Oberon] Assumed issue in the Lola-2 compiler

[Jörg Straube]

Rochus, Wojtek

be aware that the Lola compiler in Oberon supports unsigned values!

Just follow these rules:
- use hex values with length (without length, signed decimal LONGINTs are written, with length unsigned hex values are written)
- when porting LSV.WriteHex from Oberon to other languages pay attention that the MOD operator in Oberon ALWAYS generates positive values even for negative values.
In other words: WriteHex does support negative values (-1 MOD 10H = 0FH) as expected. If you used the % operator while porting to C, this might not hold. Use & instead.

As I wrote yesterday, add a length to all constant values in MouseP.Lola. If so, the LSV (ported to LinzOberon on Windows 10) generates the Verilog values you expect.

BTW: The SYSTEM module of the Oberon-07 FPGA compiler supports unsigned multiplication „UML“ and unsigned checks „COND()“ if needed.

br
Jörg

> Am 14.04.2019 um 17:22 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
> 
> 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.
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon