January 2021 - Oberon - mailman3.inf.ethz.ch

Re (2): Oberon genealogy.
by peter＠easthope.ca 18 Jan '21

18 Jan '21

From: Joerg <joerg.straube(a)iaeth.ch> Date: Wed, Oct 21, 2020 at 9:17 AM > Just as a remark to the genealogy: > a yellow box =E2=80=9EMedos-2=E2=80=9C could be added; running on (red) Lil= > ith HW > https://www.research-collection.ethz.ch/handle/20.500.11850/137906 > Medos-2 can be seen as grand grand father of today=E2=80=98s Oberon system. I need help arranging the diagram properly. Lilith is in the Wikipedia. "1977, Lilith" is in Ivan's diagram. According to Wikipedia, the machine was developed '78-'80. Either '77 is too early or Wikipedia is too late. Ideally time should progress downward in the diagram. Some corruption is evident but not particularly harmful. For example, Kronos Research Group appears above Lilith. The rank constraint in DOT might correct that. Was Medos written in Pascal? Modula-2? Thanks, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

2 1

Oberon genealogy.
by peter＠easthope.ca 18 Jan '21

18 Jan '21

The genealogy graph created by Ivan Denisov is now in https://en.wikibooks.org/wiki/Oberon#Historical_Perspective . Thanks to Ivan! In the past few months someone commented about node colors and shapes denoting language, organization, system, compiler and workstation. I would have quoted the message but failed to find it. A private message? If someone wants to improve the diagram, good. The caption has a link to the DOT source oberongenealogy.gv. Rather than edit the SVG directly, please edit oberongenealogy.gv, update it in the book, render the new SVG and update oberongenealogy.svg in commons.wikimedia.org. The revised image will appear in the book. Experimental Oberon is an obvious possibility. It requires a node for the language revision and a node for the compiler revision; correct? Andreas, if you send a revised oberongenealogy.gv or instructions, will do my best to incorporate properly. I've also reorganized the information about Text to recognize differences between systems more realistically. The front page has a overview. https://en.wikibooks.org/wiki/Oberon#Oberon_Text System specific information is linked there. Comments and complaints always welcome. Thx, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

7 6

Re (2): Oberon genealogy.
by peter＠easthope.ca 17 Jan '21

17 Jan '21

From: Pablo Cayuela <pablo.cayuela(a)gmail.com> Date: Sun, 17 Jan 2021 19:06:44 -0300 > Maybe was this message: That's it. Didn't trust my memory that it was from Joerg and didn't search properly. From: Joerg <joerg.straube(a)iaeth.ch> Date: Wed, Oct 21, 2020 at 9:17 AM > a yellow box =E2=80=9EMedos-2=E2=80=9C could be added; running on (red) Lil= > ith HW > https://www.research-collection.ethz.ch/handle/20.500.11850/137906 > Medos-2 can be seen as grand grand father of today=E2=80=98s Oberon system. From: "Chris Burrows" <chris(a)cfbsoftware.com> Date: Mon, 18 Jan 2021 09:01:45 +1030 > I recommend that the link from Oberon-2 to Oberon-07 be > removed. ... Thanks Joerg, Pablo, Chris, When a revision in my sandbox is worth reading, will post again. ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

1 0

Oberon is on HackerNews (again)
by Liam Proven 16 Jan '21

16 Jan '21

There is some discussion and some interesting links. https://news.ycombinator.com/item?id=25786470 -- Liam Proven – Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk – gMail/gTalk/gHangouts: lproven(a)gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

1 0

Re (2): V4, 64 bit version;
by peter＠easthope.ca 16 Jan '21

16 Jan '21

From: Charles Perkins <chuck(a)kuracali.com> Date: Fri, 15 Jan 2021 13:17:03 -0800 > On review of the source, I see that LONGREAL is currently aliased to REAL > in ORB, suggesting that REAL may stay 32-bit and LONGREAL would be 64-bit. > Would the same be done for SET, introducing LONGSET perhaps? >From the new Project Oberon book I had the impression that the gain of one type rather than two outweighed the loss of storing some numbers in capacities larger than necessary. If so, wouldn't any machine have only REAL, according to hardware capability, whether 32 bits or 64 bits or 128 bits? What are the requirements motivating interest in 64 bits? Numerical modeling? Thanks, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

