HN user

dsand

26 karma
Posts0
Comments11
View on HN
No posts found.

About 360 and pi: In the late 70's, "Two Pi Corporation" of Santa Clara made S/370-clone minicomputers named V/32. In early 1981, Two Pi was acquired by Four Phase Systems of Cupertino, a maker of early PMOS cpus. Four Phase was itself acquired in late 1981 by Motorola and withered away. Four Phase's campus was leveled and replaced by Apple's Infinite Loop campus, with nearly the same footprint.

My partner Elaine Gord was on VisiOn's C compiler team in 1982-1984 with two others. They experimented with having two instruction sets: the native 8088 code for best performance, and a C virtual machine bytecode for code density. The two modes were mixed at the function level, and shared the same call/return stack mechanism. This was terrible for speed, but was thought necessary because the target machines did not have enough ram for the total VisiOn functionality. I don't know if the bytecode scheme got into "production".

Yes, all Tandem full-time employees got paid sabbaticals. And stock options.

My partner joined Tandem 2 years after me, so our eligibility for sabbaticals was out of sync. One of us would have to defer our next sabbatical for 2 years to get us in sync. Instead, we both took off together for 6 weeks every two years, using time off without pay when it wasn't our turn for a paid vacation. We took a lot of overseas trips.

The historical former building stood unchanged until 5-10 years ago. There was a historical plaque on that building. It has been demolished and replaced by a nameless large 5-story office building.

There are no heirs for LCM. Allen's will specified what do to in particular with a few of his many assets. But for all the rest, he wrote to sell it all, and donate the raised money to charities. So the will's executor (his sister) does not have the latitude to divert some assets to other outcomes.

LCM was never self-sustaining via tickets. It always needed yearly infusions of cash from Allen. Re-opening it as it was would require similar levels of cash to burn. I wish that Allen had loved the LCM enough to design an endowment to keep it going, and had specified in the will how to treat LCM specially. But he did not. What he wanted instead for his legacy, was large cash donations to various charities.

HP partnered with Intel to bring HP's Playdoh vliw architecture to market, because HP could not afford to continue investing in new leading-edge fabs. Compaq/DEC similarly killed Alpha shortly before getting acquired by HP, because Compaq could not afford its own new leading edge fab either. SGI spun off its MIPS division and switched to Itanium for the same reason -- fabs were getting too expensive for low-volume parts. The business attraction wasn't Itanium's novel architecture. It was the prospect of using the high-volume most profitable fab lines in the world. But ironically, Itanium never worked well enough to sell in enough volumes to pay its way in either fab investments or in design teams.

The entire Itanium saga was based on the theory that dynamic instruction scheduling via OOO hardware could not be scaled up to high IPC with high clock rates. Lots of academic papers said so. VLIW was sold as a path to get high IPC with short pipelines and fast cycle times and less circuit area. But Intel's own x86 designers then showed that OOO would indeed work well in practice, better than the papers said. It just took huge design teams and very high circuit density, which the x86 product line could afford. That success doomed the Itanium product line, all by itself.

Intel did not want its future to lie with an extended x86 architecture shared with AMD. It wanted a monopoly. It wanted a proprietary, patented, complicated architecture that no one could copy, or even retarget its software. That x86-successor arch could not be yet another RISC, because those programs are too easy to retarget to another assembler language. So, way beyond RISC, and every extra gimmick like rotating register files was a good thing, not a hindrance to clock speeds and pipelines and compilers.

HP's Playdoh architecture came from its HP Labs, as had the very successful PARISC before it. But the people involved were all different. And they could make their own reputations only by doing something very different from PARISC. They sold HP management on this adventure without proving that it would work for business and other nonnumerical workloads.

VLIW had worked brilliantly in numerical applications like Floating Point Systems' vector coprocessor. Very long loop counts, very predictable latencies, and all software written by a very few people. VLIW continues to thrive today in the DSP units inside all cell phone SOCs. Josh Fisher thought his compiler techniques could extract reliable instruction-level parallelism from normal software with short-running loops, dynamically-changing branch probabilities, and unpredictable cache misses. Fisher was wrong. OOO was the technically best answer to all that, and upward compatible with massive amounts of existing software.

Intel planned to reserve the high-margin 64-bit server market for Itanium, so it deliberately held back its x86 team from going to market with their completed 64 bit extensions. AMD did not hold back, so Intel lost control of the market it intended for Itanium.

Itanium chips were targeted only for high-end systems needing lots of ILP concurrency. There was no economic way to make chips with less ILP (or much more ILP), so no Itanium chips cheap and low-power enough to be packaged as development boxes for individual open-source programmers like Torvalds. This was only going to market via top-down corporate edicts, not bottom-up improvements.

The first-gen Itanium chip, Merced, included a modest processor for directly executing x86 32-bit code. This ran much slower than Intel's contemporary cheap x86 chips, so no one wanted that migration route. It also ran slower than using static translation from x86 assembler code to Itanium native code. So HP dropped that x86 portion from future Itanium chips. Itanium had to make it on its own via its own native-built software. The large base of x86 software was of no help. In contrast, DEC designed Alpha and migration tools so that Alpha could efficiently run VAX object code at higher speeds than on any VAX.

The 1401 was designed as a stored-program alternative to IBM's never-shipped WWAM World Wide Accounting Machine. WWAM was designed in IBM Europe in 1955. WWAM was to be a low-cost plugboard-programmed transistor computer to handle the same card tasks as IBM's existing and popular relay-based punch-card accounting equipment. WWAM was IBM's reaction to the threat of losing its many punch-card customers to a low-cost computer Gamma 3 made by French company Bull. 1401 uses the same ALU etc as WWAM, but with newer standard circuit modules. Both use arbitrary-length decimal fields, just like the punch card machines before them.

Several incompatible IBM machines in the 7000 series also used arbitrary length decimal numbers, not binary words.

At Burroughs, the "Medium Systems" B2500-B4800 series were similarly decimal only with arbitrary length numbers. They got extended with fixed-length decimal accumulator and index registers, and competed with IBM's mid range 360 and 4331 systems. Building a decimal-addressed memory using binary-addressed chips got increasingly kludgy.

https://ibm-1401.info/1401Origins.html#Motivations-1

That is a very interesting article. For how they aim to run existing software by binary translations to an ISA optimized for such binary translations. And how much they dread possibly being cut off from foreign foundries and ARM and x86 chips.