December 2012 - Oberon - mailman3.inf.ethz.ch

Doubt from Project Oberon book.
by Srinivas Nayak 25 Dec '12

25 Dec '12

Dear All, From the book, Project Oberon, I read, 2.2.2. Commands The parameter text must refer to objects that exist before command execution starts and are quite likely the result of a previous command interpretation. In most operating systems, these objects are files registered in the directory, and they act as interfaces between commands. The Oberon System broadens this notion; the links between consecutive commands are not restricted to files, but can be any global variable, because modules do not disappear from storage after command termination, as mentioned above. What is the meaning? I couldnt understand this. Also I found that, this book uses technologies/terminologiesof 1980s which make things bit difficult to understand, for us who are used to with latest technologies/terminologies. Example, RAM/Memory is referred as "store". With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

5 10

Re: [Oberon] Oberon Digest, Vol 104, Issue 22
by Guenter Dotzel 25 Dec '12

25 Dec '12

I already tried recently but failed badly to encourage people on this list to only quote what is really essential to see what you are replying to.

1 0

On Commands in Oberon.
by Srinivas Nayak 24 Dec '12

24 Dec '12

Dear All, I have seen and understood how middle mouse button works on a command in Oberon. I have seen commands of the form Module.Procedure parameter1 parameter2 ~ However, recently I came across some new verities of input parameters. Like Module.Procedure * Module.Procedure ^ ~ Also while reading Programming in Oberon A derivative of Programming in Modula-2 (1982) Niklaus Wirth - a 65 page document briefing the programming in Oberon - I found that, 22.4 Standard Input and Output The following conventions have established themselves for the designation of input texts. Assume that the command (procedure) name is followed by - an identifier (possibly qualified). Then this is the name of the input text (input file), - an asterisk (*). Then the marked viewer (window) contains the input text, - an @ symbol. Then the most recent text selection is the beginning of the input text, - an arrow (^). Then the most recent selection denotes the file name of the input text. What is the meaning of this, can you please help me understanding this? How shall we be able to activate commands of the form, Module.Procedure * Module.Procedure ^ ~ Module.Procedure @ etc. With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

3 3

Oberon compiler futures
by Mike McGaw 24 Dec '12

24 Dec '12

Regarding the suggestions to create an Oberon compiler that somehow connects to GCC, but at one of the intermediate code levels: I would argue that we should be careful of such an exercise for many reasons, not the least of which is the fact that GCC and the underlying structures are huge and as others have pointed out, are a moving target. We have already options for Oberon compilers that generate C. I have never liked that approach; it is rather like taking a bath with your socks on. But, it can (and has already) been done. I would argue that we should instead concentrate on a very clean, very straight forward VM, and then write a back end accordingly. I am not in favor of the Java VM, or other such VMs- they are too big, too complex and too much of a moving target. Rather, I think a clear, concise, clean design is needed here. If the VM is well conceived, we should be able to 'kill all the birds (with one stone)' that have been discussed, whether your need is embedded, to be able to run Oberon TUI, etc., etc. If the VM is well conceived, for example, written in a subset of Oberon that could be compiled also, let us say, by M2, then, this VM source can be easily machine translated to the language of your choice (including C). But here, because (if the VM is cleanly conceived) the source Oberon/M2 implementation is elemental, the resulting target language translation should be readily digestible not only to the reader of the translated source, but this should also be reliably compiled by almost any (C) compiler you wish to use. A major plus is that the plethora of (C-based, or at least C-callable) device drivers become available in a direct way to this (translated-to-C) VM. And we could finally, once and for all, lock in on a target backend architecture, which would also, once and for all, fix the object format so that the module loader, once and for all, could be fixed. THAT would make the system portable, and provide a future lifetime comparable to the venerable P-system based Pascal, and far more useful. If you really, really, really had to have native code, then, it would be a much simpler exercise to design translators that map the VM op codes and so on to the new target native op codes and so on. How easy this is to do will depend alot on the VM design, and the target native architecture of course, but, the RISC VM and compiler that Wirth is working on should enable a reasonably straight-forward means of doing such a translation to another RISC target (since most of what we are seeing today are RISC machines of one sort or another). The benefits of this are immediately recognizable. Getting an Oberon system up on the Raspberry Pi would be a walk in the park, if we had such a compiler and associated VM. -M

6 7

ARM:ETHO ?
by eas lab 23 Dec '12

23 Dec '12

