[Oberon] Negative integer literals in Oberon
Jörg
joerg.straube at iaeth.ch
Wed Apr 29 11:08:40 CEST 2020
Chris
Right. In this case I accept it: ReadInteger (data) reads an INTEGER (perhaps reading several digits as ASCII characters and converting them using INTEGER arithmetic to an INTEGER), and SYSTEM.PUT transparently puts the unknown internal presentation of INTEGER to memory.
The other way around, it's more tricky: SYSTEM.GET(address, data); WriteInput (data). You have no clue whether the "data" got from memory does really represent an INTEGER. When it was generated like in the previous example, then it's okay. But it could for example be a REAL.
So here the use of INTEGER is misleading, as basically it can be an INTEGER but it could be something completely different.
If you want to compare the "data" with something, you can't use INTEGER literals, as only the compiler knows how INTEGERs are represented.
(Eg is it big endian or little endian?)
br
Jörg
Am 28.04.20, 23:22 schrieb "Oberon im Auftrag von Chris Burrows" <oberon-bounces at lists.inf.ethz.ch im Auftrag von chris at cfbsoftware.com>:
How could that possibly be? If ReadInput was reading text input, it would need a CHAR or ARRAY OF CHAR parameter, in which case ReadInput(data) would fail to compile. If I had been reviewing the code myself I would have complained about the use of the identifier name startAdr.
Maybe this would be more acceptable?
VAR
address, nWords, data: INTEGER;
FOR address := 0ABCDEFH TO (address + nWords) BY 4 DO
ReadIntegerInput(data);
SYSTEM.PUT(address, data)
END
Regards,
Chris Burrows
CFB Software
https://www.cfbsoftware.com
> -----Original Message-----
> From: Joerg [mailto:joerg.straube at iaeth.ch]
> Sent: Wednesday, 29 April 2020 12:39 AM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: Re: [Oberon] Negative integer literals in Oberon
>
> 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
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon
More information about the Oberon
mailing list