4 ms·

Hi all, My name is Devine, and I'm to blame for the uxn disaster.. I'm getting this link thrown at me from all sides right now, so I figured I might as well ch

Hi all, My name is Devine, and I'm to blame for the uxn disaster.. I'm getting this link thrown at me from all sides right now, so I figured I might as well chip in. I'm a bit more on the design-y side of things, and all these fancy words to talk about computers and retro computing, are a bit beyond me, and reference an era of computing which I didn't really had a chance to experience first hand. But let's talk about "the uxn machine has quite the opposite effect, due to inefficient implementations and a poorly designed virtual machine, which does not lend itself to writing an efficient implementation easily." This is meaningful to me and I'd love to have your opinion on this. Before setting on the journey to build uxn, I looked around at the options that were out there, that would solve our specific problems, and I'd like to know what you would recommend. Obviously, I take it that the author is not advocating that we simply return to Electron, and I take it they understand that re-compiling C applications after each change is not viable with our setup, that Rust is manyfolds too slow for us to make any use of it, and that they understand that our using Plan 9, C is not a good candidate for writing cross-compatible(libdraw) applications anyway. So, what should we have done differently? I'm genuinely looking for suggestions, even if one suggestion might not be compatible with our specific position, many folks come to us asking for existing solutions in that space, and I would like to furnish our answers with things I might have not tried. Here are some directions we tried prior to Uxn: https://wiki.xxiivv.com/site/devlog.html https://wiki.xxiivv.com/site/devlog.html Ah, one last thing, this is how you fib the first 65k shorts in uxntal: https://git.sr.ht/~rabbits/uxn/blob/main/projects/examples/exercises/fib.tal https://git.sr.ht/~rabbits/uxn/blob/main/projects/examples/e...

mwcampbell 4y ago
I think a VM for a small, but highly abstract, language like Scheme might address the objections of the author(s) of this article. You might like Chibi-Scheme: https://github.com/ashinn/chibi-scheme https://github.com/ashinn/chibi-scheme Having said that, IMO, if you're having fun with uxn and its retro 8-bit aesthetic, by all means keep going with that.
- entaloneralie 4y ago
  I did use Chibi! I've implemented a few lisps, but I always found their bytecode implementation too convoluted and slow, so I went with a stack machine for this particular project. I might at some point, implement a proper scheme in uxntal. It's neat, but I don't remember seeing a graphical API for it, I'll have a look :)
  - mwcampbell 4y ago
    I'm not aware of one. I was thinking that you could roll your own, just as your Varvara computer defines a graphics device on top of uxn. You'd still gain the benefits of using an existing language.
csande17 4y ago
I am not very familiar with Uxn, but the one thing from the article that struck me as an actual problem was that the memory containing the program's code can be modified at runtime. The downsides of that can heavily outweigh the benefits in many cases; it turns "write a uxn -> native code compiler" from a weekend project to a nearly impossible task, for example. This is probably relatively easy to fix, assuming uxn programs do not regularly use self-modifying code. (The article proposes an elaborate scheme involving alias analysis and bounds checks, but something like "store executable code and writable data in two separate 64KB regions" would work just as well.) The article suggests that Uxn programs can write to arbitrary locations on the filesystem. If that is the case, it seems like it would be really easy to change that in the interpreter. Then Uxn's security model would be essentially identical to how the article describes WebAssembly: the interpreter serves as a "sandbox" that prevents programs from touching anything outside their own virtual memory. This is a good security model and it likely makes a lot of sense for Uxn. Otherwise, the article seems to be more bluster than substance. Uxn is probably not going to be the fastest way to compute the Fibonacci sequence, nor the most secure way to protect a telecommunications network from foreign cyber-attacks, but it doesn't need to be either of those things to be useful and valuable as a way to write the kind of UI-focused personal computer software you want to write.
- tumult 4y ago
  The second (or first, maybe) most popular Uxn emulator, Uxn32, has sandboxed filesystem access, and has had it since the beginning. The author of the original article doesn't know what they're talking about.
- entaloneralie 4y ago
  I use Uxn's self-modification powers quite a bit, I use them mostly for routines that runs thousands of times per frames, so I don't have to pull literals from the stack, I just can just write myself a literal in the future and have it available. I wonder, what about this makes a native code compiler difficult, is it because most programs protect against this sort of behaviors? or that programs are stored in read-only memory? Some of the emulator sandbox the file device, it is likely to be the way that all the emulators will work eventually.
