1. 20 Aug, 2007 2 commits
  2. 09 Aug, 2007 1 commit
  3. 13 Jul, 2007 2 commits
    • Clemens Fruhwirth's avatar
      Add import facility to cmm parser · d55027c9
      Clemens Fruhwirth authored
      The cmm parser classified all unknown variables as imported. This
      behaviour is not changed with this patch. Explicitly imported
      variables get a different internal label type, namely ForeignLabel
      instead of RtsLabel. In PIC compilation, the NCG creates dynamic
      access for ForeignLabel, while RtsLabel are not treated as PIC when
      -package rts. Hence, putting explicit imports into cmm files enables
      the NCG to distinguish between RTS-external and RTS-internal symbols,
      and create the appropriate code.
      d55027c9
    • Clemens Fruhwirth's avatar
      Fix the knot-tying in loopDecls to actually do what its comment tells: provide... · 1e15be89
      Clemens Fruhwirth authored
      Fix the knot-tying in loopDecls to actually do what its comment tells: provide access to global declarations
      1e15be89
  4. 18 Jul, 2007 2 commits
  5. 15 Jul, 2007 1 commit
  6. 05 Jul, 2007 2 commits
  7. 03 Jul, 2007 1 commit
  8. 28 Jun, 2007 2 commits
  9. 27 Jun, 2007 5 commits
    • Michael D. Adams's avatar
      d31dfb32
    • Michael D. Adams's avatar
      Added stack checks to the CPS algorithm · 1f46671f
      Michael D. Adams authored
      This eliminates one of the panics introduced by 
      the previous patch:
      'First pass at implementing info tables for CPS'
        
      The other panic introduced by that patch still remains.
      It was due to the need to convert from a
        ContinuationInfo to a CmmInfo.
        (codeGen/CgInfoTbls.hs:emitClosureCodeAndInfoTable)
        (codeGen/CgInfoTbls.hs:emitReturnTarget)
      1f46671f
    • Michael D. Adams's avatar
      First pass at implementing info tables for CPS · f96e9aa0
      Michael D. Adams authored
      This is a fairly complete implementation, however
      two 'panic's have been placed in the critical path
      where the implementation is still a bit lacking so
      do not expect it to run quite yet.
      
      One call to panic is because we still need to create
      a GC block for procedures that don't have them yet.
      (cmm/CmmCPS.hs:continuationToProc)
      
      The other is due to the need to convert from a
      ContinuationInfo to a CmmInfo.
      (codeGen/CgInfoTbls.hs:emitClosureCodeAndInfoTable)
      (codeGen/CgInfoTbls.hs:emitReturnTarget)
      f96e9aa0
    • Michael D. Adams's avatar
    • Michael D. Adams's avatar
      Added pointerhood to LocalReg · 20780258
      Michael D. Adams authored
      This version should compile but is still incomplete as it introduces
      potential bugs at the places marked 'TODO FIXME NOW'.
      It is being recorded to help keep track of changes.
      20780258
  10. 06 Jun, 2007 1 commit
  11. 29 May, 2007 1 commit
  12. 16 May, 2007 2 commits
  13. 13 Jun, 2007 1 commit
    • Simon Marlow's avatar
      FIX #1418 (partially) · 23e5985c
      Simon Marlow authored
      When the con_desc field of an info table was made into a relative
      reference, this had the side effect of making the profiling fields
      (closure_desc and closure_type) also relative, but only when compiling
      via C, and the heap profiler was still treating them as absolute,
      leading to crashes when profiling with -hd or -hy.
      
      This patch fixes up the story to be consistent: these fields really
      should be relative (otherwise we couldn't make shared versions of the
      profiling libraries), so I've made them relative and fixed up the RTS
      to know about this.
      23e5985c
  14. 11 May, 2007 1 commit
  15. 27 Apr, 2007 1 commit
  16. 17 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Re-working of the breakpoint support · cdce6477
      Simon Marlow authored
      This is the result of Bernie Pope's internship work at MSR Cambridge,
      with some subsequent improvements by me.  The main plan was to
      
       (a) Reduce the overhead for breakpoints, so we could enable 
           the feature by default without incurrent a significant penalty
       (b) Scatter more breakpoint sites throughout the code
      
      Currently we can set a breakpoint on almost any subexpression, and the
      overhead is around 1.5x slower than normal GHCi.  I hope to be able to
      get this down further and/or allow breakpoints to be turned off.
      
      This patch also fixes up :print following the recent changes to
      constructor info tables.  (most of the :print tests now pass)
      
      We now support single-stepping, which just enables all breakpoints.
      
        :step <expr>     executes <expr> with single-stepping turned on
        :step            single-steps from the current breakpoint
      
      The mechanism is quite different to the previous implementation.  We
      share code with the HPC (haskell program coverage) implementation now.
      The coverage pass annotates source code with "tick" locations which
      are tracked by the coverage tool.  In GHCi, each "tick" becomes a
      potential breakpoint location.
      
      Previously breakpoints were compiled into code that magically invoked
      a nested instance of GHCi.  Now, a breakpoint causes the current
      thread to block and control is returned to GHCi.
      
      See the wiki page for more details and the current ToDo list:
      
        http://hackage.haskell.org/trac/ghc/wiki/NewGhciDebugger
      cdce6477
  17. 28 Feb, 2007 1 commit
  18. 12 Jan, 2007 1 commit
  19. 22 Oct, 2006 1 commit
  20. 11 Oct, 2006 1 commit
    • Simon Marlow's avatar
      Module header tidyup, phase 1 · 49c98d14
      Simon Marlow authored
      This patch is a start on removing import lists and generally tidying
      up the top of each module.  In addition to removing import lists:
      
         - Change DATA.IOREF -> Data.IORef etc.
         - Change List -> Data.List etc.
         - Remove $Id$
         - Update copyrights
         - Re-order imports to put non-GHC imports last
         - Remove some unused and duplicate imports
      49c98d14
  21. 25 Jul, 2006 1 commit
    • Simon Marlow's avatar
      Generalise Package Support · 61d2625a
      Simon Marlow authored
      This patch pushes through one fundamental change: a module is now
      identified by the pair of its package and module name, whereas
      previously it was identified by its module name alone.  This means
      that now a program can contain multiple modules with the same name, as
      long as they belong to different packages.
      
      This is a language change - the Haskell report says nothing about
      packages, but it is now necessary to understand packages in order to
      understand GHC's module system.  For example, a type T from module M
      in package P is different from a type T from module M in package Q.
      Previously this wasn't an issue because there could only be a single
      module M in the program.
      
      The "module restriction" on combining packages has therefore been
      lifted, and a program can contain multiple versions of the same
      package.
      
      Note that none of the proposed syntax changes have yet been
      implemented, but the architecture is geared towards supporting import
      declarations qualified by package name, and that is probably the next
      step.
      
      It is now necessary to specify the package name when compiling a
      package, using the -package-name flag (which has been un-deprecated).
      Fortunately Cabal still uses -package-name.
      
      Certain packages are "wired in".  Currently the wired-in packages are:
      base, haskell98, template-haskell and rts, and are always referred to
      by these versionless names.  Other packages are referred to with full
      package IDs (eg. "network-1.0").  This is because the compiler needs
      to refer to entities in the wired-in packages, and we didn't want to
      bake the version of these packages into the comiler.  It's conceivable
      that someone might want to upgrade the base package independently of
      GHC.
      
      Internal changes:
      
        - There are two module-related types:
      
              ModuleName      just a FastString, the name of a module
              Module          a pair of a PackageId and ModuleName
      
          A mapping from ModuleName can be a UniqFM, but a mapping from Module
          must be a FiniteMap (we provide it as ModuleEnv).
      
        - The "HomeModules" type that was passed around the compiler is now
          gone, replaced in most cases by the current package name which is
          contained in DynFlags.  We can tell whether a Module comes from the
          current package by comparing its package name against the current
          package.
      
        - While I was here, I changed PrintUnqual to be a little more useful:
          it now returns the ModuleName that the identifier should be qualified
          with according to the current scope, rather than its original
          module.  Also, PrintUnqual tells whether to qualify module names with
          package names (currently unused).
      
      Docs to follow.
      61d2625a
  22. 29 Jun, 2006 1 commit
  23. 20 Jun, 2006 1 commit
  24. 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.
      0065d5ab
  25. 14 Mar, 2006 1 commit
    • Simon Marlow's avatar
      Fix a really nasty bug in SMP · a9dc9658
      Simon Marlow authored
      In SMP mode a THUNK can change to an IND at any time.  The generic
      apply code (stg_ap_p etc.) examines a closure to determine how to
      apply it to its arguments, if it is a THUNK it must enter it first in
      order to evaluate it.  The problem was that in order to enter the
      THUNK, we were re-reading the info pointer, and possibly ending up
      with an IND instead of the original THUNK.  It isn't safe to enter the
      IND, because it points to a function (functions are never "entered",
      only applied).  Solution: we must not re-read the info pointer.
      a9dc9658
  26. 28 Feb, 2006 1 commit
    • Simon Marlow's avatar
      Allow C argument regs to be used as global regs (R1, R2, etc.) · 14a5c62a
      Simon Marlow authored
      The problem here was that we generated C calls with expressions
      involving R1 etc. as parameters.  When some of the R registers are
      also C argument registers, both GCC and the native code generator
      generate incorrect code.  The hacky workaround is to assign
      problematic arguments to temporaries first; fortunately this works
      with both GCC and the NCG, but we have to be careful not to undo this
      with later optimisations (see changes to CmmOpt).
      14a5c62a
  27. 06 Jan, 2006 1 commit
    • simonmar's avatar
      [project @ 2006-01-06 16:30:17 by simonmar] · 9d7da331
      simonmar authored
      Add support for UTF-8 source files
      
      GHC finally has support for full Unicode in source files.  Source
      files are now assumed to be UTF-8 encoded, and the full range of
      Unicode characters can be used, with classifications recognised using
      the implementation from Data.Char.  This incedentally means that only
      the stage2 compiler will recognise Unicode in source files, because I
      was too lazy to port the unicode classifier code into libcompat.
      
      Additionally, the following synonyms for keywords are now recognised:
      
        forall symbol 	(U+2200)	forall
        right arrow   	(U+2192)	->
        left arrow   		(U+2190)	<-
        horizontal ellipsis 	(U+22EF)	..
      
      there are probably more things we could add here.
      
      This will break some source files if Latin-1 characters are being used.
      In most cases this should result in a UTF-8 decoding error.  Later on
      if we want to support more encodings (perhaps with a pragma to specify
      the encoding), I plan to do it by recoding into UTF-8 before parsing.
      
      Internally, there were some pretty big changes:
      
        - FastStrings are now stored in UTF-8
      
        - Z-encoding has been moved right to the back end.  Previously we
          used to Z-encode every identifier on the way in for simplicity,
          and only decode when we needed to show something to the user.
          Instead, we now keep every string in its UTF-8 encoding, and
          Z-encode right before printing it out.  To avoid Z-encoding the
          same string multiple times, the Z-encoding is cached inside the
          FastString the first time it is requested.
      
          This speeds up the compiler - I've measured some definite
          improvement in parsing at least, and I expect compilations overall
          to be faster too.  It also cleans up a lot of cruft from the
          OccName interface.  Z-encoding is nicely hidden inside the
          Outputable instance for Names & OccNames now.
      
        - StringBuffers are UTF-8 too, and are now represented as
          ForeignPtrs.
      
        - I've put together some test cases, not by any means exhaustive,
          but there are some interesting UTF-8 decoding error cases that
          aren't obvious.  Also, take a look at unicode001.hs for a demo.
      9d7da331
  28. 02 Aug, 2005 1 commit
  29. 21 Jun, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-06-21 10:44:37 by simonmar] · 0c53bd0e
      simonmar authored
      Relax the restrictions on conflicting packages.  This should address
      many of the traps that people have been falling into with the current
      package story.
      
      Now, a local module can shadow a module in an exposed package, as long
      as the package is not otherwise required by the program.  GHC checks
      for conflicts when it knows the dependencies of the module being
      compiled.
      
      Also, we now check for module conflicts in exposed packages only when
      importing a module: if an import can be satisfied from multiple
      packages, that's an error.  It's not possible to prevent GHC from
      starting by installing packages now (unless you install another base
      package).
      
      It seems to be possible to confuse GHCi by having a local module
      shadowing a package module that goes away and comes back again.  I
      think it's nearly right, but strange happenings have been observed.
      
      I'll try to merge this into the STABLE branch.
      0c53bd0e
  30. 18 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-18 13:37:27 by simonmar] · d1c1b7d0
      simonmar authored
      Flags cleanup.
      
      Basically the purpose of this commit is to move more of the compiler's
      global state into DynFlags, which is moving in the direction we need
      to go for the GHC API which can have multiple active sessions
      supported by a single GHC instance.
      
      Before:
      
      $ grep 'global_var' */*hs | wc -l
           78
      
      After:
      
      $ grep 'global_var' */*hs | wc -l
           27
      
      Well, it's an improvement.  Most of what's left won't really affect
      our ability to host multiple sessions.
      
      Lots of static flags have become dynamic flags (yay!).  Notably lots
      of flags that we used to think of as "driver" flags, like -I and -L,
      are now dynamic.  The most notable static flags left behind are the
      "way" flags, eg. -prof.  It would be nice to fix this, but it isn't
      urgent.
      
      On the way, lots of cleanup has happened.  Everything related to
      static and dynamic flags lives in StaticFlags and DynFlags
      respectively, and they share a common command-line parser library in
      CmdLineParser.  The flags related to modes (--makde, --interactive
      etc.) are now private to the front end: in fact private to Main
      itself, for now.
      d1c1b7d0