1. 18 Apr, 2016 1 commit
  2. 25 Oct, 2013 1 commit
  3. 01 Oct, 2013 1 commit
  4. 23 Mar, 2012 1 commit
  5. 15 Mar, 2012 1 commit
  6. 25 Aug, 2009 1 commit
  7. 02 Aug, 2009 1 commit
    • Simon Marlow's avatar
      RTS tidyup sweep, first phase · a2a67cd5
      Simon Marlow authored
      The first phase of this tidyup is focussed on the header files, and in
      particular making sure we are exposinng publicly exactly what we need
      to, and no more.
       - Rts.h now includes everything that the RTS exposes publicly,
         rather than a random subset of it.
       - Most of the public header files have moved into subdirectories, and
         many of them have been renamed.  But clients should not need to
         include any of the other headers directly, just #include the main
         public headers: Rts.h, HsFFI.h, RtsAPI.h.
       - All the headers needed for via-C compilation have moved into the
         stg subdirectory, which is self-contained.  Most of the headers for
         the rest of the RTS APIs have moved into the rts subdirectory.
       - I left MachDeps.h where it is, because it is so widely used in
         Haskell code.
       - I left a deprecated stub for RtsFlags.h in place.  The flag
         structures are now exposed by Rts.h.
       - Various internal APIs are no longer exposed by public header files.
       - Various bits of dead code and declarations have been removed
       - More gcc warnings are turned on, and the RTS code is more
       - More source files #include "PosixSource.h", and hence only use
         standard POSIX (1003.1c-1995) interfaces.
      There is a lot more tidying up still to do, this is just the first
      pass.  I also intend to standardise the names for external RTS APIs
      (e.g use the rts_ prefix consistently), and declare the internal APIs
      as hidden for shared libraries.
  8. 27 Jul, 2007 1 commit
    • Simon Marlow's avatar
      Pointer Tagging · 6015a94f
      Simon Marlow authored
      This patch implements pointer tagging as per our ICFP'07 paper "Faster
      laziness using dynamic pointer tagging".  It improves performance by
      10-15% for most workloads, including GHC itself.
      The original patches were by Alexey Rodriguez Yakushev
      <mrchebas@gmail.com>, with additions and improvements by me.  I've
      re-recorded the development as a single patch.
      The basic idea is this: we use the low 2 bits of a pointer to a heap
      object (3 bits on a 64-bit architecture) to encode some information
      about the object pointed to.  For a constructor, we encode the "tag"
      of the constructor (e.g. True vs. False), for a function closure its
      arity.  This enables some decisions to be made without dereferencing
      the pointer, which speeds up some common operations.  In particular it
      enables us to avoid costly indirect jumps in many cases.
      More information in the commentary:
  9. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
  10. 04 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-04 12:01:11 by simonmar] · 7f5ad47f
      simonmar authored
      include ghcautoconf.h rather than ghcconfig.h, the reason being that
      this file is included form the compiler, and we don't want the
      platform defines from ghcplatform.h.
  11. 13 Aug, 2004 1 commit
  12. 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
        - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
          in GHCi which affected primitives and unboxed tuples are now
        - 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.
  13. 03 Oct, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-10-03 13:57:42 by simonmar] · b4623557
      simonmar authored
      Tidy up ghc/includes/Constants and related things.
      Now all the constants that the compiler needs to know, such as header
      size, update frame size, info table size and so on are generated
      automatically into a header file, DeriviedConstants.h, by a small C
      program in the same way as NativeDefs.h.  The C code in the RTS is
      expected to use sizeof() directly (it already does).
      Also tidied up the constants in MachDeps.h - all the constants
      representing the sizes of various types are named SIZEOF_<foo>, to
      match the constants defined in config.h.  PrelStorable.lhs now doesn't
      contain any special knowledge about GHC's conventions as regards the
      size of certain types, this is all in MachDeps.h.
  14. 17 Aug, 2001 1 commit
    • apt's avatar
      [project @ 2001-08-17 17:18:51 by apt] · 1dfaee31
      apt authored
      How I spent my summer vacation.
      The format of the primops.txt.pp file has been enhanced to allow
      (latex-style) primop descriptions to be included.  There is a new flag
      to genprimopcode that generates documentation including these
      descriptions. A first cut at descriptions of the more interesting
      primops has been made, and the file has been reordered a bit.
      31-bit words
      The front end now can cope with the possibility of 31-bit (or even 30-bit)
      Int# and Word# types.  The only current use of this is to generate
      external .core files that can be translated into OCAML source files
      (OCAML uses a one-bit tag to distinguish integers from pointers).
      The only way to get this right now is by hand-defining the preprocessor
      symbol WORD_SIZE_IN_BITS, which is normally set automatically from
      the familiar WORD_SIZE_IN_BYTES.
      Just in case 31-bit words are used, we now have Int32# and Word32# primitive types
      and an associated family of operators, paralleling the existing 64-bit
      stuff.  Of course, none of the operators actually need to be implemented
      in the absence of a 31-bit backend.
      There has also been some minor re-jigging of the 32 vs. 64 bit stuff.
      See the description at the top of primops.txt.pp file for more details.
      Note that, for the first time, the *type* of a primop can now depend
      on the target word size.
      Also, the family of primops intToInt8#, intToInt16#, etc.
      have been renamed narrow8Int#, narrow16Int#, etc., to emphasize
      that they work on Int#'s and don't actually convert between types.
      As another part of coping with the possibility of 31-bit ints,
      the addr2Int# and int2Addr# primops are now thoroughly deprecated
      (and not even defined in the 31-bit case) and all uses
      of them have been removed except from the (deprecated) module
      Addr# should now be treated as a proper abstract type, and has these suitable operators:
      nullAddr# : Int# -> Addr# (ignores its argument; nullary primops cause problems at various places)
      plusAddr# :  Addr# -> Int# -> Addr#
      minusAddr : Addr# -> Addr# -> Int#
      remAddr# : Addr# -> Int# -> Int#
      Obviously, these don't allow completely arbitrary offsets if 31-bit ints are
      in use, but they should do for all practical purposes.
      It is also still possible to generate an address constant, and there is a built-in rule
      that makes use of this to remove the nullAddr# calls.
      There is a new compile flag -fno-code that causes GHC to quit after generating .hi files
      and .core files (if requested) but before generating STG.
      Z-encoded names for tuples have been rationalized; e.g.,
      Z3H now means an unboxed 3-tuple, rather than an unboxed
      tuple with 3 commas (i.e., a 4-tuple)!
      Removed misc. litlits in hslibs/lang
      Misc. small changes to external core format.  The external core description
      has also been substantially updated, and incorporates the automatically-generated
      primop documentation; its in the repository at /papers/ext-core/core.tex.
      A little make-system addition to allow passing CPP options to compiler and
      library builds.
  15. 19 Jul, 2001 1 commit
  16. 25 Jan, 2000 1 commit
    • panne's avatar
      [project @ 2000-01-25 14:39:14 by panne] · 4266041d
      panne authored
      Added a bunch of #defines for {SIZEOF,ALIGNMENT}_{INT,WORD}{8,16,32,64}.
      All this is a real hack: The include files need a more thorough restructuring.
  17. 05 Feb, 1999 1 commit
  18. 02 Dec, 1998 1 commit