Funny enough when Intel and DEC settled their lawsuit Intel got StrongARM[1] from DEC which was pretty fast for its time. It was a pretty cool, literally, chip that didn't need a heatsink. I had a Shark set-top appliance prototype. The offical name was DNARD — Digital Network Appliance Reference Design.
The hardware folks at HP were big into the outdoors. The story went that it was named Halfdome but customers outside the US who weren't familiar with Yosemite would ask where the other half was.
Did the PA-RISC shops run their old PA-RISC code with the Aries emulator?
One of the selling points for HP users was running old code via dynamic translation and x86 would just work on the hardware directly.
Another fun fact I remember from working at HP was that later PA-RISC chips were fabbed at Intel because the HP-Intel agreement had Intel fabbing a certain amount of chips and since Merced was running behind... Intel-fabbed PA-RISC chips!
I lost track of it but HP, as co-architects, had its own compiler team working on it. I think SGI also had efforts to target ia64 as well.
But the EPIC (Explicitly Parallel Instruction Computing) didn't really catch on.
VLIW would need recompilation on each new chip but EPIC promised it would still run.
Itanium was compatible with x86. In fact, it booted into x86 mode. Merced, the first implementation had a part of the chip called the IVE, Intel Value Engine, that implemented x86 very slowly.
You would boot in x86 mode and run some code to switch to ia64 mode.
HP saw the end of the road for their solo efforts on PA-RISC and Intel eyed the higher end market against SPARC, MIPS, POWER, and Alpha (hehe. all those caps) so they banded together to tackle the higher end.
But as AMD proved, you could win by scaling up instead of dropping an all-new architecture.
* worked at HP during the HP-Intel Highly Confidential project.
Having briefly worked at HP on the IA64 effort IIRC the PA-RISC chips fabbed at Intel were the side-effect of the Itanium agreement. HP was owed a certain volume of chips and since Merced was very delayed they had to make those chips for HP.
Not to detract form your point, but Itanium's design was to address the code compatibility between generations. You could have code optimized for a wider chip run on a narrower chip because of the stop bits.
The compiler still needs to know how to schedule to optimize for a specific microarchitecture but the code would still run albeit not as efficiently.
As an aside, I never looked into the perf numbers but having adjustable register windows while cool probably made for terrible context switching and/or spilling performance.
I find it somewhat ironic that many years ago HP’s PA-RISC chips were fabbed at Intel because contractually they had to supply chips due Itanium not yet taping out.
But maybe it was more of an early foreshadowing. I had a housemate that worked on their internal CAD tools and it also sounded like a bit of a mess with NIH syndrome. (20+ years ago)
It’s in the Jargon file. Your comment made me remember this bit:
Hackers at HP/Apollo (the former Apollo Computers which was swallowed by HP in 1989) have been heard to complain that Mr. Packard should have pushed to have his name first, if for no other reason than the greater eloquence of the resulting acronym.
Both DEC and HP were pushing for NT. (I interned at dec and worked briefly at HP while both were still
pushing Alpha and PA)
HP foodnote: HP had this vision of NT at the desktop and HP/UX server iron. Folks preferred Solaris over HP/UX so that was their idea to adopt windows. The guy at hp pushing that agenda, Belluzo, eventually left and went to Microsoft.
Cell used the PowerPC isa as did the Xbox 360. Both were designed in the same IBM facility but separated by a floor. IIRC the Xbox team indirectly learned from the Cell team's mistakes at the process/microarch level.
Cell was definitely more weird to code against and Sony put max theoretical perf above Xbox's approach to be more general purpose chip architecture.
So strictly speaking it wasn't like most PCs at the time in the x86 sense but in the three mostly same cores for Xbox vs custom Cell and special ways to squeeze out performance.
I don't remember if the parent article mentioned it but there were also a bunch of things like the predicate bits for predicated execution and I remember trying to gain an advantage using speculative loads was also very tricky. In the end it was pretty gnarly.
The other bit no one mentions is that it was an HP-Intel alliance. HP committed to PA-RISC compatibility with a combination of hardware and software whereas Intel just expected stuff to run.
From the instruction reference guide:
```
Binary compatibility between PA-RISC and IA-64 is handled through dynamic object code translation. This process is very efficient because there is such a high degree of correspondence between PA-RISC and IA-64 instructions. HP’s performance studies show that on average the dynamic translator only spends 1-2% of its time in translation with 98-99% of the time spent executing native code. The dynamic translator actually performs optimizations on the translated code to take advantage of IA-64’s wider instructions, and performance features such as predication, speculation and large register sets
```
There was some hardware support for 32-bit userspace binaries. See the addp4 instruction.
> Itanium is designed for a machine with three execution units and each instruction pack has up to three instructions, one for each of them.
The design was that each bundle had some extra bits including a stop which was a sort of barrier to execution. The idea was that you could have a series of bundles with no stop bit and the last one would set it. That meant the whole series could be safely scheduled on a future wide IA64 machine. Of course that meant the compiler had to be explicit about that parallelism (hence EPIC) but future machines would be able to schedule on the extra execution units.
This also addressed the problem where VLIW traditionally would require re-compilation to run/run more efficiently on newer hardware.
> Due to not having register renaming, VLIW architectures conventionally have a large register file (128 registers in the case of the Itanium). This slows down context switches, further reducing performance. Out-of-order CPUs can cheat by having a comparably small programmer-visible state, with most of the state hidden in the bowels of the processor and consequently not in need of saving or restoring.
Itanium borrowed the register windows from SPARC. It was effectively a hardware stack that had a minimum of 128 physical registers but were referenced in instructions by 6 bits — e.g. 64 virtual registers, iirc.
So you could make a function call and the stack would push. And a return would pop. Just like SPARC execept they weren't fixed-sized windows.
That said, the penalty for spilling the RSE (They called this part the Register Stack Engine) for say, an OS context switch was quite heavy since you'd have to write the whoe RSE state to memory.
It was pretty cool reading about this stuff as a new grad.
> Another enginering issue was that x86 simulation on the Itanium performed quite poorly, giving existing customers no incentive to switch.
As I mentioned in my previous comment Merced had a tiny corner of the chip devoted to the IVE, Intel Value Engine which was meant to be the very simple 32-bit x86 chip meant mainly for booting the system. The intent was (and the docs also had sample code) to boot, do some set up of system state, and then jump into IA64 mode where you would actually get a fast system.
I think they did devote more silicon to x86 support but I had already served my very short time at HP and Merced still took 2+ years to tape out.
I was at HP pre-Merced tape-out and HP did have a number of simulators available. I worked on a compiler-related team so we were downstream.
As for running linux in 32-bit compatibility mode, wasn't that the worst of all worlds on Merced? When I was there which was pre-Merced tape-out, a tiny bit of the chip was devoted to the IVE (Intel Value Engine) which the docs stated were supposed to be just good enough to book the firmware and then jump into IA64 mode. I figured at the time that this was the goal — boot in 32-bit x86 and then jump to 64-bit mode.
Had fun browsing there twenty years ago after a fellow older tinkerer told me about it. I once managed to get a motherboard for cheap to replace my friend’s “server” that was hosting his homepage over his very fast at the time 768kbps DSL connection.
[1] https://en.wikipedia.org/wiki/StrongARM [2] https://collection.maynardhistory.org/items/show/8946