Bernd Oppolzer wrote:
Am 01.09.2013 19:40, schrieb Mark Morgan Lloyd:
At this point I'd throw in that one of the things the higher levels of
the compiler knows is the overall properties of the registers, i.e.
things like which ones are available for procedure parameters. This is
one of the things that the lower level has to specify, so the
lower-level units aren't there solely to do a macro-style substitution
converting the compiler's internal representation to a sequence of
assembler lines.
The corollary of this is that it's fairly common for a new target CPU
to necessitate higher-level changes, and these then have to be
propagated to all of the other targets. Which is why it's important to
keep people like Florian and Jonas happy :-)
Any comments from me below probably need checking by Florian et al.
ok, so to keep Florian, Jonas and Sven (and others) happy,
I would like to tell you that I am deeply impressed by the great
work you all have done here.
I appreciate that you discuss those things with me, and I'd like
to discuss things a little further, because before investing time
here, I would like to know as much as possible about the environment.
The last few hours gave me much insight. Thank you for that.
As I understand it now, we have several levels of the compiler:
a) scanning and parsing the source code, which leads to a "tree
representation"
of the units, which IMO is a kind of in-storage-representation of the
source code
(and tables etc.), without much dependencies of the target, if any. I
don't think,
that informations about available registers etc. of the target machine
are necessary
at this level.
As a general point, I think it's worth considering that FPC (as a
particular example of a modern compiler) supports a lot of things that
weren't in e.g. classic Pascal (as described by Jensen & Wirth) which
are implemented at this level rather than necessarily requiring fancy
opcode sequences at the lowest levels. Dynamic strings and arrays,
reference counting associated with both of these, generics, custom
definitions of opcodes, and so on.
b) the "tree representation" is translated into a "linear assembly
list", which is
target specific; from previous posts it sounds as if there are generic
methods
which help with this, and those methods of course need information about
the
target platform - but there is no "intermediate language" at this stage
like
in the P-Code case. (I know of other compilers, namely the IBM commercial
ones, which translate in this stage for an abstract target machine which
has
an arbitrary number of registers, and the later "real" code generator
puts it
down to the real number, for example 16, and the missing registers are
simulated in storage). This needs to be examined more.
I think that register-based compilers are now fairly standard. It's
still worth considering other things that the compiler might usefully
understand, e.g. the sliding window mechanism used by SPARC (and
possibly by the Itanium).
c) the "linear assembly list" is written to files, more or less without
changes
d) the files are assembled using an external assembler (in our case);
it must be callable from the FPC compiler. There exists an interface for
gas;
interfaces to other assemblers have to be built.
It's possible to get the compiler to output script files to control
assembly and linkage, so the compiler and assembler don't /have/ to be
on the same system. Also there are already interfaces other than gas,
but I think a significant thing is that gas is much more widely
implemented than the alternatives.
e) in the same way an external linker is used to link the units together.
Is this correct so far?
I'm not sure if and when I will find the time to jump really into this
doing real work,
but anyway: if we discuss these things now, it will remain in the
archives of the mailing
list and if others (like for example Paul Robinson) read this, they
don't have to
discuss it again. So IMO it's useful anyway.
I noticed comment elsewhere this morning from Paul saying that he'd been
working on a new compiler, without any further detail.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
