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

dave at brownsmeet.com dave at brownsmeet.com
Tue Apr 28 11:08:32 CEST 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200428/93e2b280/attachment.html>


More information about the Oberon mailing list