[Oberon] Negative integer literals in Oberon (dave at brownsmeet.com)

[Arthur Yefimov]

> I think the answer to Arthur's original question depends on whether his
> goal is a single integer size compiler, or whether there is an intent to
> add support for e.g. Oberon 2's SHORTINT and LONGINT.

At first we are going to support a single INTEGER type only. Then we will
need to think if we also need to add any support for SHORTINT, LONGINT etc.
(and may be even SYSTEM.INT32 etc.) But still I think it would be
convenient to be able to pass 90909090H to a procedure that accepts a
32-bit INTEGER even though it would end up being a negative number. Anyway,
inside the procedure we are dividing it by 100H, 10000H etc. to get the
individual bytes.

> The crux of the issue from my point of view is that supporting 90909090H
> as a 32 bit integer parameter is easy for a compiler like Oberon 2013
> that supports a single INTEGER size, and not easy, or not possible for a
> compiler that supports OBERON 2's multiple integer sizes.

I may be wrong, but as long as we are only implementing this for constants,
I have an idea of an easy solution for an Ofront-like compiler. Below I'll
use some kind of pseudocode (let's suppose Int32 and Int64 are integer
constants, i. e. 3 and 4).

The value 90909090H is a constant, so
it's (x.mode = Const) & (x.type.form = Int64).
And the corresponding formal parameter is
(par.class = Var) & (par.type.form = Int32).
As our item (x) is a constant, we also know it's value at compile-time. Why
not to add a cascade of IF-statements like so?
IF (x.mode = Const) & (par.type.form = Int32) &
    (x.type.form = Int64) & (x.val >= 0) &
    (x.val < 100000000H)
THEN x.type.form := Int32
END

Let me know if this makes sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200428/55a90499/attachment.html>