5 ms·

This is a fascinating and elegant little virtual machine design that I think many here would find interesting.

by tonyg 3y ago

rollcat 3y ago
What blows me away is how practical it is. They've ported it to every piece of junk they had laying around, and wrote tons of software. It's not just a design on someone's web page, they're making tools, games, art.
- anthk 3y ago
  For gaming it's good, but sadly for software it lacks Unicode support. I wouldn't mind basic support with GNU unifont in further revisions. Altough the complexity would skyrocket. Then, if I wanted to write an adventure in Spanish I would omit the tildes, starting question/interrogation symbols and I would map ñ to ny.
  - TazeTSchnitzel 3y ago
    > for software it lacks Unicode support That's not an inherent limitation of the VM at least, just of the current software ecosystem. It would be possible and practical to make a tiny unifont-based Unicode text library. Though handling bidirectional text, joined scripts and vertical scripts would be something else… :(
    - rollcat 3y ago
      This illustrates just how complex even the "basic" stuff turns out to be in practice. Text rendering hates you[1]. Even if you take obvious shortcuts/compromises like limiting yourself to monospace, you'll get bitten by "double width" characters. Kudos to those who try, rather than bundling a copy of Chrome with their chat app. [1]: https://faultlore.com/blah/text-hates-you/ https://faultlore.com/blah/text-hates-you/
      - anthk 3y ago
        Yeah, that's why ASCII with a few of accenter chars and glyphs [áéíóüñ] would be enough with just a small extended western table. Optional as a library, OFC. By default you write ASCII chars from a table with a "display" device. I prefer uxn's simplicity over my own complex locales. Anyway, as I said, a tiny .tal code for extended chars wouldn't be very big. Some fonts for uxn (look at the ~rabbit repos at git.sr.ht) already bring extended chars.
        rollcat 3y ago
        > [...] ASCII with a few of accenter chars and glyphs [áéíóüñ] would be enough [...] Making a bespoke ASCII extension would be a step back - by about 30 years. You don't need a lot of code to support UTF8; if you're concerned about runtime memory usage, you can make your rune type take 8 bits and support only the U+0000-00FF range[1]. It happens to cover all of [áéíóüñ] and a whole bunch of other languages - unfortunately, not my native one, which would leave me gravely upset ;P [1]: https://www.unicode.org/charts/PDF/U0080.pdf https://www.unicode.org/charts/PDF/U0080.pdf
        zzo38computer 3y ago
        Then you could just implement ISO-8859-1 instead. It is the same range but a simpler encoding, and external programs could be used for conversion if necessary.
        rollcat 3y ago
        1. UTF8 encoding is trivial and everything already speaks it by default nowadays; 2. it is useful to explicitly differentiate byte arrays from text; 3. if you'd change your mind later on and decide you do want to support Japanese (like here: https://100r.co/site/niju.html https://100r.co/site/niju.html), you haven't dug yourself into a hole.
        anthk 3y ago
        The problem it's uxn it's ported to tons of devices. Would utf8 work under platforms like the Nintendo DS or DOS with a simple header file?
kouteiheika 3y ago
For a more mainstream take on the concept it's also worth to check out RISC-V. Implementing a baseline RISC-V interpreter VM without any extensions is a ~day of work (I've done it; it's a little more complex than their ISA, but not by much), and it can essentially run any piece of software you can throw at it as real compilers can target it. (You still need to supply the rest of the VM though to get I/O and such.)
- genpfault 3y ago
  https://github.com/cnlohr/mini-rv32ima https://github.com/cnlohr/mini-rv32ima

This is a fascinating and elegant little virtual machine design that I think many here would find interesting.

by tonyg 3y ago

This is a fascinating and elegant little virtual machine design that I think many here would find interesting.

What blows me away is how practical it is. They've ported it to every piece of junk they had laying around, and wrote tons of software. It's not just a design on someone's web page, they're making tools, games, art.

anthk 3y ago
For gaming it's good, but sadly for software it lacks Unicode support. I wouldn't mind basic support with GNU unifont in further revisions. Altough the complexity would skyrocket. Then, if I wanted to write an adventure in Spanish I would omit the tildes, starting question/interrogation symbols and I would map ñ to ny.
- TazeTSchnitzel 3y ago
  > for software it lacks Unicode support That's not an inherent limitation of the VM at least, just of the current software ecosystem. It would be possible and practical to make a tiny unifont-based Unicode text library. Though handling bidirectional text, joined scripts and vertical scripts would be something else… :(
  - rollcat 3y ago
    This illustrates just how complex even the "basic" stuff turns out to be in practice. Text rendering hates you[1]. Even if you take obvious shortcuts/compromises like limiting yourself to monospace, you'll get bitten by "double width" characters. Kudos to those who try, rather than bundling a copy of Chrome with their chat app. [1]: https://faultlore.com/blah/text-hates-you/ https://faultlore.com/blah/text-hates-you/
    - anthk 3y ago
      Yeah, that's why ASCII with a few of accenter chars and glyphs [áéíóüñ] would be enough with just a small extended western table. Optional as a library, OFC. By default you write ASCII chars from a table with a "display" device. I prefer uxn's simplicity over my own complex locales. Anyway, as I said, a tiny .tal code for extended chars wouldn't be very big. Some fonts for uxn (look at the ~rabbit repos at git.sr.ht) already bring extended chars.
      - rollcat 3y ago
        > [...] ASCII with a few of accenter chars and glyphs [áéíóüñ] would be enough [...] Making a bespoke ASCII extension would be a step back - by about 30 years. You don't need a lot of code to support UTF8; if you're concerned about runtime memory usage, you can make your rune type take 8 bits and support only the U+0000-00FF range[1]. It happens to cover all of [áéíóüñ] and a whole bunch of other languages - unfortunately, not my native one, which would leave me gravely upset ;P [1]: https://www.unicode.org/charts/PDF/U0080.pdf https://www.unicode.org/charts/PDF/U0080.pdf
        zzo38computer 3y ago
        Then you could just implement ISO-8859-1 instead. It is the same range but a simpler encoding, and external programs could be used for conversion if necessary.
        rollcat 3y ago
        1. UTF8 encoding is trivial and everything already speaks it by default nowadays; 2. it is useful to explicitly differentiate byte arrays from text; 3. if you'd change your mind later on and decide you do want to support Japanese (like here: https://100r.co/site/niju.html https://100r.co/site/niju.html), you haven't dug yourself into a hole.
        anthk 3y ago
        The problem it's uxn it's ported to tons of devices. Would utf8 work under platforms like the Nintendo DS or DOS with a simple header file?

kouteiheika 3y ago

For a more mainstream take on the concept it's also worth to check out RISC-V. Implementing a baseline RISC-V interpreter VM without any extensions is a ~day of work (I've done it; it's a little more complex than their ISA, but not by much), and it can essentially run any piece of software you can throw at it as real compilers can target it. (You still need to supply the rest of the VM though to get I/O and such.)

genpfault 3y ago
https://github.com/cnlohr/mini-rv32ima https://github.com/cnlohr/mini-rv32ima