5 5

Re: [Oberon] V4, 64 bit version
by Chris Burrows 15 Jan '21

15 Jan '21

> > On Fri, Jan 15, 2021 at 1:08 PM Charles Perkins <chuck(a)kuracali.com> > wrote: > I like the idea. > > The sizes of datatypes in the RISC5 compiler are defined in ORB.Mod. > Currently we have: > byteType := type(Byte, Int, 1); (*symbol: BYTE *) > boolType := type(Bool, Bool, 1); (*symbol: BOOLEAN *) > charType := type(Char, Char,1); (*symbol: CHAR *) > intType := type(Int, Int, 4); (*symbols: INTEGER, LONGINT *) > realType := type(Real, Real, 4); (*symbol: REAL *) > setType := type(Set, Set,4); (*symbol: SET *) > nilType := type(NilTyp, NilTyp, 4);(*symbol: NIL *) > > In a 64-bit compiler derived from the RISC5 compiler I imagine we > would also have 8 byte REALs and SETs and NIL values: > byteType := type(Byte, Int, 1); (*symbol: BYTE *) > boolType := type(Bool, Bool, 1); (*symbol: BOOLEAN *) > charType := type(Char, Char,1); (*symbol: CHAR *) > intType := type(Int, Int, 4); (*symbol: INTEGER *) > longType := type(Long, Long, 8); (*symbol: LONGINT *) > realType := type(Real, Real, 8); (*symbol: REAL *) > setType := type(Set, Set,8); (*symbol: SET *) > nilType := type(NilTyp, NilTyp, 8); (*symbol: NIL *) > > Chuck > Are you aware of the existing Intel 64 Oberon-07 compiler? https://github.com/congdm/Patchouli-Compiler/tree/v0.8 The data types are specified here: https://github.com/congdm/Patchouli-Compiler/wiki/Detailed-Documentation Note that all the 32-bit data type dependencies have now been removed from the Oberon Language: The data type definitions pre-2011 were: -------------------------------------------------- BOOLEAN the truth values TRUE and FALSE. CHAR the characters of the Latin-1 set. INTEGER the integers between -2^31 and +2^31-1. REAL real numbers (IEEE Standard, 32 bits). LONGREAL long real numbers (IEEE Standard, 64 bits). SET the sets of integers between 0 and 31. -------------------------------------------------- In Sep 2011 they were: -------------------------------------------------- BOOLEAN the truth values TRUE and FALSE CHAR the characters of a standard character set INTEGER the integers REAL real numbers LONGREAL real numbers SET the sets of integers between 0 and 31 The type LONGREAL is intended to represent real numbers with a higher number of digits than REAL. However, the two types may be identical. -------------------------------------------------- In Oct 2013, they were further generalised to: -------------------------------------------------- BOOLEAN the truth values TRUE and FALSE CHAR the characters of a standard character set INTEGER the integers REAL real numbers BYTE the integers between 0 and 255 SET the sets of integers between 0 and an implementation-dependent limit The type BYTE is compatible with the type INTEGER, and vice-versa. -------------------------------------------------- i.e. CHAR could be any standard character set (not necessarily 8-bits), INTEGER and REAL can be any size, LONGREAL has been removed from the language and SET is no longer constrained to be 32 bits. Note that the Patchouli compiler handles the platform-dependent usefulness of additional data types while still conforming with the language specification by including their definitions in SYSTEM. Regards, Chris Burrows CFB Software https://www.astrobe.com

2 1

V4, 64 bit version; was: Re: Starting V4. (Hellwig Geisse)
by scrutinizer 15 Jan '21

15 Jan '21

