separate module compilation

[GoogleCodeExporter]

The initial bootsrap is starting to take time now that there is a ton of code 
being compiled and executed at least twice by the vanilla vm.

One way to make things better would be to allow compiling all the libraries in 
parallel. The fasl encoding would make this easy, but there are some unresolved 
issues what the thing to be serialized should actually contain.

Main unresolved issue: how should the bindings in one module end up pointing to 
those in another? Some options:

 - write a linker which essentially does a search & replace over the module at load time pointing some unique placeholder values to those in the loaded dependency library

 - use higher order modules, or actually just functions, for which (module-gen dep-module-1 .. dep-module-n) -> actual-module

 - have all the modules included in each library as in regular fasl. this doesn't sound too good in this context, but added as an option since the philosophy of linking everything is used by default elsewhere (in regular fasl and closure representation)

Original issue reported on code.google.com by aohelin on 27 Dec 2011 at 9:42

[GoogleCodeExporter]

 - have separate (fasl-modular-encode <thing> <modules>) -> encode module info and dependencies first, and then a regular fasl object with links which are filled in at decode-time, (fasl-modular-decode ...) which does that, and (fasl-modular-load <path> (<lib-path> ...)) which tries to automatically load the libraries as needed if they aren't already loaded.

Original comment by aohelin on 28 Dec 2011 at 8:44

[GoogleCodeExporter]

 - how to handle varying (macro) instruction sets? probably best to have precompiled modules contain vanilla bytecode and have the loading owl be responsible of any translation. other option would be to make the fasls vm-dependent, which sounds like a bad idea. the bytecode<->macro-op mapping could be handled by the same store which handles code sharing.

Original comment by aohelin on 28 Dec 2011 at 10:23

[GoogleCodeExporter]

Original comment by aohelin on 18 May 2012 at 7:58

• Added labels: Type-Enhancement
• Removed labels: Type-Defect