> > 3) The compiler builds an parse tree for every procedure, but I found no > way yet to make this tree accessible.
It is no parse tree but some intermediate represensation. > There should exist a > method/procedure in the CPU specific code, that is called to create the > binary code for a procedure, but I could not yet locate it. psub.pas: tcgprocinfo.generate_code, it is generic. > > 4) It's not yet known how the rest of a unit (declarations...) is > represented internally. It is processed directly. > > In detail the last item [5] suggests an more flexible parser, that can > do with the scanned tokens whatever is appropriate in the scope of a > specific application. The general solution is a separation of the > syntactical and semantical procedures in the parser. For fastest > processing the semantical code can be made selectable just as for the > CPU, by placing this code into a dedicated directory. I hope that this > solution is acceptable to the FPC maintainers, and I'm willing to > refactor all the parser units accordingly. I see two problems: - speed - reduced readability of the parser code because the code for handling something will be spread over different locations resulting also in reduced maintainability: just look at the code generator code, to support different architectures fpc the code generator is split at several levels making it very hard to get an overview on it and even more get into it. > One big advantage of the separation into syntactical and semantical > parts is the chance for adding further languages to the compiler, Is this really desired? The advantages of fpc are that it is written in its native language but its code generator is not sophisticated enough so it's imo not worth to add another front end. -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
