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.
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...
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.
Awesome project! I've been on the lookout for such projects ever since discovering uxn, I'll definitely have a look and keep an eye on uvm.
>The creator of UXN is a friend of mine and we chat semi-regularly about our VMs.
Does the discussion happen in a public place? If yes I'd be extremely happy to join in since I also got started with making my own system around a month ago, and it feels a bit lonely going on such an endeavor at times.
It's extremely early and I haven't really shared it anywhere yet, but I feel there is already the possibilty to play around with the custom editor I made, try to make little graphical programs etc.. If you manage to build it that is (I develop mostly on OpenBSD and also try to make it build under Ubuntu with gcc sometimes).
The README (in the about tab) should give a rough explanation of what it is, I also have a bit of documentation already.
>Another difference is that IMO, UVM is more approachable.
Very interesting choice, I did away with such assumptions and ran the other way, my system might feel quite alien/esoteric since I went for something that draws a lot of inspiration from Chuck Moore's work with ColorForth as well as his F18 chip.
> Does the discussion happen in a public place? If yes I'd be extremely happy to join in since I also got started with making my own system around a month ago, and it feels a bit lonely going on such an endeavor at times.
> Very interesting choice, I did away with such assumptions and ran the other way, my system might feel quite alien/esoteric since I went for something that draws a lot of inspiration from Chuck Moore's work with ColorForth as well as his F18 chip.
If you're building a system for fun, or to explore new ideas, then it seems fine to make it as esoteric as you want. However, in my experience, making esoteric choices when designing programming languages for instance, can really alienate potential users. Especially if you could have obviously gone with some more traditional and familiar choices but you went with something more esoteric that doesn't have any clear value added.
IMO it's a bit like when it comes to terminology. If there's a commonly accepted way to refer to something, use it. Don't make up your own nomenclature, you'll just create extra confusion for no reason.
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:
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?
You mention parallel computation and being open for discussion.
My favourite area of computing is parallel computing and multithreading.
My toy multithreaded interpreter in Java can communicate integers between threads with message passing. I never got around to communicating complicated objects because I'm not sure how to solve the garbage collection problem with compound data structures/object graphs AND sending objects between threads. I'm currently relying on Java garbage collection at this time but I have played with a garbage collector written by Matthew Plant (http://maplant.com/gc.html), so if I were to implement my language in C I could also be inspired by Pony's reference capabilities.
Since my interpreter is a simple imaginary assembly interpreter I have instructions for "sendcode" "receivecode" which tell a thread to do a remote jump. There is also a "send" and "receive" instruction for sending data between threads in a thread safe manner. This uses actor style mailboxes behind the scenes.
I was thinking something like actors, or independent processes sending messages would be nice. Just because it's very safe and predictable. Less error-prone than threads.
The thing that kind of gets me is it seems difficult to have safe shared memory with actors? You ideally want to be able to share memory if you want things to be efficient, but if you have shared memory, then you get into issues with atomic writes and things being observed in different orders, etc.
I assume you would be communicating pointers with actor mailboxes, so the only copy is a pointer. I believe Erlang copies data itself into other actor's heaps, that simplifies garbage collection since GC can be done per process and there is only one owning reference to a processes' data.
You might find Pony's ORCA interesting which is how they implement garbage collection between actors.
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
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.
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.