Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a Minimalistic Virtual Machine

pointersgonewild.com

Post reply on HN
Print view View original

11–20 of 72 posts

Re: Building a Minimalistic Virtual Machine

#11

Post by throwaway78941 »

samsquire wrote: post #8

This is awesome. Thank you for sharing. My ancient ruby code and nodejs code all broke because I didn't pin dependencies. As a result I've got software that is unrunnable. More software shall be unrunnable as time goes on, I don't know many trends that prevent software from being unbuildable and unrunnable due to change except maybe repeatable builds and hermetic builds. Given platform toolchains complexity and libc…

> My ancient ruby code and nodejs code all broke because I didn't pin dependencies. As a result I've got software that is unrunnable.

You can simply remove the ^ symbol from your versions listed in package.json and it will use exactly that version you originally added.

Re: Building a Minimalistic Virtual Machine

#12

Post by kaba0 »

Hi! I can’t help but see a big similarity to the JVM, both in terms of design goals and the semantics of the byte codes - only “not having dynamic linking” being an exception.

Could you expand on what you don’t find sufficient in JVM byte code, when it is arguably one of the best platform for backwards compatibility, has easy support for bringing up a canvas and start painting, etc.

Re: Building a Minimalistic Virtual Machine

#13

Post by entaloneralie »

throwaway290 wrote: post #3
l_theanine wrote: post #2

Arguably more interesting is UXN: 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.

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

Creator of Uxn here, Maxime is a dear friend of mine and we've jammed extensively on the design of UVM together.

Re: Building a Minimalistic Virtual Machine

#14

Post by deckard1 »

throwaway290 wrote: post #3
l_theanine wrote: post #2

Arguably more interesting is UXN: 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.

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

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.

Re: Building a Minimalistic Virtual Machine

#15

Post by maxime_cb »

kaba0 wrote: post #12

Hi! I can’t help but see a big similarity to the JVM, both in terms of design goals and the semantics of the byte codes - only “not having dynamic linking” being an exception. Could you expand on what you don’t find sufficient in JVM byte code, when it is arguably one of the best platform for backwards compatibility, has easy support for bringing up a canvas and start painting, etc.

For one the JVM is a huge piece of software. Large enough that only a large corporation could realistically reimplemented or maintain it. It also exposes many APIs with a large surface area. Then there's the issue of Oracle and how you feel about them as a company.

UVM has obviously nowhere near the ecosystem, but you can draw pixels to a frame buffer with two function calls, and your UI will be guaranteed to look the same everywhere.

Re: Building a Minimalistic Virtual Machine

#16

Post by maxime_cb »

throwaway78941 wrote: post #11
samsquire wrote: post #8

This is awesome. Thank you for sharing. My ancient ruby code and nodejs code all broke because I didn't pin dependencies. As a result I've got software that is unrunnable. More software shall be unrunnable as time goes on, I don't know many trends that prevent software from being unbuildable and unrunnable due to change except maybe repeatable builds and hermetic builds. Given platform toolchains complexity and libc…

> My ancient ruby code and nodejs code all broke because I didn't pin dependencies. As a result I've got software that is unrunnable. You can simply remove the ^ symbol from your versions listed in package.json and it will use exactly that version you originally added.

Besides the issue of whether you pin or don't pin your dependencies, the problem is that node packages can depend on external native code. You can have several more layers of dependencies in there. If, for any reason, those native packages won't install/run on your machine, your dependencies can still break under you, even if you pin them. Python and Ruby have the same vulnerability when it comes to dependencies breaking.

Re: Building a Minimalistic Virtual Machine

#17

Post by maxime_cb »

samsquire wrote: post #10
maxime_cb wrote: post #4

Earlier quoted context omitted.

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…

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.

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

Re: Building a Minimalistic Virtual Machine

#18

Post by maxime_cb »

n4ture wrote: post #9
maxime_cb wrote: post #4

Earlier quoted context omitted.

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…

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…

> 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

> 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.

Re: Building a Minimalistic Virtual Machine

#19

Post by maxime_cb »

rhn_mk1 wrote: post #7
maxime_cb wrote: post #6

Earlier quoted context omitted.

LLVM is more heavyweight. Has a lot of analysis and optimization passes for static compilation. UVM is currently very lightweight, will be JIT compiled. Crucially UVM will provide graphics, audio and networking primitives.

That's what LLVM is today, but IIRC their goals were the same. It might be worth it to look at what made it turn away from the minimal idea and into the heavyweight that it is now.

If I had to guess, I would say it probably comes down to wanting to go with static, ahead of time compilation rather than JIT. There are real and valid advantages to AOT compilation. There's downsides with the LLVM approach too. For example, LLVM makes it explicit that they provide zero guarantees when it comes to the stability of their bitcode format. That somewhat limits what you can do with it.
Post reply on HN