[fpc-devel] Blackfin support
DrDiettrich1 at aol.com
Mon Jul 12 17:54:21 CEST 2010
Michael Schnell schrieb:
>> I just stripped down the machine files for a no_cpu machine (all
>> fakes), with some documentation about the required units etc.
> Is this based on what we already have for X86, ARM, etc, or does it
> "fork" to another set of ARC implementations ? If "fork", is it intended
> / viable to move the existing implementations into that scheme ?
The no_cpu skeleton was stripped down from the M68K machine, which in
turn seems to have inherited from the ARM. Due to hard coded
dependencies it was impossible to remove e.g. registers completely, and
also a $define of some already known machine must be given, else every
compilation will fail immediately with an $fatal error.
That skeleton reflects the units, data structures and procedures, that
are referenced by other parts of the compiler (hard coded). Every
machine consists of a formal description (registers, instructions...),
node generators for the parse tree, code (tree) optimizers, assembler
and output generators for binary code and debug info. A distinct machine
back-end is selected by adding its source folder to the unit search
path. This may be the fastest possible implementation for one (of
multiple) machines, but it doesn't allow to support multiple machine
back-ends in one program. The same applies to the front-ends, which
currently are not exchangable at all. More flexibility would require a
plug-in scheme or similar, hard to do without dynamically loadable
packages. But since some abstract links already exist (class type
variables for machine specific descendants), these links could be
exchanged at runtime, not only in the initialization section of the
machine specific units. Then it would be sufficient to add all (wanted)
front- or back-ends to the compiler, and switch amongst these at
runtime. Where switching the target machine at runtime does not make
much sense to me, in contrast to switching front-ends based on the
source file types.
>> An implementation of a new CPU, based on that skeleton, would rise the
>> priority for further explorations and documentation.
> No idea in what state the structure / documentation of the existing
> fully supported implementations such as x86 and ARM is.
I could not find much, and most existing documentation is outdated since
Some parts, like the parse tree nodes, are somewhat self-explaining. The
formal machine descriptions (registers, options...) are almost
undocumented. I tried to make the construction of the register
descriptor constants more transparent, by composing them from other sets
of constants. There seem to exist tools that produce e.g. register
descriptors (in include files), but I did not yet dig into the tools folder.
More information about the fpc-devel