I was about 5 links deep before I figured out what Oberon actually was. A high-level explainer at the top of the readme would be really nice for folks who aren't already familiar with the Oberon ecosystem
Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)
51–60 of 122 posts
Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)
#52Earlier quoted context omitted.
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 dev…
Cool. Is macOS (Apple Silicon) also supported? If not, well there's another reason to have a Linux VM ready :)
Technically yes, but since Apple locked down their OS completely, you might have to compile the tools yourself on your machine so the OS allows them to start at all.
Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)
#53Earlier quoted context omitted.
It might have been Brandis' thesis I was primarily thinking about. Of the PhD theses at EHTz on Oberon, I'm also a big fan of Michael Franz' thesis on Semantic Dictionary Encoding, but that only touched on optimization potential as a sidenote. I'm certain there was at least one other paper on optimization, but it might not have been a PhD thesis... I get the motivation for wanting to use LLVM, but personally I don't…
I don’t like LLVM either, because its size and complexity are simply spiraling out of control, and especially because I consider the IR to be a total design failure. If I use LLVM at all, it would be version 4.0.1 or 3.4 at most. But it is the standard, especially if you want to run tests related to the question the fellow asked above. The alternative would be to build a frontend for GCC, but that is no less complex…
> However, C on LLVM or GCC should probably be considered the “upper bound” when it comes to how well a program can be optimized, and thus the benchmark for any performance measurement.
Is it? Isn't it rather the case that C is too low level to express intent and (hence) offer room to optimize? I would expect that a language in which, e.g. matrix multiplication can be natively expressed, could be compiled to more efficient code for such.
I would rather expect, that for compilers which don't optimize well, C is the easiest to produce fairly efficient code for (well, perhaps BCPL would be even easier, but nobody wants to use that these days).
Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)
#54Earlier quoted context omitted.
I don’t like LLVM either, because its size and complexity are simply spiraling out of control, and especially because I consider the IR to be a total design failure. If I use LLVM at all, it would be version 4.0.1 or 3.4 at most. But it is the standard, especially if you want to run tests related to the question the fellow asked above. The alternative would be to build a frontend for GCC, but that is no less complex…
When you call LLVM IR a design failure, do you mean its semantic model (e.g., memory/UB), or its role as a cross-language contract? Is there a specific IR propert that prevents clean mapping from Oberon?
Several historical design choices within the IR itself have created immense complexity, leading to unsound optimizations and severe compile-time bloat. It's not high-level enough so you e.g. don't have to care about ABI details, and it's not low-level enought to actually take care of those ABI details in a decent way. And it's a continuous moving target. You cannot implement something which then continus to work.
Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)
#55Earlier quoted context omitted.
I don’t like LLVM either, because its size and complexity are simply spiraling out of control, and especially because I consider the IR to be a total design failure. If I use LLVM at all, it would be version 4.0.1 or 3.4 at most. But it is the standard, especially if you want to run tests related to the question the fellow asked above. The alternative would be to build a frontend for GCC, but that is no less complex…
> However, C on LLVM or GCC should probably be considered the “upper bound” when it comes to how well a program can be optimized, and thus the benchmark for any performance measurement. Is it? Isn't it rather the case that C is too low level to express intent and (hence) offer room to optimize? I would expect that a language in which, e.g. matrix multiplication can be natively expressed, could be compiled to more eff…
> I would expect that a language in which, e.g. matrix multiplication can be natively expressed, could be compiled to more efficient code for such.
That's exactly the question we would hope to answer with such an experiment. Given that your language received sufficient investments to implement an optimal LLVM adaptation (as C did), we would then expect your language to be significantly faster on a benchmark heavily depending on matrix multiplication. If not, this would mean that the optimizer can get away with any language and the specific language design features have little impact on performance (and we can use them without performance worries).
Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)
#56Impressive work. Native boot on Raspberry Pi without emulation is a rare thing to see working cleanly. How's the performance compared to running Oberon on a standard x86 setup? And does this open up the possibility of running it headless as a small server?
Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)
#57This is great, especially being System 3, given the nice user experience Oberon eventually morphed into. In System 3 with the Gadgets system it was already starting to feel like a proper mainstream OS, instead of the plain black and white, without framework like experience from the initial Project Oberon, even thought it was a technological achivement already, with a memory safe systems language. I prefer the path ta…
Thanks. Preparations for the migraion of AOS/Bluebottle are underway. Concerning memory safety: it's only memory safe if you don't use the SYSTEM module features, and OberonSystem 3 (and later) heavily depend on those features.
Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)
#58This is great, especially being System 3, given the nice user experience Oberon eventually morphed into. In System 3 with the Gadgets system it was already starting to feel like a proper mainstream OS, instead of the plain black and white, without framework like experience from the initial Project Oberon, even thought it was a technological achivement already, with a memory safe systems language. I prefer the path ta…
Thanks. Preparations for the migraion of AOS/Bluebottle are underway. Concerning memory safety: it's only memory safe if you don't use the SYSTEM module features, and OberonSystem 3 (and later) heavily depend on those features.
Sure, but that in the end is what matters with memory safe systems languages, reduction of attack surface and easy to spot when safety is being disabled.
Alternative being Assembly written primitives, like in Smalltalk originally. Blue book description.
Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)
#59Earlier quoted context omitted.
Thanks. Preparations for the migraion of AOS/Bluebottle are underway. Concerning memory safety: it's only memory safe if you don't use the SYSTEM module features, and OberonSystem 3 (and later) heavily depend on those features.
Sure, but that in the end is what matters with memory safe systems languages, reduction of attack surface and easy to spot when safety is being disabled. Alternative being Assembly written primitives, like in Smalltalk originally. Blue book description.
There are better alternatives than assembly. The Oberon approach would already benefit if low-level code no longer operates behind the compiler's back and instead supports full type checking. My new Micron language provides this.
Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)
#60Does Oberon still require capitalized keywords? That always seemed to be emphasizing the wrong thing: IF disaster THEN abort;
Yes, like Modula-2 as well. However, people always forget we don't program in Notepad, rather programmer editors that are able to do automatic capitalisation of keywords. It is a non problem, like discussion of parentheses or white space in programming languages that require them.
Does the editor in this environment do automatic capitalisation?
I have to say that when I used Modula-2, editors were very simple and banging away on the shift key or caps lock was a real irritation.