[Oberon] Negative integer literals in Oberon
chris at cfbsoftware.com
Tue Apr 28 13:42:14 CEST 2020
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:
startAdr, nWords, data: INTEGER;
FOR startAdr := 0ABCDEFH TO (startAdr + nWords) BY 4 DO ReadInput(data); SYSTEM.PUT(startAdr, data) END
> -----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
> 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
> - 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()
> 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>:
> >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
> 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
> The value has to be used as provided below, or there will be no
> 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
> 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.
> 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
> > 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
> > (* 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
> > 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
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon