[Oberon] Negative integer literals in Oberon

[Joerg]

The main question is: why does somebody want to hand over 90909090H to an INTEGER value?

What does 90909090H mean? Does the author mean 2’425’393’296 in decimal or does he mean -1’869‘574‘000 (assuming he knows how INTEGERs are implemented)

If it is 2 billion, it will not fit in an 31bit INTEGER.
If it is -1 billion, it will fit in an 31bit INTEGER.

In short: if the compiler generates an error try
-6F6F6F70H. It’s the same as 90909090H on a machine that implements INTEGERs with 31 bits and MSB as sign.

br
Jörg

> Am 27.04.2020 um 18:50 schrieb dave at brownsmeet.com:
> 
> 
> I think there are a couple of conversations going on here, I'm trying to get straight what's being discussed.
> 
> Arthur's original question was about passing 90909090H as a literal to a 32 bit INTEGER parameter, he found that Oberon 2013 supported it and VOC didn't.
> 
> I chimed in because I had tried to support this in VOC but had not been able to. My response was an attempt to explain why VOC could not support it but I suspect I just confused the matter.
> 
> VOC is an Oberon 2 compiler including support for SHORTINT, INTEGER and LONGINT, and for size conversions SHORT() and LONG(), and applies type compatibility rules as per the OBERON 2 language report.
> 
> This is in contrast to the Oberon 2007/2013/2016 language which has a single integer size. (While it also has BYTE, it does not have the size compatibility rules of Oberon 2, nor does it have SHORT() and LONG(). This makes it a lot simpler.)
> 
> I think I am seeing some level of consensus that having a single INTEGER size has benefits.
> 
> (Aside - I worked a lot with the original CDC 6000 Pascal which had a single integer size of 60 bits. It worked vary well, I miss it. All arithmetic was done on 60 bit values. Additionally Pascal supported subrange types - these did not affect arithmetic, but they did
>   1) support compile time range and run time value checking
>   2) affect storage size - only when used in packed records.
> )
> 
> 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.
> 
> 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. (Component Pascal has the H vs L suffix workaround for 64 bit and 32 bit integers, but does not provide similar solutions for 16 or 8 bit integers.)
> 
> -- Dave.
> 
> 
> 
>> On 2020-04-27 00:55, Chris Burrows wrote:
>> 
>> It is useful that Blackbox reports those compilation errors; it is less forgiving than many Oberon compilers. By not making assumptions it forces the programmer to really think about what he is trying to achieve.
>> 
>>  
>> 
>> As far as I know there are no specific literal constants defined in Component Pascal for BYTE or SHORTINT values.
>> 
>>  
>> 
>> If I were you I would implement two completely separate compilers. One that implements 32-bit INTEGERs and another that implements 64-bit INTEGERs and avoid mixing the two. In that way you can still conform to the Oberon Language report and not have to introduce any extensions. If you are concerned that a programmer might want to write code using the 64-bit compiler and then try to run it on the 32-bit compiler that is a problem for the programmer not you.
>> 
>>  
>> 
>> If the programmer is writing code that he wants to run on both systems then he should separate any parts that are sensitive to the size of INTEGER and include assertions in those parts such as:
>> 
>>  
>> 
>> ASSERT(SYSTEM.SIZE(INTEGER) = 8)
>> 
>>  
>> 
>> to prevent it from accidentally being compiled for, and run on, the wrong platform.
>> 
>>  
>> 
>> Regards,
>> 
>> Chris Burrows
>> 
>> CFB Software
>> 
>> https://www.astrobe.com
>> 
>>  /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/20200427/dc1b73d9/attachment.html>