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

[Jörg]

Dave

 

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 

 

br

Jörg

 

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

and indeed

  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.

-- Dave.

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

END

 

Let me know if this makes sense.

 

--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon

-- 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...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200428/67ca954f/attachment.html>