4 ms·

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,

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?
n4ture 4y ago
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 source is hosted here for now: https://git.blazebone.com/pochi/ https://git.blazebone.com/pochi/ 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.
- maxime_cb 4y ago
  > 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. I'm happy to discuss anything in the GitHub discussions for UVM: https://github.com/maximecb/uvm/discussions https://github.com/maximecb/uvm/discussions > 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.
samsquire 4y ago
Could you explain what you did to build in mind for JIT? I feel WASM has the opportunity to create a truly audiovisual API for interacting with computers.
- maxime_cb 4y ago
  I go into some of the design decisions I made to make JIT optimizations easier here: https://github.com/maximecb/uvm/blob/main/doc/design.md https://github.com/maximecb/uvm/blob/main/doc/design.md
  - samsquire 4y ago
    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 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.
    - maxime_cb 4y ago
      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.

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?

n4ture 4y ago

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 source is hosted here for now: https://git.blazebone.com/pochi/ https://git.blazebone.com/pochi/ 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.

maxime_cb 4y ago
> 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. I'm happy to discuss anything in the GitHub discussions for UVM: https://github.com/maximecb/uvm/discussions https://github.com/maximecb/uvm/discussions > 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.

samsquire 4y ago

Could you explain what you did to build in mind for JIT? I feel WASM has the opportunity to create a truly audiovisual API for interacting with computers.

maxime_cb 4y ago
I go into some of the design decisions I made to make JIT optimizations easier here: https://github.com/maximecb/uvm/blob/main/doc/design.md https://github.com/maximecb/uvm/blob/main/doc/design.md
- samsquire 4y ago
  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 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.
  - maxime_cb 4y ago
    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.