20 ms·

Oberon-2, a hi-performance alternative to C++ (1997)

73 points by abricq 4y ago

Rochus 4y ago
Well, Oberon-2 (designed and published by Hanspeter Mössenböck in 1991) was indeed closer to C++ than its predecessor Oberon 87 and 90, but definitely not a true alternative to C++ (because it only supports a fraction of the C++ features). Neither is the optimization done by the available Oberon compilers comparable to what we see in C++ compilers, not even in 1997.
- rurban 4y ago
  That's why you would use o2c, which can use gcc-13 or clang-14. Though I'm convinced that this ship has sailed, with go replacing oberon
  - Rochus 4y ago
    There is even a better alternative; just use the Oberon+ toolchain (compatible with Oberon 87, Oberon-2 and Oberon-07), so you can benefit of a decent IDE with a source-level debugger and a C99 transpiler.
  - kristianp 4y ago
    Or use Modula-2, which was recently added to gcc (https://www.phoronix.com/news/Module-2-GCC-Merged https://www.phoronix.com/news/Module-2-GCC-Merged).
    - rurban 4y ago
      When we can use Oberon, there is no need for Modula-2. Oberon is by far simpler and superior. Just enum and records might be missing from the default Oberon.
      - mannschott 4y ago
        Enumerations and subranges (in style of Modula-2 and Pascal) are missing from Oberon, but Records are present subject to type extension in the style of structs in Go. In Oberon(-1), we used (pointers to) procedures in record fields as methods when programming in an object-oriented style. Oberon-2 added methods which dispatch dynamically based on type of receiver. These were "type bound procedures". You'll find this idea echoed in Go as well.
  - MarcusE1W 4y ago
    As a bit more comfortable alternative to Oberon I would suggest Modula-3. https://github.com/modula3/cm3 https://github.com/modula3/cm3 It even comes with a GUI library, which even though developed in the 90th Stil, works on x11. I find that quite fascinating :-)
- bhaak 4y ago
  > (because it only supports a fraction of the C++ features) I'm pretty sure that both Mössenböck and Wirth would consider this a feature, not a bug.
  - Rochus 4y ago
    Neither Mössenböck nor Wirth were involved with the posted paper, and neither intended to create a "high-performance alternative to C++". The authors of the paper who made this claim are different people, who apparently didn't know C++ good enough.
    - bhaak 4y ago
      The title of the article is quite clickbaity. Neither is the performance of Oberon-2 discussed nor how it compares to C++. But you are wrong if you think that Oberon-2 wasn't considered a competitor to C++. I'd say 1997 was early enough that it wasn't obvious yet that Java would snatch up such a big part of C++'s market share. Wirth has always been very critical of software bloat and C++ is an abomination in programming language design. They certainly didn't set out to make an alternative to C++ but a good language that was an improvement over Oberon.
      - Rochus 4y ago
        C++ was never a role model, neither for Oberon nor for Oberon-2. Wirth was always opposed to C++ and Mössenböck worked in his group. The official goal for Oberon-2 was "to make object-oriented proramming easier without sacrifiicing the conceptual simplicity of Oberon" (from ETH INF Report 160, 1991). Wirth himself was involved when Apple designed Clascal and Object Pascal, and even though you see a different solution to OO in both Oberon and Oberon-2; the latter introduced the receiver syntax for its type-bound procedures, which you can also find in Go (not surprisingly since Mössenböck was the PhD supervisor of Griesemer).
- mpweiher 4y ago
  > [Optimization not comparable to C++] Hmm...considering Proebsting's Law[1], which is always shown to be too optimistic despite its pessimism[2][3], the arguments presented by DJ Bernstein[4] and the fact that Frances Allen got all the good ones in 1971 [5], etc. not sure how much this matters outside a few specialised domains. [1] http://proebsting.cs.arizona.edu/law.html http://proebsting.cs.arizona.edu/law.html [2] https://gwern.net/docs/cs/algorithm/2001-scott.pdf https://gwern.net/docs/cs/algorithm/2001-scott.pdf [3] https://zeux.io/2022/01/08/on-proebstings-law/ https://zeux.io/2022/01/08/on-proebstings-law/ [4] https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf [5] http://venge.net/graydon/talks/CompilerTalk-2019.pdf http://venge.net/graydon/talks/CompilerTalk-2019.pdf
- mhd 4y ago
  I'm currently reading Mössenböck's introduction to OOP (1992), and I'd say it's all pretty much by design. Refreshingly for that era, he doesn't recommend using OOP for everything, and he's aware of other language's features that C++ later embraced, like generics (Ada/Eiffel), but argues that they might not be necessary for what it aims at. And the latter is something we don't see as much these days, where people don't like "gaps", and compiled languages are measured by what they can't do (Go being one notable exception, it seems). For the Oberon system, Oberon was enough, and anything more would probably not have been worth it. Wirth and Mössenböck didn't really aim at meteorology super computers or whatever was the HPC rage in the late 80s/early 90s.
  - pjmlp 4y ago
    Which makes sense in 1990's computing world, and I was a big Oberon fan. However there is a reason why it didn't stop at Oberon-2, and Component Pascal, Active Oberon, Zonnon and others followed up. Not everyone at ETHZ agreed on the minimalism, and for some low level coding it was proven that having stuff like untraced references (introduced in Active Oberon, based on Modula-2+/Modula-3 work) actually made sense. Latest revisions of Active Oberon also have some kind of generics support.
ThinkBeat 4y ago
Pascal is a great alternative to C. It is practical for writing operating systems. Though its use for this has declined if not vanished. Most think of it as a "basic tinkering and learning" language, and indeed, that is probably the most common application. It does not have to be. [1] UNIX came with C, and C became "IT". [1] https://wiki.freepascal.org/Operating_Systems_written_in_FPC#:~:text=Other%20operating%20systems%20written%20in,based%20operating%20system%20from%20scratch https://wiki.freepascal.org/Operating_Systems_written_in_FPC....
- Rochus 4y ago
  The operating systems written in Pascal I'm aware of (e.g. the Lisa the source code of which was published last week) used extended versions of Pascal, which e.g. had the '@' operator; actually I don't know any system of significant size which used original Pascal as specified in Jensen/Wirth's User Manual and Report; do you have references?
  - yjftsjthsd-h 4y ago
    Eh, that's fine, nobody writes OSs in standard C without compiler extensions either.
    - Rochus 4y ago
      There are a couple of operating systems which indeed use standard C; Linux is rather an exception in this respect.
      - yjftsjthsd-h 4y ago
        What OSs would those be? AFAIK none of the major ones - NT, Linux, illumos, or the BSDs are in standard C.
        kevin_thibedeau 4y ago
        All of the embedded OSs. They need to support a mixture of commercial C compilers that don't support GNU extensions.
mikewarot 4y ago
Turbo Pascal/Delphi/Free Pascal evolved since Pascal, and cover quite a bit of the feature set of Oberon, as far as I can tell. The main improvement I see is the implied handling of multiple statements in an if-then-else-end. It seems like it would eliminate a lot of begin/end pairs, so I like it. Wirth's decision to revert to Case sensitivity was a bad one. With the exception of replacing "Uses" with "Import", it looks identical to Free Pascal/Delphi.
- musicale 4y ago
  Not entirely sure why people are downvoting your perspective. There are at least two object lineages for Pascal: one leading to Oberon and the other to Delphi. Both to semi-obscurity, but there is a lot to like in the Pascal language family in my opinion. Personally I find the syntax to be simple and attractive. Even though I spend a lot of time writing C-style languages, I don't have any trouble reading Pascal-style syntax. My complaints about Ada and VHDL, which seem to have Pascal-inspired syntax, are they they feel a bit verbose compared to C++ and Verilog. On the other hand, Ada supports concurrency and memory safety, and has packages for dimensional analysis of physical units, and VHDL supports pluggable implementations.
- pjmlp 4y ago
  While uppercase keywords is a bummer, many IDEs support automatic capitalization. One thing from Oberon linage that Turbo Pascal/Delphi/Free Pascal lack, is automatic memory management (with the exception for COM based types).
  - mikewarot 4y ago
    No garbage collection, but Strings... it handles those brilliantly, you never need to allocate them, and they are automatically reference counted, and just work, even with a gigabyte of ascii in them. It's the best of both worlds. No GC pause, yet you can have huge strings in memory, return them from functions, all without issue.
fortran77 4y ago
Someday Rust will go the way of Oberon.
- sheepscreek 4y ago
  Username checks out. Jokes aside, I’m excited about any future additions to Fortran, esp. to make it appealing to direct data science use.
- speed_spread 4y ago
  You mean there will be a Rust-2? Nice.
- throwaway17_17 4y ago
  Genuinely curious, do you mean Rust will become equivalent to Oberon in terms of developer mindshare/use in production in 2023 (i.e. very limited); or, that someone will ‘Wirth’-ify the Rust language and produce a less complex language that still allows for writing code at Rust’s level of abstraction?
  - mhd 4y ago
    There don't seem to be any Wirth's around, design-wise. We're in the Algol-68 committee's time line.
    - bhaak 4y ago
      Wirth was initially on the committee and resigned after being dissatisfied with the direction Algol 68 took. So we can't be sure if there really is no next Wirth around.
      - mhd 4y ago
        Would academia still reward that kind of thinking? Business certainly doesn't seem to, where you're mostly sticking to 'universal' solutions. The problem is that this 'universe' has such an enormous range.
KMag 4y ago
One interesting thing about at least some versions of the Oberon system is that they found that it was faster to store programs as compressed abstract syntax trees on disk and compile them at load time instead of storing them on disk as native code. This was largely due to 2 factors: (1) the ratio of disk I/O bandwidth to CPU speed on the ETH Zurich workstations and (2) Wirth-style compilers generating code very quickly (with relatively few optimizations). Wirth's graduate student Michael Franz took this a bit further and adapted to storing Java programs as compressed SSA control flow graphs, called SafeTSA. Franz's research group modified the Jalapeno (now JikesRVM) JVM to be able to load SafeTSA files as well as regular Java class files. They found that the time to JIT code was reduced, and the performance of the generated native code was faster when using SafeTSA. The downside is that SafeTSA isn't well suited to interpretation in a HotSpot style hybrid JIT. So, program start-up time would likely suffer unless using AoT compilation. Last time I played around with A2/Bluebottle/AOS, I believe compressed syntax trees were the on-disk program format.
- vidarh 4y ago
  Huge fan of Franz' work on this, his PhD thesis on it[1] is a thing of beauty for it's simple, accessible description. Beyond that, I just wanted to add a couple of things: It doesn't require keeping the generated datastream at the level of the AST per see. You can generate as high- or low-level data as suitable where e.g. a lower level representation requires additional computation but remains independent of hardware architectures. The key is just that what you generate should fit a tree structure. So you can do any number of optimisation steps on the tree prior to applying the semantic dictionary encoding step if you choose. The extension to e.g. serialising SSA forms was pretty natural - there was work at ETHZ on generating SSA form around the same time as well [2] The real beauty of the method is that the encoder and decoder each generates a dictionary the same way e.g. LZW does (and the dissertation cites Welch; Lempel-Ziv style variable length dictionary entries is achieved by simply variable length encoding all integers stored), but where the encoder uses it to compress and flatten the tree, the decoder does not reconstitute the original tree, but uses it to generate machine code fragments directly, and either copy it straight into the code being generated or stores it as a template to reuse for generation of other occurrences of that dictionary element. The compression/decompression and serialization/code-generation are one and the same, and avoiding a separate layer is a key reason why it achieved the speed it did. [1] Code-Generation On-the-Fly: A Key to Portable Software, M. Franz (1994): https://oberoncore.ru/_media/library/franz_m.code-generation_on-the-fly_a_key_to_portable_software.en.pdf https://oberoncore.ru/_media/library/franz_m.code-generation... [2] Single-pass generation of static single-assignment form for structured languages, M. Brandis, H. Mössenböck (1994)
dang 4y ago
Related: Oberon-2, a high performance alternative to C++ (1996) - https://news.ycombinator.com/item?id=13734438 https://news.ycombinator.com/item?id=13734438 - Feb 2017 (2 comments) A basic forking server in Oberon-2 - https://news.ycombinator.com/item?id=11627697 https://news.ycombinator.com/item?id=11627697 - May 2016 (36 comments) Oberon-2, a hi-performance alternative to C++ (1996) - https://news.ycombinator.com/item?id=3361469 https://news.ycombinator.com/item?id=3361469 - Dec 2011 (18 comments)
msla 4y ago
I never got the big appeal of Wirth languages. When they weren't just vanilla Algol derivatives, they were making a virtue out of a performance hack (enforced define-before-use to enable single-pass compilers) or relying on non-standard variants (Turbo Pascal/Delphi) to claim that uninspiring base languages were competitive. As an aside, Oberon-2 isn't a C++ alternative because it apparently has mandatory garbage collection, which isn't acceptable to C++ programmers now (which is why they're going to Rust instead of Go) and damned well wasn't acceptable to them in 1997, else they would have moved to Java.
- kragen 4y ago
  in 01997 it was acceptable to them and that's why most of them did move to java, once hotspot came out if not earlier c++ projects today are very different from c++ projects in the 01990s when basically all 'serious' software was either c++ or c a lot of c++ projects in the 01990s were what we think of now as java projects or c# projects (or django projects): line-of-business systems full of boilerplate and shitty architecture, not streamlined mega-optimized aaa game engines or web browsers c++ projects today are the niche that was left over, which is, yeah, basically the cases where you can't afford gc — ⁂ — the appeal of wirth languages is that you get 90% of the value of a monstrosity like pl/i or c++ for about 5% of the complexity language complexity hurts you three times: when you are learning the language, when you are choosing a compiler, and when you are debugging your code so actually sometimes you get 200% of the value of a monstrosity like pl/i or c++ hopefully at some point someone will develop a wirthified version of rust, but i don't think wirth will do it this time
  - midoridensha 4y ago
    >in 01997 it was acceptable to them >c++ projects today are very different from c++ projects in the 01990s >a lot of c++ projects in the 01990s You got the year wrong with that '0' prefix. The decade you're referring to is the 11990s.
    - shadowofneptune 4y ago
      This might be the finest criticism I've seen of attempts to extend the Christian epoch forward or backwards.
