cvs commit: fptools/ghc/compiler/ghci ByteCodeFFI.lhs ByteCodeGen.lhs ByteCodeInstr.lhs ByteCodeLink.lhs fptools/ghc/compiler/typecheck TcForeign.lhs

[Julian Seward]

sewardj     2001/08/02 10:15:17 PDT

  Modified files:
    ghc/compiler/ghci    ByteCodeGen.lhs ByteCodeInstr.lhs 
                         ByteCodeLink.lhs 
    ghc/compiler/typecheck TcForeign.lhs 
  Added files:
    ghc/compiler/ghci    ByteCodeFFI.lhs 
  Log:
  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.
  
  Revision  Changes    Path
  1.50      +180 -41   fptools/ghc/compiler/ghci/ByteCodeGen.lhs
  1.5       +24 -7     fptools/ghc/compiler/ghci/ByteCodeInstr.lhs
  1.18      +17 -8     fptools/ghc/compiler/ghci/ByteCodeLink.lhs
  1.37      +9 -2      fptools/ghc/compiler/typecheck/TcForeign.lhs