Oberon Linux Revival

OLR is the Oberon System with Gadgets running natively on the Linux Kernel of X86, MIPS and ARM processors. It is a consolidation effort to make a single distribution from Linux Native Oberon, ARM Linux Oberon and MIPS Linux Oberon.

Basis of the system is the latest Alpha of PC Native Oberon of ETH Zürich. Main changes are the filesystem which is not based on OFS any more and a more direct display system. Object/symbol files are in olr/x86/ , olr/mips/ and olr/arm/ for X86, MIPS and ARM

Oxford Oberon CompilerA fairly portable compiler, runs on Windows/Ubuntu, Debian and Debian derivatives, OS X, Raspberry Pi. It uses the Objective Caml runtime, but is statically linked. A, checklist for Oberon-07 features/compatibility is available for tracking future planned support of Oberon-07.

Vishap Oberon CompilerA new, well maintained, and natively both 32-bit and 64-bit Oberon-2 compiler, which is highly portable. Runs on Linux x86/AMD64/ARM 4-7 including Raspberry Pi/OS X; FreeBSD). Untested on Windows. Voc also includes a simple Oberon-07 compiler. The compiler uses static linking, but a dynamic run-time has been discussed as a future possibility. The author also has a proprietary compiler he worked on at ETH, but which is not publically available.

Someday I want to try this out!

A case against the GOTO statement


A Case against the GO TO Statement.

by Edsger W.Dijkstra
Technological University
Eindhoven, The Netherlands

