According to this
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff561499(v=vs.85).aspx)
32-bit registers are automatically zero extended on x64
architecture while 16-bit and 8-bit registers are not.
"Operations that output to a 32-bit subregister are automatically
zero-extended to the entire 64-bit register. Operations that
output to 8-bit or 16-bit subregisters are not zero-extended
(this is compatible x86 behavior)."
Hmmm. Sounds like 32-bit compatibilty mode stuff. I'm concerned
that a 64-bit binary outputted by dmd would contain no 32-bit
mode instructions, therefore, although a load instuction exists
that would automatically zero-pad, I'm not sure dmd uses it.
The file command (in Linux) tells me that my outputted binary is
a 64-bit binary, not a 32-bit/64-bit hybrid binary. Then again,
maybe it's not programmed to check for hybrid binaries and just
says "64-bit" if it is 64-bit overall.
To try and check for myself, I ran the binary through objdump. I
found the "LEA"
instruction. I don't know if it's a 32-bit load instruction or a
64-bit load instruction.
But _wow_ was I shocked at how many lines of assembly were
generated!
I tried the following:
int main()
{
int loadMe = void;
return loadMe;
}
And got 86,421 lines of assembly!! I expected a load instruction
to load whatever was at loadMe's location into r0 (the return
register) and not much else. Maybe 10 lines - tops - due to
compiler fluffiness. I got about 8,641 times that - over 3 more
orders of magnatude. What is going on here?
I guess the exact type of variables should remain up in the air
until the whole thing is implemented and tested using different
types?
Yes very much so.
Ah ha. Thanks for the tip. I see that this makes one's effort to
lay down an API/library/module specification a little
interesting. Can't publish your chickens until they hatch.
