On 21 Aug 2011, at 19:05, dmitry boyarintsev wrote: > On Sun, Aug 21, 2011 at 3:45 AM, Jonas Maebe <[email protected]> > wrote: >> >> On 21 Aug 2011, at 02:37, dmitry boyarintsev wrote: >> >>> So there're actually 2 code generators right now. One is used for JVM >>> and another is used for native machine code? >> >> The JVM target only uses the high level code generator. The other targets >> use a combination of both. > > Are there a plans to merge branches (trunk and jvm branch) together?
Yes, once other developers have had the chance to review the jvm branch and comment about it. Other requirements are that there are no regressions for non-JVM targets anymore (although I think I fixed all of those today) and that all new memory leaks are fixed (there are a few in the new symcreat unit). > What about changing the native code generator to become more "high > level" as JVM? That doesn't really offer any advantages, so I'm not sure whether it's worth the trouble. Code generation has two parts in the compiler: * all parse tree nodes have a method called pass_generate_code that calls general code generator routines * the code generator returns emit assembler statements In svn trunk, all pass_generate_code routines called the low level code generation routines. In the jvm branch, several of those pass_generate_code routines have been converted to call the high level code generator. For native targets, there is a special high level code generator implementation that generally just calls through to the low level code generator. As long as new implementations of pass_generate_code methods use the high level code generator (which has almost the same interface as the low level code generator, only the "size" parameters are high level definitions instead of only things like "4 byte unsigned value"), and if new code generator methods are added to the high level instead of low level code generator classes, there should be no problem keeping everything in sync without duplicating any work (and without making things harder for anyone). Jonas_______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
