[fpc-devel] Episode 4. Addressing and it's limits Part Two

[Mark Morgan Lloyd]

Sven Barth wrote:
> Am 08.02.2012 15:16, schrieb rvmartin2 at ntlworld.com:
>> Hans-Peter Diettrich<DrDiettrich1 at aol.com>  wrote the following on 
>> 08/02/12 11:28:49:
>>> Mark Morgan Lloyd schrieb:
>>>> Hans-Peter Diettrich wrote:
>>>>> steve smithers schrieb:
>>>>>
>>>>>> Regardless of what you may believe, FreePascal is not the first
>>>>>> compiler to be
>>>>>> implemented on 370 architecture.
>>>>>
>>>>> I.e. you can study how they create code, before you reinvent the wheel
>>>>> :-)
>>>>
>>>> :-) Had occurred to me as well, although obviously a lot is dictated by
>>>> FPC's higher-level parsing and structure.
>>>
>>> This should not be a problem. It's up to the code generator to define
>>> its own strategies for allocating space for code and data items, and how
>>> to address them in generated code. The parse tree tells the back-end
>>> *what* should be done, the back-end then has to know *how* to do it.
>>>
>>>> Might still be very useful for
>>>> getting calling conventions etc. right.
>>>
>>> The implementation of calling conventions is up to the code generator as
>>> well. You can invent your own conventions, and map them to any
>>> predefined one. As a starting point it's sufficient to support only one
>>> calling convention, the one for system calls. More conventions for
>>> calling other external libraries may be required, depending on the
>>> target OS conventions.
>>
>> Where can I find details of the input to the back-end?
>> I'd like to have a crack at generating assembler code for VM/SP.
> 
> Best (and AFAIK only) available source: the compiler's source code. Sorry.

I think that that's one of the things that Paul Robinson was trying to 
write up: the overall collection of files and how they related to each 
other. It's also something that I started working through with regards 
to the MIPS backend, and I suspect that there might have been others.

My understanding is that as far as the compiler is concerned almost of 
the CPU-specific stuff is in e.g. ./compiler/mips. There are obviously 
other things e.g. in the makefiles that glue a particular target into 
the overall framework, but once those are in place the developer(s) 
working on a particular target are nicely fenced off (for their own 
protection, as much as everybody else's :-)

One thing that could be useful: is it possible to build a compiler with 
a dummy backend? In other words, such that it can emit all of the node 
information (fpc's -an option) even though it doesn't generate any code?

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]