3 ms·

Compiling Oberon to native code, nice! Since Oberon is as much a compiler as it's a complete system, a big part of the work is to integrate that system into it

Compiling Oberon to native code, nice! Since Oberon is as much a compiler as it's a complete system, a big part of the work is to integrate that system into its host. It seems they've done it for files and stdin/stdout, but not for the graphical system yet (through SDL or something). I wonder if it's on their roadmap. As a shameless plug, I'm in the process of doing something very similar[1] for Dusk OS[2]. [1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/comp/oberon.txt https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co... [2]: http://duskos.org http://duskos.org

Rochus 2y ago
> Since Oberon is as much a compiler as it's a complete system, The system and the language are two different things (even if they unfortunately share the same name); the language itself doesn't depend on the system. Instead there is a standard library defined in the Oakwood guidelines; the guidelines even define a (primitive) drawing window (XYPlane). The Oberon+ compiler (see https://github.com/rochus-keller/oberon/ https://github.com/rochus-keller/oberon/) includes a foreign function interface and a binding to e.g. the NAppGUI library which is a powerfull cross-platform user interface framework, but also an SDL binding, which is e.g. used by https://github.com/rochus-keller/OberonSystem3/ https://github.com/rochus-keller/OberonSystem3/.
sevoves 2y ago
Actually it's transpiling to C (but the other way around would make more sense so existing code can be ported to project oberon os). For example there's an X11 wrapper [1], or http library [2], a package manager [3], etc, and calling external C code is easy, e.g. PROCEDURE -fstat(fd: LONGINT): INTEGER "fstat(fd, &s)"; Other libraries are mostly scattered all over the internet, and there are often compatibility issues between compilers, even though they target the same standards. [1]:https://github.com/vishapoberon/compiler/tree/master/src/library/oocX11 https://github.com/vishapoberon/compiler/tree/master/src/lib... [2]:https://github.com/norayr/http/ https://github.com/norayr/http/ [3]:https://github.com/vishapoberon/vipack https://github.com/vishapoberon/vipack > very similar[1] for Dusk OS[2] wow this is cool
joshu 2y ago
I love what you’re doing with duskos! have been watching for a while.
- vdupras 2y ago
  Thanks. While I'm fully self-motivated (when you feel you're in uncharted waters, it's hard to stop exploring), I still appreciate some sort of external validation that I'm not delusional. But this stuff (well, Forth in general) requires such a big shift in mindset as to how we approach computing that I understand why it stays niche. Kind of like Lisp but, IMO, deeper.
  - joshu 2y ago
    i have been thinking about how to build a machine that is smaller and easier to understand and looking for an OS that is smaller and easier to understand to go with it. yours is probably one of the closest i’ve looked at…
    - vdupras 2y ago
      Let me know when you find the matching hardware! I'll make it my official "canonical Dusk machine" :) Most modern hardware is way too complex. Dusk uses a fraction of it, but still has to deal with spurious complexity. Personally, my favorite 32-bit SBC so far is PC Engine's Alix board[1]. Sure, it has the ugly BIOS legacy, but is otherwise a very nice no-frills SBC. I just wish I bought one with a VGA adapter before it closed shop. [1]: https://pcengines.ch/alix.htm https://pcengines.ch/alix.htm
      - joshu 2y ago
        conveniently i have several alixes but none with video output. I am actually thinking about custom hardware at the moment. Or maybe FPGA emulation of custom hardware. I actually would prefer a smaller machine but most of them are too impaired (eg 6502 is just a bit too weird) so probably 68k-based. which you support! (is there a boot image somewhere? i wonder if it would run in an emulator) right now my thought is an FPGA board is probably for the best...
lproven 2y ago
> Compiling Oberon to native code, nice! I may be missing something but don't all versions of Oberon compile to native code? Or is what you are getting at code that's native to the underlying OS and not the Oberon environment?
- vdupras 2y ago
  Yes, that's what I mean. Classic Oberon compiles to RISC5 (not RISC-V), which is a "made up" CPU. Unless you have a FPGA, Oberon is always going to be emulated on a regular machine.
  - lproven 2y ago
    Not really, no. Here is the 386 PC version, which loads from MS-DOS. https://sourceforge.net/projects/dosoberon/files/DOS%20Oberon%20Version%201.4/ https://sourceforge.net/projects/dosoberon/files/DOS%20Obero... Other versions run or ran on ARM, 68000, PowerPC, x86-64 and other platforms.
    - vdupras 2y ago
      Interesting, I didn't know about that! I wonder why the Project Oberon website doesn't link to those ports.
      - lproven 2y ago
        Because it's an updated version of Prof Wirth's original in-house project from ETH, once an inexpensive FPGA became viable. I wrote about it a decade ago: https://www.theregister.com/2015/12/02/pi_versus_oberton/ https://www.theregister.com/2015/12/02/pi_versus_oberton/ That's one source reflecting one particular project, which Prof Wirth came out of retirement to help with. It is not representative of the broader use and adoption of Oberon at all. Once there was commodity 32-bit hardware, Oberon researchers adopted it with enthusiasm and it has at various times run on most 32-bit CPUs. These days, the work I'm aware of is mostly on x86, though. For example, this commercial offshoot, Blackbox Component Pascal: https://blackboxframework.org/ https://blackboxframework.org/

Rochus 2y ago

> Since Oberon is as much a compiler as it's a complete system, The system and the language are two different things (even if they unfortunately share the same name); the language itself doesn't depend on the system. Instead there is a standard library defined in the Oakwood guidelines; the guidelines even define a (primitive) drawing window (XYPlane). The Oberon+ compiler (see https://github.com/rochus-keller/oberon/ https://github.com/rochus-keller/oberon/) includes a foreign function interface and a binding to e.g. the NAppGUI library which is a powerfull cross-platform user interface framework, but also an SDL binding, which is e.g. used by https://github.com/rochus-keller/OberonSystem3/ https://github.com/rochus-keller/OberonSystem3/.

sevoves 2y ago

Actually it's transpiling to C (but the other way around would make more sense so existing code can be ported to project oberon os). For example there's an X11 wrapper [1], or http library [2], a package manager [3], etc, and calling external C code is easy, e.g. PROCEDURE -fstat(fd: LONGINT): INTEGER "fstat(fd, &s)"; Other libraries are mostly scattered all over the internet, and there are often compatibility issues between compilers, even though they target the same standards. [1]:https://github.com/vishapoberon/compiler/tree/master/src/library/oocX11 https://github.com/vishapoberon/compiler/tree/master/src/lib... [2]:https://github.com/norayr/http/ https://github.com/norayr/http/ [3]:https://github.com/vishapoberon/vipack https://github.com/vishapoberon/vipack > very similar[1] for Dusk OS[2] wow this is cool

joshu 2y ago

I love what you’re doing with duskos! have been watching for a while.

vdupras 2y ago
Thanks. While I'm fully self-motivated (when you feel you're in uncharted waters, it's hard to stop exploring), I still appreciate some sort of external validation that I'm not delusional. But this stuff (well, Forth in general) requires such a big shift in mindset as to how we approach computing that I understand why it stays niche. Kind of like Lisp but, IMO, deeper.
- joshu 2y ago
  i have been thinking about how to build a machine that is smaller and easier to understand and looking for an OS that is smaller and easier to understand to go with it. yours is probably one of the closest i’ve looked at…
  - vdupras 2y ago
    Let me know when you find the matching hardware! I'll make it my official "canonical Dusk machine" :) Most modern hardware is way too complex. Dusk uses a fraction of it, but still has to deal with spurious complexity. Personally, my favorite 32-bit SBC so far is PC Engine's Alix board[1]. Sure, it has the ugly BIOS legacy, but is otherwise a very nice no-frills SBC. I just wish I bought one with a VGA adapter before it closed shop. [1]: https://pcengines.ch/alix.htm https://pcengines.ch/alix.htm
    - joshu 2y ago
      conveniently i have several alixes but none with video output. I am actually thinking about custom hardware at the moment. Or maybe FPGA emulation of custom hardware. I actually would prefer a smaller machine but most of them are too impaired (eg 6502 is just a bit too weird) so probably 68k-based. which you support! (is there a boot image somewhere? i wonder if it would run in an emulator) right now my thought is an FPGA board is probably for the best...

lproven 2y ago

> Compiling Oberon to native code, nice! I may be missing something but don't all versions of Oberon compile to native code? Or is what you are getting at code that's native to the underlying OS and not the Oberon environment?

vdupras 2y ago
Yes, that's what I mean. Classic Oberon compiles to RISC5 (not RISC-V), which is a "made up" CPU. Unless you have a FPGA, Oberon is always going to be emulated on a regular machine.
- lproven 2y ago
  Not really, no. Here is the 386 PC version, which loads from MS-DOS. https://sourceforge.net/projects/dosoberon/files/DOS%20Oberon%20Version%201.4/ https://sourceforge.net/projects/dosoberon/files/DOS%20Obero... Other versions run or ran on ARM, 68000, PowerPC, x86-64 and other platforms.
  - vdupras 2y ago
    Interesting, I didn't know about that! I wonder why the Project Oberon website doesn't link to those ports.
    - lproven 2y ago
      Because it's an updated version of Prof Wirth's original in-house project from ETH, once an inexpensive FPGA became viable. I wrote about it a decade ago: https://www.theregister.com/2015/12/02/pi_versus_oberton/ https://www.theregister.com/2015/12/02/pi_versus_oberton/ That's one source reflecting one particular project, which Prof Wirth came out of retirement to help with. It is not representative of the broader use and adoption of Oberon at all. Once there was commodity 32-bit hardware, Oberon researchers adopted it with enthusiasm and it has at various times run on most 32-bit CPUs. These days, the work I'm aware of is mostly on x86, though. For example, this commercial offshoot, Blackbox Component Pascal: https://blackboxframework.org/ https://blackboxframework.org/