In preparation for the upcoming PDS, I would like to describe the plan for the removal of IMCC from libparrot. The majority of the coding work can be completed by the 3.3 release, and I suggest we make it an official roadmap priority item between now and then.
The ultimate plan for IMCC is to have it separated out into it's own stand-alone shared library (libparrot-imcc?), which can then be loaded by a user application where necessary. A perfect example of this will be the standard Parrot executable program (frontend/parrot/main.c), which links libparrot and IMCC. Complete separation likely will not happen after 3.3 (especially if we need to perform additional deprecations), but the majority of the primary coding work can be done before 3.3. A big part of the problem with IMCC is the fact that it's currently built in to libparrot, receives a large amount of preferrential treatment, and uses special interfaces that other compilers do not have access to. This creates unequal footing where we can't use a different compiler frontend natively because the interfaces don't exist to use anything besides IMCC. By separating IMCC out of libparrot, identifying the interfaces and assumptions that it relies on, and then exposing those things in a standard way, we gain a much more flexible, pluggable, and powerful libparrot. The basic steps in this plan are as follows: 1. IMCC needs to be modified so that it's functions pass a reference to the imc_info_t* structure instead of a pointer to the Parrot interpreter structure. Likewise, the field interp->imcc_info needs to be removed from the interpreter. We do not initialize IMCC at the same time as we initialize the interpreter, and in programs where we do not need IMCC we do not initialize IMCC at all. 1a. Similarly, we need to modify IMCC so that it no longer writes data directly to fields in the Parrot interpreter structure. This creates problems with reusability and reentrancy, and requires all other compilers to work around the problems in IMCC instead of being able to safely ignore those problems. 2. The public-facing interface functions for IMCC need to be cleaned up and simplified so that we can easily call them and use IMCC from a larger set of possible front-end applications. We need a simple and small set of functions to create, initialize and setup an instance of the IMCC compiler. We also need simple-to-use functions for compiling (both from a string of code and from a file), and 3. We need to replace the current IMCC compiler PMC ($P0 = compreg "PIR"), which is currently a thin NCI wrapper around an IMCC interface routine, with a more robust and abstracted PMC type. An "IMCCompiler" PMC type can hold state information about IMCC so the interpreter doesn't have to hold it directly (See #1 above), and can provide a set of methods and capabilities more in line with HLLCompiler and PDD31. Initially, because all current-generation Parrot compilers and utilities require the existence of a PIR compiler, this IMCCompiler PMC type will be built-in. Eventually, it will be moved to be a dynpmc (probably after 3.3). 4. (optional. This can happen after 3.3 so long as IMCCompiler PMC still a built-in) We need to modify several areas in libparrot which assume the presence of a PIR compiler to no longer make those assumptions. The old embedding interface function "Parrot_compile_string" assumes the string is PIR code and calls IMCC directly. This needs to be replaced with the new API function "Parrot_api_get_compiler" which searches for a compiler by name, and then other API functions which can be used to find and invoke a method on that compiler. Also, the "load_bytecode" op currently can load a .pbc file directly or can take a .pir filename argument, compile it to PBC and load that. This secondary behavior either needs to be removed or needs to be extended to allow the use of a user-specifiable compiler for fallback. 5. We need to modify the makefile to compile IMCC into it's own stand-alone shared library. After item #4 above, libparrot should no longer be making explicit references to IMCC, so we will not have any circular dependencies. libparrot-imcc can link to libparrot, and the parrot frontend executable can link to both of them. At this point, the job is completely finished and IMCC is removed from libparrot. Steps #1, #2 and #3 above are all in process in a series of branches right now (whiteknight/imcc_info_struct, whiteknight/imcc_new_api, and whiteknight/imcc_compreg_pmc). I will probably be starting a new branch to work on #1a soon also, since it is affecting work in the first three branches. This more than anything is likely also going to require significant changes, cleanups and improvements to PackFiles and the PackFile subsystem API, which are happening concurrently. These first items (#1, #1a, #2, and #3) should all be completed and mergable before the 3.3 release at the latest. The branches I listed represent several significant changes to the codebase. I recommend any hacker interested in getting involved in this project should take a look at the work completed already, and feel free to ask me any questions about what I have done already or what is planned to be done in the near future. I would like to discuss this issue in depth at PDS, and I would like to attract a team of developers interesting in helping to push this issue forward. Thanks, --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
