- 19 Sep, 2010 1 commit
-
-
Edward Z. Yang authored
This is patch that adds support for interruptible FFI calls in the form of a new foreign import keyword 'interruptible', which can be used instead of 'safe' or 'unsafe'. Interruptible FFI calls act like safe FFI calls, except that the worker thread they run on may be interrupted. Internally, it replaces BlockedOnCCall_NoUnblockEx with BlockedOnCCall_Interruptible, and changes the behavior of the RTS to not modify the TSO_ flags on the event of an FFI call from a thread that was interruptible. It also modifies the bytecode format for foreign call, adding an extra Word16 to indicate interruptibility. The semantics of interruption vary from platform to platform, but the intent is that any blocking system calls are aborted with an error code. This is most useful for making function calls to system library functions that support interrupting. There is no support for pre-Vista Windows. There is a partner testsuite patch which adds several tests for this functionality.
-
- 30 Mar, 2010 1 commit
-
-
waern authored
The instances (and deriving declarations) have been taken from the ghc-syb package.
-
- 04 Jan, 2010 1 commit
-
-
Ben.Lippmeier@anu.edu.au authored
-
- 02 Jan, 2010 1 commit
-
-
Ben.Lippmeier@anu.edu.au authored
-
- 27 Jul, 2009 1 commit
-
-
Simon Marlow authored
It still lives in darcs, if anyone wants to revive it sometime.
-
- 24 Jul, 2009 1 commit
-
-
Ian Lynagh authored
-
- 09 Jun, 2009 1 commit
-
-
Duncan Coutts authored
First in a series of patches to add the feature. This patch just adds PrimCallConv to the CCallConv type.
-
- 11 Jun, 2009 1 commit
-
-
Duncan Coutts authored
-
- 14 Aug, 2008 1 commit
-
-
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
-
- 13 Apr, 2008 1 commit
-
-
Ian Lynagh authored
-
- 12 Apr, 2008 1 commit
-
-
Ian Lynagh authored
-
- 29 Mar, 2008 1 commit
-
-
Ian Lynagh authored
Modules that need it import it themselves instead.
-
- 04 Sep, 2007 1 commit
-
-
Ian Lynagh authored
-
- 03 Sep, 2007 1 commit
-
-
Ian Lynagh authored
Older GHCs can't parse OPTIONS_GHC. This also changes the URL referenced for the -w options from WorkingConventions#Warnings to CodingStyle#Warnings for the compiler modules.
-
- 01 Sep, 2007 1 commit
-
-
Ian Lynagh authored
-
- 16 May, 2007 1 commit
-
-
Michael D. Adams authored
-
- 07 Apr, 2006 1 commit
-
-
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.
-
- 18 Oct, 2004 1 commit
-
-
simonmar authored
ccallConvAttribute: use __attribute__((__stdcall__)) rather than __stdcall (the latter is Win32-specific).
-
- 13 Aug, 2004 1 commit
-
-
simonmar authored
Merge backend-hacking-branch onto HEAD. Yay!
-
- 16 Sep, 2003 1 commit
-
-
simonmar authored
Legacy Removal ~~~~~~~~~~~~~~ The following features have been consigned to the bit bucket: _ccall_ _casm_ ``....'' (lit-lits) the CCallable class the CReturnable class
-
- 29 May, 2003 1 commit
-
-
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.
-
- 29 Apr, 2002 1 commit
-
-
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.
-
- 04 Mar, 2002 1 commit
-
-
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).
-
- 15 Feb, 2002 1 commit
-
-
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.
-
- 04 Feb, 2002 1 commit
-
-
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.
-
- 26 Jun, 2001 1 commit
-
-
simonpj authored
Add comments
-
- 24 May, 2001 1 commit
-
-
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
-
- 22 May, 2001 1 commit
-
-
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.
-