Show me significant concepts implemented in today's languages which cannot directly be traced back to "things that were important in 1960-s" or seventies ;-)
The "OS" (or rather "kernel") was actually the VM which was implemented in microcode and BCPL. The Smalltalk code within the image was completely abstracted away from the physical machine. In today's terms it was rather the "userland", not a full OS.
It's refreshing to see Oberon getting some love on the Pi. There’s a certain 'engineering elegance' in the Wirthian school of thought that we’ve largely lost in modern systems.
While working on a C++ vector engine optimized for 5M+ documents in very tight RAM (240MB), I often find myself looking back at how Oberon handled resource management. In an era where a 'hello world' app can pull in 100MB of dependencies, the idea of a full OS that is both human-readable and fits into a few megabytes is more relevant than ever.
Rochus, since you’ve worked on the IDE and the kernel: do you think the strictness of Oberon’s type system and its lean philosophy still offers a performance advantage for modern high-density data tasks, or is it primarily an educational 'ideal' at this point?
I don't know. Unfortunately we don't have an Oberon compiler doing similar optimization as e.g. GCC, so we can only speculate. I did measurements some time ago to compare a typical Oberon compiler on x86 with GCC and the performance matched about GCC without optimizations (see https://github.com/rochus-keller/Are-we-fast-yet/tree/main/O...). The C++ type system is also pretty strict, and on the other hand it's possible and even unavoidable in the Oberon system 3 to do pointer arithmetics and other things common in C behind the compilers back (via the SYSTEM module features which are not even type safe). So the original Oberon syntax and semantics is likely not on the sweet spot of systems programming. With my Micron (i.e. Micro Oberon, see https://github.com/rochus-keller/micron/) language currently in development I try for one part to get closer to C in terms of features and performance, but with stricter type safety, and on the other hand it also supports high-level applications e.g. with a garbage collector; the availabiltiy of features is controlled via language levels which are selected on module level. This design can be regarded as a consequence of many years of studying/working with Wirth languages and the Oberon system.
Oberon is both a programming language and an operating system used mostly for teaching, much like e.g. xv6 or xinu. Similar to the latter, Wirth has written text books about the system, some of which can be downloaded for free (see https://projectoberon.net/ for the PDF links).
Thanks. In contrast to Smalltalk or Lisp, Oberon is originally a native language, and the Oberon System originally was conceived as the native operating system of the Ceres computer used for teaching in the nineties at ETH Zurich. So there is no image as in Lisp or Smalltalk. Oberon lives on today in the form of various dialects and derivatives (such as my Oberon+ or Micron languages, see https://github.com/rochus-keller/oberon and https://github.com/rochus-keller/micron). There are indeed Oberon implementations which run on Java or ECMA 335 runtimes, which is possible due to the very restricted pointer handling and memory management of Oberon.
Thanks. There is actually also an i386 version of the system in the repository, where I modified the kernel so it runs with Multiboot, making installations much easier. An essential achievement for both platforms were the stand-alone tools, i.e. I can compile and link the whole Oberon system on Linux or any other platform (see https://github.com/rochus-keller/op2/). I even implemented an IDE which I used for the development (see https://github.com/rochus-keller/activeoberon/).
Nice figures, but actually just a presentation, not a theory. Apparently based on this book: https://bookerapp.replit.app/book/fom, which neither seems to actually explain much. I agree that a better music theory is needed and that the manifold approach might work for music as well, but not much so far besides a few keywords and high-level ideas.
There is no inherrent reason why no new programming languages should be developed in the age of AI. As long as people are programming, there will be new languages. As there are still people playing traditional musical instruments in the age of sampling, there will still be programming humans, even if a lot will be automated. A programming language is a suitable way to communicate intentions and solutions with an LLM. There will be new languages which improve on this. But there will also be new "traditional" programming languages. I'm just developing one since more than a year because I see a specific need. Whether it will prevail and you can get a job using it is yet another, unrelated question. As in the past it will be mostly luck whether it will be accepted by a wider audience.
Which might behave pretty differently on the specific hardware; getting the simulation correct is only a fraction of the path. A lot more is necessary, and usually you spend days (or months depending on the size) with the logic analyzer connected to the board.
> The biggest barrier to FPGAs was always that writing HDL sucked
Are you sure about that? From my experience, that was only 10-30% of the actual work (if your goal is not just to pass the simulator).
They claim that the chip has an "MMU". But unfortunately this doesn't seem to be a true RISC-V MMU (according to the Sv32 specification) integrated into the CPU core itself, but just a peripheral designed for memory mapped SPI flash and PSRAM. So as far as I understand there is no true process isolation with page faults and dynamic paging.
Maybe Espressif will notice that there are no RV32 chips with MMU so far (at least to my knowledge); we only have 32 bit MCUs or then only 64 bits for the CPUs. Something like Cortex-A7 is missing.
Baochip looks very interesting, and I highly respect bunnie's work, but I can't realistically say Baochip is a viable option for me, an unprofessional tinkerer.
I'm not sure why you are not sure - S3 was using Cadence's Xtensa 32-bit LX7 dual-core microprocessor, but the article on S31 only mentions "dual core" without too much detail.
That's the SoC. The CPU is a small part of it. For example they could be using an open source design like the CVA6, or a commercial design from someone like Andes.
reply