> It would be nice to have a version running in > a 64-bit environment, but I'm not sure that this I'd propose to take a little plunge and change LONGINT to 64 bit and bootstrap V4 on 64 bit operating system(s). Apart from modifying the compiler to 64 bit, the source code changes to the whole [Linz] V4 package are minimal as the port to AOS (Alpha Oberon System) for 64 bit Alpha OpenVMS in the mid 1990s showed. Most Elems and apps, etc. could be compiled and ran without any source code changes. Only very few modules required source code changes. This port left no 32 bit restrictions.* See http://www.modulaware.com/mdlt/mdlt81.htm http://www.modulaware.com/mdlt73.htm The Alpha processor is history since about 20 years (due to the sales of DEC to Compaq to HP and finally to Intel for the Alpha processor. Intel burried the Alpha in a drawer to push Itanium.) But to give an impression of the number and kind of changes needed for a 64 bit port of V4, attached is an edited output of $ grep -a -e "_32" -e "ADDRESS32" -e "INTEGER32" -e "INT32" -- *.mod* >diff64bit.lis for the V4 modules. (The "-a" is needed to also get 'about' readable grep-results for those source files which are in oberon text format.) Another challenge would be the 64 port of FPGA Oberon. cheers! *) Apart from the main- and coroutine-*stack*, which is due to an implementation restriction of OpenVMS Alpha 7.1 -- (The number after the colon in the filename is the file version number, i.e., the number of edits.) browser.mod:62: a0, a1, a2: SYSTEM.SIGNED_32; (* a0 gives org in module list *) (* 20+2, 24+2, 28+2 *) browser.mod:62: size :SYSTEM.SIGNED_32; browser.mod:62: id: SYSTEM.SIGNED_32; browser.mod:62: m^.a0 := SYSTEM.VAL(SYSTEM.SIGNED_32, W.buf.len); browser.mod:62: PROCEDURE Index(name: ARRAY OF CHAR): SYSTEM.SIGNED_32; browser.mod:62: VAR id0, j: SYSTEM.SIGNED_32; ch: CHAR; (*enter identifier*) browser.mod:62: VAR i, j, s, h, h1, h2, class, mm: INTEGER; m, k, k1, k2: SYSTEM.SIGNED_32; strno: LONGINT; browser.mod:62: PROCEDURE Read4 (VAR i: SYSTEM.SIGNED_32); browser.mod:62: BEGIN Files.ReadLInt(SF, x); i := SYSTEM.VAL(SYSTEM.SIGNED_32, x) END Read4; browser.mod:62: VAR i,j: SYSTEM.SIGNED_32; ch: CHAR; browser.mod:62: EnterTyp("SIGNED_32", LInt, 4, linttyp); (* was "LONGINT" *) browser.mod:62: better use SIGNED_32 instead of LONGINT browser.mod:62: EnterTyp("SYSTEM.ADDRESS_32", Pointer, 4, sysptrtyp); (* = SYSTEM.PTR with /pointersize=32 *) browser.mod:62: EnterTyp("SYSTEM.UNSIGNED_32", Card, 4, cardtyp); files.mod:119: VAR i: SYSTEM.SIGNED_32; files.mod:119: BEGIN ReadBytes(R, i, SIZE(SYSTEM.SIGNED_32)); x := i; files.mod:119: VAR i: SYSTEM.SIGNED_32; files.mod:119: IF SIZE(LONGINT) = SIZE(SYSTEM.SIGNED_32) THEN files.mod:119: WriteBytes(R, x, SIZE(SYSTEM.SIGNED_32)); files.mod:119: i := SYSTEM.SHORT(x); WriteBytes(R, i, SIZE(SYSTEM.SIGNED_32)); fonts.mod:22: pixmap, pixmapX, pixmapDX, pixmapW, pixmapH, RasterBase, b, n, a, count, list: SYSTEM.SIGNED_32; input.mod:41: RETURN S.VAL(S.SIGNED_32, (timeval.usec DIV 1000 + timeval.sec * 1000 - timeStart) MOD 7FFFFFFFH); kernel.mod:480: TYPE Tag = POINTER TO RECORD (*size,*) ptroff: INTEGER32; END; (* todo x64 Bit: ptrofs -> 64Bit *) kernel.mod:480: PROCEDURE ALLOCATE * (VAR v: ADDRESS32; size: INTEGER32); kernel.mod:480: v := S.VAL(ADDRESS32, NewBlock(size)); modules0.mod:31: INTEGER32 = S.SIGNED_32; modules0.mod:31: data-, const-, code-: POINTER TO ARRAY OF INTEGER32; modules0.mod:31: VAR fp, sp, p: LONGINT; q: INTEGER32; invoContext: EX.InvoContext; modules0.mod:31: k1 :S.SIGNED_32; (* todo x64: substitute k1 by k to get long consts *) modules0.mod:31: ext: RECORD extlev, maxIdentLen: INTEGER32; END; modules0.mod:31: ASSERT(j <= MAX(INTEGER32)); modules0.mod:31: S.PUT(t, S.VAL(INTEGER32, j)); (* todo x64 Bit: remove 32Bit boundary *) modules0.mod:31: S.PUT(t, S.VAL(INTEGER32, -(nofptr+2)*ptroffSize)); (* todo x64 Bit: remove 32Bit boundary *) modules0.mod:31: TYPE STdPtr = POINTER TO RECORD tag: ADDRESS64; size: INTEGER64; p0, p1: INTEGER32; END; (* todo x64 bit; *) modules.mod:539: INTEGER32 = S.SIGNED_32; modules.mod:539: PointerOffset = INTEGER32; (* type used for ptr offsets in TypeDescs; todo 64 xbit: change to INT64 *) modules.mod:539: data-, const-, code-: POINTER TO ARRAY OF INTEGER32; modules.mod:539: ext: RECORD extlev, maxIdentLen: INTEGER32; END; modules.mod:539: extlev: INTEGER32; oberon.mod:33: PROCEDURE MinTime(): SYSTEM.SIGNED_32; (* << *) oberon.mod:33: minTime := MAX(SYSTEM.SIGNED_32); t := PrevTask; oberon.mod:33: RETURN pictures.mod:6: INT32 = S.SIGNED_32; pictures.mod:6: pixels: ARRAY 256 OF INT32; (* Handle to X11 - Color cell *) pictures.mod:6: truePix: ARRAY trueColorPaletteSize, trueColorPaletteSize, trueColorPaletteSize OF INT32; pictures.mod:6: VAR iPtr: X11.ImagePtr; img: X11.Image; filler, bits: INTEGER; x, y, z, n, dummy2: INT32; put.mod:3: INTEGER32 = SYS.SIGNED_32; put.mod:3: VAR i: INTEGER; si: SHORTINT; li: INTEGER32; qi: INTEGER64; r1: Ref.Rider; put.mod:3: VAR r, r1: Ref.Rider; i, j: INTEGER; si: SHORTINT; li: INTEGER32; qi: INTEGER64; reals.mod:45: VAR i: S.SIGNED_64; k: INTEGER; h, q, q2:S.SIGNED_32; ref.mod:6: PROCEDURE (VAR r: Rider) WriteLInt* (li: S.SIGNED_32); ref.mod:6: IF r.form = Procedure THEN S.PUT(r.Adr(), S.VAL(S.ADDRESS_32, p)) ref.mod:6: IF r.form = Pointer THEN S.PUT(r.Adr(), S.VAL(S.ADDRESS_32, p)) refelems.mod:6: VAR si: SHORTINT; i, j: INTEGER; li: S.SIGNED_32; qi: S.SIGNED_64; adr: LONGINT; rtdt.mod:174: Instruction* = SYS.SIGNED_32; (* 4 byte *) rtdt.mod:174: PROCEDURE Trap (VAR sigArgs: Sys.SigArgs; mechArgs: Sys.MechArgs): SYS.SIGNED_32; rtdt.mod:174: VAR retval: SYS.SIGNED_32; p: Proc; rtdt.mod:174: instr := SYS.VAL(SYS.SIGNED_32, ASH(01AH, 26) + ASH(R31, 21) + ASH(RA, 16) + ASH(0, 0)); SYS.PUT(codeseg + 8, instr); system.mod:285: PROCEDURE Trap (VAR sigArgs: EX.SigArgs; mechArgs: EX.MechArgs): SYSTEM.SIGNED_32; system.mod:285: Texts.WriteInt(W, LEN(m.code^)*SIZE(SYSTEM.SIGNED_32), 5); system.mod:285: ch: CHAR; cv, completion: SYSTEM.SIGNED_32; system.mod:285: context, status: SYSTEM.SIGNED_32; types.mod:61: ext-: RECORD extlev-, maxIdentLen-: INTEGER32; END; unix.mod hides the OpenVMS operating system interface) unix.mod:334: PID* = SY.SIGNED_32; (* Process Id. *) unix.mod:334: sec*, usec*: SY.SIGNED_32 unix.mod:334: BaseSecs: SY.SIGNED_32; (* TimeBase - UnixEpoch in seconds *) unix.mod:334: PROCEDURE Adr32* (VAR s :ARRAY OF SY.BYTE):SY.SIGNED_32; unix.mod:334: RETURN (SY.VAL(SY.SIGNED_32, adr) # adr); (* hG/28-Oct-1997 faster than next line*) unix.mod:334: PROCEDURE Exit*(status: SY.SIGNED_32); unix.mod:334: VAR mem: SY.SIGNED_32; unix.mod:334: result:SY.SIGNED_32; l: SY.SIGNED_64; unix.mod:334: VAR size: SY.SIGNED_64; result: SY.SIGNED_32; unix.mod:334: result := lib.LIB$FREE_VM (SY.SHORT(size), SY.VAL(SY.SIGNED_32, mem)); unix.mod:334: secs, usecs, n:SY.SIGNED_32; unix.mod:334: f0.fab.XAB := SY.VAL(SY.SIGNED_32, NIL); unix.mod:334: n: SY.SIGNED_32; unix.mod:334: VAR n: SY.SIGNED_32; unix.mod:334: ut.sec := SY.VAL(SY.SIGNED_32, clock); ut.usec := 0; unix.mod:334: dummy_length: SY.SIGNED_32; unix.mod:334: dummy_length: SY.SIGNED_32; unix.mod:334: cv := VMS.SYS$DCLEXH(SY.VAL(SY.SIGNED_32, ep)); (* todo 64Bit *) unix.mod:334: completion: SY.SIGNED_32 (*CV*); unix.mod:334: m : SY.SIGNED_32; --