Since a number of years I am familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. Later I discovered why the use of the go to statement has such disastrous effects and did I become convinced that the go to statement should be abolished from all “higher level” programming languages (i.e. everything except —perhaps— plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so.

My first remark is that, although the programmer’s activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to effectuate the desired effect, it is this process that in its dynamic behaviour has to satisfy the desired specifications. Yet, once the program has been made, the “making” of the corresponding process is delegated to the machine.

My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost best to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

Let us now consider how we can characterize the progress of a process. (You may think about this question in a very concrete manner: suppose that a process, considered as a time succession of actions, is stopped after an arbitrary action, what data do we have to fix in order that we can redo the process until that very same point?) If the program text is a pure concatenation of, say, assignment statements (for the purpose of this discussion regarded as the descriptions of single actions) it is sufficient to point in the program text to a point between two successive action descriptions. (In the absence of go to statements I can permit myself the syntactic ambiguity in the last three words of the previous sentence: if we parse them as “successive (action descriptions)” we mean successive in text space, if we parse as “(successive action) descriptions” we mean successive in time.) Let us call such a pointer to a suitable place in the text a “textual index”.

When we include conditional clauses (if B then A), alternative clauses (if B then A1 elseA2), choice clauses as introduced by C.A.R.Hoare (case[i] of (A1, A2,…..,An)) or conditional expressions as introduced by J. McCarthy (B1 → E1, B2 → E2,….., BnEn), the fact remains that the progress of the process remains characterized by a single textual index.

As soon as we include in our language procedures we must admit that a single textual index is no longer sufficient: in the case that a textual index points to the interior of a procedure body the dynamic progress is only characterized when we also give to which call of the procedure we refer. With the inclusion of procedures we can characterize the progress of the process via a sequence of textual indices, the length of this sequence being equal to the dynamic depth of procedure calling.

Let us now consider repetition clauses (like, while B repeat A or repeat A until B). Logically speaking, such clauses are now superfluous, because we can express repetition with the aid of recursive procedures. For reasons of realism I don’t wish to exclude them: on the one hand repetition clauses can be implemented quite comfortably with present day finite equipment, on the other hand the reasoning pattern known as “induction” makes us well equipped to retain our intellectual grasp on the processes generated by repetition clauses. With the inclusion of the repetition clauses textual indices are no longer sufficient to describe the dynamic progress of the process. With each entry into a repetition clauses, however, we can associate a so-called “dynamic index”, inexorably counting the ordinal number of the corresponding current repetition. As repetition clauses (just as procedure calls) may be applied nestedly, we find that now the progress of the process can always be uniquely characterized by a (mixed) sequence of textual and/or dynamic indices.

The main point is that the values of these indices are outside programmer’s control: they are generated (either by the write up of his program or by the dynamic evolution of the process) whether he wishes or not. They provide independent coordinates in which to describe the progress of the process.

Why do we need such independent coordinates? The reason is—and this seems to be inherent to sequential processes—that we can interpret the value of a variable only with respect to the progress of the process. If we wish to count the number, n say, of people in an initially empty room, we can achieve this by increasing n by 1 whenever we see someone entering the room; in the in-between moment that we have observed someone entering the room but have not yet performed the subsequent increase of n, its value equals the number of people in the room minus one!

The unbridled use of the go to statement has as an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. Usually, people take into account as well the values of some well chosen variables, but this is out of the question because it is relative to the progress that the meaning of these values is to be understood! With the go to statement one can, of course, still describe the progress uniquely by a counter counting the number of actions performed since program start (viz. a kind of normalized clock). The difficulty is that such a coordinate, although unique, is utterly unhelpful: in such a coordinate system it becomes an extremely complicated affair to define all those points of progress where, say, n equals the number of persons in the room minus one!

The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one’s program. One can regard and appreciate the clauses considered as bridling its use. I do not claim that the clauses mentioned are exhaustive in the sense that they will satisfy all needs; but whatever clauses are suggested (e.g. abortion clauses) they should satisfy the requirement that a programmer independent coordinate system can be maintained to describe the process in a helpful and manageable way.

It is hard to end this article with a fair acknowledgement: am I to judge by whom my thinking has been influenced? It is fairly obvious that I am not uninfluenced by Peter Landin and Christopher Strachey, and that I do not regret their influence upon me. Finally I should like to record (as I remember it quite distinctly) how Heinz Zemanek at the pre-ALGOL meeting in early 1959 in Copenhagen quite explicitly expressed his doubts whether the go to statement should be treated on equal syntactic footing with the assignment statement. To a modest extent I blame myself for not having then drawn the consequences of his remark.

The remark about the undesirability of the go to statement is far from new. I remember having read the explicit recommendation to restrict the use of the go to statement to alarm exits, but I have not been able to trace it; presumably, it has been made by C.A.R. Hoare. In [1, Sec. 3.2.1] Wirth and Hoare together make a remark in the same direction in motivating the case construction: “Like the conditional, it mirrors the dynamic structure of a program more clearly than go to statements and switches, and it eliminates the need for introducing a large number of labels in the program.”

In [2] Guiseppe [sic] Jacopini seems to have proved the (logical) superfluousness of the go to statement. The exercise to translate an arbitrary flow diagram more or less mechanically into a jumpless one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one.


  1. Wirth, Niklaus, and Hoare, C.A.R. A contribution to the development of ALGOL. Comm. ACM 9 (June 1966), 413–432.
  2. Böhm, Corrado, and Jacopini, Guiseppe. Flow diagrams, Turing machines and languages with only two formation rules. Comm. ACM 9 (May 1966), 366–371.

HP 1000 Pascal

I worked at KSLA Shell Amsterdam labs 1980-1983. One of my projects was to develop a realtime system in Pascal.

Goal of the project was to emulate a TDC 2000 device, with only the public information supplied by Honeywell, in hardware and software.
The Honeywell TDC 2000/3000 is an advanced distributed control system. TDC 2000 was introduced in 1975.
To do this special hardware was developed (a 6809 micropocessor system) as a device driver in an HP1000 minicomputer to talk to the TDC2000 bus.
The HP1000 itself was running its own real time operating system RTE. The application I wrote, in HP1000 Pascal, was responsible for communication over the TDC2000 bus via this device driver, being a node in the TDC2000 system.

HP1000 Pascal was quite a good implementation of Standard Pascal. Via systems calls one could communicate with device drivers. The whole system, operating systen and application, was in the end burned into EPROMs as disk  (many 2716s!) so the machine could run diskless in harsh environments.

The program was a realtime application. And Shell wanted it to be in a higher level language and Pascal was en voque in the KSLA lab these days. I learned and discussed a lot with fellow engineers there about Pascal (Concurrent Pascal, Standard Pascal, Pascal Plus etc).

As a realtime applciation the standard layout was chosen: an init part and an endless main loop servicing the devices with commands over the bus and transmitting results over the bus with answers on queries.
I do remember the HP1000 was not the fastest machine. Since the response had to be realtime, I encountered several performance problems during the loop of the 1 second dutycycle available. One was a calculation of a real variable, a sinus value. Floating point was done in software, so that was a bottleneck. I solved that by at the init part calculating and storing in a table the sinus values in the resolution required and doing a table lookup in the main loop. It all worked out very well.


Per Brinch Hansen

hansenBrinch Hansen was one of the pioneers of concurrent programming and operating systems (kernels). In the 1960s, Brinch Hansen worked at the Danish computer company Regnecentralen, first in the compiler group headed by Peter Naur and Jørn Jensen, and, later, as the chief architect of the RC 4000 minicomputer and its renowned operating system kernel (RC 4000 Multiprogramming System). In 1972, he wrote the first comprehensive textbook on Operating System Principles.

In 1970 his research in computer science focused on concurrent programming.  Inspired by Ole-Johan Dahl and Kristen Nygaard’s programming language Simula 67, he invented the monitor concept in 1972. In the United States, he also developed the first concurrent programming language, Concurrent Pascal, in 1975. In 1977, he wrote the first book on Concurrent Programming: The Architecture of Concurrent Programs.

Per Brinch Hansen has concentrated on simplicity. Only the essential, always ask why complications are tolerated. His book on Programming a Personal Computer, read by me in 1983, made a lasting deep impresssion on me.

Two citations from Per Brinch Hansen on simplicity and programming
– Writing is a rigorous test of simplicity: It is just not possible to write convincingly about ideas that cannot be understood.
– Programming is the art of writing essays in crystal clear prose and making them executable

Information on the work of Per Brinch Hansen:
Solo and Concurrent/Sequential Pascal
Edison system
Joyce A programming language for networks
– Collected articles by Per Brinch Hansen http://brinch-hansen.net/.

Books in my library:

pbhoperating Operating System Principles
(1973, ISBN 0-13-637843-9) (scanned)
pbharchitecture The Architecture of Concurrent Programs
(1977, ISBN 0-13-044628-9)
Concurrent Pascal and Solo
Programming a Personal Computer, Per Brinch Hansen
The book describing the Edison system, design,
development,listing of programs including compiler in the Edison language,
and the interpreter/runtime written in PDP-11 Alva language.
(1983, ISBN 0-13-730267-3), the Edison system
Programming a Personal Computer, Per Brinch Hansen
OCR version (thanks Daniel Toffetti)
pbhpascalcompiler Brinch Hansen on Pascal Compilers
(1985, ISBN 0-13-083098-4) (scanned)
pbhpascalcompiler Brinch Hansen on Pascal Compilers
OCR version (thanks Daniel Toffetti)
The Search for Simplicity.
Essays on Parallel ProgrammingSee below.
(1996, ISBN 0-8186-7566-7

The Search for Simplicity. Essays on Parallel Programming.

The Cobol compiler for the Siemens 3003
Design considerations for the RC 4000 computer
The logical structure of the RC 4000 computer
The RC 4000 real-time control system at Pulawy
RC 4000 Software: Multiprogramming System (abridged)
RC 4000 Computer: Reference Manual
RC 4000 Software: Multiprogramming System (complete)
The nucleus of a multiprogramming system
An outline of a course on operating system principles
Structured multiprogramming
Shared classes
Testing a multiprogramming system
The programming language Concurrent Pascal
The Solo operating system: A Concurrent Pascal program
The Solo operating system: Processes, monitors, and classes
The programmer as a young dog
Experience with modular concurrent programming
Design principles
Network—A multiprocessor program
Distributed processes: A concurrent programming concept
Reproducible testing of monitors
A keynote address on concurrent programming
The design of Edison
Joyce—A programming language for distributed systems
A multiprocessor implementation of Joyce
The nature of parallel programming
The Joyce Language Report
The linear search rediscovered
Householder reduction of linear equations
Monitors and Concurrent Pascal: A personal history
Model programs for computational science
Parallel cellular automata
Multiple-length division revisited
SuperPascal—A publication language
Interference control in SuperPascal
Efficient parallel recursion
The all-pairs pipeline
Balancing a pipeline
Java’s insecure parallelism
The evolution of operating systems
The invention of concurrent programming

Other books:
– Studies in Computational Science: Parallel Programming Paradigms (1995, ISBN 0-13-439324-4)
– Programming for Everyone in Java (1999, ISBN 0-387-98683-9)
– Classic Operating Systems: From Batch Processing to Distributed Systems (2001, ISBN 0-387-95113-X)
– The Origin of Concurrent Programming: From Semaphores to Remote Procedure Calls (2004, ISBN 0-387-95401-5)
– A Programmer’s Story: The Life of a Computer Pioneer (2004, local copy available here at http://brinch-hansen.net/)
– Many articles in the scientific journals, many available at local copy of http://brinch-hansen.net/.

With father

Class of 1949

Age 21

Ivar Bech

Naur and Brinch Hansen

Naur, Dahl, Brinch Hansen

Compiler Group

RC4000 computer




Edsger Dijkstra

In Pursuit of Simplicity Presentation slides of A Symposium Honoring Professor Edsger Wybe Dijkstra May 12–13, 2000

A Case against the GO TO Statement.

Famous quotes

Articles and books by and on Edsger Dijkstra

On my bookshelf
On my bookshelf
On my bookshelf
Structured Programming
O.J. Dahl, E. W. Dijkstra, C.A.R. Hoare
E.Q. Dijkstra PhD thesis
A Discipline of Programming
ALGOL The Dijkstra Zonneveld ALGOL-60 Compiler
for the X1, sources, stories, explanations
F.J. Kruseman Aretz
In Pursuit of Simplicity.pdf
The Man Who Carried Computer Science on His Shoulders
Krzystof Apt

Edsger Dijkstra archive, the manuscripts

Edsger W. Dijkstra

Edsger W. Dijkstra

How do we tell truths that might hurt?
Sometimes we discover unpleasant truths. Whenever we do so, we are in difficulties: suppressing them is scientifically dishonest, so we must tell them, but telling them, however, will fire back on us. If the truths are sufficiently impalatable, our audience is psychically incapable of accepting them and we will be written off as totally unrealistic, hopelessly idealistic, dangerously revolutionary, foolishly gullible or what have you. (Besides that, telling such truths is a sure way of making oneself unpopular in many circles, and, as such, it is an act that, in general, is not without personal risks. Vide Galileo Galilei…..)

Computing Science seems to suffer severely from this conflict. On the whole, it remains silent and tries to escape this conflict by shifting its attention. (For instance: with respect to COBOL you can really do only one of two things: fight the disease or pretend that it does not exist. Most Computer Science Departments have opted for the latter easy way out.) But, Brethren, I ask you: is this honest? Is not our prolonged silence fretting away Computing Science’s intellectual integrity? Are we decent by remaining silent? If not, how do we speak up?

To give you some idea of the scope of the problem I have listed a number of such truths. (Nearly all computing scientists I know well will agree without hesitation to nearly all of them. Yet we allow the world to behave as if we did not know them….)

Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.
The easiest machine applications are the technical/scientific computations.

The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.

FORTRAN —”the infantile disorder”—, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use.

PL/I —”the fatal disease”— belongs more to the problem set than to the solution set.

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.

APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums.
The problems of business administration in general and data base management in particular are much too difficult for people that think in IBMerese, compounded with sloppy English.

About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead.
Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer.

Many companies that have made themselves dependent on IBM-equipment (and in doing so have sold their soul to the devil) will collapse under the sheer weight of the unmastered complexity of their data processing systems.

We can found no scientific discipline, nor a hearty profession on the technical mistakes of the Department of Defense and, mainly, one computer manufacturer.
The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity.
By claiming that they can contribute to software engineering, the soft scientists make themselves even more ridiculous. (Not less dangerous, alas!) In spite of its name, software engineering requires (cruelly) hard science for its support.

In the good old days physicists repeated each other’s experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other’s programs, bugs included.
Projects promoting programming in “natural language” are intrinsically doomed to fail.

Isn’t this list enough to make us uncomfortable? What are we going to do? Return to the order of the day, presumably…….
18th June 1975

The Netherlands prof.dr.Edsger W.Dijkstra
Burroughs Research Fellow
PS. If the conjecture “You would rather that I had not disturbed you by sending you this.” is correct, you may add it to the list of uncomfortable truths.


Pascal-VU compiler

Pascal-VU compiler

During my study at the VU Amsterdam in 1979, 1980 I worked with the Pascal-VU compiler. A full ISO standard ...

Read More

Pascal-M updates

Pascal-M updates

New developments for Pascal-M: Pascal-M for Flex OS on 6809 , 1980, source of compiler (in Pascal-M) and intepreter (6809 assembler ...

Read More

New version of the Pascal-M system 2K1

New version of the Pascal-M system 2K1

New version of the Pascal-M system, run Pascal programs on the KIM-1. Use it on a KIM-1 and cross compile on ...

Read More

Per Brinch Hansen pages updated

After the scan of Brinch Hansen on Pascal compilers I went on and also scanned the book on Edison: Programming ...

Read More

Per Brinch Hansen on Pascal compilers

Scanned version of Per Brinch Hansen on Pascal compilers book added to the Per Brinch Hansen page, as well as ...

Read More

This site is about my experience with the Wirth school of languages, based on the ideas and implementations of Prof Niklaus Wirth, Kenneth Bowles, Per Brinch Hansen, colleagues, and their students. And my experience with the various variants, from the P2 and P4 compilers originating in Zürich ETH, via UCSD Pascal P-System to the Borland compilers and Modula and Oberon systems. All applicable to small computers and device control.

On this website you will find information on Pascal for small machines, like Wirth compilers, the UCSD Pascal system, many scanned books and other files on UCSD Pascal, Pascal on MSX and CP/M, Delphi programming on PC, Freepascal and Lazarus on Windows and Raspberry Pi, Oberon systems. Many sources of early Pascal compilers! And last but not least my Pascal-M system!

On this site you will information on (see the menu on the right!)
Standard Pascal and Validation
Niklaus Wirth
Edsger Dijkstra
Per Brinch Hansen
Ca.A.R Hoare
Jim Welsh
Pascal Px descendants like P5 and Pascal-M
UCSD Pascal
– Other Pascal articles like Freepascal on Raspberry Pi, Turbo Pascal and Delphi and electronics

Timeline of my exposure to the Wirth language and OS and systems family, 5 years as student, 10 years as software engineer, hobby, 40 years as the way of programming!

  • WIRTH (1)1970- Pascal compilers, the P2-P4 compilers, Pascal-S, Pascal-VU (the forerunnner of the Amsterdam Compiler Kit), Andrew Tanenbaum, Professor R.P  van de Riet.
  • 1979 – Pascal-M
  • 1980 – UCSD P-System, HP Pascal 1000
  • 1983 – RSX-11M VMS Pascal
  • 1985 Turbo Pascal, , 10 years VAX/VMS Pascal programmer, teacher of the Teleac support course Pascal, teacher and examinator Exin/Novi T5 Pascal
  • 1990 – Turbo Pascal 3 on CP/M and MS DOS to Delphi on Windows
  • 2010 – Freepascal + Lazarus on Windows and Linux