[Oberon] Assumed issue in the Lola-2 compiler
paulreed at paddedcell.com
Sun Apr 14 17:42:42 CEST 2019
> [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.
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!
More information about the Oberon