1. 14 Aug, 2008 1 commit
    • dias@eecs.harvard.edu's avatar
      Merging in the new codegen branch · 176fa33f
      dias@eecs.harvard.edu authored
      This merge does not turn on the new codegen (which only compiles
      a select few programs at this point),
      but it does introduce some changes to the old code generator.
      
      The high bits:
      1. The Rep Swamp patch is finally here.
         The highlight is that the representation of types at the
         machine level has changed.
         Consequently, this patch contains updates across several back ends.
      2. The new Stg -> Cmm path is here, although it appears to have a
         fair number of bugs lurking.
      3. Many improvements along the CmmCPSZ path, including:
         o stack layout
         o some code for infotables, half of which is right and half wrong
         o proc-point splitting
      176fa33f
  2. 13 Apr, 2008 1 commit
  3. 12 Apr, 2008 1 commit
  4. 29 Mar, 2008 1 commit
  5. 04 Sep, 2007 1 commit
  6. 03 Sep, 2007 1 commit
  7. 01 Sep, 2007 1 commit
  8. 16 May, 2007 1 commit
  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.
      0065d5ab
  10. 18 Oct, 2004 1 commit
  11. 13 Aug, 2004 1 commit
  12. 16 Sep, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-09-16 13:03:37 by simonmar] · 2129fa6f
      simonmar authored
      Legacy Removal
      ~~~~~~~~~~~~~~
      
      The following features have been consigned to the bit bucket:
      
        _ccall_
        _casm_
        ``....''  (lit-lits)
        the CCallable class
        the CReturnable class
      2129fa6f
  13. 29 May, 2003 1 commit
    • sof's avatar
      [project @ 2003-05-29 14:39:26 by sof] · a7d8f437
      sof authored
      Support for interop'ing with .NET via FFI declarations along the
      lines of what Hugs98.NET offers, see
      
       http://haskell.org/pipermail/cvs-hugs/2003-March/001723.html
      
      for FFI decl details.
      
      To enable, configure with --enable-dotnet + have a look
      in ghc/rts/dotnet/Makefile for details of what tools are needed to
      build the .NET interop layer (tools from VS.NET / Framework SDK.)
      
      The commit doesn't include some library additions + wider-scale
      testing is required before this extension can be regarded as available
      for general use. 'foreign import dotnet' is currently only supported
      by the C backend.
      a7d8f437
  14. 29 Apr, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-04-29 14:03:38 by simonmar] · b085ee40
      simonmar authored
      FastString cleanup, stage 1.
      
      The FastString type is no longer a mixture of hashed strings and
      literal strings, it contains hashed strings only with O(1) comparison
      (except for UnicodeStr, but that will also go away in due course).  To
      create a literal instance of FastString, use FSLIT("..").
      
      By far the most common use of the old literal version of FastString
      was in the pattern
      
      	  ptext SLIT("...")
      
      this combination still works, although it doesn't go via FastString
      any more.  The next stage will be to remove the need to use this
      special combination at all, using a RULE.
      
      To convert a FastString into an SDoc, now use 'ftext' instead of
      'ptext'.
      
      I've also removed all the FAST_STRING related macros from HsVersions.h
      except for SLIT and FSLIT, just use the relevant functions from
      FastString instead.
      b085ee40
  15. 04 Mar, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-03-04 17:01:26 by simonmar] · 0171936c
      simonmar authored
      Binary Interface Files - stage 1
      --------------------------------
      
      This commit changes the default interface file format from text to
      binary, in order to improve compilation performace.
      
      To view an interface file, use 'ghc --show-iface Foo.hi'.
      
      utils/Binary.hs is the basic Binary I/O library, based on the nhc98
      binary I/O library but much stripped-down and working in terms of
      bytes rather than bits, and with some special features for GHC: it
      remembers which Module is being emitted to avoid dumping too many
      qualified names, and it keeps track of a "dictionary" of FastStrings
      so that we don't dump the same FastString more than once into the
      binary file.  I'll make a generic version of this for the libraries at
      some point.
      
      main/BinIface.hs contains most of the Binary instances.  Some
      instances are in the same module as the data type (RdrName, Name,
      OccName in particular).  Most instances were generated using a
      modified version of DrIFT, which I'll commit later.  However, editing
      them by hand isn't hard (certainly easier than modifying
      ParseIface.y).
      
      The first thing in a binary interface is the interface version, so
      nice error messages will be generated if the binary format changes and
      you still have old interfaces lying around.  The version also now
      includes the "way" as an extra sanity check.
      
      Other changes
      -------------
      
      I don't like the way FastStrings contain both hashed strings (with
      O(1) comparison) and literal C strings (with O(n) comparison).  So as
      a first step to separating these I made serveral "literal" type
      strings into hashed strings.  SLIT() still generates a literal, and
      now FSLIT() generates a hashed string.  With DEBUG on, you'll get a
      warning if you try to compare any SLIT()s with anything, and the
      compiler will fall over if you try to dump any literal C strings into
      an interface file (usually indicating a use of SLIT() which should be
      FSLIT()).
      
      mkSysLocal no longer re-encodes its FastString argument each time it
      is called.
      
      I also fixed the -pgm options so that the argument can now optionally
      be separted from the option.
      
      Bugfix: PrelNames declared Names for several comparison primops, eg.
      eqCharName, eqIntName etc. but these had different uniques from the
      real primop names.  I've moved these to PrimOps and defined them using
      mkPrimOpIdName instead, and deleted some for which we don't have real
      primops (Manuel: please check that things still work for you after
      this change).
      0171936c
  16. 15 Feb, 2002 1 commit
    • sof's avatar
      [project @ 2002-02-15 22:13:32 by sof] · d95869c5
      sof authored
      New call attribute on foreign imports, threadsafe.
      
      It indicates that a foreign import can(*) safely be called
      concurrently with the continued evaluation of other Haskell
      threads, i.e., when the foreign call is made by a Haskell
      thread, it won't hinder the progress of other threads.
      
      (*) - if the platform and RTS supports it, it _will be_
      invoked concurrently.
      d95869c5
  17. 04 Feb, 2002 1 commit
    • chak's avatar
      [project @ 2002-02-04 03:40:31 by chak] · 0299e1a1
      chak authored
      Foreign import/export declarations now conform to FFI Addendum Version 1.0
      
      * The old form of foreign declarations is still supported, but generates
        deprecation warnings.
      
      * There are some rather exotic old-style declarations which have become
        invalid as they are interpreted differently under the new scheme and there
        is no (easy) way to determine which style the programmer had in mind (eg,
        importing a C function with the name `wrapper' where the external name is
        explicitly given will not work in some situations - depends on whether an
        `unsafe' was specified and similar things).
      
      * Some "new" old-style forms have been introduced to make parsing a little bit
        easier (ie, avoid shift/reduce conflicts between new-style and old-style
        grammar rules), but they are few, arcane, and don't really hurt (and I won't
        tell what they are, you need to find that out by yourself ;-)
      
      * The FFI Addendum doesn't specify whether a header file that is requested for
        inclusion by multiple foreign declarations should be included only once or
        multiple times.  GHC at the moment includes an header as often as it appears
        in a foreign declaration.  For properly written headers, it doesn't make a
        difference anyway...
      
      * Library object specifications are currently silently ignored.  The feature
        was mainly requested for external calls in .NET (ie, calls which invoke C
        routines when Haskell is compiled to ILX), but those don't seem to be
        supported yet.
      
      * Foreign label declarations are currently broken, but they were already
        broken before I started messing with the stuff.
      
      The code is moderately tested.  All modules in lib/std/ and hslibs/lang/
      (using old-style declarations) still compile fine and I have run a couple of
      tests on the different forms of new-style declarations.
      0299e1a1
  18. 26 Jun, 2001 1 commit
  19. 24 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-24 13:59:09 by simonpj] · cbdeae8f
      simonpj authored
      ------------------------------------------------------
      	More stuff towards generalising 'foreign' declarations
      	------------------------------------------------------
      
      This is the second step towards generalising 'foreign' declarations to
      handle langauges other than C.  Now I can handle
      
        foreign import dotnet type T
        foreign import dotnet "void Foo.Baz.f( T )" f :: T -> IO ()
      
      
      
      			** WARNING **
      	I believe that all the foreign stuff for C should
      	work exactly as before, but I have not tested it
      	thoroughly.  Sven, Manuel, Marcin: please give it a
      	whirl and compare old with new output.
      
      
      Lots of fiddling around with data types.  The main changes are
      
      * HsDecls.lhs
      	The ForeignDecl type and its friends
      	Note also the ForeignType constructor to TyClDecl
      
      * ForeignCall.lhs
      	Here's where the stuff that survives right through
      	compilation lives
      
      * TcForeign.lhs DsForeign.lhs
      	Substantial changes driven by the new data types
      
      * Parser.y ParseIface.y RnSource
      	Just what you'd expect
      cbdeae8f
  20. 22 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-22 13:43:14 by simonpj] · f16228e4
      simonpj authored
      -------------------------------------------
      	Towards generalising 'foreign' declarations
      	-------------------------------------------
      
      This is a first step towards generalising 'foreign' declarations to
      handle langauges other than C.  Quite a lot of files are touched,
      but nothing has really changed.  Everything should work exactly as
      before.
      
      	But please be on your guard for ccall-related bugs.
      
      Main things
      
      Basic data types: ForeignCall.lhs
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      * Remove absCSyn/CallConv.lhs
      
      * Add prelude/ForeignCall.lhs.  This defines the ForeignCall
        type and its variants
      
      * Define ForeignCall.Safety to say whether a call is unsafe
        or not (was just a boolean).  Lots of consequential chuffing.
      
      * Remove all CCall stuff from PrimOp, and put it in ForeignCall
      
      
      Take CCallOp out of the PrimOp type (where it was always a glitch)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      * Add IdInfo.FCallId variant to the type IdInfo.GlobalIdDetails,
      	along with predicates Id.isFCallId, Id.isFCallId_maybe
      
      * Add StgSyn.StgOp, to sum PrimOp with FCallOp, because it
        *is* useful to sum them together in Stg and AbsC land.  If
        nothing else, it minimises changes.
      
      
      Also generally rename "CCall" stuff to "FCall" where it's generic
      to all foreign calls.
      f16228e4