November 2015 - Oberon - mailman3.inf.ethz.ch

Astrobe for FPGA
by greim 13 Feb '16

13 Feb '16

Hallo Chris, > > Yes - editing, compiling and uploading are all done on the PC using the > Astrobe IDE. The Oberon source code files on the PC are just text files so > you can use any of your other Windows software development tools (editors, > difference listers, version control systems, grep searches) to maintain > them. The resulting modules (*.rsc files) are dynamically linked on the FPGA > exactly as they are in the full Project Oberon system. > > The core OS modules that I use - Kernel, FileDir, Files and Modules (the > dynamic loader), are identical to the Project Oberon distribution except for > one difference: I have implemented a Files.SetDate function that I call from > the Upload function so that files uploaded from the PC have the same date / > timestamp on the Oberon system. > > As for a 'business model' Astrobe for FPGA RISC5 is free - you'll just have > to register your name and email address to use it: > > http://www.astrobe.com/forum/viewtopic.php?f=13&t=476 > > The downside is that you will get half-a-dozen or so Astrobe-related emails > from me each year ;-) > thats ok, i guess i already got it, because afaik I have a license for ARM... > Support is limited to this mailing list and the Astrobe forum. Anything else > that would create work for me which I am not already doing for myself I > would have to charge for e.g. helping you to get it working on a board that > you have built or purchased for your own or commercial use. An exception > would be for individuals like Magnus (Saanlima) or Enso who were developing > a board specifically aimed at supporting Oberon. I am happy to try and help > them if possible - the only cost to them would be to send me a board to work > with. If Xilinx or Altera was the customer that might be a different story > :) > ok, thats a very fair business model > No Linux version of Astrobe for RISC5 is planned - it requires Windows 7, 8 > or 10. > > If you wanted a Linux version you would be able to use the target system as > long as you had a Linux tool to write the supplied core OS disk image to an > SD Card. You would also need: > > * A Linux text editor to create your Oberon programs > * To port the RISC5 Oberon compiler to Linux. > Gardens Point Component Pascal (GPCP) for JVM might be a good starting > point. It only took a couple of days to port the compiler using GPCP for > .NET > * A Linux terminal emulator that can run at 115200 baud to upload the object > files (*.rsc) to the target. ok, maybe i will make a try with WINE, but i have also Windows in a container on my Linux desktop, i must confess.... > > Sorry - I missed your last question in my previous reply. Yes you can use > the full featured FPGAOberon system as your developing/master system. You > just need a way of transferring the resulting .rsc files from the full > system to your target system. I'll supply a disk image for the full system > as well as the core OS to make sure that the module versions are compatible. > that sounds very elegant... One last question regarding this topic: The timing of the full FPGAOberon is strongly influenced by the CRT refresh rate. Is there any speed/clock-frequency increase with your slim system realized/possible? Best Regards Markus

2 2

Re: [Oberon] Numerical CASE Statements in Project Oberon
by John Stout 17 Jan '16

17 Jan '16

