Document trampoline instruction

[mn200]

At meeting on 2 September 2014, we agreed that an LLVM-style trampoline primitive would probably be a good idea. Because

• the abstraction will allow generate of good machine code for varying architectures
• it may be necessary to turn fnptr * environment into a single fnptr for the sake of FFI calls

[wks]

The proposed .expose top-level def and the @uvm.native.expose instruction serve similar functions by secretly hiding one argument (the "cookie") into the generated "exposed function" (probably implies a trampoline, too).

The current "function exposing" is inspired by LuaJIT. Its implementation creates a global entity (such as an entry in a jump table with a MOV %rax, cookie before JMP func, or looking at the PC pushed on the stack, depending on the architecture) rather than fills a user-allocated region of memory with code. It is not clear which approach is more efficient, the LuaJIT-style jump table, or the LLVM-style trampoline.

Mu does not model the "cookie" as the first argument, but as a value obtained via a special instruction @uvm.native.getcookie. This reduced the burden of the trampoline by not shuffling the registers, but needs to store the cookie somewhere well-known (a spare register, or some thread-local memory location).