1. 21 Oct, 2002 1 commit
    • 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)
  2. 18 Oct, 2002 5 commits
    • simonpj's avatar
      [project @ 2002-10-18 13:41:50 by simonpj] · f53483a2
      simonpj authored
         Fix a serious error in the "newtype deriving" feature
      The "newtype deriving" feature lets you derive arbitrary classes for
      a newtype, not just the built-in ones (Read, Show, Ix etc).  It's very
      cool, but Hal Duame discovered that it did utterly the Wrong Thing
      for superclasses.  E.g.
      	newtype Foo = MkFoo Int deriving( Show, Num, Eq )
      You'd get a Num instance for Foo that was *identical* to the
      Num instance for Int, *including* the Show superclass. So the
      superclass in the Num dictionary would show a Foo just like an
      Int, which is wrong... it should show as "Foo n".
      This commit fixes the problem, by building a new dictionary every time,
      but using the methods from the dictionary for the representation type.
      I also fixed a bug that prevented it working altogether when the
      representation type was not the application of a type constructor.
      For example, this now works
      	newtype Foo a = MkFoo a deriving( Num, Eq, Show )
      I also made it a bit more efficient in the case where the type is
      not parameterised.  Then the "dfun" doesn't need to be a function.
    • simonpj's avatar
      [project @ 2002-10-18 13:36:17 by simonpj] · fbd11e24
      simonpj authored
      Add a trace
    • simonpj's avatar
      [project @ 2002-10-18 13:35:46 by simonpj] · 9b4d74c7
      simonpj authored
      Import wibbles
    • simonmar's avatar
      [project @ 2002-10-18 09:51:03 by simonmar] · f05e7d3f
      simonmar authored
      Add atomicModifyIORef, as discussed on the FFI list.
    • simonmar's avatar
      [project @ 2002-10-18 09:36:21 by simonmar] · c7566eea
      simonmar authored
      Add a note about the profiling versions of the interface files in a package.
  3. 17 Oct, 2002 2 commits
    • simonmar's avatar
      [project @ 2002-10-17 14:49:52 by simonmar] · f9449b97
      simonmar authored
      - Don't flush the finder cache after adding a new package.  We'll
        assume that packages don't overlap.
      - Add the extra command-line flags specified by a package when we
        add a package from the GHCi prompt.
    • simonmar's avatar
      [project @ 2002-10-17 14:26:16 by simonmar] · 06575d67
      simonmar authored
      Finder overhaul.
      The finder had got pretty complicated; this commit is mainly a
      cleanup, with one new feature:
        - the finder has a cache (again).  The cache may be flushed by
          calling flushFinderCache, which actually only flushes home modules
          from the cache, because package modules are assumed not to move.
          This change is apropos of some other changes which will result in
          the finder being called more often, so we think a cache is going
          to be worthwhile.
      Also a couple of bugs were fixed:
        - the field ml_hi_file in a ModLocation is now *always* the name
          of the .hi file.  If you need a .hi-boot file, you have to make
          it up by changing the suffix of ml_hi_file.  (DriverMkDepend and
          RnHiFiles do this).  This was the cause of a bug, but I can't
          remember the details.
        - The -odir flag now works in a more reasonable way: hierarchical
          modules get put in subdirectories of the -odir directory.  eg.
          if your module is A.B.C, and -odir D is specified, then the object
          will be D/A/B/C.o; previously it would have been D/C.o.
  4. 15 Oct, 2002 13 commits
  5. 14 Oct, 2002 3 commits
  6. 13 Oct, 2002 1 commit
    • wolfgang's avatar
      [project @ 2002-10-13 10:55:06 by wolfgang] · 61de6a58
      wolfgang authored
      Darwin/PowerPC: Don't generate PIC code by default
      Non-PIC-code is slightly smaller and faster.
      This means that GHC now requires GCC3 (Mac OS X 10.2 Jaguar).
  7. 12 Oct, 2002 4 commits
    • wolfgang's avatar
      [project @ 2002-10-12 23:28:48 by wolfgang] · 97906cfc
      wolfgang authored
      The Native Code Generator for PowerPC.
      Still to be done:
      *) Proper support of Floats and Doubles
         currently it seems to work, but it's just guesswork.
      *) Some missing operations, only needed for -O, AFAICT.
      *) Mach-O dynamic linker stub generation.
         (can't import foreign functions from dynamic libraries,
         and it might fail for big programs)
    • wolfgang's avatar
      [project @ 2002-10-12 23:19:54 by wolfgang] · 9506b93c
      wolfgang authored
      Object Splitting for Mac OS X.
      MERGE TO STABLE (... but not today, I have to test it first)
    • 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.
    • erkok's avatar
      [project @ 2002-10-12 18:16:11 by erkok] · b41b49bd
      erkok authored
      mdo wibbles
  8. 11 Oct, 2002 11 commits