Am 06.09.2010 16:12, schrieb Hans-Peter Diettrich: > Florian Klaempfl schrieb: > >>> I have no real idea, how in such a model the initialization of the >>> threadvars has to be implemented. That's why I try to assign all >>> state-related variables to a definite object, whose reference can be >>> easily copied (or moved?) into any created thread. >> >> In case of current_filepos, the initialization could be done by the >> specific worker thread class doing e.g. code generation. > > I see the main problem in the identification of all the global > variables, that have to become threadvars. Or do you know of an way, to > make the compiler identify variables that have to become threadvars?
No. > Another more recent experiment was to convert the back-ends into > classes. It turned out that much target-specific code resides in the > general compiler units, whose separation into virtual back-end methods > would involve much work. In another approach the $IFDEFs could be > replaced by ordinary IFs, what would both simplify the redesign and > preserve the current compiler speed. You still didn't point out which locations you actually mean. > > >>> The current compiler "structure" is >>> dictated by purely *formal* aspects (unit dependencies), and does not >>> reflect the *logical* dependencies between objects, variables, >>> procedures etc. >> >> The problem is (very simplified): in a compiler everything depends on >> everything, so getting some structure is only possible with some >> formalism, formalism is the last resort when logic does not work >> anymore. Formalism is also something absolute while logic might be >> rather subjective. > > I dare to disagree. It's not so hard to encapsulate everything in > dedicated (mostly existing) classes. Only the requirement, that > *external* tools should be able to use part of the compiler, without > importing too many dependencies, results in the implementation of > otherwise unneeded hacks and workarounds. In a radical OO redesign the > number of involved units (and global variables) could be reduced > dramatically, Why do you want to reduce them? Logic or formalism? > so that finally the compiler could be decomposed into a > small number of building blocks (packages...), with tiny interfaces to > each other. Counter example: your attempt of the OOP parser :) > > >>> This lack of logical structure, next lack of up-to-date >>> documentation, >> >> Nobody volounteered yet to continue Carl's work of documenting the >> compiler. > > Where can this work be found? Do you mean the 1.x PDF document, that is > not helpful with newer versions? Yes. > > As mentioned above, I've started an documentation attempt some time ago. > But after many arising questions remained unanswered, I had to figure > out everything myself. Indeed, that's what we do as well :) Some parts of the compiler, e.g. parser, are probably not touched for 10 years. > And after I found out that the current compiler > implementation is based on formal requirements, not on logical ones, I As I said before: formalism is absolute, logic is subjective so in complex situation formalism is really helpful. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
