[Oberon] Negative integer literals in Oberon

[Joerg]

yes, yes. As replied to Wojtek, addresses are INTEGERs and you might use hex notation if you feel more comfortable.

In your example I see more of an issue with „data“ than with „startAdr“....

your code moves 32 bit entities around and not INTEGERs... The input ReadInput works on might be a text or whatever. So in this case INTEGER is kind of misused as you know from the compiler that it by coincidence can hold 32 bits.

br
Jörg

> Am 28.04.2020 um 13:43 schrieb Chris Burrows <chris at cfbsoftware.com>:
> 
> Just one example I can think of is that I've stored a HEX value representing an absolute start address into an INTEGER and then incremented it to initialise a block of memory at that address.
> 
> Something like this:
> 
> VAR
>  startAdr, nWords, data: INTEGER;
> 
> ...
>  FOR startAdr := 0ABCDEFH TO (startAdr + nWords) BY 4 DO ReadInput(data); SYSTEM.PUT(startAdr, data) END
> 
> Regards,
> Chris Burrows
> CFB Software
> https://www.astrobe.com
> 
> 
>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Jörg
>> Sent: Tuesday, 28 April 2020 6:42 PM
>> To: ETH Oberon and related systems
>> Subject: Re: [Oberon] Negative integer literals in Oberon
>> 
>> Wojtek
>> 
>> There is no question, that hex notation is convenient and needed.
>> But are we really talking about INTEGERs here? Whenever I saw hex
>> notation in my career, it had something to do with HW registers and silly
>> register constants for low level programming.
>> - INTEGERs and REALs are abstractions to do calculations with undefined
>> precision.
>> - POINTER is an abstraction to address memory
>> - SET is an abstraction for bit operations.
>> 
>> To what Oberon type should the hex notation apply?
>> In my point of view to INTEGERs the least. SET the most, but this is not
>> foreseen today.
>> And POINTERs have no explicit value at all, as all is abstracted away
>> (hidden) by NEW()
>> 
>> br
>> J rg
>> 
>> ?Am 28.04.20, 06:51 schrieb "Oberon im Auftrag von Skulski, Wojciech"
>> <oberon-bounces at lists.inf.ethz.ch im Auftrag von
>> skulski at pas.rochester.edu>:
>> 
>>    Joerg:
>> 
>>> It s a good point but a little bit a corner case. Principally,
>>> Oberon does not know addresses, as addresses are abstracted
>>> away by the type construct POINTER TO
>> 
>>    Yes, POINTER TO needs to be used eventually. But we are facing the
>> question
>>    how to assign the hard coded address to the POINTER. The VRAMORG is
>>    the case in point. This address is connected to the firmware video
>> controller.
>>    The value has to be used as provided below, or there will be no
>> video.
>> 
>>    VRAMORG does not have to be coded in hex in Oberon. The FW developer
>> can use
>>    0E7F00H, while the Oberon programmer can write 950016 in decimal. But
>> it is
>>    much easier and less error prone if both developers can use the same
>> notation.
>>    So we need the hex in this case because firmware developers are
>> likely to use hex.
>> 
>>    Another example is perhaps all these protocols like Ethernet where
>> the documentation
>>    will provide hex constants. Imagine the Oberon developer not being
>> able to use these,
>>    but rather using a Windows calculator to translate to decimal because
>> hex notation
>>    was removed from the language.
>> 
>>    Wojtek
>> 
>>    br, J rg
>> 
>>> Am 27.04.2020 um 22:40 schrieb Skulski, Wojciech
>> <skulski at pas.rochester.edu>:
>>> 
>>> ?Joerg:
>>> 
>>>> Could somebody give me a good example, where INTEGERs need a hex
>> notation?
>>> 
>>> How about this? These INTEGERS represent addresses. Are addresses
>> integers? I believe they are. The memory is a collection of addresses
>> with consecutive numbers expressed with integers. So it is a relevant
>> example.
>>> 
>>> (* Memory map; PO.System page 104 *)
>>> STACKSIZE* = 8000H;      (* 32 kB. Was hardwired in Kernel.Init *)
>>> STACKORG*  = 80000H;   (* stackOrg = 524,288; half a megabyte. *)
>>> HEAPORG*   = STACKORG; (* heapOrg = stackOrg *)
>>> FSoffset*  = STACKORG;     (* Not clear what it is *)
>>> MEMLIM*    = 0E7EF0H;     (* 1 MB minus 98,575 bytes of VRAM at the
>> end*)
>>> VRAMORG*   = 0E7F00H;   (* start of memory-mapped display frame*)
>>> VRAMSIZE*  = 1024*768 DIV 8;     (* 1024 x 768 pixel, monocolor
>> display frame*)
>>> --
>>    --
>>    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
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon