Emulation

R-ten-K wrote: I think the feature I remember was their odd cache strategy: usually they implemented a single very large cache level.... And now that you brought the handler issues, it makes a lot of sense to have a big honking cache when so much overhead is expected when servicing interrupts, exceptions, etc.

Yeah, even today, the last generation PA-RISCs have 32 and 64Mb L2 caches. I'm not sure why they do that.

R-ten-K wrote:
It must have been weird to be motorola in the 80s, everyone leaving you for yet another RISC vendor.

I was at Motorola in the 90's and they were still in the process of moving 68k based UNIX boxes used internally to competitors CPU's (mostly PA-RISC). All the 68k based Macs were being replaced as well, but at least they had a stake in PowerPC, so it wasn't all bad.

hamei wrote: While we've got you two dissecting the shortcomings in processors, how about the Power lineup ? And where does the Itanic really fit in ? Would it have been the processor to end all processors if it hadn't been such a bust ?

I have never really used POWER systems - I've only read some of the papers on POWER and AIX. It is actually a couple of similar architectures in one (to support old POWER 32 & 64 bit, PowerPC-AS, PowerPC 32 & 64 bit). Plus it has great virtualisation support (in combination with firmware), and they have also started to implement hardware assists for commonly needed stuff at OS level. And it achieves decent clock speeds. All in all, a nice chip, and a shame it isn't being used more widely.

Ahh. Itanium
... take many PA-RISC features (already overly complicated from an OS point of view)
... add things like register window concept from SPARC, some of MIPS CP0 features, the PALcode idea from Alpha,
... add a huge number of registers, so that normal context switching strategies are not feasible. Ensure that lazy strategies are needed, and thus complicated stack unwinding is needed when something needs to access the register file of a suspended thread.
... then implement full IA-32 compatibility in hardware (i.e. one of the most complicated and kludged architectures ever).
... then for the ISA, use an explicitly parallel design that puts a massive burden of work on compiler writers (and also those writing assembly for the kernel and libraries).

I was never impressed with it from the start, and wasn't the least bit surprised that what seemed like the underdog (AMD Hammer, now AMD64) took the role expected of the mighty Itanium in the 64-bit world. Its actually funny - I recall around 1999 or so seeing graphs projecting annual shipment of 30 million itanium based systems just a few years later. Its a shame several decent architectures (Alpha, and MIPS to an extent) got killed off for what turned out to be a commercial flop. Admittedly it did do FP well, and scientific sales are probably the only thing that justifies keeping it alive nowadays.

Itanic technically it is a dog, however it seems that in hindsight it must have been a marketing tour de force since it did annihilate the competition: AXP, MIPS, and to a lesser extent SPARC/POWER. Which I guess, under Intel's POV, it must have been a worthy investment.

I can't believe the IA64 people decided to implement register windows. When I was in grad school, one of the projects I had to develop an out-of-order scheduler for a machine with register windows (SPARC). And it was a massive pain in the ass... I was impressed when I read that the itanium people had managed to get an out-of-order implementation internally, but I assume it is so complex as to not be worth it.

I liked the concept of predication, but now it is clear that it is a bad idea from a power consumption standpoint.

Power may not be around for long, I think most of Power7 is subsidised by DARPA. Power6 is interesting, in the sense that IBM decided to ditch out of order and go for sheer speed. Still, they do some really strange things to that architecture, like the decimal ALUs (ugh).

If anything, the only architecture I am looking forward to see release soon is ROCK from SUN. It is mighty late, but I am interested in seeing an actual implementation of transactional memory. Although, after playing with nehalem... I hope the sun people get it right.

R-ten-K wrote: ...
I also remember that at some point, the next generation Amigas were supposed to be based around HP-PA? It must have been weird to be motorola in the 80s, everyone leaving you for yet another RISC vendor.

It was called Hombre, pardner!
http://en.wikipedia.org/wiki/Hombre_chipset

- Simon.

kramlq wrote: Ahh. Itanium
... take many PA-RISC features (already overly complicated from an OS point of view)
... add things like register window concept from SPARC, some of MIPS CP0 features, the PALcode idea from Alpha,
... add a huge number of registers, so that normal context switching strategies are not feasible. Ensure that lazy strategies are needed, and thus complicated stack unwinding is needed when something needs to access the register file of a suspended thread.
... then implement full IA-32 compatibility in hardware (i.e. one of the most complicated and kludged architectures ever).
... then for the ISA, use an explicitly parallel design that puts a massive burden of work on compiler writers (and also those writing assembly for the kernel and libraries).

Actually, that feature was dropped completely, and is now handled entirely in the IA32 Execution Layer, which is software. And, from experience, it is never, ever used.

Itanium2 is not a bad chip. It's definitely not the best - I'm sure some people here can debate for weeks over this title - but it's really not a bad chip. Combined with the chipsets HP provides (ZX2, ZX2000) it has an interesting amount of total I/O and memory bandwidth. It never had that funky take-cover-im-a-RISC feeling you get from MIPS, Sparc, POWER, HPPA, ... though.

Alver wrote:

kramlq wrote: Ahh. Itanium
... take many PA-RISC features (already overly complicated from an OS point of view)
... add things like register window concept from SPARC, some of MIPS CP0 features, the PALcode idea from Alpha,
... add a huge number of registers, so that normal context switching strategies are not feasible. Ensure that lazy strategies are needed, and thus complicated stack unwinding is needed when something needs to access the register file of a suspended thread.
... then implement full IA-32 compatibility in hardware (i.e. one of the most complicated and kludged architectures ever).
... then for the ISA, use an explicitly parallel design that puts a massive burden of work on compiler writers (and also those writing assembly for the kernel and libraries).

Actually, that feature was dropped completely, and is now handled entirely in the IA32 Execution Layer, which is software. And, from experience, it is never, ever used.

I know. If you read it again, you'll see I was giving my take on the design process for the Itanium architecture . The process of designing Itanium (or IA64 as it was called back then) happened a long time before Itanium2 chips (i.e. implementation ) arrived, and back then, they decided to have full IA-32 compatibility on chip.

kramlq wrote: ... they decided to have full IA-32 compatibility on chip.

Presumably the folks at Intel believe you can never have too much backward compatibility.