Changes between Version 36 and Version 37 of NewPlugins


Ignore:
Timestamp:
Jan 24, 2011 9:48:32 PM (5 years ago)
Author:
thoughtpolice
Comment:

remove backends stuff, since it's a little out of the current scope

Legend:

Unmodified
Added
Removed
Modified
  • NewPlugins

    v36 v37  
    11= New Plugins work =
    22
    3 Max originally did the work on [wiki:Plugins GHC plugins] in his GSoC 2008 hacking sprint. It involved the implementation of [wiki:Plugins/Annotations annotations] as well as a dynamic loading aspect to GHC. While the annotations work was included into GHC HEAD, the loading infrastructure was not. This document describes the current work (as of 2011) to get it integrated into GHC HEAD so you can write core plugins, and future extensions to the interface, primarily writing C-- passes, and new backends.
     3Max originally did the work on [wiki:Plugins GHC plugins] in his GSoC 2008 hacking sprint. It involved the implementation of [wiki:Plugins/Annotations annotations] as well as a dynamic loading aspect to GHC. While the annotations work was included into GHC HEAD, the loading infrastructure was not. This document describes the current work (as of 2011) to get it integrated into GHC HEAD so you can write core plugins, and future extensions to the interface, primarily writing C-- passes.
    44
    55This page explains what the plug-in mechanism does, how to use it, and a little about the implementation.  For discussion, and the current state of play, see the ticket: #3843. If you're interested in writing plugins for GHC, '''please comment and give feedback, we want to do it right'''!
     
    127127TODO: fixme. check and explain current Hoopl combinators for deep/shallow passes (deepFwdRw and deepBwdRw,) as well as composing them (thenFwdRw and thenBwdRw) and how they should fit into this part of the API
    128128
    129 == New Backends ==
    130 
    131 1/21/2011: So half-baked it's not funny, but still thinking of ideas after reading `./compiler/main` for an hour or so. Most of this is probably stupid - I'm open to ideas on a mammoth project like this.
    132 
    133 Backends could be written using plugins as well. This would make it possible to, for example pull the LLVM code generator out of GHC, and into a `cabal` package using the [http://hackage.haskell.org/package/llvm llvm] bindings on hackage (like the dragonegg plugin for GCC) among other crazy things.
    134 
    135  * New interface to `Plugin` that is used by `CodeOutput` for custom backends?
    136   * TODO FIXME: any assumptions about the backend that would invalidate this general idea?
    137 
    138 Currently the new code generator converts the new Cmm based on Hoopl to the old Cmm representation when in use, so it can be passed onto the current native code generators. So adding this part of the API is rather independent of the current status of the new backend - the backend API just has to use the old CMM representation for conversion.
    139 
    140 All backends are given the final Cmm programs in the form of the `RawCmm` datatype.
    141 
    142 Possible (and obviously crappy rough draft) interface: extend `Plugin` with a new field on the constructor, which can have a Cmm backend (TODO: should `DynFlags` argument to plugin be replaced with type `[CommandLineOption]` that is already in use?)
    143 
    144 {{{
    145 type CmmBackend = DynFlags -> FilePath -> [RawCmm] -> IO ()
    146 type CmmBackendPlugin = Maybe (String, CmmBackend)
    147 
    148 data Plugin = Plugin {
    149   ...
    150   installCmmBackend :: CmmBackendPlugin
    151   ...
    152 }
    153 
    154 defaultPlugin = Plugin {
    155   ...
    156   installCmmBackend = Nothing
    157 }
    158 
    159 }}}
    160 
    161 Then, to use:
    162 
    163 {{{
    164 module Some.Cmm.Plugin (plugin) where
    165 import GHCPlugins
    166 
    167 plugin :: Plugin
    168 plugin = defaultPlugin {
    169   installCmmBackend = Just ("Wharble code generator backend", backend)
    170 }
    171 
    172 backend :: DynFlags -> FilePath -> [RawCmm] -> IO ()
    173 backend dflags filenm flat_absC = do
    174   ...
    175 }}}
    176 
    177 `backend` is expected, roughly, to produce some intermediate code of some sort (like .S files for GNU as or .bc for LLVM.)
    178 
    179 Modifications to compiler pipeline:
    180 
    181  * Dynamic code loading can be provided by the same code that works for Core plugins, so this is DONE
    182  * Extending `HscTarget` to recognize the new compilation output case
    183   * Might not be necessary. We can load plugins whenever, and scrutinize the 'installCmmBackend' field to see if there is `Nothing` and if there is,
    184     invoke the normal pipeline, otherwise call our own backend and exit then.
    185  * Modify `compiler/main/CodeOutput.lhs` to invoke the plugin callback.
    186   * Should Plugin-based backends should automatically prioritize over built-in backends (i.e., if it gets loaded through `-fplugin`, it is gettin' used no question?)
    187  * `DriverPipeline` needs to be aware of how to integrate a new backend into the overall compilation phase - for example, see `compiler/main/DriverPipeline.hs`, specifically
    188    `runPhase` which does things like running the LLVM optimizer, compiler and LLVM mangler when the LLVM backend is invoked. Afterwords, the assembler is invoked on the
    189    resultant asm files, followed by linking.
    190   * Even though normally the backends are responsible for the code generation up to but not including linking, the Cmm backends need to have some concept of how to link together the final resultant program, and GHC needs to give it the necessary information - the plugin could very well want to do its own linking/final compilation steps for good reasons.
    191 
    192129= References =
    193130