[MLton] PIC in amd64 assembly

[Wesley W. Terpstra]

I have been unsuccessful at modifying the amd64 codegen, but I know what the
assembly should look like now.

For position dependent code (PDC) the current codegen does everything
correct. For position independent code (PIC), it matters whether or not the
object being accessed is linked into the same .so or whether it is provided
by another library. This distinction doesn't matter in the PDC case.

PDC Address: movq $name, %rax
PDC Function Call: call name
PDC Data Access: movq name, %rax

PIC Internal Address: leaq name(%rip),%rax
PIC Internal Function Call: call name
PIC Internal Data Access: movq name(%rip),%rax

PIC External Address: movq name at GOTPCREL(%rip),%rax
PIC External Function Call: call name at PLT
PIC External Data Access: movq name at GOTPCREL(%rip),%rax; movq (%rax),%rax

Interestingly, gcc uses movq name(%rip),%eax even for PDC data access.
Perhaps it's faster?

So the amd64 codegen should use the PIC Internal instructions when compiled
to a library.

Since all system calls needed by the basis library are made via the runtime,
which is linked with the amd64 codegen output, a program not using user FFI
will never need the PIC External instructions. If the user uses the FFI to
import his own functions and variables, there should also be no problem
because those are linked together into the output library.

The only case were PIC External would be needed is if the user writes an
SML-only wrapper for an existing library and an SML project using this
wrapper gets compiled into a library itself. If the wrapper proxied all it's
calls via C like the basis, there would again be no problem.

To solve this one corner case, it would suffice to add an "external" keyword
to _import.


PS. It's a shame that the x86/amd64 codegens are so difficult to understand
(lack of documentation, too much indirection, and no way to inspect
intermediate results). This has prevented me from getting the win64 calling
convention to work and also from making the simple instruction substitution
I've outlined here. I don't know what to do about this problem, but I do
think it is a barrier to contributing to MLton.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20080726/bb97adeb/attachment.html