I used to think that gcc was mature/stable, but I recently had bad experience trying to install Linux: Festival TextToSpeech from Edenbourgh (sp) university, and that's where I REALLY needed LEO to untangle the mess. chris(a)gcjd.de-web.ws wrote:- > I would recommend aagainst this way unless you are experienced with gcc > internals already. ;-) > ... > Several years ago I evaluated this way and unless things have changed > very much since then gcc internals are a mess, documentation is soso and > gcc is a huge and moving target not easy to handle if you have been > exposed to Wirth style. Yes moving target: the people who had succeeded in installing festival, had the version of the OS & gcc that matched the version of festival. In contrast I installed LEO several years ago when using Mandrake9, then when I move up to FC1, on a different partition, I just linked to the old LEO and again when I moved up to Slak13 [to get better USB use], and LEO behaves the same under all versions of Linux that I've used [which have X]. Peter Matthias' proposed project is probably the closest to ARM:ETHO. I *MUST* have the TUI look-and-feel. But LEO's easy acces to the dir-system instead of the continuation of the flat-file-system which LNO catered for is necessary. So I had another look into LEO's docos:-- This is fom LEO's docos, where my comments are thus "=>" => Oberon.Desk == Base Systems: x86 Linux Tool. (Linux Kernel >= 2.6 !!) x86 Solaris Tool. sparc Solaris Tool. ppc MacOS X Tool. (Darwin >= 6.2 !!) ppc Linux (no longer supported) <--? Does this REALLY support non-x86 system/s ?! Can we find any actual code which PROVES that this is non-x86 ?? => UnixOberon.Tool == <non-Desktop eqivalent tool> ... ppc MacOS X Tool. (Darwin >= 6.2 !!) <-- opened below ## ppc Linux (no longer supported) ## => Tools/ppc.Darwin.Tool == Oberon startup code ------------ cd ppc/Darwin/startup <- search for make -------------- these modules get loaded by Modules0 -------- =!=> OK, since we are now in LEO, which can access linux files, lets use LEO to copy some of the file contents here [we've already used linux to look at them]. But LEO is far superior for keeping notes. -> System.Directory ppc/Darwin/startup/*\d == <plenty> ... ppc/Darwin/startup/CallOberon.s 17.01.2002 12:35:22 1555 ... ppc/Darwin/startup/Makefile 24.10.2003 23:43:07 -> EditTools.OpenUnix ppc/Darwin/startup/CallOberon.s == # # G. Feldmann 30.12.96 # .text .align 2 .globl _CallOberon _CallOberon: mflr r0 stw r0,8(r1) stmw r2,-120(r1) <-- !! This is NON-x86 asm stwu r1,-176(r1) ... =!=> let's confirm what the corresponsing x86 asm looks like:- There are NO src/x86/ *.s files OK, I need not have looked at ppc/Darwin since ppc/Linux is also non-x86, but ppc/Darwin seems further removed from x86/Linux and we want to know if we get do ARM/Linux. The coding and documentation looks very orderly, and I'm optimistic that we can use it to get to ETHO:ARM.Linux Is Gunter Feldman available? == Chris Glur. It's very difficult for me to email since my African ISP is broken

1 0

On Oberon Tasks.
by Srinivas Nayak 23 Dec '12

23 Dec '12

Dear All, From Project Oberon Book, 2.2.3 Tasks The primary advantage of a system dealing with a single process is that task switches occur at *user-defined points* only, where no local process state has to be preserved until resumption. Furthermore, because the switches are user-chosen, the tasks cannot interfere in unexpected and uncontrollable ways by accessing common variables. The system designer can therefore omit all kinds of protection mechanisms that exclude such interference. This is a significant simplification. I understood that Oberon is a single process system, That means, only a single while loop is the whole life of Oberon OS. No scheduler present which switches the context of different processes. In Oberon, we rather have small small modules which can be called tasks, which are similar to processes in Linux. The big loop continuously looks for events. Events may be invoking the module.procedure, the tasks. Am I correct till this point? Now, what is the meaning of user-defined points here? The essential difference between Oberon and multiprocess-systems is that in the former task switches occur between commands only, whereas in the latter a switch may be invoked after any single instruction. Evidently, the difference is one of granularity of action. Oberon's granularity is coarse, which is entirely acceptable for a single-user system. I couldn't understand, how can task switching happen between commands only. Then how, Oberon runs two tasks simultaneously? Or it is not possible to view a movie in video player and read some document simultaneously? With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

2 1

On Oberon Commands
by Srinivas Nayak 23 Dec '12

23 Dec '12

