[Oberon] Assumed issue in the Lola-2 compiler

[Paul Reed]

Hi R.K.,

> [Prof. Wirth's] LSV.WriteHex has a signature of (x: LONGINT) with the
> comment "x >= 0"... As far as I understood ... the LONGINT is
> a signed 32 bit integer type.

Correct - in both Oberon-88 and Oberon-07.

> 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.

Correct.  Although it's not in the Oberon-07 report, LONGINT is 
implemented in the Oberon-07 compiler as a synonym for INTEGER, which is 
now 32-bit (whereas it was 16-bit in Oberon-88).

This makes it easier for some carefully-written code to be portable 
between the two; LSV.Mod is a case in point.


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

What fix?

I think the comment may be orphaned, in the sense that the code does 
actually work for x < 0, right?

I wonder if what happened was, the comment was added as a documented 
precondition when the REPEAT loop only had (x = 0) as a termination 
condition.  Then, negative numbers were handled (as opposed to being 
split up like in many compilers, into the minus sign and the numeric 
constant) by adding the extra condition (i = 8).

Is it possible your code isn't working because of a problem with MOD?  
What's (-1) MOD 10H in your code, it should be 15, right?

@Wojtek, as you know, Oberon-07 is intentionally a minimalist language, 
in reaction, for example, to Modula-2, where Prof. Wirth rues that he 
was persuaded to add too many features, types etc..  So please give an 
example of where unsigned types are "necessary" and what that even 
means, so we can have a sensible discussion.  Thanks!

Cheers,
Paul