How do you think position independent code can call functions from other .so's without being patched with their addresses?
They can't, so even PIC code still has to have a relocation table that gets patched. It's in a different page than the code though, so code does still get reused.
There's a part of the .so ELF file (the Global Offset Table aka GOT) that has to be modified with all the addresses of the functions being imported, which of course vary from process to process.
If not patching, what exactly would you call modifying part of the file?
And the got is just a big table of pointers like any other table of pointers your application manipulates as it runs.
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.
Those mappings by default all go to the same shared memory.
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.
Poorly designed or managed chips can reach the point that hot spots in the silicon literally melt, which happens at ~1400C. Thermodynamics sitting on an insulator (relative to the metal portions of the chip at least) on very small scales is very weird and can reach wild spot temps.
That's why chip thermals is its own whole subfield of physical design.
Sure, but the center of a PWR fuel rod reaches high temperature in normal operation. Uranium dioxide is not a great conductor of heat.
Chips have the advantage that the workings are right at the surface, mere microns from it. So the heat can easily get out. The power density in that thin surface layer can be very high. Perhaps similarly, the power density of a PV cell can be very high, if one just looks at the active layer where light is being absorbed. In CdTe this layer is < 1 micron thick. The energy delivered over the life of the cell per atom in this layer can approach that of nuclear reactions.
I will add that if we're talking about abnormal operation, say in a reactor meltdown, uranium dioxide can reach its melting point, 2865 C.
Anyway, it's a promising comparison, since the core of a PWR can reach volumetric power density of ~100 MW/m^3 (and probably higher in naval reactors). Servers can potentially be made very compact.
I found it interesting that this uinstr format doesn't include omnipresent control flow bits like I see in most uinstr archs. I was going to ask about RNI being it's own instruction, but looked at the microcode dump you linked to, and it's clear that you'd need a nop in almost all of those slots anyway because of the delay apparently needed after register transfers.
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'.
> 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?
For a comprehensive answer, a good vintage introductory digital design textbook is Ward and Halstead's 1989 Computation Structures, from the "peak CISC" era! [1]
There, the second (vertical) type is often used for highly complex instructions/fancy addressing modes, that you might want to implement with some sort of procedure abstraction, loops, working memory, etc. A "luxury" vertical microcode engine would have facilities like "microprocedure calls", a micro-stack and workspace RAM, a micro-ALU, dispatch table micro-instructions. The authors use the suggestive term "interpretive microcode".
String instructions come to mind as a complex example; non-register machine architectures (stack machines); tagged data architectures that have instruction-level polymorphism (e.g. Lisp machines).
The culminating project of Ward and Halstead is an elaborate two-level microcode system (vertical on horizontal/second on first). I think the first Motorola 68k had this architecture -- here is the patent. [2]
It's genuinely a fun read. The "write an micro-interpreter for your CISC ISA" approach is hopelessly out of date now that we need pervasive microarchitectural parallelism, and have HDLs.
So, I've read Computation Structures. And agreed, an absolutely fantastic text. [0]
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.
[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.
Basically why my car is so old it doesn't even have a CAN bus.
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?
But they used Floppy disks and data chip thingies for transferring data. If the Cylons were any good they’d have eventually created a self perpetuating virus. Even humans have pulled that off (Stuxnet and Iranian nuclear centrifuges)
Same. Want to update the firmware in the computer? Sure but you'll need to unscrew the driver's seat, unscrew the desktop PC sized ECU, unscrew its four pencil-thick battery connections, unplug its 27 connectors, unscrew the 50 screws in three slightly different sizes holding the top cover on, remove the heatsinks, unscrew the eight screws holding the motherboard in, and desolder both the 144-pin 68HCxxx chips that do all the thinking.
There's a big custom chip made by GEC Plessey that has a small flash chip beside it, but it's totally undocumented. They also make the custom chips in the door, window switch, and seat outstations. I found some very very general documentation about them but nothing enough to start picking the firmware apart.
They had to calculate jump fast to join the fleet and the only way was to break the taboo - connecting the computers.
Cylons seized the opportunity and despite of the software firewall they managed to periodically disturb this network. In the end all computers were disconnected. IIRC Gaeta later had to wipe drives and install operating systems again, from these fancy octagonal "cds".
I never understood this. They're networked? So what? Don't connect it to other ships, or the Baltarnet or whatever they call it. Is the idea that if a Cylon gets on the ship, they can access the CIC from the thermostat in the bathroom? Did I miss something? Did I watch it wrong?
I wouldn't quite go that far. Linux runs on nommu systems. With some psram you should be able to get a version to run on at least the rp2350 using the riscv cores with relatively minimal fuss.
I image that'd be handled via a fairly regular minor bit of additional fine tuning to update them with new information rather than polluting the context space.
reply