[fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....

[Mark Morgan Lloyd]

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]