[fpc-devel] Episode 4. Addressing and it's limits Part Two
Mark Morgan Lloyd
markMLl.fpc-devel at telemetry.co.uk
Fri Feb 10 22:18:11 CET 2012
rvmartin2 at ntlworld.com wrote:
>> Now let's stop arguing at cross purposes about whether the platform is
>> still used and what governs things like character set selection, and get
>> on with trying to work out how to do the job.
> I'm pretty sure I know how to do it, I just don't see why it's
> necessary ;-)
> But I'm willing to have a go, just for fun, which is why I'm trying to
> find out what is fed into the "back-end".
:-) I'm a very long way from being a core programmer, but my
understanding is that FPC doesn't use a serialised intermediate format
which the backend translates. Rather, it constructs one or more internal
trees of objects which are walked, at least some of those objects
translate into assembler sequences. In other words,
procedure secondpass(var p : tnode);
begin
p.pass_generate_code;
end;
which is called from... frankly, all over the place, and which via a
couple of not-very-thick layers tells subclasses of tnode in the
processor-specific directories to emit code.
About the best I can do at the moment is
http://wiki.lazarus.freepascal.org/ZSeries#Digression:_example_FPC_output
which can, initially, be read in conjunction with ./compiler/pass_2.pas
etc. as above. However that is still rather incomplete, in particular it
doesn't show enough of the objects' state to reveal to the casual reader
why some sequences generate code and others don't, and it doesn't really
describe the logic behind emission of the data sections in the latter
part of the listing.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
More information about the fpc-devel
mailing list