[project @ 2001-08-02 17:15:16 by sewardj]
authorsewardj <unknown>
Thu, 2 Aug 2001 17:15:17 +0000 (17:15 +0000)
committersewardj <unknown>
Thu, 2 Aug 2001 17:15:17 +0000 (17:15 +0000)
commit54afa8cb01aa038f64fb9ab943d92a9638394e34
tree5f3778ef3f46ea33c5b68908fac4a79425a64a97
parenta36219092d7d700125f7b4952d969e1fbacb08d1
[project @ 2001-08-02 17:15:16 by sewardj]
Haskell-side support for FFI (foreign import only).

Since doing the FFI necessarily involves gruesome
architecture-specific knowledge about calling conventions, I have
chosen to put this knowledge in Haskell-land, in ByteCodeFFI.

The general idea is: to do a ccall, the interpreter accumulates the
args R to L on the stack, as is the normal case for tail-calls.
However, it then calls a piece of machine code created by ByteCodeFFI
and which is specific to this call site.  This glue code copies args
off the Haskell stack, calls the target function, and places the
result back into a dummy placeholder created on the Haskell stack
prior to the call.  The interpreter then SLIDEs and RETURNs in the
normal way.

The magic glue code copies args off the Haskell stack and pushes them
directly on the C stack (x86) and/or into regs (sparc et al).  Because
the code is made up specifically for this call site, it can do all
that non-interpretively.  The address (of the C fn to call) is
presented as just another tagged Addr# on the Haskell stack.  This
makes f-i-dynamic trivial since the first arg is the said Addr#.

Presently ByteCodeFFI only knows how to generate x86 code sequences.
ghc/compiler/ghci/ByteCodeFFI.lhs [new file with mode: 0644]
ghc/compiler/ghci/ByteCodeGen.lhs
ghc/compiler/ghci/ByteCodeInstr.lhs
ghc/compiler/ghci/ByteCodeLink.lhs
ghc/compiler/typecheck/TcForeign.lhs