3 4

Starting V4.
by peter＠easthope.ca 14 Jan '21

14 Jan '21

Hello again, The default routine for starting A2: (1) cd <workingDirectory> (2) execute aos or execute a script invoking aos. How is V4 started? Thanks, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

4 9

Smallest Oberon board ever made?
by Magnus Karlsson 13 Jan '21

13 Jan '21

I have been playing around with a concept of an Oberon board smaller than RPI zero just for fun. The board is 60 x 25mm in size and runs the Oberon disk image from projectOberon without modifications. It has an 8 MB PSRAM chip so with software changes it supports an 8MB Oberon system. FPGA: Artix 7-50 KB/Mouse via PS2 Video via microHDMI Serial/Power via microUSB 8 status LED 4 DIP switches reset/abort switch nRF24 RF chip with uFL antenna connector 8 MB PSRAM chip (IPS6404) via 128kB cache Video frame buffer in BRAM (mono) microSD socket As you can see in the images below the PS2 connectors are huge compared to the rest! https://www.saanlima.com/images/Oberon_zero/OZ3.jpg https://www.saanlima.com/images/Oberon_zero/OZ1s.jpg https://www.saanlima.com/images/Oberon_zero/OZ2s.jpg Booting: https://www.saanlima.com/images/Oberon_zero/IMG_5862.MOV The novel thing about this board is the use of a small QSPI PSRAM as main memory. Cheers, Magnus

12 40

Dynamic type of record var parameter
by Andreas Pirklbauer 12 Jan '21

12 Jan '21

Correction (typo). The correct new instruction in ORG.VarParam is IF x.deref THEN Put2(Ldr, RH, x.r, -8); incR (* <-- pass x.r and not 0 as the third parameter *)

1 0