pjmlp 4y ago
For screenshots of what it feels like to use an Oberon based OS, see http://progtools.org/article.php?name=oberon&section=compilers&type=tutorial http://progtools.org/article.php?name=oberon&section=compile...

73 points by abricq 4y ago

Well, Oberon-2 (designed and published by Hanspeter Mössenböck in 1991) was indeed closer to C++ than its predecessor Oberon 87 and 90, but definitely not a true alternative to C++ (because it only supports a fraction of the C++ features). Neither is the optimization done by the available Oberon compilers comparable to what we see in C++ compilers, not even in 1997.

rurban 4y ago
That's why you would use o2c, which can use gcc-13 or clang-14. Though I'm convinced that this ship has sailed, with go replacing oberon
- Rochus 4y ago
  There is even a better alternative; just use the Oberon+ toolchain (compatible with Oberon 87, Oberon-2 and Oberon-07), so you can benefit of a decent IDE with a source-level debugger and a C99 transpiler.
- kristianp 4y ago
  Or use Modula-2, which was recently added to gcc (https://www.phoronix.com/news/Module-2-GCC-Merged https://www.phoronix.com/news/Module-2-GCC-Merged).
  - rurban 4y ago
    When we can use Oberon, there is no need for Modula-2. Oberon is by far simpler and superior. Just enum and records might be missing from the default Oberon.
    - mannschott 4y ago
      Enumerations and subranges (in style of Modula-2 and Pascal) are missing from Oberon, but Records are present subject to type extension in the style of structs in Go. In Oberon(-1), we used (pointers to) procedures in record fields as methods when programming in an object-oriented style. Oberon-2 added methods which dispatch dynamically based on type of receiver. These were "type bound procedures". You'll find this idea echoed in Go as well.
- MarcusE1W 4y ago
  As a bit more comfortable alternative to Oberon I would suggest Modula-3. https://github.com/modula3/cm3 https://github.com/modula3/cm3 It even comes with a GUI library, which even though developed in the 90th Stil, works on x11. I find that quite fascinating :-)
bhaak 4y ago
> (because it only supports a fraction of the C++ features) I'm pretty sure that both Mössenböck and Wirth would consider this a feature, not a bug.
- Rochus 4y ago
  Neither Mössenböck nor Wirth were involved with the posted paper, and neither intended to create a "high-performance alternative to C++". The authors of the paper who made this claim are different people, who apparently didn't know C++ good enough.
  - bhaak 4y ago
    The title of the article is quite clickbaity. Neither is the performance of Oberon-2 discussed nor how it compares to C++. But you are wrong if you think that Oberon-2 wasn't considered a competitor to C++. I'd say 1997 was early enough that it wasn't obvious yet that Java would snatch up such a big part of C++'s market share. Wirth has always been very critical of software bloat and C++ is an abomination in programming language design. They certainly didn't set out to make an alternative to C++ but a good language that was an improvement over Oberon.
    - Rochus 4y ago
      C++ was never a role model, neither for Oberon nor for Oberon-2. Wirth was always opposed to C++ and Mössenböck worked in his group. The official goal for Oberon-2 was "to make object-oriented proramming easier without sacrifiicing the conceptual simplicity of Oberon" (from ETH INF Report 160, 1991). Wirth himself was involved when Apple designed Clascal and Object Pascal, and even though you see a different solution to OO in both Oberon and Oberon-2; the latter introduced the receiver syntax for its type-bound procedures, which you can also find in Go (not surprisingly since Mössenböck was the PhD supervisor of Griesemer).
mpweiher 4y ago
> [Optimization not comparable to C++] Hmm...considering Proebsting's Law[1], which is always shown to be too optimistic despite its pessimism[2][3], the arguments presented by DJ Bernstein[4] and the fact that Frances Allen got all the good ones in 1971 [5], etc. not sure how much this matters outside a few specialised domains. [1] http://proebsting.cs.arizona.edu/law.html http://proebsting.cs.arizona.edu/law.html [2] https://gwern.net/docs/cs/algorithm/2001-scott.pdf https://gwern.net/docs/cs/algorithm/2001-scott.pdf [3] https://zeux.io/2022/01/08/on-proebstings-law/ https://zeux.io/2022/01/08/on-proebstings-law/ [4] https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf [5] http://venge.net/graydon/talks/CompilerTalk-2019.pdf http://venge.net/graydon/talks/CompilerTalk-2019.pdf
mhd 4y ago
I'm currently reading Mössenböck's introduction to OOP (1992), and I'd say it's all pretty much by design. Refreshingly for that era, he doesn't recommend using OOP for everything, and he's aware of other language's features that C++ later embraced, like generics (Ada/Eiffel), but argues that they might not be necessary for what it aims at. And the latter is something we don't see as much these days, where people don't like "gaps", and compiled languages are measured by what they can't do (Go being one notable exception, it seems). For the Oberon system, Oberon was enough, and anything more would probably not have been worth it. Wirth and Mössenböck didn't really aim at meteorology super computers or whatever was the HPC rage in the late 80s/early 90s.
- pjmlp 4y ago
  Which makes sense in 1990's computing world, and I was a big Oberon fan. However there is a reason why it didn't stop at Oberon-2, and Component Pascal, Active Oberon, Zonnon and others followed up. Not everyone at ETHZ agreed on the minimalism, and for some low level coding it was proven that having stuff like untraced references (introduced in Active Oberon, based on Modula-2+/Modula-3 work) actually made sense. Latest revisions of Active Oberon also have some kind of generics support.

ThinkBeat 4y ago

Pascal is a great alternative to C. It is practical for writing operating systems. Though its use for this has declined if not vanished. Most think of it as a "basic tinkering and learning" language, and indeed, that is probably the most common application. It does not have to be. [1] UNIX came with C, and C became "IT". [1] https://wiki.freepascal.org/Operating_Systems_written_in_FPC#:~:text=Other%20operating%20systems%20written%20in,based%20operating%20system%20from%20scratch https://wiki.freepascal.org/Operating_Systems_written_in_FPC....

Rochus 4y ago
The operating systems written in Pascal I'm aware of (e.g. the Lisa the source code of which was published last week) used extended versions of Pascal, which e.g. had the '@' operator; actually I don't know any system of significant size which used original Pascal as specified in Jensen/Wirth's User Manual and Report; do you have references?
- yjftsjthsd-h 4y ago
  Eh, that's fine, nobody writes OSs in standard C without compiler extensions either.
  - Rochus 4y ago
    There are a couple of operating systems which indeed use standard C; Linux is rather an exception in this respect.
    - yjftsjthsd-h 4y ago
      What OSs would those be? AFAIK none of the major ones - NT, Linux, illumos, or the BSDs are in standard C.
      - kevin_thibedeau 4y ago
        All of the embedded OSs. They need to support a mixture of commercial C compilers that don't support GNU extensions.

mikewarot 4y ago

Turbo Pascal/Delphi/Free Pascal evolved since Pascal, and cover quite a bit of the feature set of Oberon, as far as I can tell. The main improvement I see is the implied handling of multiple statements in an if-then-else-end. It seems like it would eliminate a lot of begin/end pairs, so I like it. Wirth's decision to revert to Case sensitivity was a bad one. With the exception of replacing "Uses" with "Import", it looks identical to Free Pascal/Delphi.

musicale 4y ago
Not entirely sure why people are downvoting your perspective. There are at least two object lineages for Pascal: one leading to Oberon and the other to Delphi. Both to semi-obscurity, but there is a lot to like in the Pascal language family in my opinion. Personally I find the syntax to be simple and attractive. Even though I spend a lot of time writing C-style languages, I don't have any trouble reading Pascal-style syntax. My complaints about Ada and VHDL, which seem to have Pascal-inspired syntax, are they they feel a bit verbose compared to C++ and Verilog. On the other hand, Ada supports concurrency and memory safety, and has packages for dimensional analysis of physical units, and VHDL supports pluggable implementations.
pjmlp 4y ago
While uppercase keywords is a bummer, many IDEs support automatic capitalization. One thing from Oberon linage that Turbo Pascal/Delphi/Free Pascal lack, is automatic memory management (with the exception for COM based types).
- mikewarot 4y ago
  No garbage collection, but Strings... it handles those brilliantly, you never need to allocate them, and they are automatically reference counted, and just work, even with a gigabyte of ascii in them. It's the best of both worlds. No GC pause, yet you can have huge strings in memory, return them from functions, all without issue.

fortran77 4y ago

Someday Rust will go the way of Oberon.

sheepscreek 4y ago
Username checks out. Jokes aside, I’m excited about any future additions to Fortran, esp. to make it appealing to direct data science use.
speed_spread 4y ago
You mean there will be a Rust-2? Nice.
throwaway17_17 4y ago
Genuinely curious, do you mean Rust will become equivalent to Oberon in terms of developer mindshare/use in production in 2023 (i.e. very limited); or, that someone will ‘Wirth’-ify the Rust language and produce a less complex language that still allows for writing code at Rust’s level of abstraction?
- mhd 4y ago
  There don't seem to be any Wirth's around, design-wise. We're in the Algol-68 committee's time line.
  - bhaak 4y ago
    Wirth was initially on the committee and resigned after being dissatisfied with the direction Algol 68 took. So we can't be sure if there really is no next Wirth around.
    - mhd 4y ago
      Would academia still reward that kind of thinking? Business certainly doesn't seem to, where you're mostly sticking to 'universal' solutions. The problem is that this 'universe' has such an enormous range.

KMag 4y ago

One interesting thing about at least some versions of the Oberon system is that they found that it was faster to store programs as compressed abstract syntax trees on disk and compile them at load time instead of storing them on disk as native code. This was largely due to 2 factors: (1) the ratio of disk I/O bandwidth to CPU speed on the ETH Zurich workstations and (2) Wirth-style compilers generating code very quickly (with relatively few optimizations). Wirth's graduate student Michael Franz took this a bit further and adapted to storing Java programs as compressed SSA control flow graphs, called SafeTSA. Franz's research group modified the Jalapeno (now JikesRVM) JVM to be able to load SafeTSA files as well as regular Java class files. They found that the time to JIT code was reduced, and the performance of the generated native code was faster when using SafeTSA. The downside is that SafeTSA isn't well suited to interpretation in a HotSpot style hybrid JIT. So, program start-up time would likely suffer unless using AoT compilation. Last time I played around with A2/Bluebottle/AOS, I believe compressed syntax trees were the on-disk program format.

vidarh 4y ago
Huge fan of Franz' work on this, his PhD thesis on it[1] is a thing of beauty for it's simple, accessible description. Beyond that, I just wanted to add a couple of things: It doesn't require keeping the generated datastream at the level of the AST per see. You can generate as high- or low-level data as suitable where e.g. a lower level representation requires additional computation but remains independent of hardware architectures. The key is just that what you generate should fit a tree structure. So you can do any number of optimisation steps on the tree prior to applying the semantic dictionary encoding step if you choose. The extension to e.g. serialising SSA forms was pretty natural - there was work at ETHZ on generating SSA form around the same time as well [2] The real beauty of the method is that the encoder and decoder each generates a dictionary the same way e.g. LZW does (and the dissertation cites Welch; Lempel-Ziv style variable length dictionary entries is achieved by simply variable length encoding all integers stored), but where the encoder uses it to compress and flatten the tree, the decoder does not reconstitute the original tree, but uses it to generate machine code fragments directly, and either copy it straight into the code being generated or stores it as a template to reuse for generation of other occurrences of that dictionary element. The compression/decompression and serialization/code-generation are one and the same, and avoiding a separate layer is a key reason why it achieved the speed it did. [1] Code-Generation On-the-Fly: A Key to Portable Software, M. Franz (1994): https://oberoncore.ru/_media/library/franz_m.code-generation_on-the-fly_a_key_to_portable_software.en.pdf https://oberoncore.ru/_media/library/franz_m.code-generation... [2] Single-pass generation of static single-assignment form for structured languages, M. Brandis, H. Mössenböck (1994)

dang 4y ago

Related: Oberon-2, a high performance alternative to C++ (1996) - https://news.ycombinator.com/item?id=13734438 https://news.ycombinator.com/item?id=13734438 - Feb 2017 (2 comments) A basic forking server in Oberon-2 - https://news.ycombinator.com/item?id=11627697 https://news.ycombinator.com/item?id=11627697 - May 2016 (36 comments) Oberon-2, a hi-performance alternative to C++ (1996) - https://news.ycombinator.com/item?id=3361469 https://news.ycombinator.com/item?id=3361469 - Dec 2011 (18 comments)

msla 4y ago

I never got the big appeal of Wirth languages. When they weren't just vanilla Algol derivatives, they were making a virtue out of a performance hack (enforced define-before-use to enable single-pass compilers) or relying on non-standard variants (Turbo Pascal/Delphi) to claim that uninspiring base languages were competitive. As an aside, Oberon-2 isn't a C++ alternative because it apparently has mandatory garbage collection, which isn't acceptable to C++ programmers now (which is why they're going to Rust instead of Go) and damned well wasn't acceptable to them in 1997, else they would have moved to Java.

