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

Uxn

100r.co

Post reply on HN
Print view View original

71–80 of 102 posts

Re: Uxn

#71

Post by d66 »

dmitrygr wrote: post #29
kragen wrote: post #25

Earlier quoted context omitted.

I don't think you can emulate it on a tiny piece of hardware; the smallest full Uxn/Varvara implementation I've seen so far is the GameBoy Advance, which has 384KiB of RAM. On the other hand, you've previously been able to emulate some pretty astonishing things on pretty astonishing hardware. There are a lot of minor things in Uxn and Varvara that make them hard to emulate efficiently. Extensive use of self-modifying…

LE is all i'd ask for. I bet I could get it to run on an 8008 even without that change, but LE would make it easier to emulate :) 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.

There's no requirement that stacks grow upwards in Varvara.

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.

Re: Uxn

#72

Post by theamk »

__MatrixMan__ wrote: post #5

That page answers "what?" 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…

It's interesting that the virtual machine is neither very fast nor it is memory efficient. If you really want to have max speed + portability, it's hard to beat restricted subset of C, especially since almost every platform has highly optimized compiler. Something like:

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

Re: Uxn

#73

Post by vessenes »

Qwertious wrote: post #54
kragen wrote: post #41

Earlier quoted context omitted.

It seems a bit off target, though. It's not entirely wrong; it's true, for example, that Uxn doesn't lend itself to writing an efficient implementation easily. It's also true that the existing implementations are all on hardware that still requires a substantial amount of power, 2000 milliwatts or more, as well as being fairly inefficient in absolute terms. On the other hand, on my laptop, the Left text editor runnin…

>the Left text editor running in Uxn (with SDL!) still uses less energy than Emacs does, despite the interpretation overhead 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 no…

Obligatory: https://xkcd.com/378/

Re: Uxn

#74

Post by theamk »

kragen wrote: post #41
vessenes wrote: post #33

Earlier quoted context omitted.

That is a savage savage critique beautifully written and demonstrated. I don’t even like small ‘simple’ systems and I’m smarting a bit reading it. Thanks for the link.

It seems a bit off target, though. It's not entirely wrong; it's true, for example, that Uxn doesn't lend itself to writing an efficient implementation easily. It's also true that the existing implementations are all on hardware that still requires a substantial amount of power, 2000 milliwatts or more, as well as being fairly inefficient in absolute terms. On the other hand, on my laptop, the Left text editor runnin…

emacs is a really bad comparison, given that it has million of functions and is infinitely customizable. It's slow performance has been subject of many jokes back in the 1970's [0] ("EMACS: Eight Megabytes And Constantly Swapping")

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

Re: Uxn

#75

Post by 0xdeadbeefbabe »

theamk wrote: post #72
__MatrixMan__ wrote: post #5

That page answers "what?" 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…

It's interesting that the virtual machine is neither very fast nor it is memory efficient. If you really want to have max speed + portability, it's hard to beat restricted subset of C, especially since almost every platform has highly optimized compiler. Something like: "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.…

Infocom also took the VM approach and I can still play their games years later, and it worked out for them in the short term too.

Re: Uxn

#76

Post by d0mine »

__MatrixMan__ wrote: post #5

That page answers "what?" 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…

The mission sounds like the original Java mission.

Unclear why something like zig/llvm won't fit the bill.

Re: Uxn

#79

Post by guidoism »

d0mine wrote: post #76
__MatrixMan__ wrote: post #5

That page answers "what?" 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…

The mission sounds like the original Java mission. Unclear why something like zig/llvm won't fit the bill.

Look up “convivial computing”. This fits within that ethos.

Re: Uxn

#80

Post by hosh »

theamk wrote: post #72
__MatrixMan__ wrote: post #5

That page answers "what?" 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…

It's interesting that the virtual machine is neither very fast nor it is memory efficient. If you really want to have max speed + portability, it's hard to beat restricted subset of C, especially since almost every platform has highly optimized compiler. Something like: "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.…

There's an effort to port uxn to DuskOS (https://duskos.org/). The goal here isn't to be maximally performant or memory efficient (though at this point, running uxn on DuskOS on certain architecture is faster than the mainline uxn implementation).

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.

Post reply on HN