This isn't meant as a reductive take, but instead that there is a difference between completely describable in C like the contents of the .got section, and something like a .reloc section that actually has to understand the generated assembly in order to build the relocation table to load and link the executable. Both are linking, but I've saved "patching" for more brain surgery esque techniques. Like on mips, the jump instruction immediate is the bottom 26 bits of the absolute address of the target, so you're going through and modifying all of the jump instructions if you load it to somewhere it wasn't linked at.

Unices have been sharing executable memory between processes longer than there's been mmap for user space to do the same thing themselves. I remember seeing it in the 2BSD kernel for instance.

We're already in the company of the asteroid that wiped out the dinosaurs.

https://en.wikipedia.org/wiki/Holocene_extinction

However, my question is kind of orthogonal to vertical versus horizontal microcode.

As a counter example I'd point to the microcode format of the system 370/145, which while pretty clearly being something that would be described as vertical microcode also doesn't have implicit control flow [1]. It's a little on the wide side for vertical microcode at 32 bits, I'll grant you, but it has an op field(s) with about a dozen variants that then is used to further decode the other fields, at an overall decode complexity comparable to a RISC arch. Horizontal microcode looks more like 'these specific bits just always plug into this mux, and are simply set to some default if unused in this specific operation, reducing decode to essentially wires'. That being said, it also doesn't have an incrementer on the program counter, with the last byte of instructions encoding a (conditional) branch to the next instruction[2].

For another example, I'd point to modern microcode formats in Intel and AMD cores. They pretty universally have a vertical microcode instruction format (though grouped into triads or quads of instructions typically) then paired with explicit, dedicated microprogram control flow field for the group. The uops there are pretty wide at 48-64 bits typical, but they sort of need to be to fit immediates that are common for 64 bit archs, and also fit into that RISC like level of decode complexity you see in vertical microcode. [3]

[0] - As an aside, if you like Computation Structures, I'd recommend The Anatomy of a High-Performance Microprocessor: A Systems Perspective by Shriver and Smith as well. The mad lads stuck a surprising amount of the RTL for the AMD K6 in that book, albeit translated into some custom academic langauge. That mid 90s era design of a multi instruction per clock CISC decoder dumping a speculative instruction stream into an OoO RISC like backend is arguably just as much peak CISC as the early 80s given that it won against the UNIX RISCs by the early 2000s and survives to this day with remarkably few tweaks relatively speaking. CISC seems to be kind of like the Roman empire; any time it starts losing the war, it just unashamedly starts integrating the concepts of its competitor it's losing to. Which is great in this case. That's called good engineering.

[1] - Pages A2-A5 for an overview, chapter 4 for a more in depth discussion. https://www.bitsavers.org/pdf/ibm/370/fe/3145/SY24-3581-1_31...

[2] - Though it does have an explicit far jump/call instruction for control flow outside that window addressable by that byte, and a couple other bits sometimes depending on the instruction format.

[3] - https://www.usenix.org/system/files/conference/usenixsecurit... and https://github.com/chip-red-pill/uCodeDisasm

That's why chip thermals is its own whole subfield of physical design.

So I guess my question is: what do you see as the reasons why you'd pick a particular school of micro control flow as a microcode engine implementer? ie. along the spectrum of 'no increment on upc, every uinstr explicitly encodes jump, maybe oring bits into the address for conditional control flow', to 'looks like a relatively normal assembly, assumed incrementing program counter, specialized control flow uinstrs otherwise'.

Yeah, it was intended to limit lateral movement from compromised systems.

Roslin: I heard you're one of those people. You're actually afraid of computers.

Adama: No, there are many computers on this ship. But they're not networked.

Roslin: A computerized network would simply make it faster and easier for the teachers to be able to teach-

Adama: Let me explain something to you. Many good men and women lost their lives aboard this ship because someone wanted a faster computer to make life easier. I'm sorry that I'm inconveniencing you or the teachers, but I will not allow a networked computerized system to be placed on this ship while I'm in command. Is that clear?

Roslin: Yes, sir.

Adama: Thank you. 'Scuse me.

Is that a good idea? Well, not really.

https://www.reddit.com/r/sonos/comments/1desj5c/sonos_update...