Am 20.08.2010 12:39, schrieb Hans-Peter Diettrich: > Jonas Maebe schrieb: > >>> Such complications can be eliminated by a refactoring of the >>> targets, into dedicated classes. This can be done in the same >>> branch, because the existing units (in the target directories) have >>> conflicting names, and consequently must be replaced by new unit >>> trees - something similar to the systems implementation. >> >> I don't understand why this "consequently must be" done. The compiler >> only supports generating code for a single architecture, and there >> are no plans to change this. It would needlessly complicate the >> compiler source. > > My experience with the compiler sources is different. The many > conditional parts, which are not even properly chained by {$ELSEIF ...}, > make the maintance and refactoring a mess :-( > > Currently the introduction of a new target CPU requires to update many > parts of the existing general compiler units,
E.g.? I just greped for ifdef sparc in the general compiler directory: 11 hits: - 5 in ogelf.pas (elf output generator, so quite natural) - 1 in globals.pas to define the default cpu switches in init_settings - 2 in options to display sparc only help pages and create sparc specific defines - 1 in systems.pas to set the sparc fallback target - 1 in psystems.pas to set the sparc default floating point type - 1 in fpcdefs.inc to set sparc specific conditionals > with no reliable search > key for these parts. This is usually not needed. Doing a test driven approach, you'll identify the parts to change very quickly. > No problem when the critical pieces become (part > of) virtual methods, where it's immediately clear that virtual methods > may deserve different target-specific implementations. > > A proper OO approach will simplify the compiler maintenance, and it does > not require that a final compiler really should support multiple targets. The problem is: not everything can be solved easily using OOP. And I'am also against trying to make everything fit into OOP. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel