[fpc-devel] External tools API

[Hans-Peter Diettrich]

Sven Barth schrieb:

>> P.S.: In ppudump4.patch I could remove further dependencies, except for
>> globals.tsettings.

> May I ask why you couldn't move it somewhere else?

In the meantime I moved it into its own unit :-)

One problem with the move of such an structured type are dependencies on 
other types, which can result in cyclic unit references.


> Another question to the core devs: Why is tsettings.controllertype 
> ifdef'd? Doesn't this make dumping the contents of a ARM or AVR ppu on a 
> non ARM/AVR system a bit... well... impossible?

Right, at least it makes an dump more complicated :-(
[Thanks for this hint, I'll have another look at this problem]

Even more puzzling is the inability to cross-compile from x86_64 to e.g. 
i386, because x86_64 has no Extended type [At least I concluded this 
from hints on the Best_Real type]. This may also explain the debugging 
problems of 32 bit executables in an 64 bit x86 environment.

I already came across this problem in my research of multiple back-ends. 
There exist some (mostly enumerated) types, which differ for every 
target CPU - and Controllertype (currently) even only exists for these 
architectures.

A more general (or abstract) implementation would declare integral types 
for these enums, mostly Byte, and leave it to the derived CPU class to 
e.g. translate the values into strings. Similar hacks are found already 
in e.g. the TModule class, where several fields are declared bare 
TObjects - to avoid cyclic unit dependencies.

DoDi