Heute ist Dienstag der 24. Februar 2026.

Vor 410 Jahren, am 24. Februar 1616, verurteilte die Inquisition Galileo Galilei zum ersten Mal wegen der Häresie dass sich die Erde um die Sonne dreht und die Sonne stationär im Zentrum des Planetensystems befindet.

Zugleich ist heute der 44. Gründungstag einer Computerfirma, die es nicht mehr gibt.

Sie hieß SUN.

Der 24-Feb 1982 war ein Mittwoch. Mittwoch ist ist also SUN-Day.

@isotopp I really mourn the loss of Sun Microsystems...

There were so many cool things, way ahead of their time. I sometimes try to imagine what could have been if they had opted to do ARM instead of SPARC 🙂.

@masek @isotopp SPARC isn't that different from ARM, both are architecturally much more extendable than 8086, which for some reason has managed to survive to this day. So, sticking with SPARC is not what killed Sun. The real death sentence for Sun was selling out to that Ellison place. Could they have avoided that? Who knows…

@deBaer @masek Uh, SPARC is nothing like ARM, not even close.

SPARC has a register file (of unknown size to the machine language, because the machine language abstracts it away, yes, really). Which makes context switches absurdly expensive.

It has a linear address cache that interferes with itself until you introduce hardware process IDs and a number of hilarious or weird specialties that Intel and ARM are lacking.

https://infosec.exchange/@isotopp/116124684289733634

Kris (@[email protected])

Attached: 1 image A modern CPU runs at approximately 3 GHz, sometimes faster, sometimes slower, depending on a lot of factors (thermal state of the CPU, workload, availability of plugin power vs. battery). That's 3 clock cycles per nanosecond, or 3 billion cycles per second. A CPU register access is one cycle, 0.3 ns. L1 cache comes in at 3 cycles, 1 ns. L2 usually at 10-15 cycles, 3-5 ns. L3 cache at 30-60 cycles, 10-20 ns, and RAM access at 50-100 ns, 150 to 300 cycles. Cycles that the CPU spends waiting for data unless we manage to make it do something else. Which is modern CPU hardware keeps track of instruction independence and executes code "out of order" (not in the order it is stored in memory) in order to fill memory wait gaps. Before we learned to build CPUs that way, SPARC did something unusual: They built CPUs with a very large set of registers (hundreds) and did not expose them to the machine language. SPARC machine language has 8 global 32 bit registers, %g0 to %g7, 8 input registers (%i0 to %i7), 8 local registers (%L0 to %L7), and 8 output registers (%o0 to %o7) – 32 visible registers in total. Physically we have the 8 fixed global registers, and the register file, a set of say 128 or more registers and a current window pointer that determines the set of registers that are currently the i and L registers. A function call moves the CWP by -16, so you get a fresh set of L0 to L7, and the old O-registers of the caller become the i-registers of the callee. That makes using 8 local variables free, and makes passing 8 function parameters free. When the CWP rolls around, a window overflow trap occurs, and old window contents are spilled to memory – which was very, very slow. Similarly, a window underflow trap can occur and the window is loaded back into the register file. If you think that makes a SPARC suck at recursion (if you go more than the register file depth deep) you have the absolutely correct idea. It also makes a SPARC suck at context switching, because on a context switch the full register file needs to be spilled and the other processes register file must be loaded in full (there are fixes where that happens partially, lazy window spilling). So this idea was not good and got abandoned. Modern CPUs do register renaming, they sell you registers with fixed names but in reality have hundreds of registers and dynamically keep track of them, across context switches and subroutine calls.

Infosec Exchange