Dear All, From Project Oberon Book, 2.2.2. Commands This tremendous flexibility seems to open Pandora's box, and indeed it does when misused. The reason is that global variables' states may completely determine and alter the effect of a command. The variables represent hidden states, hidden in the sense that the user is in general unaware of them and has no easy way to determine their value. The positive aspect of using global variables as interfaces between commands is that some of them may well be visible on the display. All viewers - and with them also their contents - are organized in a data structure that is rooted in a global variable (in module Viewers). Parts of this variable therefore constitute visible states, and it is highly appropriate to refer to them as command parameters. This is good, I am able to understand it. One of the rules of what may be called the Oberon Programming Style is therefore to avoid hidden states, and to reduce the introduction of global variables. We do not, however, raise this rule to the rank of a dogma. There exist genuinely useful exceptions, even if the variables have no visible parts. As I understood, we are using global variables, but these have visible states. So better for using them as parameters to user commands. There remains the question of how to denote visible objects as command parameters. An obvious case is the use of the most recent selection as parameter. A procedure for locating that selection is provided by module Oberon. (It is restricted to text selections). Another possibility is the use of the caret position in a text. This is used in the case of inserting new text; the pressing of a key on the keyboard is also considered to be a command, and it causes the character's insertion at the caret position. This says, caret position (which is seen on screen texts after pressing left mouse key) can be interpreted as starting of a parameter list. Also the text under selection (which we are able to make using right mouse button on screen texts) can be interpreted as starting of a parameter list. A special facility is introduced for designating viewers as operands: the star marker. It is placed at the cursor position when the keyboard's mark key (SETUP) is pressed. The procedure Oberon.MarkedViewer identifies the viewer in whose area the star lies. Commands which take it as their parameter are typically followed by an asterisk in the text. Whether the text contained in a text viewer, or a graph contained in a graphic viewer, or any other part of the marked viewer is taken as the actual parameter depends on how the command procedure is programmed. Huh, here I couldn't understand, what is a marked viewer. Which one is the equivalent of "keyboard's mark key" in IBM 102 style keyboard? How a graph be input to some command? I am not able to understand this paragraph! With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

3 2

Re: [Oberon] Funding for a Compiler Project
by Aubrey.McIntosh＠Alumni.UTexas.Net 21 Dec '12

21 Dec '12

That's unfortunate. Let's try again.<http://www.kickstarter.com/projects/1378252804/681865516?token=bfb40102> I've been editing this all day. I am *very *open to suggestions before I hit the "Launch" button. On Fri, Dec 21, 2012 at 4:38 PM, CFB Software <cfbs(a)internode.on.net> wrote: > Hi Aubrey, > > ... > > The 'previous KickStarter project' link worked fine but, unfortunately, > when > I clicked on the 'KickStarter project of my own' link: > > http://www.kickstarter.com/projects/1378252804/681865516?token=9ca2a4ea > > I got the message: > > ------------------------ > 404 > > -- Aubrey McIntosh, Ph.D. 211 E. 5th St. Morris MN 56267 (512)-348-7401

1 0

Funding for a Compiler Project
by Aubrey.McIntosh＠Alumni.UTexas.Net 21 Dec '12

21 Dec '12

I am sure that many of you know about KickStarter<http://www.kickstarter.com>. It is used to fund eclectic creative projects. I have submitted a KickStarter project of my own<http://www.kickstarter.com/projects/1378252804/681865516?token=9ca2a4ea> for approval to launch. This follows closely on a previous KickStarter project<http://www.kickstarter.com/projects/1378252804/the-green-lady-photographs-f…>that will be live for a few more hours. This seems like an opportunity to have a dual hardware / software project where an Oberon family compiler and a hardware board are tuned to each other. It is also an opportunity to showcase Oberon and/or Component Pascal to the MakerSpace community and other allied communities who closely follow KickStarter. Perhaps video segments showing the various Oberons and small board designs, such as Wojtec's boards and CBF's compilers. One potential project would be to switch my board to use the MIPS chips offered by Microchip Technology Inc<http://www.microchip.com/pagehandler/en-us/family/32bit/>. I have loaded, through a long and arcane process, the output from the Regis Creiler compiler onto the MIPS evaluation board and I can verify that it executes correctly. A parallel project would then update the Regis Creiler Oberon compiler as a new back end for the Component Pascal project. Both of these compilers follow a very similar architecture, and this is documented in the literature. The administrative permissions to use this source is an exercise for the reader. The new back end can be realized by writing a few modules in the Component Pascal environment. The Browser actually uses some of the front end and dumps some of the internal data structures as its method of operation, so there are lots of resources already in place. In addition, there are SPARC core microchips available and an existing SPARC Oberon compiler. There are also ARM chips available. I also understand that Wirth developed a small language for one of the PIC chips. It would be wonderful to have a companion KickStarter project. I hope someone is in a position to put one together. We would, of course, reference each other's projects in our descriptions. If you have preliminary interest, I would like to know of your CPU choice fairly soon. The KickStarter page says that the projects are limited to people (with bank accounts) in the US or GB. However, there have been projects from other countries. I don't know how they made that happen, but one possibility is for me to be an administrative partner, as many projects are team efforts. -- Aubrey McIntosh, Ph.D. 211 E. 5th St. Morris MN 56267 (512)-348-7401

1 0

Current Oberon System
by Bernhard Treutwein 21 Dec '12

21 Dec '12

>> 5. Which line of Oberon system is being currently developed? x86 >> (Native) Oberon? System 3? A2? > > I think AOS or A2 is more a research project than a true OS. > My imporession is that all Oberon Systems are/were research projects about OS design and the only one, which is currently still developed is A2 respectively WinAos/UnixAos. But the active group is much too small ... -- Bernhard

13 20