Everything Else

Intel's Itanium, once destined to replace x86 processors in PCs, hits end of line .

Well, I guess we saw that one coming for a while.

The writing has been on the wall for a long while. It's interesting to see how many times Intel has tried to introduce new architectures to complement or replace x86, and each time they've failed badly.

Still, Itanium will unfortunately be remembered for killing off Alpha, MIPS and PA-RISC as so many jumped onto the Itanium bandwaggon, so Intel will still feel that good came of it.

It didn't kill off MIPS, just HPC MIPS, since MIPS is still used in network and embedded applications.

I don't mourn MIPS, it's a dirty architecture with nasty register spill tendency, similar to SuperH.

Itanium has its own problems - strictly in-order, difficult to optimize without the right compilers, code density issues.

John C. Dvorak should be pleased.

RIP.

HP was looking to replace its aging PA-RISC with a modern 64-bit server chip that could run legacy OSes like Unix.

always a pleasure to read articles written by n00bs

Raion-Fox wrote: I don't mourn MIPS, it's a dirty architecture with nasty register spill tendency, similar to SuperH.

Well, MIPS is not a dirty architecture, why dirty? it's a clean and interesting architecture, from the first R2K to the last MIPS64, and the last MIPS32R2 fixes a lot of things, making assembly more friendly.

I have been programming assembly MIPS for years (now you can do it with Microchip PIC32), what I don't really like is .. the MIPS-cache! Cache is still terrible on MIPS. Even worse than on PowerPC.

The nasty register spill tendency is natural on RISC, and as every RISC, MIPS suffers of being bloated in code density. It's the price to pay for a simple decode unit. But the internal design along the datapath is simple enough to have fun on your own HDL implementation. Can't you do it so simple with other RISC.

p.s.
never programmed SuperHitachi, but I have an old SH3 chip in my old GPS. It comes with an external flash, SOIC chip, it can be unsoldered and wired out to a ROM emulator. There is also a serial port, and 512Kbyte of RAM.

It sounds funny. Just need to find the occasion (time) to hack it

Raion-Fox wrote: It didn't kill off MIPS, just HPC MIPS, since MIPS is still used in network and embedded applications.

I don't mourn MIPS, it's a dirty architecture with nasty register spill tendency, similar to SuperH.

Itanium has its own problems - strictly in-order, difficult to optimize without the right compilers, code density issues.

I wholeheartedly disagree. MIPS was a great CPU to write kernel level code for - you could be executing C code from a 1:1 mapped virtual window within a few hundred lines of boot assembly code. Virtual memory and the TLB were quite straightforward, and the CP0 model of kernel support features was quite clean. The only thing I didn't like was that if you needed to write code across many vendors MIPS processors, there was little on chip support for explicit feature detection. The MIPS32/MIPS64 series addressed this main shortcoming.

I never worked on compilers, but did plenty of disassembly and debugging, and never thought code generated was too bad either. I studied many processor architectures over the years, and always though the "features" like visible register windows on SPARC (and Itanium to an extent) were overkill and had the potential to add inefficiency to critical paths.

kramlq wrote: The only thing I didn't like was that if you needed to write code across many vendors MIPS processors, there was little on chip support for explicit feature detection.

Do you remember IDT-MIPS (R3K)? I remember (back to 90s) a lot of assembly code just to identify their CPUs in order to handle them properly. Cache was terrible also because of different behaviors on different vendor/id. So, it was a lot of code, full of #ifdef and switch cases

kramlq wrote: I wholeheartedly disagree. MIPS was a great CPU to write kernel level code for - you could be executing C code from a 1:1 mapped virtual window within a few hundred lines of boot assembly code. Virtual memory and the TLB were quite straightforward, and the CP0 model of kernel support features was quite clean. The only thing I didn't like was that if you needed to write code across many vendors MIPS processors, there was little on chip support for explicit feature detection. The MIPS32/MIPS64 series addressed this main shortcoming.

I never worked on compilers, but did plenty of disassembly and debugging, and never thought code generated was too bad either. I studied many processor architectures over the years, and always though the "features" like visible register windows on SPARC (and Itanium to an extent) were overkill and had the potential to add inefficiency to critical paths.

I'll admit, I have a soft spot for Alpha's setup. I'd love for a modern Alpha-style (Shenwei, we want modern Alpha systems on Taobao, y'hear?) ISA, but honestly POWER has gotten mature enough that the little ASM I have to do is pretty easy. I'll agree, SPARC is pretty awful in terms of design, but at least Fujitsu has made it pretty performant!

The MIPS code I've dealt with is dirty, the register spill problem was worse than other RISCs, and at the end of the day, the ISA never lived up to its potential.

ARM64 is pretty good if we see high performance on the same pricepoint as Intel. I don't mind x64, tbh, but AMD's offerings suck ass, so Intel is the only player I can take seriously, and we know how monocultures are.

I'm surprised it lasted this long (granted HP was basically dragging Intel by its hair through chip generations at the end).

I suppose we'll see Xeon Superdomes soon.

ClassicHasClass wrote: I suppose we'll see Xeon Superdomes soon.

Running Linux, no doubt either. HP-UX is kinda cool, and its going to be sad to see it go.

Raion-Fox wrote: The MIPS code I've dealt with is dirty, the register spill problem was worse than other RISCs

It sounds a problem specific to the compiler you used (gcc? with silly flags?)

Raion-Fox wrote: and at the end of the day, the ISA never lived up to its potential.

The MIPS's ISA makes easier to introduce your own defined COP (COP0 is reserved as Exception, COP1 is reserved as FPU) than on other RISCs.

Y888099 wrote: The MIPS's ISA makes easier to introduce your own defined COP (COP0 is reserved as Exception, COP1 is reserved as FPU) than on other RISCs.

This capability is used by the Tensilica cores to add reconfigurable logic to the ISA. Much more elegant than anything Altera or Xilinx has come out with in their SoCs.

The Motorola 88K also had a block of coprocessor instructions, but that architecture was never used nearly as widely as MIPS (being fabless is a big advantage for not competing with your customers in ISA licensing)

ClassicHasClass wrote: I'm surprised it lasted this long (granted HP was basically dragging Intel by its hair through chip generations at the end).

I suppose we'll see Xeon Superdomes soon.

Superdome X machines are already available.

robespierre wrote: Much more elegant than anything Altera or Xilinx has come out with in their SoCs.

Indeed!

p.s.
different context, but on FPGa+SoC hybrid I have to say: I don't like AMBA!
(it's not CPU's ISA, it's a connection bus, mainly used with ARM, in fpga coSoC solutions)
It goes too damn complex

GL1zdA wrote:

ClassicHasClass wrote: I'm surprised it lasted this long (granted HP was basically dragging Intel by its hair through chip generations at the end).

I suppose we'll see Xeon Superdomes soon.

Superdome X machines are already available.

What do those run? Surely not HP-UX (I haven't kept up with HP's product line after PA-RISC got axed, though).

They run Linux, sadly. RHEL IIRC. I would be very surprised if HP-UX makes it to x64

indeed very unlikely. even more so since they're now offering linux containers for hpux.
nice however that intel announced optane for hpux nevertheless

ClassicHasClass wrote:

GL1zdA wrote: Superdome X machines are already available.

What do those run? Surely not HP-UX (I haven't kept up with HP's product line after PA-RISC got axed, though).

HP officially supports Windows Server, RHEL, SLES, and vSphere on Superdome X.
http://h20564.www2.hpe.com/hpsc/doc/pub ... =c05333408