5 ms·

That's no guarantee it would succeed though - AMD64 also cleaned up a number of warts on the x86 architecture, like more registers. While I suspect the Intel e

by kimixa 1y ago

That's no guarantee it would succeed though - AMD64 also cleaned up a number of warts on the x86 architecture, like more registers. While I suspect the Intel equivalent would do similar things, simply from being a big enough break it's an obvious thing to do, there's no guarantee it wouldn't be worse than AMD64. But I guess it could also be "better" from a retrospective perspective. And also remember at the time the Pentium 4 was very much struggling to get the advertised performance. One could argue that one of the major reasons that the AMD64 ISA took off is that the devices that first supported it were (generally) superior even in 32-bit mode. EDIT: And I'm surprised it got as far as silicon. AMD64 was "announced" and the spec released before the pentium 4 was even released, over 3 years before the first AMD implementations could be purchased. I guess Intel thought they didn't "need" to be public about it? And the AMD64 extensions cost a rather non-trivial amount of silicon and engineering effort to implement - did the plan for Itanium change late enough in the P4 design that it couldn't be removed? Or perhaps this all implies it was a much less far-reaching (And so less costly) design?

chasil 1y ago
The times that I have used "gcc -S" on my code, I have never seen the additional registers used. I understand that r8-r15 require a REX prefix, which is hostile to code density. I've never done it with -O2. Maybe that would surprise me.
- astrange 1y ago
  You should be able to see it. REX prefixes cost a lot less than register spills do. If you mean literally `gcc -S`, -O0 is worse than not optimized and basically keeps everything in memory to make it easier to debug. -Os is the one with readable sensible asm.
  - chasil 1y ago
    Thanks, I'll give it a try.
- o11c 1y ago
  Obviously it depends on how many live variables there are at any point. A lot of nasty loops have relatively few non-memory operands involved, especially without inlining (though even without inlining, the ability to control ABI-mandated spills better will help). But it's guaranteed to use `r8` and `r9` for for a function that takes 5 and 6 integer arguments (including unpacked 128-bit structs as 2 arguments), or 3 and 4 arguments (not sure about unpacking) for Microsoft. And `r10` is used if you make a system call on Linux.
- wat10000 1y ago
  I don't have gcc handy, but this bit of code pretty easily gets clang to use several of them: int f(int **x) { int *a = x[0]; int *b = x[1]; int *c = x[2]; int *d = x[3]; puts("hello"); return *a + *b + *c + *d; }
