- 07 Mar, 2006 1 commit
-
-
David Himmelstrup authored
MkIface.writeIfaceFile doesn't check GhcMode anymore. All it does is what the name say: write an interface to disk. I've refactored HscMain so the logic is easier to manage. That means we can avoid running the simplifier when typechecking (: And best of all, HscMain doesn't use GhcMode at all, anymore! The new HscMain intro looks like this: It's the task of the compilation proper to compile Haskell, hs-boot and core files to either byte-code, hard-code (C, asm, Java, ect) or to nothing at all (the module is still parsed and type-checked. This feature is mostly used by IDE's and the likes). Compilation can happen in either 'one-shot', 'batch', 'nothing', or 'interactive' mode. 'One-shot' mode targets hard-code, 'batch' mode targets hard-code, 'nothing' mode targets nothing and 'interactive' mode targets byte-code. The modes are kept separate because of their different types and meanings. In 'one-shot' mode, we're only compiling a single file and can therefore discard the new ModIface and ModDetails. This is also the reason it only targets hard-code; compiling to byte-code or nothing doesn't make sense when we discard the result. 'Batch' mode is like 'one-shot' except that we keep the resulting ModIface and ModDetails. 'Batch' mode doesn't target byte-code since that require us to return the newly compiled byte-code. 'Nothing' mode has exactly the same type as 'batch' mode but they're still kept separate. This is because compiling to nothing is fairly special: We don't output any interface files, we don't run the simplifier and we don't generate any code. 'Interactive' mode is similar to 'batch' mode except that we return the compiled byte-code together with the ModIface and ModDetails.
-
- 06 Mar, 2006 5 commits
-
-
David Himmelstrup authored
-
wolfgang.thaller@gmx.net authored
-
wolfgang.thaller@gmx.net authored
-
wolfgang.thaller@gmx.net authored
In the rare event that a .o file contains more than one flavour of a [non]lazy pointers sections, resolve all of them, not just one.
-
David Himmelstrup authored
-
- 05 Mar, 2006 1 commit
-
-
David Himmelstrup authored
-
- 04 Mar, 2006 12 commits
-
-
David Himmelstrup authored
-
David Himmelstrup authored
-
David Himmelstrup authored
I've changed the name to 'getGhcMode'. If someone changes it back, please write an explanation above it.
-
David Himmelstrup authored
-
David Himmelstrup authored
-
David Himmelstrup authored
-
David Himmelstrup authored
-
David Himmelstrup authored
-
David Himmelstrup authored
-
David Himmelstrup authored
-
David Himmelstrup authored
-
David Himmelstrup authored
None of the new code is in use yet. The current Haskell compiler (HscMain.hscMain) isn't as typed and as hack-free as we'd like. Here's a list of the things it does wrong: * In one shot mode, it returns the new interface as _|_, when recompilation isn't required. It's then up to the users of hscMain to keep their hands off the result. * (Maybe ModIface) is passed around when it's known that it's a Just. Hey, we got a type-system, let's use it. * In one shot mode, the backend is returning _|_ for the new interface. This is done to prevent space leaks since we know that the result of a one shot compilation is never used. Again, it's up to the users of hscMain to keep their hands off the result. * It is allowed to compile a hs-boot file to bytecode even though that doesn't make sense (it always returns Nothing::Maybe CompiledByteCode). * Logic and grunt work is completely mixed. The frontend and backend keeps checking what kind of input they're handling. This makes it very hard to get an idea of what the functions actually do. * Extra work is performed when using a null code generator. The new code refactors out the frontends (Haskell, Core), the backends (Haskell, boot) and the code generators (one-shot, make, nothing, interactive) and allows them to be combined in typesafe ways. A one-shot compilation doesn't return new interfaces at all so we don't need the _|_ space-leak hack. In 'make' mode (when not targeting bytecode) the result doesn't contain Nothing::Maybe CompiledByteCode. In interactive mode, the result is always a CompiledByteCode. The code gens are completely separate so compiling to Nothing doesn't perform any extra work. DriverPipeline needs a bit of work before it can use the new API.
-
- 03 Mar, 2006 1 commit
-
-
Simon Marlow authored
When the volatile regs attached to a CmmCall is Nothing, it means "save everything", not "save nothing".
-
- 09 Feb, 2006 1 commit
-
-
wolfgang.thaller@gmx.net authored
-
- 05 Feb, 2006 2 commits
-
-
wolfgang.thaller@gmx.net authored
-
wolfgang.thaller@gmx.net authored
-
- 03 Feb, 2006 1 commit
-
-
wolfgang.thaller@gmx.net authored
-
- 02 Mar, 2006 6 commits
-
-
simonpj@microsoft.com authored
After a long hunt I discovered that the reason that GHC.Enum.eftIntFB was being marked as a loop-breaker was the bizare behaviour of exprFreeVars, which returned not only the free variables of an expression but also the free variables of RULES attached to variables occuring in the expression! This was clearly deliberate (the comment was CoreFVs rev 1.1 in 1999) but I've removed it; I've left the comment with further notes in case there turns out to be a Deep Reason.
-
Simon Marlow authored
This turned out to be a lot easier than I thought. Just moving a few bits of -split-objs support from the build system into the compiler was enough. The only thing that Cabal needs to do in order to support -split-objs now is to pass the names of the split objects rather than the monolithic ones to 'ar'.
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
simonpj@microsoft.com authored
-
- 01 Mar, 2006 10 commits
-
-
David Himmelstrup authored
-
simonpj@microsoft.com authored
-
Simon Marlow authored
The NCG cannot be used in an unregisterised compiler, so there's no point in including it.
-
simonpj@microsoft.com authored
Sadly the above patch wasn't right, because it fouls up pre/postInlineUnconditionally. This patch puts things back as they were functionally, but with slightly tidied-up code.
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
contributed by Neil Mitchell <ndmitchell@gmail.com>, with docs by me.
-
Simon Marlow authored
this is so that the stage1 compiler has proper support for Unicode. Should fix these errors: lexical error in string/character literal at character '\8759' when building the stage2 compiler.
-