5 ms·

Arguably more interesting is UXN: https://100r.co/site/uxn.html https://100r.co/site/uxn.html A small personal computing stack, with a plethora of examples rea

Arguably more interesting is UXN: https://100r.co/site/uxn.html https://100r.co/site/uxn.html A small personal computing stack, with a plethora of examples ready to go. Built by two they/them hackers who live on a boat and basically have bootstrapped everything about their vessel, their computing, their engineering, etc. It's very, VERY old-school hacker-y. They would've made excellent phreaks back in the good ol' days.

throwaway290 4y ago
I was about to mention uxn. It's almost as if people with enough motivation to build and use this are also people who will never agree to use and contribute to one another's work. Not to say any of this work is a waste of course
- entaloneralie 4y ago
  Creator of Uxn here, Maxime is a dear friend of mine and we've jammed extensively on the design of UVM together.
- deckard1 4y ago
  welcome to the world of Forth/Lisp It is somewhat sadly ironic that to preserve software one has to actually create software that other people care about preserving. And, as we've seen with emulators, if you have software people care about then there are no roadblocks that will stand in the way of someone figuring out how to get your ancient code to run. I take the whole 100R thing as more an interesting art project than a serious goal. More of a "what if". With that said, I feel most devs are the same. How often do you come across a lead or senior dev that becomes passive aggressive over people modifying "their" code? Quite often, in my experience. Any code that I didn't write sucks and any code I have to touch that I didn't write is the worst code ever written. Code that I didn't write is old obsolete dog turds and code I wrote is "modern". Every dev slaps "modern" on their open source project today.
maxime_cb 4y ago
Author here. The creator of UXN is a friend of mine and we chat semi-regularly about our VMs. I have a lot of respect for uxn and credit it as an inspiration, but the goals of each project are different. UXN is a 16-bit system with 64KB of RAM accessible. It will also probably always remain interpreted. These design restrictions are seen as tools to foster creativity. UVM is a 32/64-bit VM. It's currently interpreted, but I've designed the instruction set with JIT compilation in mind. I have a PhD in compiler design and I'm fairly confident that I can make a fast JIT for UVM in a relatively short amount of time, when I feel the design is mature/stable enough. At the moment, UVM is relatively immature, but I want it to be a small/minimalistic VM that you can still build "real" or modern software in that takes good advantage of the capabilities and performance of your machine. Another difference is that IMO, UVM is more approachable. UXN's assembly language is fairly esoteric IMO. It doesn't look like any other assembly language I've ever seen. That doesn't make it bad, but it does potentially make it harder to learn and harder to leverage an existing base of programming skills. UVM's assembly is designed to not be surprising if you've ever programmed in assembly and know the basic ideas about how a stack machine works. I also have a WIP C compiler that's already usable to write simple programs. See my little snake game for a fun toy example: https://github.com/maximecb/uvm/blob/main/ncc/examples/snake.c https://github.com/maximecb/uvm/blob/main/ncc/examples/snake... Assembly syntax example: https://github.com/maximecb/uvm/blob/main/vm/examples/factorial.asm https://github.com/maximecb/uvm/blob/main/vm/examples/factor... I'll point to the fact that there is almost no boilerplate necessary to start drawing some pixels on a 2D canvas, which IMO makes it a fun platform to develop for. Like I said, it's immature, but I'll iron out all the bugs I can find and keep making it better.
- int_19h 4y ago
  It might be worth linking the instruction set in the sources (there doesn't seem to be a doc yet?) - it gives a fairly decent picture of what kind of VM we're talking about: https://github.com/maximecb/uvm/blob/main/vm/src/vm.rs https://github.com/maximecb/uvm/blob/main/vm/src/vm.rs One thing I didn't quite grok there. It seems that the operand stack is also used directly for locals and hence is indexable, with what looks like an implicit frame base register? But the stack is not addressable. Is the language runtime expected to manage a separate in-memory stack for addressable locals and dynamically allocated arrays, like wasm?

throwaway290 4y ago

I was about to mention uxn. It's almost as if people with enough motivation to build and use this are also people who will never agree to use and contribute to one another's work. Not to say any of this work is a waste of course

entaloneralie 4y ago
Creator of Uxn here, Maxime is a dear friend of mine and we've jammed extensively on the design of UVM together.
deckard1 4y ago
welcome to the world of Forth/Lisp It is somewhat sadly ironic that to preserve software one has to actually create software that other people care about preserving. And, as we've seen with emulators, if you have software people care about then there are no roadblocks that will stand in the way of someone figuring out how to get your ancient code to run. I take the whole 100R thing as more an interesting art project than a serious goal. More of a "what if". With that said, I feel most devs are the same. How often do you come across a lead or senior dev that becomes passive aggressive over people modifying "their" code? Quite often, in my experience. Any code that I didn't write sucks and any code I have to touch that I didn't write is the worst code ever written. Code that I didn't write is old obsolete dog turds and code I wrote is "modern". Every dev slaps "modern" on their open source project today.

maxime_cb 4y ago

Author here. The creator of UXN is a friend of mine and we chat semi-regularly about our VMs. I have a lot of respect for uxn and credit it as an inspiration, but the goals of each project are different. UXN is a 16-bit system with 64KB of RAM accessible. It will also probably always remain interpreted. These design restrictions are seen as tools to foster creativity. UVM is a 32/64-bit VM. It's currently interpreted, but I've designed the instruction set with JIT compilation in mind. I have a PhD in compiler design and I'm fairly confident that I can make a fast JIT for UVM in a relatively short amount of time, when I feel the design is mature/stable enough. At the moment, UVM is relatively immature, but I want it to be a small/minimalistic VM that you can still build "real" or modern software in that takes good advantage of the capabilities and performance of your machine. Another difference is that IMO, UVM is more approachable. UXN's assembly language is fairly esoteric IMO. It doesn't look like any other assembly language I've ever seen. That doesn't make it bad, but it does potentially make it harder to learn and harder to leverage an existing base of programming skills. UVM's assembly is designed to not be surprising if you've ever programmed in assembly and know the basic ideas about how a stack machine works. I also have a WIP C compiler that's already usable to write simple programs. See my little snake game for a fun toy example: https://github.com/maximecb/uvm/blob/main/ncc/examples/snake.c https://github.com/maximecb/uvm/blob/main/ncc/examples/snake... Assembly syntax example: https://github.com/maximecb/uvm/blob/main/vm/examples/factorial.asm https://github.com/maximecb/uvm/blob/main/vm/examples/factor... I'll point to the fact that there is almost no boilerplate necessary to start drawing some pixels on a 2D canvas, which IMO makes it a fun platform to develop for. Like I said, it's immature, but I'll iron out all the bugs I can find and keep making it better.

int_19h 4y ago
It might be worth linking the instruction set in the sources (there doesn't seem to be a doc yet?) - it gives a fairly decent picture of what kind of VM we're talking about: https://github.com/maximecb/uvm/blob/main/vm/src/vm.rs https://github.com/maximecb/uvm/blob/main/vm/src/vm.rs One thing I didn't quite grok there. It seems that the operand stack is also used directly for locals and hence is indexable, with what looks like an implicit frame base register? But the stack is not addressable. Is the language runtime expected to manage a separate in-memory stack for addressable locals and dynamically allocated arrays, like wasm?