[fpc-devel] Re: Episode 4. Addressing and it's limits Part Two
steve smithers
stevie at collector.org
Thu Feb 9 03:35:14 CET 2012
> rvmartin2 at ntlworld.com wrote on Wed, 8 Feb 2012 14:16:50 +0000 (GMT)
> > 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.
Maybe I've misunderstood the logic here, but it's my understanding
that the back-end produces assembler statements to produce executable
code for the processor. So if I want to move something from field a
to field b say, or add two numbers together, the backend generated the
MVC and it's related code or the Add instruction, Handles registers
and addressability and stuff. Anyway, whatever this stuff is called
it lives in the COMPILER/VMSP (apologies to you case-sensitive types)
sub-directory.
The bit that provides code for VM/SP as opposed to say MVS, is the RTL,
so if I want to open a file, there is a routine in the RTL called OpenFile
(or whatever) that issues the VM code for open. This lives in System.pp
or Sysfile.pp or whatever it's called in the RTL/VMSP sub-directory
Now, in order for the compiler to function it needs access to a certain
level of base functionality in the VM/SP RTL. Things like Allocate /
Deallocate memory, Open and Close a file, Read and Write from and to a
file. Create and Delete a file etc. These may, or may not, be written
totally or partially in assembler.
More information about the fpc-devel
mailing list