Dercuano

It's extremely unpredictable. I could list a variety of improbable outcomes, but people would find some of them distressing, so they would heavily downvote my comment, so I won't. In 02022 HN is not a place where issues like this can be debated, because people downvote and flag things they disagree with or that upset them.

Maybe it never was. Hair-trigger responses promote emotional reactions rather than careful reasoning, and two hours to edit and 14 days to reply is certainly not enough for the best ideas to arise. Even the previous four hours to edit and 28 days to reply fell short. And there's a strong negative correlation between comment length and comment score, while, as pg pointed out in 02009, there's a strong positive correlation between comment length and comment quality.

However, I do want to point out that if we get "Ukrainian victory", "Total Ukrainian victory", or "Total Russian victory" (which seems unlikely, if only because millions of Ukrainian insurgents would have safe havens in neighboring NATO nations), that's only the beginning. In any of those three cases the world order definitely will not settle down to anything similar to how things were two weeks ago. Obviously this holds a fortiori for "Global thermonuclear war".

You can download most of my previous notes in Dercuano: http://canonical.org/~kragen/dercuano. For the time being there's a copy on the web at https://dercuano.github.io/.

Specifically:

My notes on the Ukraine issue from…

> My survey of bytecode instruction sets in https://dercuano.github.io/notes/tiny-interpreters-for-micro...

Oh, cool, I'll take a look. Having started with Apple ][ in 1980 I'm already well aware of SWEET16 and admire both it's effectiveness, integration with native code, and small size of the interpreter.

> it's common in FORTH to spend no instructions on accessing arguments or returning a value

Yes, good point. Stack machines might not be good for code inside a function, but they often are good on function call/return, if you can arrange things to not need extra stack shuffling. Again, this matches very well to evaluating complex arithmetic expressions where some of the operations are function calls not inline code.

RISC-V has recent extensions -- so far the RP2350 is the most common chip that implements them -- that optimise function prologue and epilog and marshalling function arguments to S registers and S registers to function argument registers for a call. See the Zcmp extension.

https://docs.openhwgroup.org/projects/cva6-user-manual/01_cva6_user/RISCV_Instructions_RVZcmp.html

Also, Zcmt provides optimised 2-byte jumps and calls to up to 256 well-known arbitrary entry points: 32 jumps and 224 calls.

> RVC and Thumb2 are pretty extreme cases of optimized register-machine encoding, and probably not something you'd want to decode in software on a 6502.

I wan't thinking of 6502. I don't think either JVM or WASM runs there :-) If you're JITing then decoding…

> Unfortunately, it seems that they went against the project's very principle by inventing a new language, new VM and toolchain instead of simply targeting one of the existing platforms.

The intentions of Uxn are not directly in line with using say, a commodore 64, for preservation and as a portability layer, which is a monumental project to implement for each new system. The project's core principle is to design something perfectly tailored at hosting a handful of specific programs, document it in a way that if needed, others could create their own systems based on their own vision, and not centralize all preservation efforts around a handful of retrocomputing emulation.

https://wiki.xxiivv.com/site/devlog

https://100r.co/site/weathering_software_winter.html

It's more akin to using brainfuck or subleq, or Another World's VM or even Alan Kay's Chifir where the goal is to target a virtual machine that is so small(< 100 loc) that it can be easily ported. As opposed to a system so complex that it might take someone months to implement a passable C64, Amiga, or ST80 emulator.

https://tinlizzie.org/VPRIPapers/tr2015004_cuneiform.pdf

Other related similar projects:

https://dercuano.github.io/notes/uvc-archiving.html

A base 8 or 16 version of this might be useful for calculating products on old CPUs without a multiply instruction, without having unreasonably large tables.

One table driven way of accelerating 8×8 bit multiplication with a table of modest size (e.g., 256 words) is https://dercuano.github.io/notes/multiplication-with-squares.html -- however since there are 17578 distinct products of two 8 bit numbers, even a full Irish Logarithm table would probably be infeasible to store in most systems where the technique would be relevant. (you've used over 50% of a 16-bit address space on the table) And 6 table look-ups for 4 bits at a time is likely to be slower than 2 table look-ups for the 8-bit square table, even with the extra bit shifting required.

Yes, high-level language. (I submitted this post & wrote the title.)

Oberon is both the programming language and the operating system, including the IDE and the compiler and the UI.

"Oberon" is the name of the whole thing, and it's about 30K LOC in total. The entire thing is smaller than a typical Linux console-mode text editor.

The original OS -- that is the entire thing, from kernel to tiling UI to compiler -- was about 12K LOC:
http://www.edm2.com/0608/oberon.html

The compiler is about 4K LOC:
https://dercuano.github.io/notes/oberon.html

In Linux terms it is hard to even comprehend how tiny this OS is.

No, the storage part is not there. Hydroelectric storage is expensive, takes a long time to build, and is geographically dependent to boot. Only ~5 minutes of global electricity storage can be provided with batteries using all known lithium deposits. Only 19 minutes worth of storage is available with all the lithium we can mine with today's equipment [1].

This is why plans for a solar and wind grid assume that some silver bullet is going to provide dirt-cheap and nigh-infinitely scalable storage.

1. https://dercuano.github.io/notes/lithium-supplies.html