1. 08 Oct, 2003 1 commit
    • wolfgang's avatar
      [project @ 2003-10-08 09:42:34 by wolfgang] · 2203c0ce
      wolfgang authored
      Mac OS X/PowerPC:
      Learn to cope with out-of-range relative jumps.
      
      PowerPC relative branch instructions have a 24 bit displacement field.
      As PPC code is always 4-byte-aligned, this yields a +-32MB range.
      If a particular imported symbol is outside this range, we have to redirect
      the jump to a short piece of new code that just loads the 32bit absolute
      address and jumps there.
      2203c0ce
  2. 01 Oct, 2003 1 commit
    • wolfgang's avatar
      [project @ 2003-10-01 10:57:39 by wolfgang] · d3581a6a
      wolfgang authored
      New implementation & changed type signature of forkProcess
      
      forkProcess now has the following type:
      forkProcess :: IO () -> IO ProcessID
      
      forkProcessAll has been removed as it is unimplementable in the threaded RTS.
      
      forkProcess using the old type (IO (Maybe ProcessID)) was impossible to
      implement correctly in the non-threaded RTS and very hard to implement
      in the threaded RTS.
      The new type signature allows a clean and simple implementation.
      d3581a6a
  3. 26 Sep, 2003 2 commits
  4. 25 Sep, 2003 1 commit
  5. 24 Sep, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-09-24 11:06:51 by simonmar] · 8f57c3c1
      simonmar authored
      Move forkOS_createThread into the RTS so its implementation can be
      dependent on RTS_SUPPORTS_THREADS, which means we can provide a stub
      implementation in the !RTS_SUPPORTS_THREADS case, and hence not depend
      on pthread_create, which requires -lpthread.  The upshot is that GHCi
      now works again when !RTS_SUPPORTS_THREADS.
      8f57c3c1
  6. 21 Sep, 2003 1 commit
    • wolfgang's avatar
      [project @ 2003-09-21 22:20:51 by wolfgang] · 85aa72b9
      wolfgang authored
      Bound Threads
      =============
      
      Introduce a way to use foreign libraries that rely on thread local state
      from multiple threads (mainly affects the threaded RTS).
      
      See the file threads.tex in CVS at haskell-report/ffi/threads.tex
      (not entirely finished yet) for a definition of this extension. A less formal
      description is also found in the documentation of Control.Concurrent.
      
      The changes mostly affect the THREADED_RTS (./configure --enable-threaded-rts),
      except for saving & restoring errno on a per-TSO basis, which is also necessary
      for the non-threaded RTS (a bugfix).
      
      Detailed list of changes
      ------------------------
      
      - errno is saved in the TSO object and restored when necessary:
      ghc/includes/TSO.h, ghc/rts/Interpreter.c, ghc/rts/Schedule.c
      
      - rts_mainLazyIO is no longer needed, main is no special case anymore
      ghc/includes/RtsAPI.h, ghc/rts/RtsAPI.c, ghc/rts/Main.c, ghc/rts/Weak.c
      
      - passCapability: a new function that releases the capability and "passes"
        it to a specific OS thread:
      ghc/rts/Capability.h ghc/rts/Capability.c
      
      - waitThread(), scheduleWaitThread() and schedule() get an optional
        Capability *initialCapability passed as an argument:
      ghc/includes/SchedAPI.h, ghc/rts/Schedule.c, ghc/rts/RtsAPI.c
      
      - Bound Thread scheduling (that's what this is all about):
      ghc/rts/Schedule.h, ghc/rts/Schedule.c
      
      - new Primop isCurrentThreadBound#:
      ghc/compiler/prelude/primops.txt.pp, ghc/includes/PrimOps.h, ghc/rts/PrimOps.hc,
      ghc/rts/Schedule.h, ghc/rts/Schedule.c
      
      - a simple function, rtsSupportsBoundThreads, that returns true if THREADED_RTS
        is defined:
      ghc/rts/Schedule.h, ghc/rts/Schedule.c
      
      - a new implementation of forkProcess (the old implementation stays in place
        for the non-threaded case). Partially broken; works for the standard
        fork-and-exec case, but not for much else. A proper forkProcess is
        really next to impossible to implement:
      ghc/rts/Schedule.c
      
      - Library support for bound threads:
          Control.Concurrent.
            rtsSupportsBoundThreads, isCurrentThreadBound, forkOS,
            runInBoundThread, runInUnboundThread
      libraries/base/Control/Concurrent.hs, libraries/base/Makefile,
      libraries/base/include/HsBase.h, libraries/base/cbits/forkOS.c (new file)
      85aa72b9
  7. 11 Sep, 2003 1 commit
    • wolfgang's avatar
      [project @ 2003-09-11 15:12:25 by wolfgang] · d8144db0
      wolfgang authored
      Mac OS X:
      
      Bypass the dlfcn compatibility layer in lookupSymbol, use Apple's
      NSModule functions directly instead. This protects us from differences
      between different implementations of the dlcompat library (regarding
      treatment of prefixed underscores).
      Note that the compatibility layer is still used in addDLL (it's needed by
      the POSIX library anyway).
      
      Also, add a little more sanity checking (checkProddableBlock) to the Mach-O
      linker itself.
      
      MERGE TO STABLE
      d8144db0
  8. 10 Sep, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-09-10 14:45:24 by simonmar] · 868973ac
      simonmar authored
      Quick hack to work around the dynamic exception crashes in GHCi.  The
      problem is this: the Data.Typeable library (Data.Dymamic in previous
      versions of GHC) maintains an internal cache mapping type names to
      unique numbers, and this cache is used for fast comparisons on
      TypeReps.  In GHCi, there are actually two versions of the
      Data.Typeable library loaded: one linked to GHCi itself, and the other
      dynamically loaded, so there are two copies of the hash tables.
      
      The problem is that if we have a Dynamic value generated using one set
      of hash tables, it will erroneously appear to be of a different type
      when the other hash tables are used.
      
      The hack I've instigated is to use the central RTS genSym (which
      already exists) to generate the unique Ids, so that the two copies of
      the dynamic library will be using distinct Ids, and Dynamics from one
      will never be recognisable to the other.
      868973ac
  9. 29 Aug, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-08-29 16:00:25 by simonmar] · 7dc97354
      simonmar authored
      Initial x86-64 (aka amd64) support.
      
      Unregisterised it works perfectly.  Registerised, I think it's almost
      there, except that I seem to be running into the known codegen bug in
      GCC with register variables (bug #7871 in the gcc bugzilla), which
      means registerised support is basically hosed until the GCC folks
      can get their act together.
      
      We get 8 more registers on amd64, but only 2 more callee-saves
      registers.  The calling convention seems to pass args in registers by
      default, using the previously-callee-saves %rsi and %rdi as two of the
      new arg registers.
      
      I think GHCi should work, since we already have 64-bit ELF support
      thanks to Mat Chapman's work on the IA64 port.  I haven't tried GHCi,
      though.
      
      The native code generator should be a breeze, because it's so similar
      to plain x86.
      7dc97354
  10. 18 Aug, 2003 1 commit
    • dons's avatar
      [project @ 2003-08-18 09:27:54 by dons] · 0e780367
      dons authored
      x86 OpenBSD moves into ELF land
      (and sparc, alpha, sparc64 were already there)
      
      Also, it needs sligtly different header files.
      
      And dlopen can only be called with the DL_LAZY argument on this
      system.
      0e780367
  11. 20 Jul, 2003 1 commit
  12. 26 Jun, 2003 2 commits
  13. 24 Jun, 2003 1 commit
  14. 09 Jun, 2003 1 commit
  15. 30 May, 2003 1 commit
  16. 29 Apr, 2003 1 commit
  17. 31 Mar, 2003 2 commits
    • simonmar's avatar
      [project @ 2003-03-31 14:02:32 by simonmar] · 9d431e08
      simonmar authored
      On 32-bit platforms, add a bunch of symbols from libgcc.a used to
      support 64-bit arithmetic.
      
      It looks like these symbols are defined in libc on some platforms but
      not others, but it shouldn't do any harm to include them in the list
      of symbols that the linker knows about even if they're also in libc.
      They were already included for some platforms (cygwin, mingw, and
      darwin), this commit just includes then whenever we're compiling with
      gcc on a 32-bit platform.
      9d431e08
    • simonmar's avatar
      [project @ 2003-03-31 12:35:21 by simonmar] · 1f927e8f
      simonmar authored
      Include NetBSD support
      
      Submitted by: Urban Boquist <boquist@crt.se>
      1f927e8f
  18. 25 Mar, 2003 1 commit
    • sof's avatar
      [project @ 2003-03-25 17:58:47 by sof] · 2548429c
      sof authored
      to ease replacement of the underlying allocator used by stgMallocBytes() and friends, provide (&use) RtsUtils.c:stgFree()
      2548429c
  19. 21 Feb, 2003 1 commit
    • sof's avatar
      [project @ 2003-02-21 05:34:12 by sof] · 5b4f5a6a
      sof authored
      Asynchronous / non-blocking I/O for Win32 platforms.
      
      This commit introduces a Concurrent Haskell friendly view of I/O on
      Win32 platforms. Through the use of a pool of worker Win32 threads, CH
      threads may issue asynchronous I/O requests without blocking the
      progress of other CH threads. The issuing CH thread is blocked until
      the request has been serviced though.
      
      GHC.Conc exports the primops that take care of issuing the
      asynchronous I/O requests, which the IO implementation now takes
      advantage of. By default, all Handles are non-blocking/asynchronous,
      but should performance become an issue, having a per-Handle flag for
      turning off non-blocking could easily be imagined&introduced.
      
      [Incidentally, this thread pool-based implementation could easily be
      extended to also allow Haskell code to delegate the execution of
      arbitrary pieces of (potentially blocking) external code to another OS
      thread. Given how relatively gnarly the locking story has turned out
      to be with the 'threaded' RTS, that may not be such a bad idea.]
      5b4f5a6a
  20. 10 Feb, 2003 2 commits
    • wolfgang's avatar
      [project @ 2003-02-10 23:35:03 by wolfgang] · 8115ed09
      wolfgang authored
      Mac OS X:
      add one more relocation type (PPC_RELOC_BR24)
      and add more C run-time library symbols to the symbol table
      (made more difficult by the fact that these symbols don't
      have an underscore prefix, while everything else on Mac OS X has)
      8115ed09
    • simonmar's avatar
      [project @ 2003-02-10 10:41:52 by simonmar] · 84370d93
      simonmar authored
      Add some missing symbols.
      
      Should fix several recent test breakages with GHCi.
      84370d93
  21. 29 Jan, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-01-29 09:54:31 by simonmar] · b1c5d8c6
      simonmar authored
      - re-instate setProgArgv, it is used in System.Environment (bah, could
        have sworn I grepped for it and found nothing...)
      
      - Remove init_stack symbol from the Linker's symbol table; this is
        now static.
      b1c5d8c6
  22. 28 Jan, 2003 1 commit
  23. 13 Jan, 2003 1 commit
  24. 27 Dec, 2002 1 commit
  25. 19 Dec, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-12-19 14:33:22 by simonmar] · 0d27d151
      simonmar authored
      Terrible hack to restore CAF handling behaviour in GHCi (it's
      currently broken).
      
      The story used to be this: in newCAF(), if the CAF is in dynamically
      loaded code, then we save the CAF's info ptr in a spare slot in the
      closure, and add the CAF to the caf_list.  The GC will retain
      everything on the caf_list.  At any point the CAFs can all be reverted
      by replacing their info pointers from the saved copies.
      
      CAFs need to be retained for GHCi because they might be required in a
      future execution; an optimisation would be to avoid retaining the CAFs
      if we're in "revert mode"; i.e. the CAFs are all going to be reverted
      after execution anyway.  Also, this only applies to CAFs in compiled
      code; CAFs in interpreted code are currently always retained.
      
      Anyway, the old story is harder now that I removed the code that
      checks whether a pointer is dynamically loaded or not (:-)).  Rather
      than re-instate that code, I created a new version of newCAF
      (newDynCAF), and arranged that the dynamic linker redirects any
      references to newCAF to point to newDynCAF instead.  The result is
      more efficient than before, and takes less code.
      0d27d151
  26. 11 Dec, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-12-11 15:36:20 by simonmar] · 0bffc410
      simonmar authored
      Merge the eval-apply-branch on to the HEAD
      ------------------------------------------
      
      This is a change to GHC's evaluation model in order to ultimately make
      GHC more portable and to reduce complexity in some areas.
      
      At some point we'll update the commentary to describe the new state of
      the RTS.  Pending that, the highlights of this change are:
      
        - No more Su.  The Su register is gone, update frames are one
          word smaller.
      
        - Slow-entry points and arg checks are gone.  Unknown function calls
          are handled by automatically-generated RTS entry points (AutoApply.hc,
          generated by the program in utils/genapply).
      
        - The stack layout is stricter: there are no "pending arguments" on
          the stack any more, the stack is always strictly a sequence of
          stack frames.
      
          This means that there's no need for LOOKS_LIKE_GHC_INFO() or
          LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know
          how to find the boundary between the text and data segments (BIG WIN!).
      
        - A couple of nasty hacks in the mangler caused by the neet to
          identify closure ptrs vs. info tables have gone away.
      
        - Info tables are a bit more complicated.  See InfoTables.h for the
          details.
      
        - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
          in GHCi which affected primitives and unboxed tuples are now
          fixed.
      
        - Binary sizes are reduced by about 7% on x86.  Performance is roughly
          similar, some programs get faster while some get slower.  I've seen
          GHCi perform worse on some examples, but haven't investigated
          further yet (GHCi performance *should* be about the same or better
          in theory).
      
        - Internally the code generator is rather better organised.  I've moved
          info-table generation from the NCG into the main codeGen where it is
          shared with the C back-end; info tables are now emitted as arrays
          of words in both back-ends.  The NCG is one step closer to being able
          to support profiling.
      
      This has all been fairly thoroughly tested, but no doubt I've messed
      up the commit in some way.
      0bffc410
  27. 23 Oct, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-10-23 08:52:26 by simonmar] · d12023f5
      simonmar authored
      Add atomicModifyIORefzh_fast symbol (should have been done with the
      rest of the atomicModifyIORef# commit, thanks to Manuel Chakravarty
      for pointing out the problem).
      d12023f5
  28. 12 Oct, 2002 1 commit
    • wolfgang's avatar
      [project @ 2002-10-12 23:12:08 by wolfgang] · 31442604
      wolfgang authored
      Make the Mac OS X build use the HaskellSupport.framework (a MacOS-style "framework" that includes the required libraries libgmp and dlcompat) if it is present. The HaskellSupport.framework is not yet in CVS, but is available from me.
      31442604
  29. 02 Oct, 2002 1 commit
  30. 13 Sep, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-09-13 15:02:25 by simonpj] · 9af77fa4
      simonpj authored
      --------------------------------------
      	Make Template Haskell into the HEAD
      	--------------------------------------
      
      This massive commit transfers to the HEAD all the stuff that
      Simon and Tim have been doing on Template Haskell.  The
      meta-haskell-branch is no more!
      
      WARNING: make sure that you
      
        * Update your links if you are using link trees.
          Some modules have been added, some have gone away.
      
        * Do 'make clean' in all library trees.
          The interface file format has changed, and you can
          get strange panics (sadly) if GHC tries to read old interface files:
          e.g.  ghc-5.05: panic! (the `impossible' happened, GHC version 5.05):
      	  Binary.get(TyClDecl): ForeignType
      
        * You need to recompile the rts too; Linker.c has changed
      
      
      However the libraries are almost unaltered; just a tiny change in
      Base, and to the exports in Prelude.
      
      
      NOTE: so far as TH itself is concerned, expression splices work
      fine, but declaration splices are not complete.
      
      
      		---------------
      		The main change
      		---------------
      
      The main structural change: renaming and typechecking have to be
      interleaved, because we can't rename stuff after a declaration splice
      until after we've typechecked the stuff before (and the splice
      itself).
      
      * Combine the renamer and typecheker monads into one
      	(TcRnMonad, TcRnTypes)
        These two replace TcMonad and RnMonad
      
      * Give them a single 'driver' (TcRnDriver).  This driver
        replaces TcModule.lhs and Rename.lhs
      
      * The haskell-src library package has a module
      	Language/Haskell/THSyntax
        which defines the Haskell data type seen by the TH programmer.
      
      * New modules:
      	hsSyn/Convert.hs 	converts THSyntax -> HsSyn
      	deSugar/DsMeta.hs 	converts HsSyn -> THSyntax
      
      * New module typecheck/TcSplice type-checks Template Haskell splices.
      
      		-------------
      		Linking stuff
      		-------------
      
      * ByteCodeLink has been split into
      	ByteCodeLink	(which links)
      	ByteCodeAsm	(which assembles)
      
      * New module ghci/ObjLink is the object-code linker.
      
      * compMan/CmLink is removed entirely (was out of place)
        Ditto CmTypes (which was tiny)
      
      * Linker.c initialises the linker when it is first used (no need to call
        initLinker any more).  Template Haskell makes it harder to know when
        and whether to initialise the linker.
      
      
      	-------------------------------------
      	Gathering the LIE in the type checker
      	-------------------------------------
      
      * Instead of explicitly gathering constraints in the LIE
      	tcExpr :: RenamedExpr -> TcM (TypecheckedExpr, LIE)
        we now dump the constraints into a mutable varabiable carried
        by the monad, so we get
      	tcExpr :: RenamedExpr -> TcM TypecheckedExpr
      
        Much less clutter in the code, and more efficient too.
        (Originally suggested by Mark Shields.)
      
      
      		-----------------
      		Remove "SysNames"
      		-----------------
      
      Because the renamer and the type checker were entirely separate,
      we had to carry some rather tiresome implicit binders (or "SysNames")
      along inside some of the HsDecl data structures.  They were both
      tiresome and fragile.
      
      Now that the typechecker and renamer are more intimately coupled,
      we can eliminate SysNames (well, mostly... default methods still
      carry something similar).
      
      		-------------
      		Clean up HsPat
      		-------------
      
      One big clean up is this: instead of having two HsPat types (InPat and
      OutPat), they are now combined into one.  This is more consistent with
      the way that HsExpr etc is handled; there are some 'Out' constructors
      for the type checker output.
      
      So:
      	HsPat.InPat	--> HsPat.Pat
      	HsPat.OutPat	--> HsPat.Pat
      	No 'pat' type parameter in HsExpr, HsBinds, etc
      
      	Constructor patterns are nicer now: they use
      		HsPat.HsConDetails
      	for the three cases of constructor patterns:
      		prefix, infix, and record-bindings
      
      	The *same* data type HsConDetails is used in the type
      	declaration of the data type (HsDecls.TyData)
      
      Lots of associated clean-up operations here and there.  Less code.
      Everything is wonderful.
      9af77fa4
  31. 05 Sep, 2002 1 commit
  32. 16 Aug, 2002 1 commit
  33. 18 Jul, 2002 1 commit
  34. 17 Jul, 2002 1 commit
  35. 08 Jul, 2002 1 commit
  36. 02 Jul, 2002 1 commit