Well since you could potentially create classes through
Object.factory at runtime the code for unused classes will be
compiled into the binary anyways this is even if you never use
Object.factory directly in the code. I am not 100% sure but i
think the main problem is ModuleInfo that keeps everything
alive. And it keeps classes alive since they could be used by
object factory. It also keeps other information like unittests
locations and static constructors.
Well then. I hope that changes for the better. It should be
able to see that I'm not using the object factory or anything.
Then again, the language has certain exceptions it is capable of
throwing, which themselves are objects. I wonder if the garbage
collector must retain the ability to throw an exception and thus
retain the need of classes.
What tools and parameters did you use to obtain that
dissassembly?
I used the visual studio dissassembly window.
Thanks for the tip. Always nice to know about an assortment of
tools.
Can you tell whether a 32-bit load was used?
_Dmain:
push RBP
mov RBP,RSP
mov EAX,0Ah
pop RBP
ret
---- mov EAX,0AH
This is a 32-bit instruction. 64-bit instructions use the RAX
register.
It's actually the same register but it's just named diffrently
depending if you use the full 64-bits or just the lower
32-bits. It will automatically zero extend it.
See https://github.com/yasm/yasm/wiki/AMD64 for a simple intro
into x64.
Excellent! We successfully proved that it does use 32-bit load
instructions in a 64-bit binary, both for Linux and Windows!
Good to know about RAX/EAX, thanks - I was only familiar with ARM
assembly.
There is CISC in this world, apparently.
For the full experience, I disassembled the binary from the
following:
/*
I always do int mains - except when trying to simplify assembly
as much as possible for educating myself about instructions the
compiler outputs. I never even ran this binary, I only made it to
look at its disassembly.
*/
void main()
{
longLoadTest();
}
long longLoadTest()
{
long loadMe = 10;
return loadMe;
}
Sure enough, I saw something very similar to what you pointed
out, but using the RAX name instead of the EAX name (for
longLoadTest's return).
Thank you very much,
Jake
