1. 27 Feb, 2006 1 commit
  2. 12 Jul, 2005 1 commit
  3. 28 Jan, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-01-28 12:55:17 by simonmar] · 153b9cb9
      simonmar authored
      Rationalise the BUILD,HOST,TARGET defines.
      
      Recall that:
      
        - build is the platform we're building on
        - host is the platform we're running on
        - target is the platform we're generating code for
      
      The change is that now we take these definitions as applying from the
      point of view of the particular source code being built, rather than
      the point of view of the whole build tree.
      
      For example, in RTS and library code, we were previously testing the
      TARGET platform.  But under the new rule, the platform on which this
      code is going to run is the HOST platform.  TARGET only makes sense in
      the compiler sources.
      
      In practical terms, this means that the values of BUILD, HOST & TARGET
      may vary depending on which part of the build tree we are in.
      
      Actual changes:
      
       - new file: includes/ghcplatform.h contains platform defines for
         the RTS and library code.
      
       - new file: includes/ghcautoconf.h contains the autoconf settings
         only (HAVE_BLAH).  This is so that we can get hold of these
         settings independently of the platform defines when necessary
         (eg. in GHC).
      
       - ghcconfig.h now #includes both ghcplatform.h and ghcautoconf.h.
      
       - MachRegs.h, which is included into both the compiler and the RTS,
         now has to cope with the fact that it might need to test either
         _TARGET_ or _HOST_ depending on the context.
      
       - the compiler's Makefile now generates
           stage{1,2,3}/ghc_boot_platform.h
         which contains platform defines for the compiler.  These differ
         depending on the stage, of course: in stage2, the HOST is the
         TARGET of stage1.  This was wrong before.
      
       - The compiler doesn't get platform info from Config.hs any more.
         Previously it did (sometimes), but unless we want to generate
         a new Config.hs for each stage we can't do this.
      
       - GHC now helpfully defines *_{BUILD,HOST}_{OS,ARCH} automatically
         in CPP'd Haskell source.
      
       - ghcplatform.h defines *_TARGET_* for backwards compatibility
         (ghcplatform.h is included by ghcconfig.h, which is included by
         config.h, so code which still #includes config.h will get the TARGET
         settings as before).
      
       - The Users's Guide is updated to mention *_HOST_* rather than
         *_TARGET_*.
      
       - coding-style.html in the commentary now contains a section on
         platform defines.  There are further doc updates to come.
      
      Thanks to Wolfgang Thaller for pointing me in the right direction.
      153b9cb9
  4. 10 Nov, 2004 1 commit
    • wolfgang's avatar
      [project @ 2004-11-10 03:20:31 by wolfgang] · 61ccfec1
      wolfgang authored
      Implement the mblock map for 64-bit architectures.
      Fairly primitive data structure, but one 4GB-block, described by a
      12-bit block map, is cached for speed.
      
      Note that I've nuked the ia64-specific version (I think ia64 wants to
      use the general 64-bit solution, too).
      61ccfec1
  5. 12 Sep, 2004 2 commits
  6. 03 Sep, 2004 1 commit
    • simonmar's avatar
      [project @ 2004-09-03 15:28:18 by simonmar] · 95ca6bff
      simonmar authored
      Cleanup: all (well, most) messages from the RTS now go through the
      functions in RtsUtils: barf(), debugBelch() and errorBelch().  The
      latter two were previously called belch() and prog_belch()
      respectively.  See the comments for the right usage of these message
      functions.
      
      One reason for doing this is so that we can avoid spurious uses of
      stdout/stderr by Haskell apps on platforms where we shouldn't be using
      them (eg. non-console apps on Windows).
      95ca6bff
  7. 31 Oct, 2003 1 commit
  8. 23 Sep, 2003 1 commit
  9. 19 Sep, 2003 1 commit
  10. 26 Jun, 2003 1 commit
  11. 21 May, 2003 1 commit
  12. 14 May, 2003 1 commit
  13. 26 Mar, 2003 1 commit
  14. 20 Mar, 2003 1 commit
  15. 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
  16. 26 Nov, 2002 1 commit
  17. 22 Nov, 2002 2 commits
  18. 07 Nov, 2002 1 commit
  19. 05 Nov, 2002 3 commits
  20. 27 Oct, 2002 1 commit
    • wolfgang's avatar
      [project @ 2002-10-27 21:46:27 by wolfgang] · 80498a8a
      wolfgang authored
      For Mac OS X, use the underlying Mach Microkernel calls instead of mmap.
      Darwin's mmap doesn't honor the passed-in address without MAP_FIXED,
      and MAP_FIXED replaces all existing mappings, so it can't be used.
      80498a8a
  21. 25 Oct, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-10-25 12:56:34 by simonmar] · 24889e6a
      simonmar authored
      We shouldn't be using MAP_FIXED on solaris (fixes last night's crash).
      
      Unfortunately on Solaris the heuristics don't work too well.  Solaris
      seems to ignore the addr argument to mmap when MAP_FIXED is not
      specified, and starts handing out memory from the top of the address
      space.  So we allocate 2M each time and munmap() ends to leave an
      aligned 1M chunk.  This will eventually leave the address space
      completely full of 1M holes.  I don't have a good solution to this at
      the moment.
      
      MERGE TO STABLE
      24889e6a
  22. 23 Oct, 2002 1 commit
  23. 21 Oct, 2002 2 commits
    • simonmar's avatar
      [project @ 2002-10-21 12:42:31 by simonmar] · 5cc57129
      simonmar authored
      Turn an instance of 0xfff00000 into ~MBLOCK_MASK in the Win32 code.
      5cc57129
    • simonmar's avatar
      [project @ 2002-10-21 11:38:53 by simonmar] · 2be44cb2
      simonmar authored
      Bite the bullet and generalise the central memory allocation scheme.
      Previously we tried to allocate memory starting from a fixed address,
      which was set for each architecture (0x5000000 was a common one), and
      to decide whether a particular address was in the heap or not we would
      do a simple comparison against this address.
      
      This doesn't work too well, because:
      
       - if we dynamically-load some objects above the boundary, the
         heap-allocated test becomes invalid
      
       - on windows we have less control, and the heap might be
         split into multiple sections
      
       - it turns out that on some Linux kernels we don't get memory where
         we asked for it.  This might be a bug in those kernels, but it
         exposes the fragility of our allocation scheme.
      
      The solution is to bite the bullet and maintain a table mapping
      addresses to a value indicating whether that address is in the heap or
      not.  Since we normally allocate heap in chunks of 1Mb, the table is
      quite small: 4k on a 32-bit machine, using one byte for each 1Mb
      block.  Testing an address for heap residency now involves a memory
      access, but the table is normally cache-resident.  I didn't manage to
      measure any slowdown after making the change.
      
      On a 64-bit machine, we'll need to use a 2-level table; I haven't
      implemented that yet.
      
      Now we can generalise the procedure used to grab memory from the OS.
      In the general case, we allocate one megablock more than we need to,
      and trim off the slop around the allocation to leave an aligned chunk.
      The next time around, however, we try to allocate memory right after
      the last chunk allocated, on the grounds that it is aligned and
      probably free: if this doesn't work, we have to back off to the
      general mechanism (it seems to work most of the time).
      
      This cleans up the Windows story too: is_heap_alloced() has gone, and
      we should be able to handle more than 256M of memory (or whatever the
      arbitrary limit was before).
      
      MERGE TO STABLE (after lots of testing)
      2be44cb2
  24. 17 Jul, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-07-17 09:21:48 by simonmar] · 7457757f
      simonmar authored
      Remove most #includes of system headers from Stg.h, and instead
      #include any required headers directly in each RTS source file.
      
      The idea is to (a) reduce namespace pollution from system headers that
      we don't need, (c) be clearer about dependencies on system things in
      the RTS, and (c) improve via-C compilation times (maybe).
      
      In practice though, HsBase.h #includes everything anyway, so the
      difference from the point of view of .hc source is minimal.  However,
      this makes it easier to move to zero-includes if we wanted to (see
      discussion on the FFI list; I'm still not sure that's possible but
      at least this is a step in the right direction).
      7457757f
  25. 12 Apr, 2002 1 commit
  26. 26 Mar, 2002 1 commit
  27. 08 Jan, 2002 1 commit
    • sof's avatar
      [project @ 2002-01-08 16:38:27 by sof] · dd7f7b3d
      sof authored
      Make better use of the -M<size> setting under Win32. Use it to guide
      the amount of VM to reserve -- the default is (still) 256M, but the
      user will now have a way of overriding this setting.
      dd7f7b3d
  28. 10 Dec, 2001 1 commit
  29. 26 Oct, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-10-26 11:49:19 by sewardj] · 80ca788a
      sewardj authored
      merge from stable, rev 1.23.4.1:
      
        Win32 only: implement sane failure semantics + message when out of
        memory, rather than continuing and allowing the rest of the system
        to seg out.  Also, increase the 128M limit to 256M.
      
        This allegedly fixes the Antony Courtney Win32 segfault.
      80ca788a
  30. 14 Aug, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-08-14 13:40:07 by sewardj] · bc5c8021
      sewardj authored
      Change the story about POSIX headers in C compilation.
      
      Until now, all C code in the RTS and library cbits has by default been
      compiled with settings for POSIXness enabled, that is:
         #define _POSIX_SOURCE   1
         #define _POSIX_C_SOURCE 199309L
         #define _ISOC9X_SOURCE
      If you wanted to negate this, you'd have to define NON_POSIX_SOURCE
      before including headers.
      
      This scheme has some bad effects:
      
      * It means that ccall-unfoldings exported via interfaces from a
        module compiled with -DNON_POSIX_SOURCE may not compile when
        imported into a module which does not -DNON_POSIX_SOURCE.
      
      * It overlaps with the feature tests we do with autoconf.
      
      * It seems to have caused borkage in the Solaris builds for some
        considerable period of time.
      
      The New Way is:
      
      * The default changes to not-being-in-Posix mode.
      
      * If you want to force a C file into Posix mode, #include as
        the **first** include the new file ghc/includes/PosixSource.h.
        Most of the RTS C sources have this include now.
      
      * NON_POSIX_SOURCE is almost totally expunged.  Unfortunately
        we have to retain some vestiges of it in ghc/compiler so that
        modules compiled via C on Solaris using older compilers don't
        break.
      bc5c8021
  31. 24 Jul, 2001 1 commit
  32. 16 Jan, 2001 1 commit
  33. 16 Dec, 2000 1 commit
  34. 04 Dec, 2000 1 commit
  35. 06 Sep, 2000 1 commit
    • rrt's avatar
      [project @ 2000-09-06 11:12:07 by rrt] · e349469c
      rrt authored
      Made message for exceeding 128Mb of heap on Windows more helpful, and
      only abort when this limit is exceeded, not on first memory allocation!
      e349469c