chill.texi

gcc-2.95.3 Linux下最常用的C编译器

@\input texinfo @c -*-texinfo-*-
@setfilename chill.info
@settitle Guide to GNU Chill


@ifinfo
@format
START-INFO-DIR-ENTRY
* Chill::                       Chill compiler
END-INFO-DIR-ENTRY
@end format
@end ifinfo

@titlepage
@title GNU Chill
@author William Cox, Per Bothner, Wilfried Moser
@end titlepage

@ifinfo
@node Top
@top

@menu
* Options::               Compiler options
* Missing::               Unimplemented parts of the Chill language
* Enhancements::          GNU-specific enhancements to the Chill language
* Conversions::           Value and location conversions
* Separate compilation::  Separate compilation
* Differences::           Differences between GNUCHILL and Z.200/1988
* Directives::            Implemented Compiler Directives
* References::            Language definition references
@end menu

@end ifinfo

@node Options
@chapter Compiler options

Invoking the compiler:

The @sc{gnu} CHILL compiler supports several new command line options, and
brings a new use to another:

@table @code
@item -lang-chill
This option instructs gcc that the following file is a CHILL source file,
even though its extension is not the default `.ch'.

@item -flocal-loop-counter
The CHILL compiler makes a separate reach, or scope,
for each DO FOR loop.  If @code{-flocal-loop-counter} is
specified, the loop counter of value enumeration and location
enumeration is automatically declared inside that reach.
This is the default behavior, required by Z.200.

@item -fno-local-loop-counter
When this option is specified, the above automatic declaration
is not performed, and the user must declare all loop counters 
explicitly.

@item -fignore-case
When this option is specified, the compiler ignores case. All 
identifiers are converted to lower case. This enables the usage
of C runtime libraries.

@item -fno-ignore-case
Ignoring the case of identifiers is turned off.

@item -fruntime-checking
The CHILL compiler normally generates code to check 
the validity of expressions assigned to variables or
expressions passed as parameters to procedures and processes,
if those expressions cannot be checked at compile time.
This is the default behavior, required by Z.200.
This option allows you to re-enable the default behavior
after disabling it with the @code{-fno-runtime-checking}
option.

@item -fno-runtime-checking
The CHILL compiler normally generates code to check 
the validity of expressions assigned to variables, or
expressions passed as parameters to procedures and processes.
This option allows you to disable that code generation.
This might be done to reduce the size of a program's
generated code, or to increase its speed of execution.
Compile time range-checking is still performed.

@item -fgrant-only
@itemx -fchill-grant-only
This option causes the compiler to stop successfully
after creating the grant file specified by the source
file (see modular programming in CHILL).  No code is
generated, and many categories of errors are not reported.

@item -fold-string
Implement the semantics of Chill 1984 with respect to strings:
String indexing yields a slice of length one;  CHAR is similar
to CHAR(1) (or CHARS(1)); and BOOL is similar to BIT(1) (or BOOLS(1)).

@item -fno-old-string
Don't implement 1984 Chill string semantics.  This is the default.

@item -I@var{seize_path}
This directive adds the specified seize path to the compiler's
list of paths to search for seize files.  When processing a 
USE_SEIZE_FILE directive, the compiler normally searches for
the specified seize file only in the current directory.  When
one or more seize paths are specified, the compiler also 
searches in those directories, in the order of their
specification on the command line, for the seize file.

@item -c
This C-related switch, which normally prevents gcc from 
attempting to link, is *not* yet implemented by the @code{chill} command,
but you can use the @code{gcc} command with this flag.
@end table

@node Missing
@chapter Implemented and missing parts of the Chill language

The numbers in parentheses are Z.200(1988) section numbers.

@itemize @bullet
@item The FORBID keyword in a GRANT statement is currently ignored.

@item A CASE action or expression allows only a single expression
in a case selector list (5.3.2, 6.4).

@item ROW modes are not implemented (3.6.3, 3.13.4).

@item Due to the absence of ROW modes, DYNAMIC has no meaning in
connection with access and text modes.

@item Array and structure layout (PACK, POS, NOPACK, 
STEP keywords) is ignored (3.12.6).

@item Bit-string slices are not implemented.

@item The support for synchronization modes and concurrent execution
is slightly non-standard.

@item Exception handling is implemented, but exceptions are not
generated in all of the required situations.

@item Dynamic modes are not implemented (though string slices should work).

@item Reach-bound initializations are not implemented (4.1.2).

@end itemize

@node Enhancements
@chapter GNU-specific enhancements to the Chill language

@itemize @bullet
@item Grantfiles.  See @xref{Separate compilation}.
@item Precisions.  Multiple integer and real precisions are supported,
as well as signed and unsigned variants of the integer modes.
@item DESCR built-in. The new built-in function 
DESCR ( <descriptor argument> ) returns a pointer to 
STRUCT( addr PTR, length ULONG ) where <descriptor argument> can be
anything the compiler can handle but at least a location of any mode
(except synchronizing modes) and any character string or powerset value.
(A temporary location within the current stack frame may be allocated
if an expression is used.)

CHILL does not permit the writing of procedures with parameters of
any type. Yet some interfaces---in particular those to system 
calls---require
the handling of a wide range of modes, e.g. any string mode, any structure
mode, or any powerset mode. This could be handled by specifying two
parameters (PTR, INT for the length) but this is error-prone (no guarantee
the same location is used after in ADDR and LENGTH), and it will not be
possible for expressions.

Caveats: This feature permits the programmer to obtain the address of
a literal (if the compiler takes this shortcut---see 1st example below).
If hardware features protect constant parts of the program, erronous
abuse will be detected.

    Examples:
       OFFER_HANDLER( descr("dbs"), ->dbs);

       SYNMODE m_els = SET( ela, elb, elc );
       SYNMODE m_elsel = POWERSET m_els;
       DCL user_buf STRUCT( a mx, b my, c mz);
       DCL select POWERSET m_elsel;

       select := m_elsel[LOWER(m_els) : UPPER(m_els)];

       GET_RECORD( relation, recno, descr(user_buf), descr(select) );

       PUT_RECORD( relation, recno, descr(user_buf.b), descr(m_elsel[elb]) );

@item LENGTH built-in on left-hand-side.       The LENGTH built-in may be
used on the left-hand-side of an assignment, where its argument is a VARYING
character string.
@end itemize

@node Conversions
@chapter Value and location conversions

Value and location conversions are highly dependent on the target machine.
They are also very loosely specified in the 1988 standard.
(The 1992 standard seems an improvement.)

The GNU Chill compiler interprets @code{@var{mode}(@var{exp})} as follows:

@itemize @bullet
@item
If @var{exp} is a referable location,
and the size of (the mode of) @var{exp} is the same as the size of @var{mode},
a location conversion is used.
It is implemented exactly as:  @code{(@var{refmode}(-> @var{exp}))->},
where @var{refmode} is a synmode for @code{REF @var{mode}}.

The programmer is responsible for making sure that alignment
restrictions on machine addresses are not violated.

If both @var{mode} and the mode of @var{exp} are discrete modes,
alignment should not be a problem, and we get the same conversion
as a standard value conversion.

@item
If @var{exp} is a constant,
and the size of (the mode of) @var{exp} is the same as the size of @var{mode},
then a value conversion is performed.  This conversion is done
at compile time, and it has not been implemented for all types.
Specifically, converting to or from a floating-point type is not implemented.

@item
If both @var{mode} and the mode of @var{exp} are discrete modes,
then a value conversion is performed, as described in Z.200.

@item
If both @var{mode} and the mode of @var{exp} are reference modes,
then a value conversion is allowed.
The same is true is one mode is a reference mode, and the other
is an integral mode of the same size.

@end itemize

@node Separate compilation
@chapter Separate compilation

The GNU CHILL compiler supports modular programming.  It
allows the user to control the visibility of variables
and modes, outside of a MODULE, by the use of GRANT
and SEIZE directives.  Any location or mode may be made
visible to another MODULE by GRANTing it in the MODULE
where it is defined, and SEIZEing it in another MODULE
which needs to refer to it.

When variables are GRANTed in one or more modules of a
CHILL source file, the compiler outputs a grant file,
with the original source file name as the base name,
and the extension `.grt'.  All of the variables and modes
defined in the source file are written to the grant file,
together with any use_seize_file directives, and the
GRANT directives.  A grant file is created for every such
source file, except if an identical grant file already 
exists.  This prevents unnecessary makefile activity.

