summaryrefslogtreecommitdiff
path: root/compiler/ghci/ByteCodeInstr.lhs
Commit message (Collapse)AuthorAgeFilesLines
* Convert GHCi sources from .lhs to .hsRodlogic2014-10-291-329/+0
| | | | | | | | | | | | | | Summary: Signed-off-by: Rodlogic <admin@rodlogic.net> Test Plan: Does it compile? Reviewers: hvr, austin Reviewed By: austin Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D319
* ghci: detabify/unwhitespace ByteCodeInstrAustin Seipp2014-07-201-92/+84
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Add LANGUAGE pragmas to compiler/ source filesHerbert Valerio Riedel2014-05-151-1/+2
| | | | | | | | | | | | | | | | | | In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been reorganized, while following the convention, to - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before any `{-# OPTIONS_GHC #-}`-lines. - Moreover, if the list of language extensions fit into a single `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each individual language extension. In both cases, try to keep the enumeration alphabetically ordered. (The latter layout is preferable as it's more diff-friendly) While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-1/+1
|
* Strings and comments only: 'to to ' fixesGabor Greif2013-08-221-1/+1
| | | | I'd still prefer if a native english speaker would check them.
* Remove the old codegenSimon Marlow2012-10-191-3/+3
| | | | | Except for CgUtils.fixStgRegisters that is used in the NCG and LLVM backends, and should probably be moved somewhere else.
* Make StgWord a portable type tooIan Lynagh2012-09-181-1/+1
| | | | | StgWord is a newtyped Word64, as it needed to be something that has a UArray instance.
* Use -fwarn-tabs when validatingIan Lynagh2011-11-041-0/+7
| | | | | We only use it for "compiler" sources, i.e. not for libraries. Many modules have a -fno-warn-tabs kludge for now.
* Improve pretty-printing of BCOs (-ddump-bcos)Simon Marlow2011-11-021-9/+36
|
* refactoring and fixing the stage 2 compilationSimon Marlow2011-08-251-0/+1
|
* Remove unused ghci/ByteCodeFFI.lhsIan Lynagh2011-05-251-1/+1
|
* Interruptible FFI calls with pthread_kill and CancelSynchronousIO. v4Edward Z. Yang2010-09-191-1/+7
| | | | | | | | | | | | | | | | | | | | | | | 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.
* implement case-on-Word in the byte code generator/interpreter (#2881)Simon Marlow2009-09-181-0/+6
|
* Make the types we use when creating GHCi bytecode better match realityIan Lynagh2009-07-291-59/+59
| | | | | We were keeping things as Int, and then converting them to Word16 at the last minute, when really they ought to have been Word16 all along.
* Fix warnings in ByteCodeInstrIan Lynagh2008-12-291-12/+3
|
* Support for using libffi to implement FFI calls in GHCi (#631)Simon Marlow2008-02-041-1/+1
| | | | | | | | | | | | This means that an unregisterised build on a platform not directly supported by GHC can now have full FFI support using libffi. Also in this commit: - use PrimRep rather than CgRep to describe FFI args in the byte code generator. No functional changes, but PrimRep is more correct. - change TyCon.sizeofPrimRep to primRepSizeW, which is more useful
* Use GHC.Exts rather than GHC.PrimIan Lynagh2007-12-021-1/+1
|
* GHCi: use non-updatable thunks for breakpointsSimon Marlow2007-10-101-2/+5
| | | | | | | | | The extra safe points introduced for breakpoints were previously compiled as normal updatable thunks, but they are guaranteed single-entry, so we can use non-updatable thunks here. This restores the tail-call property where it was lost in some cases (although stack squeezing probably often recovered it), and should improve performance.
* Fix CodingStyle#Warnings URLsIan Lynagh2007-09-041-1/+1
|
* Use OPTIONS rather than OPTIONS_GHC for pragmasIan Lynagh2007-09-031-2/+2
| | | | | | | 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.
* Add {-# OPTIONS_GHC -w #-} and some blurb to all compiler modulesIan Lynagh2007-09-011-0/+8
|
* small performance improvement: unbox some fieldsSimon Marlow2007-05-151-9/+10
|
* Refactoring, tidyup and improve layeringSimon Marlow2007-05-021-1/+1
| | | | | | | | | | | | | | | The stack of breakpoint resume contexts is now part of the InteractiveContext and managed by the GHC API. This prevents misuse of the resume context by the client (e.g. resuming a breakpoint that isn't the topmost, which would lead to a confused IC at the least). I changed the TypeEnv in the IC to a [Id]. It only contained Ids anyway, and this allows us to have shadowing, which removes an ugly and annoying restriction. The parts of the GHC API which deal with interactive evaluation are now in a module of their own, InteractiveEval.
* remember the type of _resultSimon Marlow2007-04-251-1/+4
|
* Re-working of the breakpoint supportSimon Marlow2007-04-171-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* MERGE: Fix Windows DEP violations (bug #885)Simon Marlow2006-12-121-1/+3
| | | | Original patch by brianlsmith@gmail.com
* Add ppr for the MKPAP case, and rearrange the other cases to match the datatypeIan Lynagh2006-11-201-4/+6
|
* More import tidying and fixing the stage 2 buildSimon Marlow2006-10-111-10/+11
|
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+256
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.
View Lorry Controller Status