paweld/fpc
1
0
Fork 0
mirror of https://gitlab.com/freepascal.org/fpc/source.git synced 2025-08-14 21:33:17 +02:00
Code Issues Packages Projects Releases Wiki Activity

Grammar check and made it texable

Browse Source
This commit is contained in:
michael 1998-09-07 08:19:53 +00:00
parent 9523c61fc1
commit 2c4a8c9bd3
1 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
docs/internal.tex
View File

@ -47,9 +47,9 @@
% About this document % About this document
\section{About this document} \section{About this document}
This document tries to make the internal working of \fpc more clear. This document tries to make the internal workings of \fpc more clear.
It is assumed that the reader has some knowledge about compiler It is assumed that the reader has some knowledge about compiler
building building.
This document describes the compiler as it is/functions at the time of This document describes the compiler as it is/functions at the time of
writing. Since the compiler is under continuous development, some of the writing. Since the compiler is under continuous development, some of the
@ -91,7 +91,7 @@ list or you can contact the developers.
The symbol table is used to store informations about all The symbol table is used to store informations about all
symbols, declarations and definitions in a program. symbols, declarations and definitions in a program.
In an abtract view, a symbol table is a data base with a string field In an abstract view, a symbol table is a data base with a string field
as index. \fpc implements the symbol table mainly as a binary tree, as index. \fpc implements the symbol table mainly as a binary tree,
for big symbol tables some hash technics are used. The implementation for big symbol tables some hash technics are used. The implementation
can be found in symtable.pas, object tsymtable. can be found in symtable.pas, object tsymtable.
@ -106,17 +106,17 @@ informations about symbols and types to generate the code.
% Definitions % Definitions
\section{Definitions} \section{Definitions}
Definitions are one of the importantest data structures in \fpc. Definitions are one of the most important data structures in \fpc.
They are used to describe types, for example the type of a variable They are used to describe types, for example the type of a variable
symbol is given by a definition and the result type symbol is given by a definition and the result type
of a expression is given as a definition. of a expression is given as a definition.
They have nothing to do with the definition of a procedure. They have nothing to do with the definition of a procedure.
Definitions are implemented as a object (symtable.pas, tdef and Definitions are implemented as a object (symtable.pas, tdef and
it's decendants). There are a lot of different it's descendents). There are a lot of different
definitions: for example to describe definitions: for example to describe
ordinal type, arrays, pointers, procedures ordinal types, arrays, pointers, procedures
To make it more clear let's have a look to the fields of tdef: To make it more clear let's have a look at the fields of tdef:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Symbols % Symbols
@ -159,8 +159,8 @@ assembler for the GNU AS, the NASM (Netwide assembler) and
the assemblers of Borland and Microsoft. The default assembler the assemblers of Borland and Microsoft. The default assembler
is the GNU AS, because it is fast and and available on is the GNU AS, because it is fast and and available on
many platforms. Why don't we use the NASM? It is 2-4 times many platforms. Why don't we use the NASM? It is 2-4 times
slower than the GNU AS and it is create for slower than the GNU AS and it is created for
man kind written assembler, while the GNU AS is designed hand-written assembler, while the GNU AS is designed
as back end for a compiler. as back end for a compiler.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@ -174,7 +174,7 @@ as back end for a compiler.
\chapter{The register allocation} \chapter{The register allocation}
The register allocation is very hairy, so it gets The register allocation is very hairy, so it gets
an own chapter in that manual. Please be careful when changing things an own chapter in this manual. Please be careful when changing things
regarding the register allocation and test such changes intensive. regarding the register allocation and test such changes intensive.
Future versions will may be implement another kind of register allocation Future versions will may be implement another kind of register allocation
@ -183,9 +183,9 @@ to make this part of the compiler more robust, see
system is less or more working and changing it would be a lot of system is less or more working and changing it would be a lot of
work, so we have to live with it. work, so we have to live with it.
The current register allocation mechanism was implement 5 years The current register allocation mechanism was implemented 5 years
ago and I didn't think, that the compiler becomes ago and I didn't think, that the compiler would become
so popular, so not much time was spend in the design so popular, so not much time was spent in the design
of the register allocation. of the register allocation.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@ -195,12 +195,12 @@ of the register allocation.
The register allocation is done in the first and second pass of The register allocation is done in the first and second pass of
the compiler. the compiler.
The first pass of a node has to calculate how much registers The first pass of a node has to calculate how much registers
are necessary to generate code for the node, it have are necessary to generate code for the node, it has
also to take care of child nodes i.e. how much registers also to take care of child nodes i.e. how much registers
they need. they need.
The register allocation is done via \var{getregister\*} The register allocation is done via \var{getregister\*}
(where * is \var{32} or \var{mmx}). %(where * is \var{32} or \var{mmx}).
Registers can be released via \var{ungetregister\*}. All registers Registers can be released via \var{ungetregister\*}. All registers
of a reference (i.e. base and index) can be released by of a reference (i.e. base and index) can be released by
@ -218,7 +218,7 @@ occurs.
\subsection{The first pass} \subsection{The first pass}
This is a part of the first pass for a pointer dereferencation This is a part of the first pass for a pointer dereferencation
(\var{p\^}), the type determination and some other stuff are left out (\var{p\^\ }), the type determination and some other stuff are left out
\begin{verbatim} \begin{verbatim}
procedure firstderef(var p : ptree); procedure firstderef(var p : ptree);
@ -321,8 +321,8 @@ generate code for a binary+ node (a node with two or more
childs). If a node calls second pass for a child node, childs). If a node calls second pass for a child node,
it has to ensure that enough registers are free it has to ensure that enough registers are free
to evalute the child node (\var{usableregs>=childnode\^.registers32}). to evalute the child node (\var{usableregs>=childnode\^.registers32}).
If this condition isn't true, the current node have If this condition isn't true, the current node has
to store and restore all registers which the node does own to to store and restore all registers which the node owns to
release registers. This should be done using the release registers. This should be done using the
procedures \var{maybe\_push} and \var{restore}. If still procedures \var{maybe\_push} and \var{restore}. If still
\var{usableregs<childnode\^.registers32}, the child nodes have to solve \var{usableregs<childnode\^.registers32}, the child nodes have to solve