mwcampbell 4y ago
> re-compiling C applications after each change is not viable with our setup What setup is that? Or, where can I read more about it? I realize this is kind of irrelevant, since the original article criticizes C and similar languages. But I'm curious.
- entaloneralie 4y ago
  Looks like this: https://wiki.xxiivv.com/site/usagi.html https://wiki.xxiivv.com/site/usagi.html
  - bob29 4y ago
    Why can't you compile C on a raspberry pi 3?? Thats a supercomputer compared to anything that existed throughout the 80s 90s. Especially since your progs seem to be pretty small with kind of vintage retro graphics id imagine they compile basically instantly? I never programmed a videogame but isn't the common pattern to make a game engine plus embedded scripting language intreprter so you dont have to recompile for all the little tweaks? I mean dont get me wrong no reason not to do what you did but i'm not seeing the unique challenges solved, like in what direction r u trying to move the needle here?
    - entaloneralie 4y ago
      It's quite common that people think they know what working on a Pi is like, because on paper, it has all the specs of a very fast machine, but to actually use the thing as a daily driver, is another story altogether. So, of course you can, I've written every application that now exist on Uxn, in C prior to porting them. There was a moment when I was quite convinced that C was a good candidate for what we wanted to do. For example, equivalent programs: C version: https://git.sr.ht/~rabbits/orca-toy/tree/main/item/etc/orca.c https://git.sr.ht/~rabbits/orca-toy/tree/main/item/etc/orca.... Uxn version: https://git.sr.ht/~rabbits/orca-toy/tree/main/item/src/orca.tal https://git.sr.ht/~rabbits/orca-toy/tree/main/item/src/orca.... Compiling Orca C(SDL on Pi), is about 10x~ slower, more battery hungry, (and also for some reason, very upsetting to ASAN), than building C(libdraw on Pi), which is itself about 50x slower and battery hungry than building the Uxn version. I can compile little C cli tools on the Pi just fine, that's not the issue, building x11 or SDL applications with debug flags is another story. I much rather be assembling uxn roms in this case. I wrote a few cc65 compiled applications prior to building uxn as an alternative, but that was a non-starter on ARM.
carapace 4y ago
Check out Project Oberon: https://people.inf.ethz.ch/wirth/ProjectOberon/index.html https://people.inf.ethz.ch/wirth/ProjectOberon/index.html and "System design from provably correct constructs": https://archive.org/details/systemdesignfrom00mart https://archive.org/details/systemdesignfrom00mart And "don't let the turkeys get you down". :)
- entaloneralie 4y ago
  Oberon is great! I remember reading the book, it gave me all sorts of ideas for Uxn. I love writing Pascal, Modula+Overon's drawing API is excellent. It's much too massive a system for me, and I can't even begin to imagine how I'd bring that over the GBA/Amiga/etc.. but I recommend people go through the book from time to time. https://wiki.xxiivv.com/site/pascal.html https://wiki.xxiivv.com/site/pascal.html
  - carapace 4y ago
    Yeah, the Oberon OS might be a bit much for your applications, eh? The chip is interesting as a target for a low-tech 32-bit platform. I've heard that the folks at Noisebridge (here in San Francisco) are playing around with making their own silicon ICs. The "Provably Correct" book presents the work of Dr. Margaret Hamilton (she of Apollo 11, who coined the term "software engineer"). It shows a simple elegant way to make easy-to-use safe programming systems. I just gotta say, I envy you guys. :)
bigbillheck 4y ago
https://wiki.xxiivv.com/site/devlog.html https://wiki.xxiivv.com/site/devlog.html > For a time, I thought I ought to be building software for the NES to ensure their survival over the influx of disposable modern platforms — So, I did. . Sadly, most of the software that I care to write and use require slightly more than an 8-button controller. Seems to me you could have saved a lot of effort by changing gears slightly to target other ubiquitous 6502 machines such as the apple 2 or c64.
- entaloneralie 4y ago
  I thought so too :) I did a few C64 test applications both in plain 6502 and via cc65(which works very poorly on ARM btw), but that didn't really work out for us. I ran into issues porting VICE to Plan 9, and I had all sorts of issues with c64 sound emulation.

mwcampbell 4y ago

I think a VM for a small, but highly abstract, language like Scheme might address the objections of the author(s) of this article. You might like Chibi-Scheme: https://github.com/ashinn/chibi-scheme https://github.com/ashinn/chibi-scheme Having said that, IMO, if you're having fun with uxn and its retro 8-bit aesthetic, by all means keep going with that.

entaloneralie 4y ago
I did use Chibi! I've implemented a few lisps, but I always found their bytecode implementation too convoluted and slow, so I went with a stack machine for this particular project. I might at some point, implement a proper scheme in uxntal. It's neat, but I don't remember seeing a graphical API for it, I'll have a look :)
- mwcampbell 4y ago
  I'm not aware of one. I was thinking that you could roll your own, just as your Varvara computer defines a graphics device on top of uxn. You'd still gain the benefits of using an existing language.

csande17 4y ago

I am not very familiar with Uxn, but the one thing from the article that struck me as an actual problem was that the memory containing the program's code can be modified at runtime. The downsides of that can heavily outweigh the benefits in many cases; it turns "write a uxn -> native code compiler" from a weekend project to a nearly impossible task, for example. This is probably relatively easy to fix, assuming uxn programs do not regularly use self-modifying code. (The article proposes an elaborate scheme involving alias analysis and bounds checks, but something like "store executable code and writable data in two separate 64KB regions" would work just as well.) The article suggests that Uxn programs can write to arbitrary locations on the filesystem. If that is the case, it seems like it would be really easy to change that in the interpreter. Then Uxn's security model would be essentially identical to how the article describes WebAssembly: the interpreter serves as a "sandbox" that prevents programs from touching anything outside their own virtual memory. This is a good security model and it likely makes a lot of sense for Uxn. Otherwise, the article seems to be more bluster than substance. Uxn is probably not going to be the fastest way to compute the Fibonacci sequence, nor the most secure way to protect a telecommunications network from foreign cyber-attacks, but it doesn't need to be either of those things to be useful and valuable as a way to write the kind of UI-focused personal computer software you want to write.

