Hans-Peter Diettrich wrote

P.S.: In ppudump4.patch I could remove further dependencies, except for globals.tsettings. Until somebody can move this symbol somewhere else, no further unit dependencies can be added to globals.pas, so that other global variables have to be moved out of this unit.

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

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))

Regards,
Sven

There is no official API neither it is completly target independent. It is as target independent as needed.

Some notes on the compiler API/interface for external tools, based on my observation of the ppudump program.

When this API *really* shall be target independent, as some people believe it already is, it deserves some fixes. Every copy of declarations, out of compiler units into external tools, indicates broken independence. In a clean API all these declarations have to be moved into other units, that do not introduce unwanted dependencies when used by external tools.

In so far I consider the ppudump dependency problem solved, the rest is the job of the maintainers of either the external tools or their compiler interface.

About the design of "independent" tools, Michael annotated my ppudump patch like this:
"This patch goes against what ppudump was designed for initially: to be independent of the compiler, so as to be usable for other tools."

The new ppudmp unit logic is as independent from the compiler as the ppudump program has been. As mentioned before, true compiler independence requires that all those declarations and procedures, that are designed/acknowledged for use by external tools, have to reside in specific units (to be documented), which do not introduce unwanted compiler (target...) dependencies.

Copy&paste of declarations or entire procedures, out of the compiler units into external tools, can lead to broken tool functionality. Some concrete examples of what can happen as soon as the compiler declarations start to differ from their copies, as found in the ppudump code:

1) The tools erroneously report errors, as soon as the processed data contain values that are yet unknown to the tool.

2) The tools can not interpret correctly the rest of the data, when they simply ignore unknown data sections, instead of skipping properly over them. When such sections are subject to conditional compilation, only their *creation* can be made conditional, while every occurence in data files has to be handled unconditionally, and herefore all related declarations also must be available unconditionally.

3) The same string constants should be used for enumerated types, in both the compiler and external tools, so that typos can be detected during normal compiler development. When e.g. a type is reported as another one (signed instead of unsigned), this bug is hard to find when the output is generated from string literals in external tools.

DoDi

P.S.: In ppudump4.patch I could remove further dependencies, except for globals.tsettings. Until somebody can move this symbol somewhere else, no further unit dependencies can be added to globals.pas, so that other global variables have to be moved out of this unit.

> 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

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.

DoDi

Well... you seem to have managed this problem. :)

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).

You're welcome ^^

Regards,
Sven

Hans-Peter Diettrich wrote

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 forgot: here is a bug report highlighting that problem a bit (for programs not the compiler): http://bugs.freepascal.org/view.php?id=15305

Regards,
Sven

Sven Barth wrote

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

SSE2 does not support more than 64 bit precision for floating point.

(I don't know what other platforms provide or if we'd need a soft 80-bit float emulator).

We do need an 80 bit floating point emulator: http://bugs.freepascal.org/view.php?id=9262

Jonas

Oh yes, sorry. I've misinterpreted the Wikipedia article about this.

> (I don't know what other platforms provide or if we'd need a soft 80-bit float emulator). We do need an 80 bit floating point emulator: http://bugs.freepascal.org/view.php?id=9262

I thought so... (and thanks for digging up that link)

Regards,
Sven