[Oberon] Negative integer literals in Oberon (dave at brownsmeet.com)
joerg.straube at iaeth.ch
Tue Apr 28 11:17:24 CEST 2020
To forbid this “undesired” case, the Oberon-07 compiler parses hex literals and decimal literals differently.
For decimal literals the allowed range is 0 .. 2.1 billion.
For hexadecimal literals the allowed range is 0 to 4.2 billion. The compiler internally maps the range of 2.1 .. 4.2 to -2.1 .. 0
Von: Oberon <oberon-bounces at lists.inf.ethz.ch> im Auftrag von <dave at brownsmeet.com>
Antworten an: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Datum: Dienstag, 28. April 2020 um 11:09
An: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Cc: Arthur Yefimov <artur.efimov at gmail.com>
Betreff: Re: [Oberon] Negative integer literals in Oberon (dave at brownsmeet.com)
Yes, that would allow 90909090H as desired.
However it will also allow e.g. calling DWORD(4294000000), which will actually behave as DWORD(-967296), not desirable.
I believe fixing this means passing a flag through from the parser with the constant value to mark it as sourced from a hex literal.
But it's not just about fixing the code location you show.
You would also want to support
myint32 := 90909090H
myint32 := 90000000H + 900000H + 9000H + 90H
(where some of those may be CONSTs)
And this means passing the flag on through the constant evaluation. It makes for a large and ugly change.
Re 'why would hex constants be desirable' - A very common modern usage is the ARGB representation of colour - HTML and CSS contains plenty of HEX colour representations, and industry sources such as Pantone specify web colours in hex.
On 2020-04-28 00:51, Arthur Yefimov wrote:
> 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
Let me know if this makes sense.
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
-- Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon