[fpc-devel] NoGlobals branch

Hans-Peter Diettrich DrDiettrich1 at aol.com
Wed Aug 18 12:34:38 CEST 2010

The removal of global variables is almost finished now. I know that the 
code currently doesn't look nice, and that performance can be improved, 
but these are minor details compared to the attempts to not break the 
compiler itself.

In the last round a GlobalModule has been added, that plays the role of 
a not yet existing current_module at compiler initialization. Since the 
remaining global variables currently are scattered across many units, 
they could be moved all into the GlobalModule - any opinions?

For performance reasons it were nice to have unit-level properties with 
variable refences for the getters, instead of subroutines - any reasons 
why this is not allowed right now?

What should be done in the next step?

In contrast to the preceding OO approach, a bunch of ordinary procedures 
still waits for becoming methods, with faster access to frequently used 
class members. Should I try to convert the procedures to methods now, or 
should I wait until everything else has settled down?

Another task were the separation of the implementation parse and code 
generation, from interface parsing. This separation would allow for 
multiple worker threads for e.g. code generation.

Any suggestions?


More information about the fpc-devel mailing list