[Oberon] Negative integer literals in Oberon

[Chris Burrows]

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