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

rvmartin2 at ntlworld.com rvmartin2 at ntlworld.com
Wed Feb 8 15:35:23 CET 2012


Sven Barth <pascaldragon at googlemail.com> wrote the following on 08/02/12 14:24:17:
> 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.

Ouch!!  OK, thanks.

Bob



More information about the fpc-devel mailing list