That's how the VAX 9000 and NVAX did it. It's not the only way. It is absolutely possible to decode a number of normal VAX instructions in parallel using a pipelined decoder similar to x86 decoders. It is also possible to use a µop cache similar to many x86 and ARM implementations.

Fallbacks are only needed for the weirder addressing modes and for instructions that positively beg to microcoded (system calls/protection level transitions, some bit vector stuff, COBOL decimal stuff, block copy/scan/fill/compare, probably POLY) and startup and interrupt/exception handling.

DEC never did this but they absolutely could have.

Intel committed to not slicing and dicing the AVX instruction set going forward. AVX 10.(n+1) will not remove instructions that were in AVX 10.n. Feature testing is also easier: a single feature bit and a single version number.

I bet Intel's management will find some new counterproductive way of segmenting the market but AVX-10 (and therefore AVX-512) should be safe now.

Some early 386 CPUs had XBTS/IBTS instructions (extract/insert bit string). They used 0F A6 and 0F A7 encodings.

Some early 486 CPUs had CMPXCHG encodings that reused the XBTS/IBTS encodings. That apparently screwed up some programs that tried to execute XBTS/IBTS to see if they were running on early (buggy) 386s so Intel moved CMPXCHG to different encodings (0F B0 and 0F B1).

0F A6 and 0F A7 are still left unused by Intel and AMD in their modern chips.

There's also the delightfully petty story about SYSENTER/SYSEXIT and SYSCALL/SYSRET for fast system calls. Intel came up with the first pair, AMD with the second. AMD of course had to support both and operating systems generally only supported Intel's pair.

Then AMD extended the x86 to 64 bits and of course required SYSCALL/SYSRET for 64-bit system calls (and did not support SYSENTER/SYSEXIT in 64-bit mode). Intel had to support AMD's instructions in 64-bit mode but decided to also support SYSENTER/SYSEXIT there (which I don't think any operating system has ever bothered to support).

To summarize: AMD supports both methods outside of 64-bit mode and only their own in 64-bit mode. Intel supports both methods in 64-bit mode and only their own in 32-bit mode. Or at least that's how it used to be. Maybe they've mellowed out by now.

Which is very cheap if it means they can launch it quickly instead of being in permit hell for a year. You can also avoid sabotage (including via lawfare) and dishonest TV reporting à la "I'm standing here in front Big Bad Evil Datacenter that the local community says causes cancer and bad hair".

They also get lower latency to pretty much everybody except the neighbours of such a terrestrial data center.

The latter is an honest advantage. The former is a way of routing around damage. Both can be very valuable.

permits? connectivity?

Laura Loomer is another crazy person who went from extremely crazy to just... untrustworthy but not totally crazy on Ukraine. I still think she is crazy underneath, though.

> I wasn't sure how it was possible for a leather belt to transmit so much power.

Friction is also one of the main reasons why rivets work. And why ropes work and why knots don't unwind and lashings work and, and, and ... and of course also nails and screws and worm drives. Friction is awesome.

> Another fun aspect is safely starting the machine

I saw them start this little beaty more than a decade ago:

https://dieselhouse.dk/en/videnom/#BW2000

It was not exactly a quick and simple job.

That's a problem for some types of RNA/DNA vaccines where they use a virus as a vector. You can usually only use a specific kind of virus once per patient.

And each of those could be expanded to much more than the page you already made.

Things are almost always a lot more complicated than they seem. It seems so simple -- "water + heat makes steam, steam pushes piston, back and forth motion makes rotary motion" -- but it is really anything but.

Surely we can agree that if such kids exist then they must be very, very few in number?