[fpc-devel] External tools API
Sven Barth
pascaldragon at googlemail.com
Sun Oct 3 11:23:04 CEST 2010
On 03.10.2010 03:25, Hans-Peter Diettrich wrote:
> 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.
Well... you seem to have managed this problem. :)
>> 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.
If I remember correctly (@core devs: please correct me if I'm wrong) the
compiler needs to evaluate float constants with the correct (if typed)
or the maximal available precision (if untyped). Thus we'd need an
Extended emulator for platforms that don't have a 80-bit float type. The
calculations might be done using SSE2 instruction set on x86_64 cpus (I
don't know what other platforms provide or if we'd need a soft 80-bit
float emulator).
> Sven Barth schrieb:
>
>> 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? (at least according to the current code of ppudump (the original as well as the ppudump4.patch one))
>
> Thanks to your comment I also could make ControllerType an unconditional member of TSettings - see ppudump5.patch :-)
>
> It adds one byte to the non-ARM/AVR .ppu files and a few more bytes to the compiler itself, what should do no harm.
>
> This change also allows to remove a couple of $IFDEFs, which may be incorrect/incomplete in the current code, not reflecting AVR which also has controller types.
You're welcome ^^
Regards,
Sven
More information about the fpc-devel
mailing list