Florian Klämpfl schrieb:
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.
Yes, it's an AST, but I didn't want to put too much into the
advertisement ;-)
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.
I couldn't find out how the code generator is involved. Most methods are
non-virtual...
4) It's not yet known how the rest of a unit (declarations...) is
represented internally.
It is processed directly.
This means that the parser must be patched.
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
Not really. The semantic actions are so complex, that another call (to
them) should not matter.
- 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.
Yes and no. A good separation will help to clarify much.
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.
We'll see ;-)
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
