Then he woke up one morning wanting to reboot his life's work for his class and, undeterred by the fact the original targeted processor did not exist anymore, settled to write his own computer architecture on a Xilinx Spartan.
He then successfully ported the Oberon system and compiler to this architecture to demonstrate to his students.
I am aware of Oberon and Modula, but had never got a chance to touch them. And that's much more of his work than Pascal.
But it's so niche and windows-centered as to be almost useless. And the community is microscopic.
This is a good overview:
Oberon, a tiny text-oriented OS, evolved into A2, a graphical OS with a zooming UI called Bluebottle. There's some info about A2/Bluebottle here:
Here is the OS on GitHub:
There are bare-metal versions for x86 -- I am running it on a Thinkpad X200 as well as under VirtualBox -- and also versions that run hosted on Windows, 32-bit and 64-bit Linux and Mac OS X.
Also wort mentioning that Active Oberon has the language features that Oberon lacked for manual memory management in unsafe code and co-routines in the form of active objects, hence its name.
Paco (Active Oberon's compiler) is probably one of the first compilers with parallel phases.
A PDF is here: https://pdfs.semanticscholar.org/d48b/ecdaf5c3d962e2778f804e...
This is essential reading to understand its relevance in computer science.
Oberon is 2 things. It is a language and an OS, or even a family of OSes.
Oberon the language has several versions and works on Linux on x86, x86-64, ARM and other platforms, as well as Windows, BSD, Mac OS X, etc.
Oberon the OS runs on x86 and RISC5 among others. I am considering attempting an ARM port for Raspberry Pi.
So no, it is not at all Windows-centric. One commercial compiler is, but not the language.
It is niche but the community seems quite active.
Former Oberon researchers now work on GraalVM, Go.
The Austrian university which collaborates with Oracle Labs on Graal, used to do Oberon research before switching to Java with Sun Labs.
Java and .NET kind of killed it.
Modula-2 being Oberon's predecessor.
>"It is indeed a healthy design paradigm to stick to synchronous circuits in general, if possible. Then, quite obviously, all elements of a circuit operate concurrently, literally at the same time. Every variable and register is defined by one and only one expression combinational circuit). Multiple assignments do not make sense."
I am not quite grokking this and hope someone can explain this to me.
He starts by extolling the merits of sequential logic circuits but then goes on to say that every variable and register need only be a combinatorial circuits. Since these are the two fundamental circuit types, does this point not contradict the earlier one? What am I missing?
Sounds like the author is advocating for designs that do not have derived clocks or gated clocks or multiple clock domains -- all tricky things that designers occasionally do with great care. Clock your flip-flops with the master clock and avoid transparent latches and your design will approach the mathematical ideal that he describes when comparing a circuit to a software program.
I'd guess his Lola HDL restricts you from doing some of these things, where Verilog is more YOLO depending on the vendor and warnings that are enabled.
Looking at it again, I'm reading Wirth's statement as pretty much a bog-standard endorsement of synchronous circuit design.
/ \ | Q|
| COMB |---|D |
\ / |>CLK |
It sounds like he's doing a very (terse) RTL style. This makes it very clear what your synthesizer will do with it - he isn't trying to be clever on the RTL front.
We should email him and ask!
Also thanks for the ascii diagram.
In re-reading that passage this all makes good sense now.
This is not RISCV.
I don't share the joy of others for Plan 9, because for me Inferno is the actual end of the road, Plan 9's architecture with a sane userspace.
Papers and books read cover to cover during business travels.