3 ms·

Or just use a simple, stack machine. Or a RISC CPU. Preferrably on an emulator or FPGA already. Oberon did this.

rbanffy 10y ago
It pains me when someone decides to submit to the pain of building something directly on the legacy of the ugliest computer ever built.
- nickpsecurity 10y ago
  I hear you. Pains me it won out instead of i960 with an emulation mode for backward compatibility. Far as learning on x86, there's two counterpoints come to mind: 1. Most sample code out there for "real" OS's might be x86. Most projects that aren't embedded will target it. So, might bite the bullet for that reason. 2. Other reason is if the end goal is to improve software on x86 hardware. As in, learner explicitly wants to take advantage of high-performance, x86 chips or code. A shortcut might be porting more sample OS's to non-x86 CPU's. They learn each thing for simple architecture followed by ugly one later. Alternatively, abstract away what one can like Fluxkit project did. That was how a number of OS's were built in high-level languages without having to redo all the low-level stuff.
bogomipz 10y ago
I would like to hear more about Oberon OS running on an emulator. Might you have a link, this sounds interesting?
- Someone 10y ago
  I think the OP, when saying "Preferrably on an emulator or FPGA already. Oberon did this.” meant that Oberon (second edition; the first one ran on a NS32032) ran on a FPGA (https://lists.inf.ethz.ch/pipermail/oberon/2013/006922.html https://lists.inf.ethz.ch/pipermail/oberon/2013/006922.html, https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Computer.pdf https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Comp...)
  - bogomipz 10y ago
    I see that makes sense, thanks for the clarification and the links. The more I hear about Oberon the more intrigued I am. Thanks for the links.
- nickpsecurity 10y ago
  There were several versions of the Oberon OS as they explored new languages and hardware. The first relevant here is Native Oberon using original, Oberon language: http://www.ethoberon.ethz.ch/native/ http://www.ethoberon.ethz.ch/native/ They also did one, Active Oberon System, based on a multi-threaded language called Active Oberon. The latest version of that was A2 Bluebottle. I ran its ISO in VirtualBox a year or two ago to get a bare-bones, but fast, experience. http://www.ocp.inf.ethz.ch/wiki/OCP/Downloads http://www.ocp.inf.ethz.ch/wiki/OCP/Downloads You might also love the alternate history we missed in the Juice project to replace Java applets (or todays JS apps) with Oberon apps sent as compressed, abstract-syntax trees. If you know how fast Go is, then you'll know what we lost when it got ignored. https://github.com/Spirit-of-Oberon/Juice https://github.com/Spirit-of-Oberon/Juice
  - bogomipz 10y ago
    Oh these are great, thanks so much for the links and detailed response. I can't wait to play with these. I had one questions about this comment in regards to compresses ASTs: >" If you know how fast Go is, then you'll know what we lost when it got ignored" I am intrigued by that statement but I don't understand it. Can you elaborate? Cheers.
    - nickpsecurity 10y ago
      Go is a Wirth-like language. Wirth's measure for complexiy of a language was how long it took to compile. He'd take features out if compiles got too slow. So, the Wirth compilers were fast along lines of tens to hundred thousand lines of code compiled per second. They didn't optimize a ton either but code was fast enough. So, with Juice, you're looking at getting an Oberon program or subset of Go delivered to your computer as compressed source, type-checked + compiled in a second, and then running safely at native performance. Much better than Javascript or Java applets. Would've had way fewer vulnerabilities, too, since Oberon effectively has no runtime except the GC. It's also memory-safe. EDIT: Looking at Pascal stuff, I found an example of Wirth-style, compile speed in a Delphi discussion. Delphi was the VC++ alternative from Pascal family. One commenter on HN talking a legacy codebase praised compile speed: "a full build of 2 million lines takes less than a minute on a single core." That's for an exe with no VM's, dependencies, etc that runs on vanilla x86 & win32. Or alternative platforms with FOSS Lazaurus.

It pains me when someone decides to submit to the pain of building something directly on the legacy of the ugliest computer ever built.

nickpsecurity 10y ago
I hear you. Pains me it won out instead of i960 with an emulation mode for backward compatibility. Far as learning on x86, there's two counterpoints come to mind: 1. Most sample code out there for "real" OS's might be x86. Most projects that aren't embedded will target it. So, might bite the bullet for that reason. 2. Other reason is if the end goal is to improve software on x86 hardware. As in, learner explicitly wants to take advantage of high-performance, x86 chips or code. A shortcut might be porting more sample OS's to non-x86 CPU's. They learn each thing for simple architecture followed by ugly one later. Alternatively, abstract away what one can like Fluxkit project did. That was how a number of OS's were built in high-level languages without having to redo all the low-level stuff.

bogomipz 10y ago

I would like to hear more about Oberon OS running on an emulator. Might you have a link, this sounds interesting?

Someone 10y ago
I think the OP, when saying "Preferrably on an emulator or FPGA already. Oberon did this.” meant that Oberon (second edition; the first one ran on a NS32032) ran on a FPGA (https://lists.inf.ethz.ch/pipermail/oberon/2013/006922.html https://lists.inf.ethz.ch/pipermail/oberon/2013/006922.html, https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Computer.pdf https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Comp...)
- bogomipz 10y ago
  I see that makes sense, thanks for the clarification and the links. The more I hear about Oberon the more intrigued I am. Thanks for the links.
nickpsecurity 10y ago
There were several versions of the Oberon OS as they explored new languages and hardware. The first relevant here is Native Oberon using original, Oberon language: http://www.ethoberon.ethz.ch/native/ http://www.ethoberon.ethz.ch/native/ They also did one, Active Oberon System, based on a multi-threaded language called Active Oberon. The latest version of that was A2 Bluebottle. I ran its ISO in VirtualBox a year or two ago to get a bare-bones, but fast, experience. http://www.ocp.inf.ethz.ch/wiki/OCP/Downloads http://www.ocp.inf.ethz.ch/wiki/OCP/Downloads You might also love the alternate history we missed in the Juice project to replace Java applets (or todays JS apps) with Oberon apps sent as compressed, abstract-syntax trees. If you know how fast Go is, then you'll know what we lost when it got ignored. https://github.com/Spirit-of-Oberon/Juice https://github.com/Spirit-of-Oberon/Juice
- bogomipz 10y ago
  Oh these are great, thanks so much for the links and detailed response. I can't wait to play with these. I had one questions about this comment in regards to compresses ASTs: >" If you know how fast Go is, then you'll know what we lost when it got ignored" I am intrigued by that statement but I don't understand it. Can you elaborate? Cheers.
  - nickpsecurity 10y ago
    Go is a Wirth-like language. Wirth's measure for complexiy of a language was how long it took to compile. He'd take features out if compiles got too slow. So, the Wirth compilers were fast along lines of tens to hundred thousand lines of code compiled per second. They didn't optimize a ton either but code was fast enough. So, with Juice, you're looking at getting an Oberon program or subset of Go delivered to your computer as compressed source, type-checked + compiled in a second, and then running safely at native performance. Much better than Javascript or Java applets. Would've had way fewer vulnerabilities, too, since Oberon effectively has no runtime except the GC. It's also memory-safe. EDIT: Looking at Pascal stuff, I found an example of Wirth-style, compile speed in a Delphi discussion. Delphi was the VC++ alternative from Pascal family. One commenter on HN talking a legacy codebase praised compile speed: "a full build of 2 million lines takes less than a minute on a single core." That's for an exe with no VM's, dependencies, etc that runs on vanilla x86 & win32. Or alternative platforms with FOSS Lazaurus.