Jan I wasn't suggesting that we NOT implement it, just that compiling it (implementing it) to a series of compiled IF THEN statements may be more in keeping with NW's view. Suppose we have (taken from the Oberon-07 report): CASE k OF 0: x := x + y | 1: x := x − y | 2: x := x * y | 3: x := x / y END This would compile, using IF THEN equivalents, to code like this (I've assumed that R14 is a base register): LDR0, R14, k_offset SUBR1, R0, 0 BNECase_1 code for x := x + y BEnd_Case Case_1: SUBR1, R0, 1 BNECase_2 Code for x := x - y BEnd_Case Case_2: SUBR1, R0, 2 BNECase_3 Code for x := x * y BEnd_Case Case_3: SUBR1, R0, 3 BNEEnd_Case Code for x := x / y End_Case: This is simple and clear. There is a clear maximum execution path length. Adding label ranges is a bit longer, but still (I think) simple and clear, e.g., CASE k OF 0 .. 10: x := x − y | 11 .. 1000: x := x * y | 1001 .. 2047 : x := x / y END could compile to something like this: LDR0, R14, k_offset SUBR1, R0, 0 BLTCase_1 SUBR1, R0, 10 BGTCase_1 code for x := x - y BEnd_Case Case_1: SUBR1, R0, 11 BLTCase_1 SUBR1, R0, 1000 BGTCase_2 Code for x := x * y BEnd_Case Case_2: SUBR1, R0, 1001 BLTCase_1 SUBR1, R0, 2047 BNEEnd_Case Code for x := x / y End_Case: This will work even for very large ranges. The size of the generated code (no data needed) depends on the number of cases, not the range of the constants in the case label list or case label range. Adding label lists: CASE k OF 0, 10: x := x − y | 11, 1000: x := x * y | 1001, 2047, 19 : x := x / y END could compile to something like this: LDR0, R14, k_offset SUBR1, R0, 0 BEQC_1 SUBR1, R0, 10 BNECase_1 C_0:code for x := x - y BEnd_Case Case_1: SUBR1, R0, 11 BEQC_1 SUBR1, R0, 1000 BNECase_2 C_1:Code for x := x * y BEnd_Case Case_2: SUBR1, R0, 1001 BEQC_3 SUBR1, R0, 2047 BEQC_3 SUBR1, R0, 19 BNEEnd_Case C_3:Code for x := x / y End_Case: John >> Am 16.11.2015 um 09:31 schrieb Jan de Kruyf <jan.de.kruyf(a)gmail.com>: >> >> Yes, >> The old man has been right most of the time, I agree. And I will have >> a royal battle to reduce the compiler construction back down to >> Wirthian elegance, that I also realize. But at the same time the code >> I produce is very elegant and sweet. On the basis of that I would say >> you are wrong in your statement that IF THEN can be made as efficient >> as a good case construct. Besides, a Case statement allows ranges >> like A..Z, a..z and so on, this has never been part of IF THEN, while >> in a properly constructed bin-tree it resolves itself. >> >> So since Wirth was first and foremost a teacher all his life, we >> could say that there are 2 learning opportunities here 1. to produce >> fast code. >> 2. to construct an elegant way of doing so. >> >> I think that the master himself also realized the issues you and I >> are bringing up, and did not see his way out of the predicament yet. >> And since he is about 80 now and since he still got a few irons in >> the fire this was left for a bit. >> >> Lastly Dijkstra taught that you should never limit yourself because >> of inefficient machines. But you should strive to generalize any >> language design solution to as many cases as possible, even if that >> slows your program execution down a bit. There were big arguments in >> the Algol design meetings about that. Some people then felt that you >> had to live with the equipment given and use it as efficiently as >> possible. Wirth no doubt knows that whole history even better than I >> do. In the mean time of course, the machine limitations of those days >> (it was the time of the vacuum tubes) have been solved a hundred >> times over, but we still are trying to live with the language limitations of some of the older languages. >> Ergo the numerical case statement is in the O-7 language report, but >> is has not been implemented yet. >> >> So I feel fully justified implementing it. The way how to, we can >> talk about. If the Oberon community is alive and well ten I am sure >> that the last word has not been spoken yet. >> >> >> Enjoy your day >> >> j. >> [King George V Logo] John Stout Management Information Systems Coordinator Tel: 01704 530601 E-Mail: JSS(a)kgv.ac.uk Web: www.kgv.ac.uk Information contained in this e-mail is intended for the use of the addressee only and is confidential. Any dissemination, distribution, copying or use of this communication without prior permission of the addresseeis strictly prohibited. Every effort has been made to ensure that any attachment to this mail does not contain virus. King George V College has taken every reasonable precaution to minimise this risk, neither it nor the sender can accept liability for any damage which you sustain as a result of software viruses. You should carry outyour own virus checks before opening any attachments. [Think Before You Print]

11 17

Functional programming style for Oberon?
by eas lab 14 Jan '16

14 Jan '16

Some years ago when the OO-paradigm was at it's peek, ETHO was extended to handle procedure types, which could be passed as arguments. There's great advantages in avoiding temporary-fads, so I never exercised OOP. Now [using LEO] that it's less easy to access my old NativeOberon files, I failed to find the documentation, and example uses of the <passing PROCs as arguments>. Where should I look? Can Oberon procedure types facilitate the <functional/compositional> style of programming? Which is NOT a passing fad. *nix's <piping of functions/data-transformers> is staggeringly economical in user's effort, but has a terrible syntax. The benefit of removing the need to learn ad-hoc syntaxS is my motivation for syntax-directed-editors & menu-driven-usage: which ETHO already used successfully. An example of *nix's ability to easily get results by piping a sequence of existing/proven/well-tested functions together [but using understand-able syntax] is:-- CheckTheFileDataBaseForFilesNamed *roc*ointer* | ButSkipAllFiles *.pdf *.zip *.ps *.gz | AndListThoseContainingString "beron" The big advantage of this functioal/compositional style is the maintainablity. Which is the whole idea of NW's "MODUL"a and "COMPONENT" pascal. Some years ago, when my then ISP introduced Sender-must-ID for email, it was quite a job to modify the ETHO <emailer>. Now there's a new-fad which messes my TextToSpeech facility: instead of 'saying' "can't", it says "Sea Aye Enn Tea"; because many feature/fad-following clowns are replacing the one-byte single-quote [ASCII] by 3 bytes. Since the substantial processing-stages of fetching [unfortunately these days http-formatted] text, visually scanning it to wipe-out <bad sections> by an ETHO-like editor, and getting the TestToSpeech to a device, as a suitably-named file, needs only a few mouse-chords and typing the chosen name, you don't need to understand the details of each stage. So you can just plug-a-function-into-the-pipe-line to: <translate the 3-byte-quote-fad to ASCII(SingleQuote)>. Which just needs pasting from your library of examples, a 10 char line, and editing/modifying it; into the suitable pipe-line position. That's why I call it MickeyMouse programming. A most convincing argument, for me, for the functional style, is:-- Let's create a list of all even numbers up to 100, and another list omitting the first five of them. The program written in Java. final int LIMIT=50;int[] a = new int[LIMIT]; int[] b = new int[LIMIT - 5]; for (int i=0;i < LIMIT;i++) { a[i] = (i+1)*2; if (i >=5) b[i - 5] = a[i]; } The program written in ### let a = [2,4..100] let b = drop 5 a It is immediately clear that with ###, you can understand what's going on; whereas in Java, or any imperative language, you can barely tell what the code is supposed to do because you are overwhelmed with the low-level minutia. This effect increases as programs grow more complex. From this simplicity and abstraction flow most of ###'s advantages. ----------------------------- end of extract. -------------------- ### <- let's not get stuck on NAMES. Let's rather first understand the CONCEPTS. Of course, the above is an extreme example, but ETHO's already existing facilities could perhaps do: MapFunctionOverElements(DigitToText:PROC, DigitSequence: TextString):TextString; MapFunctionOverElements(TestForPrime:PROC, Ints1toN: IntegerList):IntegerList; There's nothing new about this. Extracting from McCarthy [designed lisp in 60s?]:- These three procedures clearly share a common underlying pattern. They are for the most part identical, differing only in the name of the procedure, the function/job of a used to compute the term to be added, and the function that provides the next value of a. We could generate each of the procedures by filling in slots in the same template: ------ snip lisp code --- The presence of such a common pattern is strong evidence that there is a useful abstraction waiting to be brought to the surface. Indeed, mathematicians long ago identified the abstraction of summation of a series and invented ``sigma notation,'' to express this concept. The power of sigma notation is that it allows mathematicians to deal with the concept of summation itself rather than only with particular sums -- for example, to formulate general results about sums that are independent of the particular series being summed ... What are unforeseen problems in using ETHO to do this too? == Chris Glur. PS. it's very problematic pasting the pre-written text into the web-browser for gmail [designed for F/B-twitter kiddies=modern] compare to the 90's N-O emailer. Can Linux:Aos handle gmail?

6 12

Re: [Oberon] OberonStation
by Chris Burrows 01 Dec '15

01 Dec '15

Hi Bob, I have solved the backup problem in a different way. I use Astrobe for RISC5 for developing with an OberonStation. I keep all of the Oberon sources on Windows and just compile and upload the executables (*.rsc) files at 115200 baud to the OberonStation via an RS232 dongle. This version of Astrobe will be generally available (for no charge) within a week or two. See the announcement on the OberonStation forum: http://oberonstation.x10.mx/smf/index.php?topic=15.0 Regards, Chris Burrows CFB Software http://www.astrobe.com > -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Bob Walkden > Sent: Tuesday, 24 November 2015 11:09 PM > To: ETH Oberon and related systems > Subject: [Oberon] OberonStation (was: Numerical CASE Statements in > Project Oberon) > > I've also just bought an OberonStation. On Saturday I managed to > delete all the object files on the SD card... :0( > > It's a great piece of kit and a really minimalistic implementation of > Oberon (I also have NO running on a Thinkpad from the 90s). > Definitely tightrope walking without a safety net, so I'm also > setting up a nrf24l01 network using an Arduino attached to a PC so > that I can backup my own files from the SD card. It's likely to be a > bit Heath Robinson. > > I downloaded the image onto another SD card to recover. For some > reason the image wouldn't fit on the original 2gb card. > > Good job I hadn't actually developed anything beyond little test > modules. > > Bob > > > > On 24 Nov 2015, at 12:26, John Stout <JSS(a)kgv.ac.uk> wrote: > > > > I've just bought an OberonStation and am getting to grips with it. > I think the first task is to get another nRF24L01+ system working so > that I can transfer stuff to and from it. > > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related > systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

2 4

Fault in https://en.wikipedia.org/wiki/Oberon_(operating_system).
by Peter Easthope 01 Dec '15

01 Dec '15

Hi, When https://en.wikipedia.org/wiki/Oberon_(operating_system) is opened for editing, the wikimedia software complains that a reference has two titles. These are "Oberon - The Oberlooked Jewel" and "The School Niklaus Wirth - The Art of Simplicity". Only the second title is displayed under References. Currently it is reference 25 and the number will change when a preceding reference is added. I don't know which of the two is preferred. Someone with a more direct interest can make the correction. Regards, ... Peter E. -- Telephone 1 360 639 0202 or +13606390202. Bcc: peter at easthope.ca http://easthope.ca/Shop.html

2 1

Re: [Oberon] Raspberry Pi Revisited
by J. 30 Nov '15

30 Nov '15

Ja ok, I did mean de Wachter in fact. But yes you also do system calls in olr. J. Sent from my ASUS MeMO Pad Peter Matthias <PeterMatthias(a)web.de> wrote: >Hi Jan, > >I think you got confused with all these Peters here ;-) Jan was talking >about Peter de Wachter. And there is also Peter Easthope here. >Unfortunately Peter Muller left. > >I am not in the details, but I am sure, GPIO can be accessed both, via >memory mapped devices and read/write operations, also within Oberon >Linux Revival on RPi. > >If doing some hybrid (ARM/FPGA) staff I would recommend using existing >hardware like MiST board. ( http://harbaum.org/till/mist/index.shtml ) > >Regards, > Peter M. > >Am 30.11.2015 um 16:26 schrieb Jan de Kruyf: >> On a scale from 5 .. 0 I would say 4.5 since I dont have a Pi Zero. >> But in general more rattling of kettles and lighting of fireworks on the >> Oberon front is Good (tm) >> >> Peter has some way of doing linux system calls. I am sure GPIO could be >> used that way? >> >> I just need a Round Tuit at the moment for a few things, so don't rely >> on me. >> But I _will_ clap for you. >> >> cheers, >> >> j. >> >> >> On Sun, Nov 29, 2015 at 6:37 PM, Jack Johnson <knapjack(a)gmail.com >> <mailto:knapjack@gmail.com>> wrote: >> >> With the release of the $5 Raspberry Pi Zero, I started thinking >> about the viability of a hybrid RISC platform. I've been thinking >> for a while about how I might simulate networking via a TUN/TAP >> implementation in Peter's fantastic emulator, but I'm also now >> wondering if it might be possible to expose the Pi's GPIO to the >> emulator as well, and end up with something that bridges the FPGA >> work and the emulator in a way that would be interesting and healthy >> for both. >> >> Interesting or pointless? >> >> -Jack >> >> -- >> Oberon(a)lists.inf.ethz.ch <mailto:Oberon@lists.inf.ethz.ch> mailing >> list for ETH Oberon and related systems >> https://lists.inf.ethz.ch/mailman/listinfo/oberon >> >> >> >> >> -- >> Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems >> https://lists.inf.ethz.ch/mailman/listinfo/oberon >> >-- >Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems >https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

Raspberry Pi Revisited
by Jack Johnson 30 Nov '15

30 Nov '15

With the release of the $5 Raspberry Pi Zero, I started thinking about the viability of a hybrid RISC platform. I've been thinking for a while about how I might simulate networking via a TUN/TAP implementation in Peter's fantastic emulator, but I'm also now wondering if it might be possible to expose the Pi's GPIO to the emulator as well, and end up with something that bridges the FPGA work and the emulator in a way that would be interesting and healthy for both. Interesting or pointless? -Jack

4 3

Blacklisting
by Peter Easthope 30 Nov '15

30 Nov '15

This is new. <oberon(a)lists.inf.ethz.ch>: host phil3.ethz.ch[129.132.183.132] said: 550 192.185.51.172 blacklisted at zen.dnsbl.ethz.ch 127.0.0.4 (in reply to RCPT TO command) Not surprising that 192.185.51.172, a big commercial server, might issue some rubbish. Is blacklisting automated? A human decision? Regards, ... Peter E. -- Telephone 1 360 639 0202 or +13606390202. Bcc: peter at easthope.ca http://easthope.ca/Shop.html

1 0

Re: [Oberon] Numerical CASE Statements in Project Oberon
by Chris Burrows 28 Nov '15

28 Nov '15

I am not talking about Ada or the Astrobe ARM compiler. I am talking about the Wirth's Oberon RISC5 compiler as used in Project Oberon. One example of the technique I used can be seen in the Project Oberon source code in ORG.Index: IF x.mode IN {ORB.Var, RegI} THEN x.a := y.a * s + x.a ELSIF x.mode = ORB.Par THEN x.b := y.a * s + x.b This could have been, but was not, written as: IF (x.mode = ORB.Var) OR (x.mode = RegI) THEN x.a := y.a * s + x.a ELSIF x.mode = ORB.Par THEN x.b := y.a * s + x.b x.mode is an INTEGER and {ORB.Var, RegI} is a SET constant just as in my version of your example t is an INTEGER and {7, 9..10}. This is perfectly valid RISC5 Oberon code. If you want to advocate the use of 'numeric' CASE statements try again. Pick an example (preferably real world rather than hypothetical) that is not as easily transformed into IF THEN ELSE. The only type of example I can think of is one that uses a disjoint set of several characters e.g. {"a", "e", "i", "o", "u"}. That is the only significant argument I can think of that remains in support of the usefulness of 'numeric' CASE statements Note also that the definition of SET in the Oberon Report has now become less restrictive Oct 2013: the sets of integers between 0 and 31 Mar 2014: the sets of integers between 0 and an implementation-dependent limit (Although the current RISC5 compiler has the limit set at 31). ------ In the following I AM now talking about the Astrobe ARM compiler: A comparison of the releative efficiency / performance of IF THEN ELSE and CASE statements in the Astrobe ARM Oberon compiler is included in section 6.2 "CASE Statements" in the Astrobe Oberon Programmers Guide. You can download a copy from: http://www.astrobe.com/Oberon.htm The conclusion was: "Timing tests using an example with ~30 cases, assuming each word occurs with the same frequency, indicates that the CASE solution is 4 times faster than the IF-THEN ladder solution. However, the CASE approach generates 5% more code." Those sorts of results could make a significant difference to an application and were achieved using a jump table. ------ I do use Peter's Oberon RISC emulator to check disk images etc. but I have only used it on Windows and would have no idea what is causing the problem you have seen. You will just have to roll your sleeves up and start debugging :-; At the risk of stating the obvious, assuming you have been making your changes incrementally, go back to the last version that worked, check the changes you made at that time and isolate the issue down to a test case. By that time you will either have worked out the answer yourself or will have something simple to report to Peter to identify. Cheers, Chris > > From: Jan de Kruyf [mailto:jan.de.kruyf@gmail.com] > Sent: Sunday, 29 November 2015 7:04 AM > To: chris(a)cfbsoftware.com; ETH Oberon and related systems > Subject: Re: [Oberon] Numerical CASE Statements in Project Oberon > > This is Ada, or set membership Chris, but you might have it included > in your compiler. > > "x IN s stands for "x is an element of s". x must be of type INTEGER, > and s of type SET." > > both in O-2 and O-7. > While I was comparing character or integer conditionals. Sure, in > real life if your cases are under 32 you might choose to use a set > rather than a case construct. > --- > > But I want to ask you something that you might know: > For starters I modified the Parser and the code Generator under > norebo from Peter de Wachter which is a derivative of his RISC > intepreter. In any case this worked fine. > > Then I modified the Scanner of the compiler to have the case > construct. This also implied recompiling ORB. > Everything compiled fine, but noway can I get the complete compiler > to run. > > It brakes on a STR or LDR instruction that is used as a Linux kernel > signal / call, but the IO address is not right the runtime says. > > So I am a bit at loss here. Did Peter modify the compiler source code > at all to accomodate his Linux interface or is it some silly bug I > introduced? > > Have you used his interpreter at all? > > Thanks, > > j. > > > On Sat, Nov 28, 2015 at 2:18 PM, Chris Burrows > <chris(a)cfbsoftware.com> wrote: > Maybe so, but that is not a fair comparison. I would have written > your IF THEN ELSE example as: > > IF t DIV 32 = 0 THEN > IF t IN {7, 9..10} THEN > t := 11 > ELSIF t IN {13, 14..16} THEN > t := 12 > END > END; > > Which is only 32 instructions using your same method of counting. > > If (as in your example) you knew for sure that t was in the range of > 0..31 you wouldn't need the initial DIV statement either, > > Regards, > Chris Burrows > CFB Software > http://www.astrobe.com > > > > > > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > > Jan de Kruyf > > Sent: Friday, 27 November 2015 2:04 AM > > To: ETH Oberon and related systems > > Subject: Re: [Oberon] Numerical CASE Statements in Project Oberon > > > > Here is some news: > > > > We get cleanly compiling code. > > > > With this test module: > > ------- > > MODULE TestIf; > > VAR t : INTEGER; > > > > BEGIN > > t := 10; > > IF ((t >= 9) & (t <= 11)) OR (t = 7) THEN > > t := 11; > > ELSIF (t = 13) OR ((t >= 14) & (t <= 16)) THEN > > t := 12 > > END; > > > > CASE t OF > > 9 .. 11, 7 : t := 11; > > |13, 14 .. 16 : t := 12 > > END; > > > > END TestIf. > > ----------- > > > > When I only compile the IF structure I get 37 assembly > instructions, > > average seek for named values is 13.66 instruction times. > > When I only compile the CASE structure I get 40 assembly > instructions, > > average seek for named values is 7.33 . > > (this is from doing a hand count through the search structure) > > > > A lot of waste in the IF is generated by reloading the 't' variable > > for every compare, while I steal a register to keep 't' loaded. > > > > j. > > > >

1 0

Re: [Oberon] Numerical CASE Statements in Project Oberon
by Chris Burrows 28 Nov '15

28 Nov '15

Maybe so, but that is not a fair comparison. I would have written your IF THEN ELSE example as: IF t DIV 32 = 0 THEN IF t IN {7, 9..10} THEN t := 11 ELSIF t IN {13, 14..16} THEN t := 12 END END; Which is only 32 instructions using your same method of counting. If (as in your example) you knew for sure that t was in the range of 0..31 you wouldn't need the initial DIV statement either, Regards, Chris Burrows CFB Software http://www.astrobe.com > > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Jan de Kruyf > Sent: Friday, 27 November 2015 2:04 AM > To: ETH Oberon and related systems > Subject: Re: [Oberon] Numerical CASE Statements in Project Oberon > > Here is some news: > > We get cleanly compiling code. > > With this test module: > ------- > MODULE TestIf; > VAR t : INTEGER; > > BEGIN > t := 10; > IF ((t >= 9) & (t <= 11)) OR (t = 7) THEN > t := 11; > ELSIF (t = 13) OR ((t >= 14) & (t <= 16)) THEN > t := 12 > END; > > CASE t OF > 9 .. 11, 7 : t := 11; > |13, 14 .. 16 : t := 12 > END; > > END TestIf. > ----------- > > When I only compile the IF structure I get 37 assembly instructions, > average seek for named values is 13.66 instruction times. > When I only compile the CASE structure I get 40 assembly > instructions, average seek for named values is 7.33 . > (this is from doing a hand count through the search structure) > > A lot of waste in the IF is generated by reloading the 't' variable > for every compare, while I steal a register to keep 't' loaded. > > j. > > > On Tue, Nov 24, 2015 at 8:38 PM, Jan de Kruyf > <jan.de.kruyf(a)gmail.com> wrote: > John, thats a complex matter really. > > Anything we dont know at compiletime is left dangling for resolving > 'later'. > Part of that 'later' is resolved by the linker, in Linux or Windows. > And still more is resolved when the code gets loaded. > > In Oberon, in general there is no linker, except when we want to > build some boot-code. > > Everything not known at compile-time must then be fixed up when we > load the module. And to complicate matters, some choices are made by > the system designer about what we actually _want_ to know at compile > time. It is basically a cost / benefit choice, sometimes it is easier > to leave the complete solution until load time, although at least > part of the knowledge was available at compile-time. > > In the case I queried I did not see a reference to the index register > that LDR uses. That space as left at '0' to be patched at load-time > (so it looked as if R0 was to be used for an index), although R12, > the standard index register, could have been written there at > compile-time for my specific code. > > Section 6.3 gives some small introduction to the art of loading. Near > the end of the page is the line: > "At the very end of the file three integers called fixorgP, fixorgD, > and fixorgT are read." > That is where he talks about the patching. > > From the code in Modules.Load and from the compiler description it > follows that globals need to be treated specially, since they might > come of any module. So although we might have a partial knowledge of > the place of a 'local' global at compile time, it is obvious that we > don't know at all about globals in other modules. So Wirth chose to > fix them all in one place: the module loader. > > In any case: a good way to learn compilers is to target a small micro > controller that you know very well, and adapt the Oberon 0 compiler. > I have done it many years ago for an 8 bit AVR, and it has helped me > ever since. > > Cheers, > > j. > > > On Tue, Nov 24, 2015 at 1:22 PM, John Stout <JSS(a)kgv.ac.uk> wrote: > Jan > > Yes, that's the one although my copy is on faded line printer paper! > > I'm interested in your email about code generation: what does > Module.Load patch and to what? > > I've just bought an OberonStation and am getting to grips with it. I > think the first task is to get another nRF24L01+ system working so > that I can transfer stuff to and from it. > > John > > > --------------------------------------------------------------------- > - > > Message: 1 > Date: Mon, 23 Nov 2015 12:09:45 +0200 > From: Jan de Kruyf <jan.de.kruyf(a)gmail.com> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Numerical CASE Statements in Project Oberon > Message-ID: > <CAA85NCh6R8Xf-Tp53sFF0=F_5rnH7WXoeTyeDQss- > eDMsVMaLg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Is it this one John? > > http://homepages.cwi.nl/~steven/pascal/ > > There are links there to a 76 version from eth. > > j. > > > On Mon, Nov 23, 2015 at 9:47 AM, John Stout <JSS(a)kgv.ac.uk> wrote: > > > Well, I should have done a bit more research before making my > comments, > > and/or done all the exercises in Compiler Construction, which would > have > > lead me to Professor Wirth's preferred implementation for CASE. > > > > I have the source code for the Pascal P4 compiler from 1976 > (courtesy of > > Lancaster University) and that uses this system, although it does > place a > > maximum of 1000 on the number of cases. > > > > John > > [King George V Logo] > John Stout > Management Information Systems Coordinator > Tel: 01704 530601 > E-Mail: JSS(a)kgv.ac.uk > Web: www.kgv.ac.uk > > > Information contained in this e-mail is intended for the use of the > addressee only and is confidential. Any dissemination, distribution, > copying or use of this communication without prior permission of the > addresseeis strictly prohibited. > > Every effort has been made to ensure that any attachment to this mail > does not contain virus. King George V College has taken every > reasonable precaution to minimise this risk, neither it nor the > sender can accept liability for any damage which you sustain as a > result of software viruses. You should carry outyour own virus checks > before opening any attachments. > > [Think Before You Print] > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related > systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon >

2 1