tumult 4y ago
The second (or first, maybe) most popular Uxn emulator, Uxn32, has sandboxed filesystem access, and has had it since the beginning. The author of the original article doesn't know what they're talking about.
entaloneralie 4y ago
I use Uxn's self-modification powers quite a bit, I use them mostly for routines that runs thousands of times per frames, so I don't have to pull literals from the stack, I just can just write myself a literal in the future and have it available. I wonder, what about this makes a native code compiler difficult, is it because most programs protect against this sort of behaviors? or that programs are stored in read-only memory? Some of the emulator sandbox the file device, it is likely to be the way that all the emulators will work eventually.

mwcampbell 4y ago

> re-compiling C applications after each change is not viable with our setup What setup is that? Or, where can I read more about it? I realize this is kind of irrelevant, since the original article criticizes C and similar languages. But I'm curious.

entaloneralie 4y ago
Looks like this: https://wiki.xxiivv.com/site/usagi.html https://wiki.xxiivv.com/site/usagi.html
- bob29 4y ago
  Why can't you compile C on a raspberry pi 3?? Thats a supercomputer compared to anything that existed throughout the 80s 90s. Especially since your progs seem to be pretty small with kind of vintage retro graphics id imagine they compile basically instantly? I never programmed a videogame but isn't the common pattern to make a game engine plus embedded scripting language intreprter so you dont have to recompile for all the little tweaks? I mean dont get me wrong no reason not to do what you did but i'm not seeing the unique challenges solved, like in what direction r u trying to move the needle here?
  - entaloneralie 4y ago
    It's quite common that people think they know what working on a Pi is like, because on paper, it has all the specs of a very fast machine, but to actually use the thing as a daily driver, is another story altogether. So, of course you can, I've written every application that now exist on Uxn, in C prior to porting them. There was a moment when I was quite convinced that C was a good candidate for what we wanted to do. For example, equivalent programs: C version: https://git.sr.ht/~rabbits/orca-toy/tree/main/item/etc/orca.c https://git.sr.ht/~rabbits/orca-toy/tree/main/item/etc/orca.... Uxn version: https://git.sr.ht/~rabbits/orca-toy/tree/main/item/src/orca.tal https://git.sr.ht/~rabbits/orca-toy/tree/main/item/src/orca.... Compiling Orca C(SDL on Pi), is about 10x~ slower, more battery hungry, (and also for some reason, very upsetting to ASAN), than building C(libdraw on Pi), which is itself about 50x slower and battery hungry than building the Uxn version. I can compile little C cli tools on the Pi just fine, that's not the issue, building x11 or SDL applications with debug flags is another story. I much rather be assembling uxn roms in this case. I wrote a few cc65 compiled applications prior to building uxn as an alternative, but that was a non-starter on ARM.

carapace 4y ago

Check out Project Oberon: https://people.inf.ethz.ch/wirth/ProjectOberon/index.html https://people.inf.ethz.ch/wirth/ProjectOberon/index.html and "System design from provably correct constructs": https://archive.org/details/systemdesignfrom00mart https://archive.org/details/systemdesignfrom00mart And "don't let the turkeys get you down". :)

entaloneralie 4y ago
Oberon is great! I remember reading the book, it gave me all sorts of ideas for Uxn. I love writing Pascal, Modula+Overon's drawing API is excellent. It's much too massive a system for me, and I can't even begin to imagine how I'd bring that over the GBA/Amiga/etc.. but I recommend people go through the book from time to time. https://wiki.xxiivv.com/site/pascal.html https://wiki.xxiivv.com/site/pascal.html
- carapace 4y ago
  Yeah, the Oberon OS might be a bit much for your applications, eh? The chip is interesting as a target for a low-tech 32-bit platform. I've heard that the folks at Noisebridge (here in San Francisco) are playing around with making their own silicon ICs. The "Provably Correct" book presents the work of Dr. Margaret Hamilton (she of Apollo 11, who coined the term "software engineer"). It shows a simple elegant way to make easy-to-use safe programming systems. I just gotta say, I envy you guys. :)

bigbillheck 4y ago

https://wiki.xxiivv.com/site/devlog.html https://wiki.xxiivv.com/site/devlog.html > For a time, I thought I ought to be building software for the NES to ensure their survival over the influx of disposable modern platforms — So, I did. . Sadly, most of the software that I care to write and use require slightly more than an 8-button controller. Seems to me you could have saved a lot of effort by changing gears slightly to target other ubiquitous 6502 machines such as the apple 2 or c64.

entaloneralie 4y ago
I thought so too :) I did a few C64 test applications both in plain 6502 and via cc65(which works very poorly on ARM btw), but that didn't really work out for us. I ran into issues porting VICE to Plan 9, and I had all sorts of issues with c64 sound emulation.