Changes between Version 2 and Version 3 of NewPlugins

Timestamp:

01/17/11 14:07:42 (2 years ago)

Author:

thoughtpolice

Comment:

--

NewPlugins

@@ -101 +101 @@
 Backends could be written using plugins as well. This would make it possible to 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, among other crazy things.
 
- * New interface to `Plugin` that is used by `CodeOutput` for custom (named) backends?
-  * TODO FIXME: current assumptions about output files/etc that would make this infeasible? Not sure where e.g. the linker is finally invoked in case you even wanted to write a backend that did something super-fancy involving duping it (LTO?)
-
- * Names would be needed since we cannot arbitrarily extend `HscTarget` - we would need some new case such as `HscPluginBackend String`, but this is sort of ugly.
+ * New interface to `Plugin` that is used by `CodeOutput` for custom backends?
+  * TODO FIXME: any assumptions about the backend that would invalidate this general idea?
 
 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.
+
+All backends are given the final Cmm programs in the form of the `RawCmm` datatype.
+
+Possible interface: extend `Plugin` with a new constructor, which can have a Cmm backend (TODO: should `DynFlags` argument to plugin be replaced with type `[CommandLineOption]` that is already in use?)
+
+{{{
+type CmmBackendPlugin = Maybe (String,(DynFlags -> FilePath -> [RawCmm] -> IO ()))
+
+data Plugin = Plugin {
+  ...
+  installCmmBackend :: CmmBackendPlugin
+  ...
+}
+
+defaultPlugin = Plugin {
+  ...
+  installCmmBackend = Nothing
+}
+
+}}}
+
+Then, to use:
+
+{{{
+module Some.Cmm.Plugin (plugin) where
+import GHCPlugins
+
+plugin :: Plugin
+plugin = defaultPlugin {
+  installCmmBackend = Just ("Wharble code generator backend", backend)
+}
+
+backend :: DynFlags -> FilePath -> [RawCmm] -> IO ()
+backend dflags filenm flat_absC = do
+  ...
+}}}
+
+Modifications to compiler pipeline:
+
+ * Dynamic code loading can be provided by the same code that works for Core plugins, so this is DONE
+ * Extending `HscTarget` to recognize the new compilation output case
+  * Might not be necessary. We can load plugins whenever, and scrutinize the 'installCmmField' to see if there is `Nothing` and if there is,
+    invoke the normal pipeline, otherwise call our own backend and exit.
+ * Modify `compiler/main/CodeOutput.lhs` to invoke the plugin callback.
+  * Plugin-based backends should automatically prioritize over built-in backends?