kragen 4y ago
in 01997 it was acceptable to them and that's why most of them did move to java, once hotspot came out if not earlier c++ projects today are very different from c++ projects in the 01990s when basically all 'serious' software was either c++ or c a lot of c++ projects in the 01990s were what we think of now as java projects or c# projects (or django projects): line-of-business systems full of boilerplate and shitty architecture, not streamlined mega-optimized aaa game engines or web browsers c++ projects today are the niche that was left over, which is, yeah, basically the cases where you can't afford gc — ⁂ — the appeal of wirth languages is that you get 90% of the value of a monstrosity like pl/i or c++ for about 5% of the complexity language complexity hurts you three times: when you are learning the language, when you are choosing a compiler, and when you are debugging your code so actually sometimes you get 200% of the value of a monstrosity like pl/i or c++ hopefully at some point someone will develop a wirthified version of rust, but i don't think wirth will do it this time
- midoridensha 4y ago
  >in 01997 it was acceptable to them >c++ projects today are very different from c++ projects in the 01990s >a lot of c++ projects in the 01990s You got the year wrong with that '0' prefix. The decade you're referring to is the 11990s.
  - shadowofneptune 4y ago
    This might be the finest criticism I've seen of attempts to extend the Christian epoch forward or backwards.

pjmlp 4y ago

For screenshots of what it feels like to use an Oberon based OS, see http://progtools.org/article.php?name=oberon&section=compilers&type=tutorial http://progtools.org/article.php?name=oberon&section=compile...