The referencing source file must:

@enumerate
@item specify the grant file in a use_seize_file directive, and
@item SEIZE each variable or mode definition that it needs.
@end enumerate

An attempt to SEIZE a variable or mode which is not
GRANTed in some seize file is an error.

An attempt to refer to a variable which is defined in
some seize file, but not explicitly granted, is an
error.

An attempt to GRANT a variable or mode which is not
defined in the current MODULE is an error.

Note that the GNU CHILL compiler will *not* write out a
grant file if:

@itemize @bullet
@item there are no GRANT directives in the source file, or
@item the entire grant file already exists, and is
     identical to the file which the compiler has just built.
(This latter ``feature'' may be removed at some point.)
@end itemize

Otherwise, a grant file is an automatic, unsuppressable
result of a successful CHILL compilation.

A future release will also support using remote spec modules
in a similar (but more Blue Book-conforming) manner.

@node Differences
@chapter Differences to Z.200/1988

This chapter lists the differences and extensions between GNUCHILL 
and the CCITT recommendation Z.200 in its 1988 version (reffered to
as Z.200/1988).

@itemize @bullet

@item 2.2 Vocabulary@*
The definition of @i{<simple name string>} is changed to:

@example
@i{<simple name string> ::=}
@example
@i{@{<letter> | _ @} @{ <letter> | <digit | _ @}}
@end example
@end example

