4 ms·

> x86 is not particularly nasty x86's terrible reputation is well deserved. x86-64 fixes a number of problems, but for most of x86's lifetime we've had to live

> x86 is not particularly nasty x86's terrible reputation is well deserved. x86-64 fixes a number of problems, but for most of x86's lifetime we've had to live with 8 registers and the lack of IP-relative addressing... Let's not forget how awful x87 floating point was, either!

protomyth 10y ago
I was curious why for the Xeon Phi / Larrabee they didn't drop all the 32-bit instructions since you would seriously have to recompile all your code anyway.
- PhantomGremlin 10y ago
  I'm not familiar with Larrabee. But it looks like it's x86 plus SIMD. If so, then Intel probably has literally 1000's of man-years of validation suites for x86. If you remove some of the x86 instructions, how much of that test code do you break? The Larrabee designers probably wanted to focus on the SIMD and on putting bunches of cores onto a single die. They didn't want to reimplement (or even fuss with) the x86 part. That's not what they were interested in. Leaving x86 alone means the chip runs Windows, Linux, etc w/o any further effort. Or does it, like I said I don't know the architecture? What do you gain by breaking that? It's probably a very small part of the silicon area anyway.
userbinator 10y ago
IMHO "amd64" (as it should really be called, since AMD came up with it) could've been a lot more orthogonal, more like the 16 to 32-bit extension that came with the 386. In practice, it's really 8 registers "and 256 bytes more" since the area around the stack pointer will be cached and accesses there can be just as fast. On the other hand, one of the things I like about x87 is that it's extremely dense because it's stack-based and RPN-ish. Here's 256 bytes of x87 awesomeness: http://www.pouet.net/prod.php?which=53816 http://www.pouet.net/prod.php?which=53816
viraptor 10y ago
I'm confused why would IP-relative addressing be useful. Have you got some interesting examples?
- cnvogel 10y ago
  For any shared object loaded on an unknown address it makes it trivially easy to load data also in that library.
- gsg 10y ago
  It's the basis of efficient relocations in position independent code, which is now very common. PIC can be emitted on older x86 machines without RIP-relative addressing, but the code is larger and slower. As an example, consider -m32 gcc output for the C program int x; int getx() { return x; } With no PIC: getx: movl x, %eax ret With PIC: getx: call __x86.get_pc_thunk.cx addl $_GLOBAL_OFFSET_TABLE_, %ecx movl x@GOT(%ecx), %eax movl (%eax), %eax ret And with -m64, which emits PIC and uses x86-64s RIP-relative addressing: getx: movl x(%rip), %eax ret Hopefully that makes the motivation clear.
  - viraptor 10y ago
    Thanks, I've seen it so many times it seems I developed (%rip) blindness :) Of course it's useful this way.

protomyth 10y ago

I was curious why for the Xeon Phi / Larrabee they didn't drop all the 32-bit instructions since you would seriously have to recompile all your code anyway.

PhantomGremlin 10y ago
I'm not familiar with Larrabee. But it looks like it's x86 plus SIMD. If so, then Intel probably has literally 1000's of man-years of validation suites for x86. If you remove some of the x86 instructions, how much of that test code do you break? The Larrabee designers probably wanted to focus on the SIMD and on putting bunches of cores onto a single die. They didn't want to reimplement (or even fuss with) the x86 part. That's not what they were interested in. Leaving x86 alone means the chip runs Windows, Linux, etc w/o any further effort. Or does it, like I said I don't know the architecture? What do you gain by breaking that? It's probably a very small part of the silicon area anyway.

userbinator 10y ago

IMHO "amd64" (as it should really be called, since AMD came up with it) could've been a lot more orthogonal, more like the 16 to 32-bit extension that came with the 386. In practice, it's really 8 registers "and 256 bytes more" since the area around the stack pointer will be cached and accesses there can be just as fast. On the other hand, one of the things I like about x87 is that it's extremely dense because it's stack-based and RPN-ish. Here's 256 bytes of x87 awesomeness: http://www.pouet.net/prod.php?which=53816 http://www.pouet.net/prod.php?which=53816

viraptor 10y ago

I'm confused why would IP-relative addressing be useful. Have you got some interesting examples?

cnvogel 10y ago
For any shared object loaded on an unknown address it makes it trivially easy to load data also in that library.
gsg 10y ago
It's the basis of efficient relocations in position independent code, which is now very common. PIC can be emitted on older x86 machines without RIP-relative addressing, but the code is larger and slower. As an example, consider -m32 gcc output for the C program int x; int getx() { return x; } With no PIC: getx: movl x, %eax ret With PIC: getx: call __x86.get_pc_thunk.cx addl $_GLOBAL_OFFSET_TABLE_, %ecx movl x@GOT(%ecx), %eax movl (%eax), %eax ret And with -m64, which emits PIC and uses x86-64s RIP-relative addressing: getx: movl x(%rip), %eax ret Hopefully that makes the motivation clear.
- viraptor 10y ago
  Thanks, I've seen it so many times it seems I developed (%rip) blindness :) Of course it's useful this way.