I think Fogus was able to summarize it quite well in his "Six works of Computer Science-Fiction" blog post [0]:
"Wirth’s magnum opus is the quintessential example of Computer Science alternative-history world-building."
Note that Oberon was not only the name of a programming language, it was also the name of an innovative (at that time) operating system.
It is possible to program real-world programs today in Oberon depending on the used implementation. For example oberonc [1] is a compiler targeting the JVM and allows you to leverage the JVM ecosystem by invoking Java code (or any other language that compiles to Java bytecode).
For more Oberon implementations see [2]
> it was also the name of an innovative (at that time) operating system
it was also an example of a complete system (from hw through os + dev tools to apps) which had been developed by only two people.
I thoroughly enjoyed Wirth's excuse for an FPGA re-implementation: "no commercial machines would talk to my favourite mouse —given to me as a parting gift from my Xerox sabbatical— so I built a workstation that would"
(He once gave a slideshow of the workstations he'd designed over the years, and although the displays got bigger, and the cpu and storage got smaller, the mouse remained the same...)
The UI paradigm involving Oberon's "system track" is still really interesting.
This isn't fanfare. I put some serious hours into messing around with Oberon (re-implementing the compiler like you, working on a couple emulators, working out how to bootstrap the system and build a disk image). Still, I never particularly enjoyed using Oberon, though.
About a year or so ago, though, while fumbling around with Firefox's bookmarks, I was entertaining the idea of a "universal sidebar" that would from the perspective of any app or web page be entirely separate but would still be sufficiently powerful to control any one (or all) of them. I realized I was re-imagining Wirth's system track, jotted the idea down, and then moved on. I'm still occasionally reminded of it, of course, due to the same frustrations that led to my daydreaming in the first place.
I do most of my computing with browser windows and terminal emulators snapped to either the left or right sides of the screen, anyway, so my existing workflow is entirely amenable to the imposition of parallel tracks. It's an underexplored UI concept on modern desktops. Windows Vista did have a widget engine that it first called the Sidebar and then called Desktop Gadgets, but it it was basically a clone of Konfabulator and the Mac Dashboard and not so much a supercharged window manager/app coordinator in the vein of Oberon or Plan 9 Acme, and I don't use Windows anyhow. The Browser Company is doing something sort of interesting with Arc, but it's still just an application-sidebar and not nearly powerful enough for what I want. Plus it's on the wrong side of the screen.
It would be great to have a simple Virgil x86-64 backend based only on the destination-driven code generation technique, and compare the performance of the generated code (and compilation speed) with the official optimizing x86-64 backend.
Would the implementation effort be comparable to the JVM backend?
BTW I really like the design of Virgil described in "Harmonizing Classes, Functions, Tuples,and Type Parameters in Virgil III", bravo!
Thanks. Interesting thought. The current Virgil compiler translates from the AST directly to SSA quite early. Specialization, analysis, data representation choices, and lowering all happen on SSA. Translating directly to machine code from the AST and using destination-driven allocation could maybe work for a simple subset with easy lowering, which would give an indication of the compile speed improvements possible.
It is interesting to see that this approach has been used by Niklaus Wirth in most of his compilers, see "Compiler Construction - The Art of Niklaus Wirth" by Hanspeter Mössenböck [0].
This technique was also described by David R. Hanson in "Code Improvement via Lazy Evaluation", 1980 [1] and "Simple Code Optimizations", 1983 [2].
The relevant section is 10.2. But its mechanism is the “inverse” of destination driven code generation as I understand it. In Wirth’s Item approach the callee picks a location and tells the caller where to look. Whereas in destination driven code generation the caller tells the callee where to put the result.
You are right, but as you can see at page 11 (Figure 4 rightmost AST) of The Oberon System Family paper [0], Wirth's approach was extended to "hint" destinations as well.
The Oberon programming language is 37 years old. Since it is a memory safe language a compiler for the JVM can be written (with some workarounds), for example see the self-hosting compiler oberonc [0].
If you want to try out only the Oberon language, you might be interested in oberonc [0] an oberon-07 self-hosting compiler for the JVM. There are other several Oberon implementations for different platforms listed here[1]
If you want to try out only the Oberon language, you might be interested in oberonc [0] an oberon-07 self-hosting compiler for the JVM. There are other several Oberon implementations for different platforms listed here[1]
If you want to try out only the Oberon language, you might be interested in oberonc [0] an oberon-07 self-hosting compiler for the JVM.
There are other several Oberon implementations for different platforms listed here[1]
If you want to try out only the Oberon language, there are several Oberon implementations for different platforms, including embedded systems, native windows executables, and the Java virtual machine: http://oberon07.com/compilers.xhtml
When I read this book I had an hard time running and compiling the source code included. If you want to read the book and try out the example compiler (oberon0), you can follow the instructions here: https://github.com/lboasso/oberon0. You just need a JVM >= 8 and the oberonc compiler: https://github.com/lboasso/oberonc
