|
From: Nicholas N. <nj...@ca...> - 2004-02-24 22:54:56
|
Hi, I was just leafing through the Intel docs for their new AMD64, er, IA32e processors: www.intel.com/technology/64bitextensions/index.htm?iid=techtrends+spotlight_64bit A couple of things caught my eye: - we now have explicit rip-relative addressing (section 1.4.2.6). Interesting, although I'm not sure what it will be useful for. - segment registers are being demoted. In 64-bit mode, they are "generally (but not completely) disabled". Roughly speaking, it seems only %fs and %gs do something in 64-bit mode, although there are various caveats. See section 1.6.4. N |
|
From: Jeremy F. <je...@go...> - 2004-02-25 00:18:03
|
On Tue, 2004-02-24 at 14:53, Nicholas Nethercote wrote: > - we now have explicit rip-relative addressing (section 1.4.2.6). > Interesting, although I'm not sure what it will be useful for. I don't think we can use it too much, but it might be useful. More interesting is that it means that client code won't have to play tricks with call to get the EIP into a register, so we can generate better code for that (like we do when we recognize "call 1f; 1:"). > - segment registers are being demoted. In 64-bit mode, they are > "generally (but not completely) disabled". Roughly speaking, it seems > only %fs and %gs do something in 64-bit mode, although there are various > caveats. See section 1.6.4. Yes, that's a bit irritating; we'll have to generate explicit bounds checking to make sure client pointers are within range. I'm thinking that we'll probably end up putting Valgrind code down low (<256Mbytes), and restricting the client address space to 256M upwards (I think this is OK; the standard load address is pretty high). We could then use "test" to make sure the appropriate bits in the address are non-zero. The other good thing is that we have more registers to play with - especially useful if we can run 32-bit code while in 64-bit mode, so we have more machine registers than VCPU registers. No spilling! J |