August 2018 - Oberon - mailman3.inf.ethz.ch

FPGA - Modules.bin - inner core size
by Andreas Pirklbauer 21 Aug '18

21 Aug '18

And if it *has* to be done from disk, here is how the boot loader (BootLoad.Mod) itself determines the number of bytes to be transferred to main store: PROCEDURE LoadFromDisk; VAR src, dst, adr, lim: INTEGER; BEGIN src := FSoffset + 4; (*start at boot block*) ReadSD(src, 0); SYSTEM.GET(16, lim); ... So, it’s location 16 in the very first block.. See also: The commands Boot.Link and Boot.Load also report the number of bytes. https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Source…

1 0

FPGA - Modules.bin - inner core size
by Andreas Pirklbauer 21 Aug '18

21 Aug '18

On FPGA Oberon, the inner core consists of the 4 modules Kernel, FileDir, Files, Modules. The boot loader transfers it byte for byte to memory location 0. So, if you know the inner workings of how the modules are loaded, one way to “guess” the size of the inner core (not from disk but once loaded), is: mod := root; name := “Modules”; WHILE (mod # NIL) & (name # mod.name) DO mod := mod.next END ; IF mod # NIL THEN size := SYSTEM.VAL(LONGINT, mod) + mod.size END ;

1 0

FPGA - Modules.bin - inner core size
by Tomas Kral 20 Aug '18

20 Aug '18

Hi, I have coded a simple procedure storing inner core boot file. FOR sec = 2 TO 63 DO Kernel.GetSector(sec*29, buf); Files.WriteBytes(r, buf, Kernel.SectorLength) END ; Ignoring some trailing NULL sectors, I can guess a file size making the original inner core => 37056 bytes. Comparing to `Modules.bin' produced by `ORL.Linker', using very early and uptodate compiler revisions, I got inner core size 37344, 37568, bytes respectively. Also binaries differ in some 3452, 20300 bytes, respectively. The newer compiler the longer binary with more differencies. Is it something expected, or do I get something wrong? What can this be accounted for? -- Tomas Kral <thomas.kral(a)email.cz>

2 2

Previous *nix 32bit efforts lost !
by eas lab 20 Aug '18

20 Aug '18

Since this forum also handles hardware matters ? Why would: "Linux Native Oberon System 3 Alpha 121104 ( 04.November.2012 ), based on Native Oberon 05.01.03" being a 32bit system, run under 64bit linuxES, whereas few other, and most importantly for me, <Linux ETH Oberon> does NOT. In the days of evolution from 8bit to 16bit: the increased data-bus width system, included all the previous sized instructions, for compatibility reasons. A typical error trace, launcing 32b from a 64b system shows:-- ./TClauncHERE: exec: line 37: ./linux.oberon.nothr: not found root@box:/mnt/sdc3/MandrkLEO# ls -l ./linux.oberon.nothr -rwxr-xr-x 1 root 3 10463 Nov 12 2016 ./linux.oberon.nothr root@box:/mnt/sdc3/MandrkLEO# ldd ./linux.oberon.nothr ./linux.oberon.nothr: error while loading shared libraries: ./linux.oberon.nothr: wrong ELF class: ELFCLASS32 I'm guessing that LEO calls 32bit library[s], which does extra 32/64bit checking, which the <MainModule> doesn't do, and that LNO doesn't call any libraries. Let's check: ldd <LNOdir>/oberon == same: <error while loading shared libraries: wrong ELF class: ELFCLASS32> Since we now have gone down to the FPGA level, is the <kernel> of the ETHO [Native Oberon eg.] still. copyright/hidden ? ==TIA

3 2

i keep getting command execution error res:3401(-.Obx not found) can .obx files be compiled and install.How to correct this error
by Robert Lewis 18 Aug '18

18 Aug '18

2 1

FPGA - Simple OOP example
by Tomas Kral 16 Aug '18

16 Aug '18

Hi, Just reading Oberon book on OOP by Hanspeter Mosenbok. I would like to set a reusable code pattern for that, not sure how close I am, my try below. There is also other way of doing it, using so called `message' handler. Cheers Tomas MODULE Term; (* TK 14.8.2018 lower/capital case terminal, simple OOP example *) IMPORT Texts, Oberon; TYPE Term* = POINTER TO TermDesc; TermDesc* = RECORD write*: PROCEDURE(t: Term; ch: CHAR) END ; VAR W: Texts.Writer; t*: Term; (* Generic output routine accepting any Term based type *) PROCEDURE Out*(t: Term; ch: CHAR); BEGIN t.write(t, ch) END Out; PROCEDURE Write(t: Term; ch: CHAR); BEGIN Texts.Write(W, ch); Texts.Append(Oberon.Log, W.buf) END Write; BEGIN Texts.OpenWriter(W); NEW(t); t.write := Write; END Term. MODULE CapTerm; (* capital terminal *) IMPORT Term, Texts, Oberon; TYPE CapTerm* = POINTER TO CapTermDesc; CapTermDesc* = RECORD (Term.TermDesc) END ; VAR W: Texts.Writer; ct*: CapTerm; PROCEDURE CAP(ch: CHAR): CHAR; VAR up: CHAR; BEGIN up := CHR(ORD(ch) + ORD("A") - ORD("a")); RETURN up END CAP; PROCEDURE Write(t: Term.Term; ch: CHAR); BEGIN IF (ch >= "a") OR (ch <= "z") THEN ch := CAP(ch) END ; Texts.Write(W, ch); Texts.Append(Oberon.Log, W.buf) END Write; BEGIN Texts.OpenWriter(W); NEW(ct); ct.write := Write; END CapTerm. MODULE TestTerm; IMPORT Term, CapTerm, Texts, Oberon; VAR W: Texts.Writer; t: Term.Term; ct: CapTerm.CapTerm; PROCEDURE Run*; VAR S: Texts.Scanner; BEGIN Texts.OpenScanner(S, Oberon.Par.text, Oberon.Par.pos); Texts.Scan(S); WHILE S.class = Texts.Name DO Term.Out(t, S.s[0]); Term.Out(ct, S.s[0]); Texts.Scan(S) END ; Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf) END Run; BEGIN Texts.OpenWriter(W); t := Term.t; ct := CapTerm.ct; END TestTerm. TestTerm.Run a b c ~ -- Tomas Kral <thomas.kral(a)email.cz>

6 22

FPGA - Bitfield operations
by Chris Burrows 16 Aug '18

16 Aug '18

> > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Jan de Kruyf > Sent: Thursday, 16 August 2018 7:23 PM > To: ETH Oberon and related systems > Subject: Re: [Oberon] FPGA - Simple OOP example > > For Oberon to be a real alternative I would minimally need: > 1. single bit variables. > 2. packed arrays of those. > 3. if at all possible multi bit variables (2, 3, 4, 5 etc.) > 4. packed > records of single and multi bit variables. > I have also been thinking about ways to implement the very same set of features. E.g. something similar to the way PACKED RECORDS works with subranges in Pascal but with some finer control over alignment and endian issues etc. Two aspects of programming the ARM Cortex-M devices have triggered these thoughts: 1. Microcontroller designers cram many different values of different data types into a single 32-bit word. This requires many packing / unpacking / type casting operations to get at the values. 2. The 'Thumb-2' instruction set used in the ARM Cortex-M3, M4 and M7 microcontrollers has efficient 'bitfield' instructions. So far I just have used the simplest approach by implementing these instructions directly as SYSTEM functions. SYSTEM.BFI is Bitfield Insert and SYSTEM.UBFX is Unsigned Bitfield extract. The following examples illustrate this. E.g. hours are stored in a time variable as a 5-bit value in bits 20..16 PROCEDURE* Pack*(hh, mm, ss: INTEGER; VAR ctime: INTEGER); VAR t: INTEGER; BEGIN t := ss; SYSTEM.BFI(t, 13, 8, mm); SYSTEM.BFI(t, 20, 16, hh); ctime := t END Pack; PROCEDURE* Unpack*(ctime: INTEGER; VAR hh, mm, ss: INTEGER); BEGIN SYSTEM.UBFX(ss, ctime, 5, 0); SYSTEM.UBFX(mm, ctime, 13, 8); SYSTEM.UBFX(hh, ctime, 20, 16) END Unpack; In case you are wondering the missing bits 6, 7, 14, 15, 21, 22, 23 and 27..31 are reserved and bits 26..24 represent the day of the week (0..6)! I hope to have some more to say on this subject in the not too distant future ... Regards, Chris Chris Burrows CFB Software http://www.astrobe.com/RISC5

2 1

FPGA - Simple OOP example
by Andreas Pirklbauer 16 Aug '18

16 Aug '18

> Just to make it clear, we are discussing the original Oberon > instance-bound OOP rather than the Oberon-2 type-bound OOP. > I know that there is no type bound OOP in Oberon-07. > > Throwing away Oberon-2 was a religious decision, was it not? A somewhat related topic (Class Methods Vs. Procedure variables in Records) has been discussed in this forum sometimes last year: http://lists.inf.ethz.ch/pipermail/oberon/2017/010300.html Rivers of ink have been spilled on the question whether Oberon and Oberon-2 remained separate languages, so I am not going to add to that. I suppose most arguments are well known by now.

2 1

Conditional compilation using IF const THEN
by Andreas Pirklbauer 12 Aug '18

12 Aug '18

> I know the *system* is not the same, but at least your compiled code is. > The overhead of the empty call and return is pretty low, at least in > a non-cached system. :) As a further refinement, one could reduce the “overhead" down to a single function call in the IF itself: IF Out.Debug() THEN … debug code … END instead of IF debug THEN … debug code … END Of course, the debug code is still sitting there, as are the strings used by it, but it is never executed if Out.Debug() returns FALSE; which one can achieve by replacing the (dynamically-loaded) Out module with a stub version in production.. The purist will of course not be satisfied with all these shenanigans discussed here. Apart from compiler directives (which one can have different opinions about - see Tony Hoare’s comment), I don’t know of any truly satisfactory and/or “clean” solution to this.

3 3

Scholarly advice.
by peter＠easthope.ca 12 Aug '18

12 Aug '18

Added this section to the wiki book. https://en.wikibooks.org/wiki/Oberon#Primary_References Advice about details or format? Additional primary references? Thanks, ... Lyall E. -- Message composed and transmitted by software designed to avoid the need, overhead and vulnerability of antivirus software. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0