ghaff 1y ago
As someone who followed IA64/Itanium pretty closely, it's still not clear to me the degree to which Intel (or at least groups within Intel) thought IA64 was a genuinely better approach and the degree to which Intel (or at least groups within Intel) simply wanted to get out from existing cross-licensing deals with AMD and others. There were certainly also existing constraints imposed by partnerships, notably with Microsoft.
- ajross 1y ago
  Both are likely true. It's easy to wave it away in hindsight, but there was genuine energy and excitement about the architecture in its early days. And while the first chips were late and on behind-the-cutting-edge processes they were actually very performant (FPU numbers were world-beating, even -- parallel VLIW dispatch really helped here). Lots of people loved Itanium and wanted to see it succeed. But surely the business folks had their own ideas too.
  - kimixa 1y ago
    Yes - VLIW seems to lend itself to computation-heavy code, used to this day in many DSP (and arguably GPU, or at least "influences" many GPU) architectures.
  - ccgreg 1y ago
    > they were actually very performant Insanely expensive for that performance. I was the architect of HPC clusters in that era, and Itanic never made it to the top for price per performance. Also, having lived through the software stack issues with the first beta chips of Itanic and AMD64 (and MIPS64, but who's counting), AMD64 was way way more stable than the others.
  - pjmlp 1y ago
    I am one of those people, and I think that it only failed because AMD had the possible to turn the tables on Intel, to use the article's title. Without AMD64, I firmly believe eventually Itanium would have been the new world no matter what. We see this all the time, technology that could be great but fails due to not being pushed hard enough, and other similar technology that does indeed succeed because the creators are willing push it at a loss during several years until it finally becomes the new way.
tuyiown 1y ago
> first supported it were (generally) superior even in 32-bit mode. They also were affordable dual cores, it wasn't the norm at all at the time.
p_l 1y ago
Pentium 4 was widely speculated of being able to run 64bit at the time of AMD64 delivering, but at half the speed. Essentially, while decoding a 64bit variant of x86 ISA might have been fused off, there was a very visible part that was common anyway, and that was available ALUs on NetBurst platform - which IIRC were 2x 32bit ALUs for integer ops. So you either issue micro-op to both to "chain" them together, or run every 64bit calculation in multiple steps.
- eigenform 1y ago
  Yeah, they wrote a paper about the ALUs too, see: https://ctho.org/toread/forclass/18-722/logicfamilies/Deleganes05.pdf https://ctho.org/toread/forclass/18-722/logicfamilies/Delega... > There are two distinct 32-bit FCLK execution data paths staggered by one clock to implement 64-bit operations. If it weren't fused off, they probably would've supported 64-bit ops with an additional cycle of latency?
  - p_l 1y ago
    At least one cycle, yes, but generally it would make it possible to deliver. AFAIK it also became crucial part of how intel could deliver "EM64T" chips fast enough - only to forget to upgrade memory subsystem which is why first generation can't run Windows (they retained 36bit physical addressing from PAE when AMD64 mandates minimum of 40, and Windows managed to trigger an issue on that)
kouteiheika 1y ago
> That's no guarantee it would succeed though - AMD64 also cleaned up a number of warts on the x86 architecture, like more registers. As someone who works with AMD64 assembly very often - they didn't really clean it up all that much. Instruction encoding is still horrible, you still have a bunch of useless instructions even in 64-bit mode which waste valuable encoding space, you still have a bunch of instructions which hardcode registers for no good reason (e.g. the shift instructions have a hardcoded rcx). The list goes on. They pretty much did almost the minimal amount of work to make it 64-bit, but didn't actually go very far when it comes to making it a clean 64-bit ISA. I'd love to see what Intel came up, but I'd be surprised if they did a worse job.

by kimixa 1y ago

chasil 1y ago

The times that I have used "gcc -S" on my code, I have never seen the additional registers used. I understand that r8-r15 require a REX prefix, which is hostile to code density. I've never done it with -O2. Maybe that would surprise me.

astrange 1y ago
You should be able to see it. REX prefixes cost a lot less than register spills do. If you mean literally `gcc -S`, -O0 is worse than not optimized and basically keeps everything in memory to make it easier to debug. -Os is the one with readable sensible asm.
- chasil 1y ago
  Thanks, I'll give it a try.
o11c 1y ago
Obviously it depends on how many live variables there are at any point. A lot of nasty loops have relatively few non-memory operands involved, especially without inlining (though even without inlining, the ability to control ABI-mandated spills better will help). But it's guaranteed to use `r8` and `r9` for for a function that takes 5 and 6 integer arguments (including unpacked 128-bit structs as 2 arguments), or 3 and 4 arguments (not sure about unpacking) for Microsoft. And `r10` is used if you make a system call on Linux.
wat10000 1y ago
I don't have gcc handy, but this bit of code pretty easily gets clang to use several of them: int f(int **x) { int *a = x[0]; int *b = x[1]; int *c = x[2]; int *d = x[3]; puts("hello"); return *a + *b + *c + *d; }

ghaff 1y ago

As someone who followed IA64/Itanium pretty closely, it's still not clear to me the degree to which Intel (or at least groups within Intel) thought IA64 was a genuinely better approach and the degree to which Intel (or at least groups within Intel) simply wanted to get out from existing cross-licensing deals with AMD and others. There were certainly also existing constraints imposed by partnerships, notably with Microsoft.

ajross 1y ago
Both are likely true. It's easy to wave it away in hindsight, but there was genuine energy and excitement about the architecture in its early days. And while the first chips were late and on behind-the-cutting-edge processes they were actually very performant (FPU numbers were world-beating, even -- parallel VLIW dispatch really helped here). Lots of people loved Itanium and wanted to see it succeed. But surely the business folks had their own ideas too.
- kimixa 1y ago
  Yes - VLIW seems to lend itself to computation-heavy code, used to this day in many DSP (and arguably GPU, or at least "influences" many GPU) architectures.
- ccgreg 1y ago
  > they were actually very performant Insanely expensive for that performance. I was the architect of HPC clusters in that era, and Itanic never made it to the top for price per performance. Also, having lived through the software stack issues with the first beta chips of Itanic and AMD64 (and MIPS64, but who's counting), AMD64 was way way more stable than the others.
- pjmlp 1y ago
  I am one of those people, and I think that it only failed because AMD had the possible to turn the tables on Intel, to use the article's title. Without AMD64, I firmly believe eventually Itanium would have been the new world no matter what. We see this all the time, technology that could be great but fails due to not being pushed hard enough, and other similar technology that does indeed succeed because the creators are willing push it at a loss during several years until it finally becomes the new way.

tuyiown 1y ago

> first supported it were (generally) superior even in 32-bit mode. They also were affordable dual cores, it wasn't the norm at all at the time.

p_l 1y ago

Pentium 4 was widely speculated of being able to run 64bit at the time of AMD64 delivering, but at half the speed. Essentially, while decoding a 64bit variant of x86 ISA might have been fused off, there was a very visible part that was common anyway, and that was available ALUs on NetBurst platform - which IIRC were 2x 32bit ALUs for integer ops. So you either issue micro-op to both to "chain" them together, or run every 64bit calculation in multiple steps.

eigenform 1y ago
Yeah, they wrote a paper about the ALUs too, see: https://ctho.org/toread/forclass/18-722/logicfamilies/Deleganes05.pdf https://ctho.org/toread/forclass/18-722/logicfamilies/Delega... > There are two distinct 32-bit FCLK execution data paths staggered by one clock to implement 64-bit operations. If it weren't fused off, they probably would've supported 64-bit ops with an additional cycle of latency?
- p_l 1y ago
  At least one cycle, yes, but generally it would make it possible to deliver. AFAIK it also became crucial part of how intel could deliver "EM64T" chips fast enough - only to forget to upgrade memory subsystem which is why first generation can't run Windows (they retained 36bit physical addressing from PAE when AMD64 mandates minimum of 40, and Windows managed to trigger an issue on that)

kouteiheika 1y ago

> That's no guarantee it would succeed though - AMD64 also cleaned up a number of warts on the x86 architecture, like more registers. As someone who works with AMD64 assembly very often - they didn't really clean it up all that much. Instruction encoding is still horrible, you still have a bunch of useless instructions even in 64-bit mode which waste valuable encoding space, you still have a bunch of instructions which hardcode registers for no good reason (e.g. the shift instructions have a hardcoded rcx). The list goes on. They pretty much did almost the minimal amount of work to make it 64-bit, but didn't actually go very far when it comes to making it a clean 64-bit ISA. I'd love to see what Intel came up, but I'd be surprised if they did a worse job.