I had to browse around a bit to answer "why?" I landed here: https://100r.co/site/mission.html
It's a cool idea. I found the contrast with electron helpful:
> While solving some of our issues, Electron was rapidly increasing in size and hunger, so despite it being open-source soon joined the rest of the software that we did away with. Our focus shifted toward reducing our energy use, and to ensure reliability we began removing dependencies.
"Code must conform to C89 with -nostdlib, and can only link to libuxn (that we wrote). And use uxn_main() instead of main(), as libuxn defines main. No binary dependencies allowed, all source files must be in project directory, and only uxn build system can be used"
The the authors would only need to write libuxn for each platform they support, which is certainly easier and faster than writing a whole emulator.
But I am guessing this solution did not satisfy other criteria, perhaps things like "playful" and "build from first principles". It's a pity though - distributing apps in source code form instead of emulator binary would make them much more modifiable by end users.
Since they were on a boat with a Raspberry Pi and not much battery power or internet, in addition to execution speed and portability, they were probably also concerned with:
- speed of compilation and linking (on small machines like Raspberry Pi)
- binary size of anything that might have to be updated or shared over the internet
- having to troubleshooting emergent issues without the ability to lookup documentation or download updates or tools from the internet
In this situation, a simpler language on a simpler VM is probably going to be faster to develop with than compiling/linking a subset of C, and after the initial implementation of the VM, might present less opportunity for an unintended interaction of leaky abstractions in your libuxn and your toolchain to ruin your day on a day when you don't have internet connectivity to check Stackoverflow or to update some buggy dependency.
I have a raspberry pi 2 (one of the first one, very low) and tried compiling orca.c on it with gcc. It took 7 seconds and produced 38KB executable. This is more than what I expected, but it's still pretty reasonable. However, I can see how this can be annoying with very rapid iteration cycles.
(Btw, building alone (no linking) takes 5.4 sec, so compilation time dominates. And optimized build (-O3) was over a minute. Not something to be done as part of development.)
But then I remembered about lighter compilers, and tried 'tcc'. This was substantially faster - just 0.6 seconds for the whole process! I think this is very reasonable, and for newer Pi's it would be even faster.
Also note that my idea was to forgo standard libraries and only link to libuxn (and only include uxn.h). This theoretical libuxn will have the same role as UXN virtual machine - written only once, and then frozen in stone, with no updates. This will take care of large binary sizes - if you are only linking to libuxn there are no updates to download. And there is no need to lookup documentation or consult stack overflow, as you are only allowed to link to libuxn, no third-party libraries.
Will such limited environment be inconvenient? Somewhat, but less that full-blown VM. Will it take effort to write and maintain libuxn on all platforms? Yes, but less effort than full-blown VM. Won't libuxn have some bugs requiring updates? Likely, but I bet it will have fewer bugs than full-blown VM.
As for other things (updating binary over internet, shareing
Rather, these are computing platforms to maximize usefulness in the event of a societal collapse.
That is why there is a handbook of uxn opscode made to include hand gestures (https://wiki.xxiivv.com/site/uxntal_opcodes.html), so that computing and transmission of computing can continue even with the loss of the computing hardware or documentation.
Imagine how cool it would be if old games were distributed in source code form, so that anyone can modify and "remix" it as much as they want with a simple text editor?
This was impossible back in 1990s, but today we can get a C compiler (tcc) which takes less than 1 megabyte of space and compiles+links a game in less than a second. As long as you don't depend on too many third-party libraries, you can ship C code, compile the game on each start and user won't even notice!
Lets think of it , how many time you restart your app when you start using the app?
Tal is the programming language for the Uxn virtual machine (2021) - https://news.ycombinator.com/item?id=39575102 - March 2024 (18 comments)
Virtualizing Uxn - https://news.ycombinator.com/item?id=37091091 - Aug 2023 (4 comments)
The Uxn Ecosystem - https://news.ycombinator.com/item?id=36734445 - July 2023 (54 comments)
The Uxn Ecosystem - https://news.ycombinator.com/item?id=36642390 - July 2023 (2 comments)
Uxn is a virtual machine with 32 instructions - https://news.ycombinator.com/item?id=33926600 - Dec 2022 (84 comments)
Uxn: Small permacomputing VM designed for easy implementability - https://news.ycombinator.com/item?id=32158816 - July 2022 (2 comments)
MicroFLENG – concurrent logic programming for CP/M, C64 and the “uxn” VM - https://news.ycombinator.com/item?id=31506240 - May 2022 (4 comments)
Uxn – Virtual AV Computer - https://news.ycombinator.com/item?id=27561463 - June 2021 (5 comments)
uxn: a portable 8-bit virtual computer - https://news.ycombinator.com/item?id=27185950 - May 2021 (47 comments)
Uxn is a 8-bit virtual stack machine - https://news.ycombinator.com/item?id=26258991 - Feb 2021 (5 comments)
On the other hand, on my laptop, the Left text editor running in Uxn (with SDL!) still uses less energy than Emacs does, despite the interpretation overhead. And you can run it on a GameBoy Advance, so it's definitely a step in the right direction if you're looking for a frugal write-once/run-anywhere platform. It's the first attempt at the problem that's good enough to criticize, and it's something you can download applications for today.
It's easy to see ways to improve it, but to my knowledge the critiquing savage in question has not written a better system yet, although their critique is indeed informative.
That said, I think he's exactly right. This ESP32 runs linux, and can run vi: https://www.mouser.com/ProductDetail/Espressif-Systems/ESP32.... Its datasheet says the power supply is 3V at 0.5amps.
It can probably run emacs, too. At least, I have, in my life run emacs on a computer less powerful than that ESP32. And, we should acknowledge emacs is not a hard target to beat :)
The main point, that tens to hundreds of thousands of man years going into optimizing compilers, combined with maybe millions of man years of silicon design and production beats a hobbyist for efficiency, I'd say he demonstrates right in the essay by handwriting assembly for uxn and comparing it with sane-to-simple C code and showing it's 100s of times faster in C than uxn.
I also take a little of his snide asides for those who know to heart; as he alludes, calling it a forth-like without the ability to compile immediate words is giving up a lot; forth is like bare metal programmability of the compiler.
Anyway, I do a lot of coding in go and (sadly) javascript, and not much in Forth, even though I like to hold the idea of the simple days of yore in my mind; we've each got our own thing. But I think he's probably right that this will always be a boutique thing which is mostly for aesthetics.
Your link is broken, but https://hackaday.com/2021/07/21/its-linux-but-on-an-esp32/ documents someone getting Linux running on an ESP32-S3 under a software emulation of RISC-V with an MMU. That's not obviously more efficient than a simple Uxn emulator and seems likely to be worse. People have also gotten ucLinux running directly on ESP32-S3 with uclibc, which seems unlikely to be able to run Emacs or GCC, though not, as you say, because the CPU is too slow or the RAM is too small. I'm not sure I've run Emacs on a machine with less than 16MiB of RAM but I'm sure it's possible.
1500 milliwatts is still several orders of magnitude more power than I think a personal computer needs, and 16MiB is obviously a couple of orders of magnitude more RAM.
Emacs is actually surprisingly efficient. We remember it as being slow and bulky in part because 30 years ago it was among the bigger resource draws on the machines we used at the time and in part because it actually was slower then. Current Emacs compiles elisp to machine code.
It turns out that it's actually pretty common for a hobbyist to be able to beat tens to hundreds of thousands of man years going into optimizing compilers, as you know if you follow the demoscene at all. Proebsting's Law explains why. The silicon design and production are equally at the disposal of GCC and the hobbyist. But the current applications codebase can easily consume all that surplus computational power.
I agree that if you were to rewrite your applications in sane-to-simple C code, compiled with a good compiler, it would come out faster than Uxn, though only by about 10×. But nobody has done it. Vaporware always beats shipped code because vaporware doesn't have bugs or scope/schedule tradeoffs.
I think it's possible to do much better than Uxn. But I also am not convinced that anybody has.
So, your idea is a computer with less than 200 kiB of RAM? So, devices like a PC AT 286 or Amiga A2000, with their whole 1 MiB RAM, are hopelessly overpowered, and the right kind of a machine is something like a Sinclair Spectrum?
Running e.g. Emacs the same way is likely unrealistic, and I find Emacs a great example of software that the user can actually inspect and personalize. I would like most user-facing software tools be like that. (In an ideal world I'd love my personal machine to have a terabyte of Optane memory, but currently such hardware is but a fantasy.)
[1]: https://community.silabs.com/s/share/a5UVm000000Vi1ZMAS/quak...
This would work better if your example text editor wasn't an operating system. Does it use less energy than vi?
I'm no expert in Emacs stuff, but AIUI the main selling point is Emacs Lisp's decades of packages, which is both amazingly valuable and also a huge blocker on optimisation, because nobody is willing to break compatibility with all the old packages in the name of performance.
You should at least compare it to "nano" editor, or even better, it's predecessor "pico".
[0] https://github.com/emacs-mirror/emacs/blob/master/etc/JOKES#...
I’ve followed them for a couple of years. From what I can tell they have a ton focus and are serious about craftsmanship.
Nothing else to add—just admire people good at making things!
I deeply respect that kind of work too, there's a place for it, but certainly it is closer to art than engineering.
Uxn is also cool, I especially liked the Orca ROM, but I couldn’t really figure it out how to make it work with MIDI, so I ended up using the Linux version.
Pity that most Plan 9 afficionados usually always forget about Inferno, with Limbo being the re-consideration that dropping Alef from Plan 9, or designing it without automatic memory management in first place was a mistake.
That's interesting, I never looked on Android at that angle. Still, Android is based on Linux (Unix), it allows JIT and NDK. Whereas Inferno does not allow escape from VM conceptually, and the whole OS, except low-level stuff, is written in Limbo and works totally in VM.
I once tried Inferno somewhere in 1998 on my PC, played with it a litte and removed. But three years later I met it in Lucent/Definity Avaya PSTN switches the company I worked for bought. Not to say I was surprised. :-)
I appreciate the care 100r has put into working with their doors open and sharing their lives, circumstances and worldview.
I'm not using Uxn but am I following a bit of a quest to try my hand at personal shaped computing. I didn't really want to write an emulator (I don't have a game-preservation shaped problem) and I like to be able to just "takeover" computers around me with bootable USB sticks. Fittingly, my project is in x86 assembly, real-mode with BIOS routines for IO and as a stand-in for drivers. (Tldr; not amazing but serviceable, and Devine is right that 64kb is a lot)
As a long time python programmer, I've found it fun to play in the land of understanding memory layouts, segmentation, and writing assembler. I highly recommend it for educational purposes. I don't need a hobby project that looks like work in my off time so real-mode programming fits nicely. As a plus I rediscovered MSDOS .COM files and it's shockingly fast and will give you 64kb of memory setup and a filesystem which is handy. Again here I don't have to write an emulator and my little Forth-like project could bootstrap from DOS assemblers and tool chains.
My take away from Uxn project is "go ahead and try to do something fun with a computer". Uxn very much isn't about making the most efficient p-machine or best language, but something that fits 100r. And that more of us with the background in computers ought to try something off the beaten path because we might learn something and we might have fun doing it.
100 years from now we'll still be able to run NES games, but running old windows programs may be nearly impossible. uxn is trying to be like the NES in that regard, but for more general use cases than just games. Write a uxn program once, and it can run anywhere, any time (on any device that can host uxn).
Probably not Uxn itself, though, because a 16-bit memory space is not a practical way to emulate Win32. Dmitry wouldn't be dissuaded, I suppose.
But another perspective for win32 support in future metal is the bigger "community" (users, software, etc) so the increase in support complexity is compensated for much (much) larger incentives for supporting much more diverse and desired old software. WINE and related SW is a testament to this
Things like LLMs and the xz backdoor, for example, may make it unappealing to accept code from people you don't know personally; things like Apple's notarization requirements may make it impractical to run open-source software except as part of a proprietary package; software patents or legal liability for third parties using your software could make it legally unappealing to free your code; etc.
in the uxn case the different hardware types include small raspberry pis, Nintendo DS, etc. So having the baseline be really simple means knowing the code you've written for uxn will run on all these different hardware types.
You can also build a CPU that runs uxn code directly on hardware (I assume).
if you are a user then the only reason you'd run uxn on modern powerful hardware is if there is an app written for it that you wanted to use. Just like java, or python, or rust.
For a developer, grabbing uxn might be an aesthetic or political choice, like the language, or you want to target low power hardware use cases.
The 'VM' in "JVM" is "virtual machine".
Given the restrictions on the VM, like 64K of memory, are they going to have issues with more complex written languages like Japanese or Arabic?
That can be achieved by adding an additional (virtual) device, as it was often done for such scripts in the past.
Would be cool to have a web hoster that follows some of the principles layed out by uxn/100r and see what kind of service would turn out.
I guess being extremely productive and successfully pushing new and exciting concepts in computing also means you need to adopt a certain level of pragmatism.
But yeah, uxn hosting is a cool idea.
I was hoping that Uxn could eventually be a vehicle to get rich, graphical apps onto less popular operating systems, like Plan 9 (which they support). While their 1st-party roms are great, the wave of software never came.
Little endian is generally a lot more amenable to emulation, since math of almost all kinds of done LSB-to-MSB
There are a lot of minor things in Uxn and Varvara that make them hard to emulate efficiently. Extensive use of self-modifying code, memory-mapped I/O, and using a stack instruction set, for example.
I'm interested to hear how you'd redesign Uxn/Varvara to be easy to emulate on some tiny piece of hardware; of everyone in the world, you're probably the best person to answer that question. Little-endian, check. What else?
Stack-based actually helps (registers suck up RAM fast). Self-mod does not matter to emulators. It would for a JIT, but that is a separate story.
If your stacks grew downwards then you could use LE instructions to operate on 16-bit values on the stack. You'd still need to support loading from BE memory into the LE stack but that might not be too bad (two 8-bit operations instead of one 16-bit operation).
The device ports are also specified as BE so in theory you'd need to split those reads/writes up too. However, in almost all cases those are done directly from the stack values so I bet most ROMs would work fine with LE devices and LE stacks. LE devices would only cause issues when someone used 8-bit reads/writes from part of a 16-bit port.
This would be a pretty amazing project. I wonder if you could get existing Uxn/Varvara applications like the Left text editor or Orca to run fast enough to be usable. Presumably for Orca you'd want to hook up external sound hardware rather than trying to bitbang the sound on the 8008, and I guess the same is even more true of a framebuffer.
If you were bitbanging RAM access at 7kbps it might be hard to get it to run instructions fast enough to be usable, though.