1. 07 Aug, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-08-07 09:16:15 by sewardj] · 0632467a
      sewardj authored
      This buffer is for notes you don't want to save, and for Lisp evaluation.
      If you want to create a file, visit that file with C-x C-f,
      then enter the text in that file's own buffer.
      Interpreter FFI improvements:
      * Support f-i dynamic.
      * Correctly handle fns which don't return anything.
      * Support x86 stdcall call-conv.
      Clean-up of FFI-related code in ByteCodeGen.lhs.
  2. 03 Aug, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-08-03 15:11:10 by sewardj] · daf8e15b
      sewardj authored
      Fix enough bugs/incompletenesses so that foreign import (static) works
      fairly well on x86.
      Still ToDo:
      * f-i dynamic
      * save/restore GC/thread context around calls
      * stdcall support
      * pass/return of 64-bit integral quantities on x86
      * sparc implementation
  3. 02 Aug, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-08-02 17:15:16 by sewardj] · 54afa8cb
      sewardj authored
      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.
  4. 25 Jun, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-06-25 08:09:57 by simonpj] · d069cec2
      simonpj authored
      	Squash newtypes
      This commit squashes newtypes and their coerces, from the typechecker
      onwards.  The original idea was that the coerces would not get in the
      way of optimising transformations, but despite much effort they continue
      to do so.   There's no very good reason to retain newtype information
      beyond the typechecker, so now we don't.
      Main points:
      * The post-typechecker suite of Type-manipulating functions is in
      types/Type.lhs, as before.   But now there's a new suite in types/TcType.lhs.
      The difference is that in the former, newtype are transparent, while in
      the latter they are opaque.  The typechecker should only import TcType,
      not Type.
      * The operations in TcType are all non-monadic, and most of them start with
      "tc" (e.g. tcSplitTyConApp).  All the monadic operations (used exclusively
      by the typechecker) are in a new module, typecheck/TcMType.lhs
      * I've grouped newtypes with predicate types, thus:
      	data Type = TyVarTy Tyvar | ....
      		  | SourceTy SourceType
      	data SourceType = NType TyCon [Type]
      			| ClassP Class [Type]
      			| IParam Type
      [SourceType was called PredType.]  This is a little wierd in some ways,
      because NTypes can't occur in qualified types.   However, the idea is that
      a SourceType is a type that is opaque to the type checker, but transparent
      to the rest of the compiler, and newtypes fit that as do implicit parameters
      and dictionaries.
      * Recursive newtypes still retain their coreces, exactly as before. If
      they were transparent we'd get a recursive type, and that would make
      various bits of the compiler diverge (e.g. things which do type comparison).
      * I've removed types/Unify.lhs (non-monadic type unifier and matcher),
      merging it into TcType.
      Ditto typecheck/TcUnify.lhs (monadic unifier), merging it into TcMType.
  5. 22 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-22 13:43:14 by simonpj] · f16228e4
      simonpj authored
      	Towards generalising 'foreign' declarations
      This is a first step towards generalising 'foreign' declarations to
      handle langauges other than C.  Quite a lot of files are touched,
      but nothing has really changed.  Everything should work exactly as
      	But please be on your guard for ccall-related bugs.
      Main things
      Basic data types: ForeignCall.lhs
      * Remove absCSyn/CallConv.lhs
      * Add prelude/ForeignCall.lhs.  This defines the ForeignCall
        type and its variants
      * Define ForeignCall.Safety to say whether a call is unsafe
        or not (was just a boolean).  Lots of consequential chuffing.
      * Remove all CCall stuff from PrimOp, and put it in ForeignCall
      Take CCallOp out of the PrimOp type (where it was always a glitch)
      * Add IdInfo.FCallId variant to the type IdInfo.GlobalIdDetails,
      	along with predicates Id.isFCallId, Id.isFCallId_maybe
      * Add StgSyn.StgOp, to sum PrimOp with FCallOp, because it
        *is* useful to sum them together in Stg and AbsC land.  If
        nothing else, it minimises changes.
      Also generally rename "CCall" stuff to "FCall" where it's generic
      to all foreign calls.
  6. 14 May, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-05-14 10:20:58 by sewardj] · 3bf43200
      sewardj authored
      Change wording of panic message on encountering unboxed tuples to:
              Bytecode generator can't handle unboxed tuples.  Possibly due
              to foreign import/export decls in source.  Workaround:
              compile this module to a .o file, then restart session.
  7. 08 May, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-05-08 16:47:25 by sewardj] · 713af4d5
      sewardj authored
      Insert interim fix in the bytecode gen to ignore polymorphic case
      for the time being.  I can't see any way to fix it right in the
      timescale before 5.00.1 goes out.  This works well enough to
      make Sergei's DoCon thing run on the interpreter without segfaults.
         -- Nasty hack; treat
         --     case scrut::suspect of bndr { DEFAULT -> rhs }
         --     as
         --     let bndr = scrut in rhs
         --     when suspect is polymorphic or arrowtyped
         -- So the required strictness properties are not observed.
         -- At some point, must fix this properly.
  8. 01 May, 2001 1 commit
  9. 21 Mar, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-03-21 11:17:00 by sewardj] · 7c98178c
      sewardj authored
      Implement tagToEnum# for the bytecode system.  Blargh.  We spot tail-calls
         tagToEnum# <type> arg
      and emit code to push the arg, then do a bytecode test-sequence to
      determine what value it is, push the relevant constructor, and merge
      control flow again, at a label which does the normal tail-call
      sequence: slide the constructor down to the sequel and enter it.
      Blargyle, or as some would say, barferama.
  10. 08 Mar, 2001 2 commits
    • qrczak's avatar
      [project @ 2001-03-08 18:03:34 by qrczak] · 69eaf10e
      qrczak authored
      Fix names imported from Id.
    • simonpj's avatar
      [project @ 2001-03-08 12:07:38 by simonpj] · 51a571c0
      simonpj authored
      	A major hygiene pass
      1. The main change here is to
      	Move what was the "IdFlavour" out of IdInfo,
      	and into the varDetails field of a Var
         It was a mess before, because the flavour was a permanent attribute
         of an Id, whereas the rest of the IdInfo was ephemeral.  It's
         all much tidier now.
         Main places to look:
      	   Var.lhs	Defn of VarDetails
      	   IdInfo.lhs	Defn of GlobalIdDetails
         The main remaining infelicity is that SpecPragmaIds are right down
         in Var.lhs, which seems unduly built-in for such an ephemeral thing.
         But that is no worse than before.
      2. Tidy up the HscMain story a little.  Move mkModDetails from MkIface
         into CoreTidy (where it belongs more nicely)
         This was partly forced by (1) above, because I didn't want to make
         DictFun Ids into a separate kind of Id (which is how it was before).
         Not having them separate means we have to keep a list of them right
         through, rather than pull them out of the bindings at the end.
      3. Add NameEnv as a separate module (to join NameSet).
      4. Remove unnecessary {-# SOURCE #-} imports from FieldLabel.
  11. 01 Mar, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-03-01 14:26:00 by simonmar] · 18b24e64
      simonmar authored
      GHCi fixes:
        - expressions are now compiled in a pseudo-module "$Interactive",
          which avoids some problems with storage of demand-loaded declarations.
        - compilation manager now detects when it needs to read the interace
          for a module, even if it is already compiled.  GHCi never demand-loads
          interfaces now.
        - (from Simon PJ) fix a problem with the recompilation checker, which
          meant that modules were sometimes not recompiled when they should
          have been.
        - ByteCodeGen/Link: move linker related stuff into ByteCodeLink.
  12. 15 Feb, 2001 1 commit
  13. 13 Feb, 2001 1 commit
  14. 12 Feb, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-02-12 11:39:48 by sewardj] · 5cf96a33
      sewardj authored
      Check for unboxed tuples and barf, rather than silently generate bogus
      code.  (There will be a proper user-level check higher up, too; this is
      just for our sanity.)
  15. 06 Feb, 2001 2 commits
    • sewardj's avatar
      [project @ 2001-02-06 12:00:17 by sewardj] · 3a8cc90c
      sewardj authored
      Support stack overflow checks in interpreted code.  The deal is:
      * If a BCO is reckoned to need less than iNTERP_STACK_CHECK_THRESH
        words of stack, no stack check insn is added.
      * If a BCO needs >= iNTERP_STACK_CHECK_THRESH words, an explicit
        check insn is added.
      The interpreter ensures at least iNTERP_STACK_CHECK_THRESH words of
      stack are available before running each BCO, regardless of whether or
      not the BCO contains an explicit check insn too.
      By setting iNTERP_STACK_CHECK_THRESH to a suitably large level
      (currently 50), most BCOs only require the implicit stack check, which
      avoids the overhead of decoding one extra insn per BCO.  BCOs which do
      have a stack check insn then do 2 stack checks rather than 1
      (implicit, then explicit), but this is rare enough that we don't care.
    • sewardj's avatar
      [project @ 2001-02-06 10:37:23 by sewardj] · 6ef1f789
      sewardj authored
      When linking a bytecode module, only add top-level (isGlobalName)
      bindings into the returned augmented closure env.
  16. 05 Feb, 2001 1 commit
  17. 21 Jan, 2001 1 commit
  18. 19 Jan, 2001 2 commits
  19. 16 Jan, 2001 1 commit
  20. 15 Jan, 2001 2 commits
  21. 12 Jan, 2001 2 commits
  22. 10 Jan, 2001 1 commit
  23. 09 Jan, 2001 1 commit
  24. 05 Jan, 2001 1 commit
  25. 03 Jan, 2001 1 commit
  26. 20 Dec, 2000 2 commits
  27. 19 Dec, 2000 2 commits
  28. 18 Dec, 2000 2 commits
  29. 15 Dec, 2000 1 commit
  30. 14 Dec, 2000 2 commits
  31. 12 Dec, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-12-12 17:16:28 by sewardj] · 933a428b
      sewardj authored
      More assembler work.  Mostly done.  Still need to import itbl stuff
      from old interpreter.  Must remember to order new hair to replaced all
      I tore out today.