@item 2.6 Compiler Directives@*
Only one directive is allowed between the compiler directive delimiters
`<>' and `<>' or the end-of-line, i.e.
@example
<> USE_SEIZE_FILE "foo.grt" <>
<> ALL_STATIC_OFF
@end example

@item 3.3 Modes and Classes@*
The syntax of @i{<mode>} is changed to:

@example
@i{<mode> ::=}
@example
  [@b{READ}] @i{<non-composite-mode>}
| [@b{READ}] @i{composite-mode>}
@end example

@i{<non-composite-mode> ::=}
@example
  @i{<discrete mode>}
| @i{<real modes>}
| @i{<powerset modes>}
| @i{<reference mode>}
| @i{<procedure mode>}
| @i{<instance mode>}
| @i{<synchronization mode>}
| @i{<timing mode>}
@end example
@end example

@item 3.4 Discrete Modes@*
The list of discrete modes is enhanced by the following modes:

@example
BYTE         8-bit signed integer
UBYTE        8-bit unsigned integer
UINT         16-bit unsigned integer
LONG         32-bit signed integer
ULONG        32-bit unsigned integer
@end example

@strong{Please note} that INT is implemented as 16-bit signed integer.

@item 3.4.6 Range Modes@*
The mode BIN(n) is not implemented. Using INT(0 : 2 ** n - 1) instead of
BIN(n) makes this mode unneccessary.

@item 3.X Real Modes@*
Note: This is an extension to Z.200/1988, however, it is defined in
Z.200/1992.

@b{syntax:}

@example
@i{<real mode> ::=}
@example
@i{<floating point mode>}
@end example
@end example

@b{semantics:}

@example
A real mode specifies a set of numerical values which approximate a
contiguous range of real numbers.
@end example

@item 3.X.1 Floating point modes@*

@b{syntax:}

@example
@i{<floating point mode> ::=}
@example
@i{<floating point mode name}
@end example
@end example

@b{predefined names:}

The names @i{REAL} and @i{LONG_REAL} are predefined as @b{floating
point mode} names.

@b{semantics:}

A floating point mode defines a set of numeric approximations to a 
range of real values, together with their minimum relative accuracy, 
between implementation defined bounds, over which the usual ordering 
and arithmetic operations are defined. This set contains only the 
values which can be represented by the implementation.

@b{examples:}

@example
@i{REAL}
@i{LONG_REAL}