And the same reason NVRAM was dead on arrival. No affordable dev systems meant that only enterprise software supported it.

That's more "load store architecture" than RISC. And by that measure, S/360 could be considered a RISC.

You may enjoy the RISC deprogrammer: https://blog.erratasec.com/2022/10/the-risc-deprogrammer.htm...

FreeBSD

ARM already has most stuff required for this on board. Two proprietary extensions are used by Rosetta: one emulates the parity (rarely used) and half-carry (obsolete) flags, which can also be emulated conventionally. The other implementa TSO memory ordering, which can either be ignored or implemented with explicit barriers; some other chips apparently have a similar setting.

The other stuff is all present in ARMv8.5 I think.

It's very likely that there is some serious autovectorisation going on behind the scenes.

Best one was when gedit had the option to syntax highlight for a language named “Los.”

Not a bad name, to be honest!

Had the same feeling browsing through the Haskell package collection. Felt like and almagamation of PhD theses, none of which were maintained after the author got his degree. Every single one a work of art, but most engeneered so badly that you would only use them begrudgingly.

My impression of Rust crates is that most are developed because a standardized solution to the problem didn't exist or didn't meet the author's needs, so they built their own. Many are well designed, but were never used by enough people to become truly usable or robust before they were abandoned.

It seems like outside certain problem domains, there isn't any effort to pool resources to keep projects alive. The few I did find were forks of forks where each subsequent maintainer stopped responding to proposed changes.

haskell

Such as?

Most of the Intel cache partitioning things were driven primarily by Google. The holy grail was to colocate latency-sensitive tasks with bulk background tasks to increase cluster utilization.

I guess technically CAT and RDT are not ISA extensions because they are managed by MSRs. I was thinking of aspects of BMI, but I am sure that large-scale buyers had input into things like vector extensions, PMU features, and the things you mentioned as well.

Also, the VAX instruction encoding is a class of horror above that of x86.

few classes above.

Only ISA where I've seen a single instruction span two memory pages despite being page aligned

Two cache lines, sure, on earlier models, but not two VM pages!!

Maximum instruction length is 56 bytes. Early models had 8 byte cache lines, later ones 64 bytes. VM page 512 bytes.

I might be mistaken then, but I recall reading something about most extreme decode on VAX going into ~522 bytes.

What I am more certain of was complaints about possibly ending with maaaany TLB lookups (and pagetable walks) for certain "business" optimized instructions.

Absolutely. Six operands [1], each of which can be in a different memory page AND have an indirection via another memory page AND both the indirection and the final operand could if you're unlucky be misaligned and straddle two memory pages ... ow.

[1] MOVTC (Move Translated Character), MOVTUC (Move Translated Until Character), ADDP6 (Add Packed 6-operand)

I think it was implied to me that every operand of ADDP6 could have been indirected, and all the resulting 3 ranges all could straddle pages.