--On Monday, October 24, 2005 11:26 PM -0500 Jonathan Berry
<berryja@xxxxxxxxx> wrote:
Perhaps this is what he meant. Though, let's not forget a DDR memory
interface is 64- or 128-bits wide. I don't think it will take any
longer to get a 64-bit pointer than a 32-bit one. Right? You get at
least 64-bits per (FSB) cycle. I still go back to it was an old quote
and maybe doesn't apply anymore. I cannot see any slight memory
overhead outweighing the other benefits of x86_64.
The issue isn't the bus width but the total amount of instruction stream to
be fetched. Let's say I issue an instruction that moves a byte from one
absolute address to another. (I don't know if such an instruction exists,
but this is just a theoretical example.) In 32 bits, this has to be at
least 9 bytes long, one byte for the instruction and 4 for each of the
pointers. The 64-bit equivalent is 1 + 8 + 8 = 17 bytes long.
Fortunately, this kind of instruction is unlikely to be common. There
should be many processing instructions between pointer loads.
Does the AMD64 instruction set support 16- and 32-bit offset references for
stack-based operations (eg. [BP + offset])? That's the more common case for
referencing local variables.
Any kind of indirection will be more expensive, including virtual C++
method calls and general C++ object references, since one has to load a
pointer before offsetting to data or the function to call.
OTOH, the greater number of registers means you don't have to "spill" one
pointer to load another, so the actual cost of the longer pointers might be
sufficiently mitigated by not needing to reload them as often.
