So having a long think over the past day, I'm starting to turn against
the second idea I had because it would require complex state variable
tracking and is just asking for a new bug to be introduced, not to
mention that the additional overhead will probably offset any potential
speed gains, so the cleaner, simple solution sounds far more appealing
now. Also, when it comes to dead nodes (an except section that gets
removed or any code following "Exit" in the same block), there's nothing
to stop the compiler from deleting the nodes completely, since semantics
have already been checked (and maybe chucking in an extra "unreachable
code" warning if needs be), thus pruning the tree and making the process
faster for pass_generate_code.
I do wonder why 'simplify' is a distinct method though, because a lot of
the time one can simply put its code at the end of 'pass_1' and there
wouldn't be any difference in functionality (plus what counts as
'pass_1' and what counts as 'simplify' is often left to the programmer's
discretion) while nodes that have more complex simplification, like
taddnode, could use their own private methods. It might be something
for me to experiment with on the side.
So the node parsing overhaul, so far...
- pass_semantic
- pass_transform (what was "pass_1")
- simplify (if not merged into the above)
- pass_generate_code (I won't touch this for now)
On another note, I do think pass_2 (pass_generate_code) could use some
refactoring. I don't like how "flowcontrol" is a global variable.
Though it's unlikely to happen, such a state variable not being tied to
a management object (e.g. current_procinfo) prevents the compiler from
being multi-threaded, at least for that pass.
Gareth aka. Kit
P.S. Anyone got a better name for "pass_transform"?
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
