Linked by Nicholas Blachford on Sun 10th Feb 2002 17:37 UTC
Editorial "This will end up being one of the world's worst investments, I'm afraid," - David House, former Intel chief of corporate strategy said in the early 1990s. I've been fasinated by microprocessors for years and have been following the Merced debacle since back in 1994 when HP and Intel announced they were getting together to make some amazing new technology.
Permalink for comment
To read all comments associated with this story, please click here.
x86 isnt really RISC
by Raptor-32 on Mon 11th Feb 2002 00:27 UTC

Before i get to that RISC comment...
"I'd imagine you could run 64 bit programs on the 32 bit XP though."

I would imagine the opposite. The *hammer processors are able to execute legacy (there is no sweeter word to use when describing x86) x86 code by behaving exactly like it, in 32bit mode. In x86-64's 32bit i dont think you have access to the other registers, which makes it _exactly_ like Protected Mode on 386-P4/Athlons. This means you would not be able to execute 64bit code (in 32bit mode) without some type of emulation. And if that code is for IA-64, you are just plain screwed on the *hammer because i'm 99.9% sure they are not binary compatible chips.

Now about RISC and x86. The 386 till even the newer chips like Athlons and P4s have always been considered CISC processors. I'm not sure about intel chips, but i know that AMD made an effort to reduce the number of instructions. The way they did that was by having a RISC-like set of instructions, and then all the others. If an app could get away by just using the "RISC" set it would take less cycles. A non-"RISC" instruction would be punished.

dec ecx
jnz label

would be the "RISC" translation of:
loop label