[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