+ Updates for 1.9.4. Mostly MACPas related

This commit is contained in:
michael 2004-05-18 22:10:56 +00:00
parent 391651dff6
commit bbd4cc630c
6 changed files with 439 additions and 46 deletions

View File

@ -323,8 +323,7 @@ endif
#####################################################################
# Tex from XML
#####################################################################
FCLOPTS=--package=fcl --descr=classes.xml --input='$(FPCSRCDIR)/fcl/classes/$(HOSTOS)/classes.pp -Fi$(FPCSRCDIR)/fcl/inc -Fi$(FPCSRCDIR)/fcl/classes'
#FCLOPTS=--package=fcl --descr=classes.xml --input='$(FPCSRCDIR)/rtl/$(HOSTOS)/classes.pp -Fi$(FPCSRCDIR)/rtl/objpas/classes'
FCLOPTS=--package=fcl --descr=classes.xml --input='$(FPCSRCDIR)/rtl/$(HOSTOS)/classes.pp -Fi$(FPCSRCDIR)/rtl/objpas/classes'
fcl.inc: classes.xml
$(FPDOC) --output=fcl.inc $(FCLOPTS) --format=latex
@ -559,7 +558,10 @@ execute:
#
# $Log$
# Revision 1.25 2004-03-19 17:39:03 peter
# Revision 1.26 2004-05-18 22:10:56 michael
# + Updates for 1.9.4. Mostly MACPas related
#
# Revision 1.25 2004/03/19 17:39:03 peter
# * use fpdoc from utils tree if found
#
# Revision 1.24 2003/11/16 00:03:03 michael

View File

@ -189,7 +189,7 @@
\newcommand{\ostwo}{\textsc{os/2}\xspace}
\newcommand{\windows}{\textsc{Windows}\xspace}
\newcommand{\windowsnt}{\textsc{Windows NT}\xspace}
\newcommand{\macos}{\textsc{mac OS}\xspace}
\newcommand{\macos}{{Mac OS}\xspace}
\newcommand{\fpc}{Free Pascal\xspace}
\newcommand{\gnu}{\textsc{gnu}\xspace}
\newcommand{\atari}{\textsc{Atari}\xspace}
@ -207,7 +207,7 @@
%
% Some versions
%
\newcommand{\fpcversion}{1.9.2}
\newcommand{\fpcversion}{1.9.4}
%
% PDF support
%

View File

