Related. Others?
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)
I don't want to go to Chel-C - https://news.ycombinator.com/item?id=31705239 - June 2022 (124 comments) is sorta-related, since it's a rebuttal.
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 ensure reliability we began removing dependencies.
Electron is slow when your code is crappy .
As a product designer, I don’t fully grasp everything the folks at 100r make.
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 really like their ideas, and I love that they follow through with actual implementation.
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?
<<reading>>...good...cool....interesting...
"big endian"
damn! Nope!
It's an 8 bit unaligned encoding, so this matters very little
From an ergonomics perspective big-endian is the little-endian of stack based machines. Register truncation is the big reason why from an ergonomics perspective we prefer little-endian, but in stack based machines the equivalent is pop truncation. But the behavior between these is reversed between the two machine types. Big endian is the layout by which pop-ing one byte off the stack gives you the truncated number.
math is still done LSB-to-MSB
why that reaction? what impact does one or the other entail?
well, if i wanted to emulate this on some tiny piece of hardware, as one does.
Little endian is generally a lot more amenable to emulation, since math of almost all kinds of done LSB-to-MSB
Great, although the VM should really migrate to being RISC-V based, now that we finally have a proper standard ISA.