@ -42,7 +42,7 @@
\begin{document}
\title{Free Pascal \\ Programmers' manual}
\docdescription{Programmers' manual for \fpc, version \fpcversion}
\docversion{1.9}
\docversion{1.10}
\input{date.inc}
\author{Micha\"el Van Canneyt}
\maketitle
@ -111,9 +111,16 @@ until the moment another switch annihilates their behaviour, or the end
of the current unit or program is reached.
\subsection{\var{\protect\$A} or \var{\protect\$ALIGN} : Align Data}
\label{se:Align}
This switch is recognized for Turbo Pascal Compatibility, but is not
yet implemented. The alignment of data will be different in any case.
The \var{\{\$ALIGN} directive can be used to select the data alignment
strategy of the compiler for the \macos. Only valid in MACPAS mode,
it can have the following values:
\begin{description}
\item[MAC68K]
\item[POWER]
\item[RESET]
\end{description}
\subsection{\var{\protect\$ASMMODE} : Assembler mode (Intel 80x86 only)}
\label{se:AsmReader}
@ -205,13 +212,13 @@ is the same as
This is useful for indication what switch is meant.
\subsection{\var{\protect\$ELSEC} : Switch conditional compilation}
In MAC mode, this directive can be used as an alternative to the \var{\$ELSE}
In MACPAS mode, this directive can be used as an alternative to the \var{\$ELSE}
directive. It is supported for compatibility with existing \macos pascal
compilers.
\subsection{\var{\protect\$ENDC} : End conditional compilation}
In MAC mode, this directive can be used as an alternative to the
In MACPAS mode, this directive can be used as an alternative to the
\var{\$ENDIF} directive. It is supported for compatibility with existing \macos pascal
compilers.
@ -392,7 +399,7 @@ More information on this can be found in the section about
conditionals.
\subsection{\var{\protect\$IFC} : Start conditional compilation}
In MAC mode, this directive can be used as an alternative to the \var{\$IF}
In MACPAS mode, this directive can be used as an alternative to the \var{\$IF}
directive. It is supported for compatibility with existing \macos pascal
compilers.
@ -467,7 +474,7 @@ By default, \var{Inline} procedures are not allowed. This directive must be
specified to use inlined code. The directive is equivalent to the command-line
switch \var{-Si}. For more information on inline routines, consult the \refref.
\subsection{\var{\protect\$INTERFACES\}} : Specify Interface type.}
\subsection{\var{\protect\$INTERFACES} : Specify Interface type.}
The \var{\{\$INTERFACES\}} directive tells the compiler what it should take
as the parent interface of an interface declaration which does not
explicitly specify a parent interface. By default the Windows COM \var{IUnknown}
@ -697,11 +704,12 @@ switch \var{-Sm}.
By default, macros are not allowed.
\subsection{\var{\protect\$MAXFPUREGISTERS} : Maximum number of FPU registers for variables (Intel 80x86 only)}
\subsection{\var{\protect\$MAXFPUREGISTERS} : Maximum number of FPU registers for variables}
The \var{\{\$MAXFPUREGISTERS XXX\}} directive tells the compiler how much floating point
variables can be kept in the floating point processor registers. This switch is ignored
unless the \var{-Or} (use register variables) optimization is used.
variables can be kept in the floating point processor registers on an Intel
X86 processor. This switch is ignored unless the \var{-Or} (use register variables)
optimization is used.
This is quite tricky because the Intel FPU stack is limited to 8 entries.
The compiler uses a heuristic algorithm to determine how much variables should be
@ -940,10 +948,30 @@ This works only on the intel compiler, and MMX support must be on
saturation support (\sees{SaturationSupport}) for more information
on the effect of this directive.
\subsection{\var{\protect\$SETC} : Define a symbol}
In MAC mode, this directive can be used as an alternative to the
\var{\$DEFINE} directive. It is supported for compatibility with existing \macos pascal
compilers.
\subsection{\var{\protect\$SETC} : Define and assign a value to a symbol}
In MAC mode, this directive can be used to define compiler symbols. It is
an alternative to the \var{\$DEFINE} directive for macros. It is supported for
compatibility with existing \macos pascal compilers. It will define a symbol
with a certain value (called a compiler variable expression).
The expression syntax is similar to expressions used in macros, but the
expression must be evaluated at compile-time by the compiler. This means
that only some basic arithmetic and logical operators can be used,
and some extra possibilities such as the \var{TRUE},\var{FALSE} and
\var{UNDEFINED}
operators:
\begin{verbatim}
{$SETC TARGET_CPU_PPC := NOT UNDEFINED CPUPOWERPC}
{$SETC TARGET_CPU_68K := NOT UNDEFINED CPUM68K}
{$SETC TARGET_CPU_X86 := NOT UNDEFINED CPUI386}
{$SETC TARGET_CPU_MIPS := FALSE}
{$SETC TARGET_OS_UNIX := (NOT UNDEFINED UNIX) AND (UNDEFINED DARWIN)}
\end{verbatim}
The \var{:=} assignment symbol may be replaced with the \var{=} symbol.
Note that this command works only in MACPAS mode, but independent of the
\var{-Sm} command-line option or \var{\{\$MACROS \}} directive.
\subsection{\var{\protect\$STATIC} : Allow use of \var{Static} keyword.}
@ -1066,7 +1094,7 @@ given for each of the directives. They must be specified {\em before} the
\var{unit} or \var{program} clause in a source file, or they will have no
effect.
\subsection{\var{\protect\$APPNAME} : Specify application name.}
\subsection{\var{\protect\$APPID} : Specify application ID.}
Used on the PALM os only, it can be set to specify the application name,
which can be viewed on the Palm only. This directive only makes sense in a
program source file, not in a unit.
@ -1075,8 +1103,8 @@ program source file, not in a unit.
{$APPID MyApplication}
\end{verbatim}
\subsection{\var{\protect\$APPNAME} : Specify application name.}
Used on the PALM os only, it can be set to specify the application name,
\subsection{\var{\protect\$APPID} : Specify application name.}
Used on the PALM os only, it can be set to specify the application name
which can be viewed on the Palm only. This directive only makes sense in a
program source file, not in a unit.
@ -1099,7 +1127,8 @@ default.
Note that on \macos such applications cannot take command-line
options, nor return a result code. They will run in a special
terminal window.
terminal window, implemented as a SIOW application, see the MPW
documentation for details.
On \ostwo, these applications can run both full-screen and in a terminal
window.
@ -1315,7 +1344,7 @@ supplied.
command-line option.
\item[GPC] GNU pascal mode. This is the same as the \var{-Sp} command-line
option.
\item[MAC] MAC mode. In this mode, the compiler tries to be more compatible
\item[MACPAS] MACPAS mode. In this mode, the compiler tries to be more compatible
to commonly used pascal dialects on the \macos, such as Think Pascal, Metrowerks
Pascal, MPW Pascal.
\end{description}
@ -1425,7 +1454,6 @@ will enable some threading features. This directive defines or undefines the
Specifying \var{\{\$THREADING OFF\}} will disable threading. The
\var{FPC\_THREADING} will be undefined.
\subsection{\var{\protect\$UNITPATH} : Specify unit path.}
This option serves to specify the unit path, where the compiler looks for
@ -4001,27 +4029,19 @@ the name of the file.
\item[userdata] The \var{userdata} field is never used by \fpc, and can
be used for special purposes by software developpers.
\end{description}
\subsection{procedural types}
<<<<<<< prog.tex
A procedural type is stored as a generic pointer, which stores
the address of the routine.
=======
A procedural type to a normal procedure or function is stored as a generic pointer,
which stores the address of the entry point of the routine.
>>>>>>> 1.29
<<<<<<< prog.tex
=======
In the case of a method procedural type, the storage consists of two pointers,
the first being a pointer to the entry point of the method, and the second
one being a pointer to \var{self} (the object instance).
>>>>>>> 1.29
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The alignment of data elements
\section{Data alignment}
@ -4712,6 +4732,329 @@ especially for GUI programs which have e.g. a menu. In order for the
change in resource strings to become visible, the new values must be
reloaded by program code into the menus \dots
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Thread programming
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Thread programming}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Introduction
\section{Introduction}
\fpc supports thread programming: There is a language construct
available for thread-local storage (\var{ThreadVar}), and cross-platform
low-level thread routines are available.
The compiler must be told to enable threading in a program. This is done
using the \var{\{\$THREADING\}} directive:
\begin{verbatim}
Program MyThreads;
{$THREADING ON}
Uses Xyz;
\end{verbatim}
The threading directive must appear in the program source code, before the
uses clause: One of the effects of the directive is that the \file{systhrds}
unit is inserted in the \var{uses} clause of the program. This unit contains
all threading routines.
Although it is not forbidden to do so, it is not recommended to use system-specific
threading routines: The language support for multithreaded programs will not be
enabled, meaning that threadvars will not work, the heap manager will be confused
which may lead to severe program errors.
The above code only enables language support for threading. The actual threading
is implemented using a thread manager. On OSes which have built-in support for
threading (such as \windows), the system thread manager will be used and threading
is functional. For other OSes (for example, \linux) the threading code resides in
the C library (it uses pthreads) and must be enabled specifically: this means that
a thread manager must be used which uses Libc's threading routines to implement
the necessary threading routines. The system thread manager will raise an exception
if threads are started.
For \linux (and other Unixes), the C thread manager can be enabled by inserting the
\var{cthreads} unit in the program's unit clause. Without this, threading programs
will give an error when started.
At a later time, a system thread manager may be implemented which implements threads
without Libc support.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Programming threads
\section{Programming threads}
To start a new thread, the \var{BeginThread} function should be used. It has one
mandatory argument: the function which will be executed in the new thread. The result
of the function is the exit result of the thread. The thread function can be passed a
pointer, which can be used to acces initialization data: The programmer must make sure
that the data is accessible from the thread and does not go out of scope before the
thread has accessed it.
\begin{verbatim}
Type
TThreadFunc = function(parameter : pointer) : longint;
function BeginThread(ThreadFunction: tthreadfunc) : DWord;
function BeginThread(ThreadFunction: tthreadfunc;
p: pointer): DWord;
function BeginThread(ThreadFunction: tthreadfunc;
p: pointer;
var ThreadId : THandle) : DWord;
\end{verbatim}
If present, the pointer \var{p} will be passed to the thread function
when it is started (otherwise, \var{Nil} is passed). If \var{ThreadID}
is present, the ID of the thread will be stored in it.
The newly started thread will run until the \var{ThreadFunction} exits,
or until it explicitly calls the \var{EndThread} function:
\begin{verbatim}
procedure EndThread(ExitCode : DWord);
procedure EndThread;
\end{verbatim}
The exitcode can be examined by the code which started the thread.
The following is a small example of how to program a thread:
\begin{verbatim}
{$mode objfpc}
{$threading on}
uses
sysutils {$ifdef unix},cthreads{$endif} ;
const
threadcount = 100;
stringlen = 10000;
var
finished : longint;
threadvar
thri : longint;
function f(p : pointer) : longint;
var
s : ansistring;
begin
Writeln('thread ',longint(p),' started');
thri:=0;
while (thri<stringlen) do
begin
s:=s+'1';
inc(thri);
end;
Writeln('thread ',longint(p),' finished');
InterLockedIncrement(finished);
f:=0;
end;
var
i : longint;
begin
finished:=0;
for i:=1 to threadcount do
BeginThread(@f,pointer(i));
while finished<threadcount do ;
Writeln(finished);
end.
\end{verbatim}
The \var{InterLockedIncrement} is a thread-safe version of the standard \var{Inc} function.
To provide system-independent support for thread programming, some utility functions are
implemented to manipulate threads. To use these functions the thread ID must have been
retrieved when the thread was started, because most functions require the ID to identify
the thread on which they should act:
\begin{verbatim}
function SuspendThread(threadHandle: dword): dword;
function ResumeThread(threadHandle: dword): dword;
function KillThread(threadHandle: dword): dword;
function WaitForThreadTerminate(threadHandle: dword;
TimeoutMs : longint): dword;
function ThreadSetPriority(threadHandle: dword;
Prio: longint): boolean;
function ThreadGetPriority(threadHandle: dword): Integer;
function GetCurrentThreadId: dword;
procedure ThreadSwitch;
\end{verbatim}
The meaning of these functions should be clear:
\begin{description}
\item[SuspendThread] Suspends the execution of the thread.
\item[ResumeThread] Resumes execution of a suspended thread.
\item[KillThread] Kills the thread: the thread is removed from memory.
\item[WaitForThreadTerminate] Waits for the thread to terminate.
The function returns when the thread has finished executing, or
when the timeout expired.
\item[ThreadSetPriority] Sets the execution priority of the thread.
This call is not always allowed.
\item[ThreadGetPriority] Returns the current execution priority of the thread.
\item[GetCurrentThreadId] Returns the ID of the current thread.
\item[ThreadSwitch] Allows other threads to execute at this point,
can cause a thread switch, but this is not guaranteed, it depends
on the OS and the number of processors.
\end{description}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Critical sections
\section{Critical sections}
When programming threads, it is sometimes necessary to avoid concurrent
access to certain resources, or to avoid having a certain routine
executed by two threads. This can be done using a Critical Section.
The FPC heap manager uses critical sections when multithreading is
enabled.
The \var{TRTLCriticalSection} type is an Opaque type; it depends on the
OS on which the code is executed. It should be initialized before it
is first used, and should be disposed of when it is no longer necessary.
To protect a piece of code, a call to \var{EnterCriticalSection} should
be made: When this call returns, it is guaranteed that the current thread
is the only thread executing the subsequent code. The call may have
suspended the current thread for an indefinite time to ensure this.
When the protected code is finished, \var{LeaveCriticalSection} must
be called: this will enable other threads to start executing the protected
code. To minimize waiting time for the threads, it is important to keep
the protected block as small as possible.
The definition of these calls is as follows:
\begin{verbatim}
procedure InitCriticalSection(var cs: TRTLCriticalSection);
procedure DoneCriticalSection(var cs: TRTLCriticalSection);
procedure EnterCriticalSection(var cs: TRTLCriticalSection);
procedure LeaveCriticalSection(var cs: TRTLCriticalSection);
\end{verbatim}
The meaning of these calls is again almost obvious:
\begin{description}
\item[InitCriticalSection] Initializes a critical section.
This call must be made before either \var{EnterCrititicalSection}
or \var{LeaveCriticalSection} is used.
\item[DoneCriticalSection] Frees the resources associated with a
critical section. After this call neither \var{EnterCrititicalSection}
nor \var{LeaveCriticalSection} may be used.
\item[EnterCriticalSection] When this call returns, the calling
thread is the only thread running the code between the \var{EnterCriticalSection}
call and the following \var{LeaveCriticalsection} call.
\item[LeaveCriticalSection] Signals that the protected code can be executed
by other threads.
\end{description}
Note that the \var{LeaveCriticalsection} call {\em must} be executed.
Failing to do so will prevent all other threads from executing the code
in the critical section. It is therefore good practice to enclose the
critical section in a \var{Try..finally} block. Typically, the code
will look as follows:
\begin{verbatim}
Var
MyCS : TRTLCriticalSection;
Procedure CriticalProc;
begin
EnterCriticalSection(MyCS);
Try
// Protected Code
Finally
LeaveCriticalSection(MyCS);
end;
end;
Procedure ThreadProcedure;
begin
// Code executed in threads...
CriticalProc;
// More Code executed in threads...
end;
begin
InitCriticalSection(MyCS);
// Code to start threads.
DoneCriticalSection(MyCS);
end.
\end{verbatim}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The Thread Manager
\section{The Thread Manager}
Just like the heap is implemented using a heap manager, and widestring
management is left to a widestring manager, the threads have been
implemented using a thread manager. This means that there is a record which
has fields of procedural type for all possible functions used in the thread
routines. The thread routines use these fields to do the actual work.
The thread routines install a system thread manager specific for each
system. On Windows, the normal Windows routines are used to implement the
functions in the thread manager. On Linux and other unices, the system
thread manager does nothing: it will generate an error when thread routines
are used. The rationale is that the routines for thread management are
located in the C library. Implementing the system thread manager would make
the RTL dependent on the C library, which is not desirable. To avoid
dependency on the C library, the Thread Manager is implemented in a separate
unit (\file{cthreads}). The initialization code of this unit sets the thread
manager to a thread manager record which uses the C (pthreads) routines.
The thread manager record can be retrieved and set just as the record for
the heap manager. The record looks (currently) as follows:
\begin{verbatim}
TThreadManager = Record
InitManager : Function : Boolean;
DoneManager : Function : Boolean;
BeginThread : TBeginThreadHandler;
EndThread : TEndThreadHandler;
SuspendThread : TThreadHandler;
ResumeThread : TThreadHandler;
KillThread : TThreadHandler;
ThreadSwitch : TThreadSwitchHandler;
WaitForThreadTerminate : TWaitForThreadTerminateHandler;
ThreadSetPriority : TThreadSetPriorityHandler;
ThreadGetPriority : TThreadGetPriorityHandler;
GetCurrentThreadId : TGetCurrentThreadIdHandler;
InitCriticalSection : TCriticalSectionHandler;
DoneCriticalSection : TCriticalSectionHandler;
EnterCriticalSection : TCriticalSectionHandler;
LeaveCriticalSection : TCriticalSectionHandler;
InitThreadVar : TInitThreadVarHandler;
RelocateThreadVar : TRelocateThreadVarHandler;
AllocateThreadVars : TAllocateThreadVarsHandler;
ReleaseThreadVars : TReleaseThreadVarsHandler;
end;
\end{verbatim}
The meaning of most of these functions should be obvious from the descriptions in
previous sections.
The \var{InitManager} and \var{DoneManager} are called when the
threadmanager is set (\var{InitManager}), or when it is unset
(\var{DoneManager}). They can be used to initialize the thread manager or to
clean up when it is done. If either of them returns \var{False}, the
operation fails.
There are some special entries in the record, linked to thread variable
management:
\begin{description}
\item[InitThreadVar] is called when a thread variable must be initialized.
It is of type
\begin{verbatim}
TInitThreadVarHandler = Procedure(var offset : dword;size : dword);
\end{verbatim}
The \var{offset} parameter indicates the offset in the thread variable
block: All thread variables are located in a single block, one after the
other. The size parameter indicates the size of the thread variable. This
function will be called once for all thread variables in the program.
\item[RelocateThreadVar] is called each time when a thread is started, and
once for the main thread. It is of type:
\begin{verbatim}
TRelocateThreadVarHandler = Function(offset : dword) : pointer;
\end{verbatim}
It should return the new location for the thread-local variable.
\item[AllocateThreadVars] is called when room must be allocated for all
threadvars for a new thread. It's a simple procedure, without parameters. The total size of the threadvars is
stored by the compiler in the \var{threadvarblocksize} global variable.
The heap manager may {\em not} be used in this procedure: the heap manager
itself uses threadvars, which have not yet been allocated.
\item[ReleaseThreadVars] This procedure (without parameters) is called when
a thread terminates, and all memory allocated must be released again.
\end{description}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Optimizations done in the compiler
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@ -5802,14 +6145,19 @@ following directories exist:
\item \file{amiga} for the \amiga.
\item \file{beos} for \beos. It has one subdirectory for each of the
supported processors.
\item \file{darwin} for the unix-compatibility layer on \macos.
\item \file{freebsd} for the \freebsd platform.
\item \file{go32v1} For \dos, using the GO32v1 extender. Not maintained any
more.
\item \file{go32v2} For \dos, using the GO32v2 extender.
\item \file{linux} for \linux platforms. It has one subdirectory for each of the supported
processors.
\item \file{macos} for the \macos platform.
\item \file{morphos} for the MorphOS platform.
\item \file{netbsd} for \netbsd platforms. It has one subdirectory for each of the supported
processors.
\item \file{netware} for the Novell netware platform.
\item \file{openbsd} for the OpenBSD platform.
\item \file{palmos} for the \palmos Dragonball processor based platform.
\item \file{os2} for \ostwo.
\item \file{sunos} for the \solaris platform. It has one subdirectory for each of the supported
@ -5825,6 +6173,9 @@ for a specific processor. The following directories exist:
\begin{itemize}
\item \file{i386} for the Intel 80x86 series of processors.
\item \file{m68k} for the Motorola 680x0 series of processors.
\item \file{powerpc} for the PowerPC processor.
\item \file{sparc} for the SUN SPARC processor.
\item \file{x86\_64} for Intel compatible 64-bit processors such as the AMD64.
\end{itemize}
\item An OS-independent and Processor independent directory: \file{inc}. This
contains complete units, and include files containing interface parts of
@ -5967,6 +6318,17 @@ directives.
\item Support for the \var{UNDEFINED} construct in macros.
\item Support for \var{TRUE} and \var{FALSE} as values in macro expressions.
\item Macros may be assigned hexadecimal numbers, like \var{\$2345}.
\item The \var {Implementation} keyword can be omitted if the implementation
section is empty.
\item The \var{cdecl} modifier keyword can be abbreviated to \var{C}.
\item \var{UNIV} modifer for types in parameter lists is accepted, but is
otherwise ignored.
\item \var{...} (ellipsis) is allowed in procedure declarations, is
functionally equal to the \var{varargs} keyword.
\item Procedures declared in the interface section which do not have a counterpart
in the implementation section are considered external (implicit externals).
In other words, for external procedures, the \var{external} keyword may be
omitted.
\end{enumerate}
(Note: Macros are called 'Compiler Variables' in \macos dialects.)
@ -7140,8 +7502,6 @@ on stack checking when compiling for this target platform.
% Appendix I : Operating system specific behavior
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
=======
>>>>>>> 1.27
\chapter{Operating system specific behavior}
\label{ch:AppH}
@ -7172,4 +7532,4 @@ Win32 & 4 & ESI, EDI, EBX\\
\hline
\end{FPCltable}
\end{document}
\end{document}

View File

@ -47,7 +47,7 @@
\renewcommand{\hline}{\xspace}
\title{Free Pascal :\\ Reference guide.}
\docdescription{Reference guide for Free Pascal, version \fpcversion}
\docversion{1.9}
\docversion{1.10}
\input{date.inc}
\author{Micha\"el Van Canneyt}
\maketitle
@ -383,14 +383,11 @@ specified in binary notation as \var{\%11111111}.
The following diagrams show the syntax for numbers.
\input{syntax/numbers.syn}
%%% !!!!!!!!!!!!
%%% For 2.0, the range has changed, and constants within
%%% a 64bit range are parsed as int64. and no longer
%%% as reals (except if they don't fit in int64!) !!!! - carl
\begin{remark}
It is to note that all decimal constants which do no fit within
the -2147483648..2147483647 range, are silently and automatically
parsed as real-type constants.
parsed as 64-bit integer constants as of version 1.9.0. Earliers
versions would convert it to a real-typed constant.
\end{remark}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@ -1959,6 +1956,30 @@ Note that the behaviour for local initialized variables is different from
the one of a local typed constant. A local typed constant behaves like a
global initialized variable.
\section{Thread Variables}
For a program which uses threads, the variables can be really global, i.e. the same for all
threads, or thread-local: this means that each thread gets a copy of the variable.
Local variables (defined inside a procedure) are always thread-local. Global
variables are normally the same for all threads. A global variable can be
declared thread-local by replacing the \var{var} keyword at the start of the
variable declaration block with \var{Threadvar}:
\begin{verbatim}
Threadvar
IOResult : Integer;
\end{verbatim}
If no threads are used, the variable behaves as an ordinary variable.
If threads are used then a copy is made
for each thread (including the main thread). Note that the copy is
made with the original value of the variable, {\em not} with the
value of the variable at the time the thread is started.
Threadvars should be used sparingly: There is an overhead for retrieving
or setting the variable's value. If possible at all, consider using local
variables; they are always faster than thread variables.
Threads are not enabled by default. For more information about programming
threads, see the chapter on threads in the \progref.
\section{Properties}
A global block can declare properties, just as they could be defined in a
class. The difference is that the global property does not need a class
@ -4054,6 +4075,7 @@ begin
Average := Temp / (High(Row)+1);
end;
\end{verbatim}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The array of const construct
\subsection{Array of const}
@ -4521,6 +4543,15 @@ it also aligns all the parameters to a default alignment.
More information about this modifier can be found in the \progref, in the
section on the calling mechanism and the chapter on linking.
\subsection{varargs}
This modifier can only be used together with the \var{cdecl} modifier, for
external C procedures. It indicates that the procedure accepts a variable
number of arguments after the last declared variable. These arguments are
passed on without any type checking. It is equivalent to using the
\var{array of const} construction for \var{cdecl} procedures, without having
to declare the \var{array of const}. The square brackets around the variable
arguments do not need to be used when this form of declaration is used.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@ -8524,4 +8555,4 @@ table \var{TableIndex} with index \var{StringIndex}.
% The index.
%
\printindex
\end{document}
\end{document}

View File

@ -49,7 +49,7 @@
%
\title{Free Pascal supplied units : \\ Reference guide.}
\docdescription{Reference guide for standard Free Pascal units.}
\docversion{1.9}
\docversion{1.10}
\input{date.inc}
\author{Micha\"el Van Canneyt\\ Florian Kl\"ampfl}
\maketitle

View File

@ -41,7 +41,7 @@
\begin{document}
\title{Free Pascal :\\ Users' manual}
\docdescription{Users' manual for \fpc, version \fpcversion}
\docversion{1.9}
\docversion{1.10}
\input{date.inc}
\author{Micha\"el Van Canneyt\\Florian Kl\"ampfl}
\maketitle
@ -1206,7 +1206,7 @@ following:
than the \var{objfpc} mode, since some \fpc extensions are switched off.
\item[fpc] free pascal dialect (default)
\item[gpc] tries to be gpc compatible.
\item[mac] tries to be compatible to the macintosh pascal dialects.
\item[macpas] tries to be compatible to the macintosh pascal dialects.
\item[objfpc] switch some Delphi 2 extensions on. This is different from
Delphi mode. because some \fpc constructs are still available.
\item[tp] tries to be TP/BP 7.0 compatible. This means, no function overloading