home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ARM Club 3
/
TheARMClub_PDCD3.iso
/
hensa
/
languages
/
icon_1
/
DOCS
/
IPD238_DOC
< prev
next >
Wrap
Text File
|
1995-12-01
|
47KB
|
1,717 lines
Configuring the Source Code for
Version 9 of Icon
Gregg M. Townsend, Ralph E. Griswold,
and Clinton L. Jeffery
Department of Computer Science, The
University of Arizona
1.__Background
The implementation of the Icon programming language is large
and sophisticated [1-3]. The implementation is, however, written
almost entirely in C and RTL [4], a superset of C, for which a
translator to C is provided. A small amount of assembly-language
code is needed for the context switch used by co-expressions.
See Appendix B. This code is optional and only affects co-
expressions.
There presently are implementations of Icon for the Acorn
Archimedes, the Amiga, the Atari ST, the Macintosh, MS-DOS, MVS,
OS/2, UNIX, VM/CMS, and VMS.
All implementations of Icon are obtained from the same source
code, using conditional compilation and defined constants to
select and configure platform-dependent code. Consequently,
installing Icon on a new platform is largely a matter of select-
ing appropriate values for configuration parameters, deciding
among alternative definitions, and possibly adding some code that
is dependent on the specific computer, operating system, and C
compiler used.
This document describes the process of configuring Version 9
of the Icon source code for a platform on which it has not previ-
ously been installed.
Since there are several existing configurations for UNIX and
MS-DOS, configuring a new platform for one of these operating
systems is easier than for other platforms. See Sections 5, 6,
and 7 for specific information concerning UNIX and MS-DOS plat-
forms.
Building Icon with a new C compiler on an operating system for
which Icon has previously been installed usually is a fairly sim-
ple task and normally can be done by adjusting a few configura-
tion parameters.
IPD238b - 1 - November 1, 1995
Installing Icon on a new operating system is more complex;
read this report carefully, especially Section 8, before under-
taking such a project.
2.__Requirements
C_Data_Sizes
Icon places the following requirements on C data sizes:
+ chars must be 8 bits.
+ ints must be 16, 32, or 64 bits.
+ longs and pointers must be 32 or 64 bits.
+ All pointers must be the same length.
+ longs and pointers must be the same length.
If your C data sizes do not meet these requirements, do not
attempt to configure Icon.
The_C_Compiler
The main requirement for implementing Icon is a production-
quality C compiler that supports at least the ``K&R'' standard
[5]. An ANSI C compiler is preferable. The term ``production
quality'' implies robustness, correctness, the ability to address
large amounts of memory, the ability to handle large files and
complicated expressions, and a comprehensive run-time library.
The C preprocessor should conform either to the ANSI C stan-
dard [6] or to the K&R standard for UNIX C preprocessors. In
particular, Icon uses the C preprocessor to concatenate strings
and substitute arguments within quotation marks. For the ANSI
preprocessor standard, the following definitions are used:
#define Cat(x, y) x##y
#define Lit(x) #x
For the UNIX K&R standard, the following definitions are used:
#define Ident(x) x
#define Cat(x, y) Ident(x)y
#define Lit(x) "x"
The following program can be used to test these preprocessor
facilities:
IPD238b - 2 - November 1, 1995
Cat(ma, in)()
{
printf(Lit(Hello world\n));
}
If this program does not compile and print Hello world using one
of the sets of definitions above, there is no point in proceed-
ing. Contact the Icon Project for alternative approaches.
Memory
The Icon programming language requires a substantial amount of
memory to run. The practical minimum depends somewhat on the
platform; 640KB is typical.
File_Space
The source code for Icon is large - about 3.5MB. Test pro-
grams and other auxiliary files take additional room, as does
compilation and testing. While the implementation can be divided
into components that can be built separately, this approach may
be painful.
3.__File_Structure
The files for Icon are organized in a hierarchy. The top
level, assuming the hierarchy is rooted in icon is:
|-bin------ executable binaries and support files
|-config--- configurations
|-icon----|-src------ source code
|-tests---- tests
There are several subdirectories in config for different operat-
ing systems:
|-acorn----
|-amiga----
|-atari_st-
|-ibm370---
--config--|-macintosh
|-msdos----
|-os2------
|-unix-----
|-vms------
Not all of these subdirectories are included in all distributions
of Icon. Some configuration directories contain subdirectories
for different platforms. These subdirectories contain various
files, depending on the platform.
IPD238b - 3 - November 1, 1995
The directory src contains the source code for various com-
ponents of Icon.
|-common---- common source
|-h--------- header files
|-iconc----- Icon compiler source
-src------|-icont----- Icon translator source
|-preproc--- C preprocessor source
|-rtt------- run-time translator source
|-vtran----- variant translator support
|-wincap---- BMP image-file format support
|-xpm------- XPM image-file format support
The directory tests contains the test material for various
components of Icon.
|-bench----- benchmarks
|-calling--- calling C functions from Icon
|-general--- general tests
|-graphics-- tests for graphics
-tests----|-ipl------- tests for the Icon program library
|-preproc--- C preprocessor tests
|-samples--- short sample programs
|-special--- tests of special features
|-vtran----- tests variant translators
Some distributions contain other, optional components of Icon.
The Icon compiler is not included in all distributions of Icon.
4.__Parameters_and_Definitions
There are many defined constants and macros in the source code
for Icon that vary from platform to platform. Over the range of
possible platforms, there are many possibilities. A complete list
is given in Appendix A. Do not be intimidated by the large
number of options listed there; most are provided only for
unusual situations and only a few are needed for any one plat-
form.
The defined constants and macros needed for a specific plat-
form are placed in src/h/define.h. There are many existing
define.h files that can be used as guides. One for a ``vanilla''
32-bit platform is:
#define HostStr "new host"
#define NoCoexpr
#define PORT 1
HostStr provides the value used in the Icon keyword &host and
should be changed as appropriate. NoCoexpr causes Icon to be
IPD238b - 4 - November 1, 1995
configured without co-expressions. This definition can be
removed when co-expressions are implemented. See Appendix B.
PORT indicates an implementation for an unspecified operating
system. It should be changed to a name for the operating system
for the new platform (see Section 8). Other definitions probably
need to be added, of course.
5.__Configuring_Icon_for_a_UNIX_Platform
Since Icon has been implemented for many UNIX platforms, the
easiest way to configure Icon for a new UNIX platform usually is
to copy an existing configuration for a platform that is similar
to the new one. A few modifications then often suffice to get
Icon running on the new platform.
In addition to define.h, a UNIX configuration also contains
headers used to construct Makefiles. These headers are named
*.hdr. Check these headers for appropriateness.
See also [7] for information concerning the installation of
Icon on a UNIX platform.
6.__Adding_Configuration_Information_for_the_X_Window_System
If your platform has X Window software, you may wish to con-
figure Icon Version 9 with X support. Icon's X support consists
of a collection of Icon functions that call Xlib, the standard C
interface to X. At present, configuration of X Window facilities
is provided only for UNIX platforms.
In order to build Icon with these X Window functions, you will
need to know what library or libraries are required to link in
the X facilities into C programs; this library information is
needed when iconx is built and when iconc links a compiled Icon
executable. Normally, the answer will be -lX11, but on some plat-
forms additional libraries or alternate paths are required. Con-
sult appropriate manuals to find out what libraries are needed.
If your platform requires the default -lX11, no additional
steps are required in creating your configuration. If your plat-
form requires additional libraries, you will need to add files to
the configuration directory for your particular system.
The files xiconx.mak and xiconc.def, if they are present, are
used during Icon configuration to supply non-default library
information to the interpreter and the compiler.
If, for example, your platform requires an additional pseudo-
terminal library and a BSD-compatibility package in order to link
X applications, you would add an xiconx.mak file with the line
IPD238b - 5 - November 1, 1995
XLIB= -L../../bin -lX11 -lpt -lbsd
and a corresponding xiconc.def file with the line
#define ICONC_XLIB "-lX11 -lpt -lbsd"
The former file gets prepended to the Makefile that builds iconx,
while the latter file gets included and compiled into iconc when
X is configured. Then proceed to the make X-Configure build
step.
In order to build Icon with X support, some platforms also
will have to specify the location of the X header files. Normally
they are in /usr/include/X11; if they are in some other location
on your platform, you will need to locate them and identify the
appropriate option to add to the C compiler command line, usually
-I path, where path is the directory above the X11 include direc-
tory.
For the Icon compiler, this option is added via the COpts
macro in define.h for your configuration. The COpts macro must
define a quoted C string. For the interpreter, the option is
added to the CFLAGS argument of the common.hdr, icont.hdr,
runtime.hdr, and xpm.hdr Makefile headers for your configuration.
7.__Configuring_Icon_for_an_MS-DOS_Platform
In the case of MS-DOS, the primary considerations in configur-
ing Icon have to do with the C compiler that is used. There are
existing configurations for several 16- and 32-bit C compilers.
The easiest approach to configuring Icon for a new MS-DOS C
compiler is to copy an existing configuration for a C compiler
that most closely matches the new one.
An MS-DOS configuration includes Makefiles, batch scripts, and
response files for linking. These files should be modified for
the new platform as appropriate. See [8] for more information
concerning the installation of Icon on an MS-DOS platform.
8.__Configuring_Icon_for_a_New_Operating_System
The conditional compilation for specific operating systems is
concerned primarily with matters such as differences in file nam-
ing, the handling of input and output, and environmental factors.
The presently supported operating systems and their defined
constants are
IPD238b - 6 - November 1, 1995
constant operating system
AMIGA AmigaDos
ARM RISC OS for the Acorn Archimedes
ATARI_ST Atari ST TOS
MACINTOSH Macintosh
MSDOS MS-DOS
MVS MVS
OS2 OS/2
PORT new
UNIX UNIX
VM VM/CMS
VMS VMS
Conditional compilation uses logical expressions composed from
these symbols. An example is:
.
.
.
#if MSDOS
.
. /* code for MS-DOS */
.
#endif
#if UNIX || VMS
.
. /* code for UNIX and VMS */
.
#endif
.
.
.
Each symbol is defined to be either 1 (for the target operating
system) or 0 (for all other operating systems). This is accom-
plished by defining the symbol for the target operating system to
be 1 in define.h. In config.h, which includes define.h, all other
operating-system symbols are defined to be 0.
Logical conditionals with #if are used instead of defined or
undefined names with #ifdef to avoid nested conditionals, which
become very complicated and difficult to understand when there
are several alternative operating systems. Note that it is
important not to use #ifdef accidentally in place of #if, since
all the names are defined.
The file define.h for a different operating system should ini-
tially contain
#define PORT 1
as indicated in Section 4. You can use PORT during the confi-
guration for a different operating system. Later you should come
IPD238b - 7 - November 1, 1995
back and change PORT to some more appropriate name.
Note: The PORT sections contain deliberate syntax errors (so
marked) to prevent sections from being overlooked during confi-
guration. These syntax errors must, of course, be removed before
compilation.
To make it easy to locate places where there is code that may
be dependent on the operating system, such code usually is brack-
eted by unique comments of the following form:
/*
* The following code is operating-system dependent.
*/
.
.
.
/*
* End of operating-system specific code.
*/
Between these beginning and ending comments, the code for dif-
ferent operating systems is provided using conditional expres-
sions such as those indicated above.
Look through some of the files for such segments to get an
idea of what is involved. Each segment contains comments that
describe the purpose of the code. In some cases, the most likely
code or a suggestion is given in the conditional code under PORT.
In some cases, no code will be needed. In others, code for an
existing operating system may suffice for the new one.
In any event, code for the new operating system name must be
added to each such segment, either by adding it to a logical dis-
junction to take advantage of existing code for other operating
systems, as in
#if MSDOS || UNIX || PORT
.
.
.
#endif
#if VMS
.
.
.
#endif
and removing the present code for PORT or by filling in the seg-
ment with the appropriate code, as in
IPD238b - 8 - November 1, 1995
#if PORT
.
. /* code for the new operating system */
.
#endif
If no code is needed for the target operating system in a partic-
ular situation, a comment should be provided so that it is clear
that the situation has been considered.
You may find need for code that is operating-system dependent
at a place where no such dependency presently exists. If the
situation is idiosyncratic to your operating system, which is
most likely, simply use a conditional for PORT as shown above.
If the situation appears to need different code for several
operating systems, add a new segment similar to the other ones,
being sure to provide something appropriate for all operating
systems.
Do not use #else constructions in these segments; this
increases the probability of logical errors and obscures the
mutually exclusive nature of operating system differences.
9.__Trouble_Reports_and_Feedback
If you run into problems, contact us at the Icon Project:
Icon Project
Department of Computer Science
The University of Arizona
P.O. Box 210077
Tucson, AZ 85721-0077
U.S.A.
(520) 621-6613 (voice)
(520) 621-4246 (fax)
icon-project@cs.arizona.edu
Please also let us know of any suggestions for improvements to
the configuration process.
Once you have completed your installation, please send us
copies of any files that you modified so that we can make
corresponding changes in the central version of the source code.
Once this is done, you can get a new copy of the source code
whenever changes or extensions are made to the implementation.
Be sure to include documentation on any features that are not
implemented in your installation or any changes that would affect
users.
IPD238b - 9 - November 1, 1995
References
1. R. E. Griswold and M. T. Griswold, The Implementation of the
Icon Programming Language, Princeton University Press, 1986.
2. R. E. Griswold, Supplementary Information for the
Implementation of Version 8 of Icon, The Univ. of Arizona Icon
Project Document IPD112, 1995.
3. R. E. Griswold, Supplementary Information for the
Implementation of Version 9 of Icon, The Univ. of Arizona
Icon Project Document IPD239, 1995.
4. K. Walker, The Run-Time Implementation Language for Icon, The
Univ. of Arizona Icon Project Document IPD261, 1994.
5. B. W. Kernighan and D. M. Ritchie, The C Programming Language,
Prentice-Hall, Inc., Englewood Cliffs, NJ, first edition,
1978.
6. American National Standard for Information Systems -
Programming Language - C, ANSI X3.159-1989, American National
Standards Institute, New York, 1990.
7. R. E. Griswold, C. L. Jeffery and G. M. Townsend, Installing
Version 9 of Icon on UNIX Platforms, The Univ. of Arizona Icon
Project Document IPD243, 1995.
8. R. E. Griswold, Building Version 9 of Icon for MS-DOS, The
Univ. of Arizona Icon Project Document IPD249, 1995.
IPD238b - 10 - November 1, 1995
Appendix A - Configuration Parameters and Definitions
C_Compiler_Considerations
Although the source code for Icon does not require an ANSI C
compiler, installation is likely to be much easier if such a
compiler is used. It is necessary to specify that the compiler
is ANSI-conformant in order to take advantage of ANSI features.
If your C compiler is completely ANSI-conformant, add
#define Standard
to define.h.
Alternatively, you can define one or more of the following
constants if only a portion of your C compiler is ANSI-
conformant:
#define StandardPP /* standard preprocessor */
#define StandardC /* standard compiler proper */
#define StandardLib /* standard library */
If your C compiler supports the void type but is not ANSI-
conformant, add
#define VoidType
to define.h.
If your C compiler supports function prototypes but is not
ANSI-conformant, add
#define Prototypes
Icon normally defines the C language const with an empty
definition to remove its effect. If you have an ANSI C compiler
and this definition causes problems, add
#define AllowConst
to define.h.
On some platforms it may be necessary to provide a different
typedef for pointer than is provided by default. For example, on
the huge-memory-model implementation of Icon for Microsoft C on
MS-DOS, its define.h contains
typedef huge void *pointer;
If an alternative typedef is used for pointer, add
IPD238b - 11 - November 1, 1995
#define PointerDef
to define.h to avoid the default one.
Sometimes computing the difference of two pointers causes
problems. Pointer differences are computed using the macro
DiffPtrs(p1, p2), which has the default definition:
#define DiffPtrs(p1, p2) (word)((p1)-(p2))
where word is a typedef that is provided automatically and
usually is long int.
This definition can be overridden in define.h. For example,
Microsoft C for the MS-DOS large memory model uses
#define DiffPtrs(p1, p2) ((word)(p1)-(word)(p2))
If you provide an alternate definitions for pointer differencing,
be careful to enclose all arguments in parentheses.
Character_Set
The default character set for Icon is ASCII. If you are
configuring Icon for a platform that uses the EBCDIC character
set, add
#define EBCDIC 1
to define.h.
Data_Sizing_and_Alignment
There are two constants that relate to the size of C data:
WordBits (default: 32)
IntBits (default: WordBits)
IntBits is the number of bits in a C int. It may be 16, 32, or
64. WordBits is the number of bits in a C long (Icon's ``word'').
It may be 32 or 64.
If your C library expects doubles to be aligned at double-word
boundaries, add
#define Double
to define.h.
The word alignment of stacks used by co-expressions is
controlled by
StackAlign (default: 2)
IPD238b - 12 - November 1, 1995
If your platform needs a different alignment, provide an
appropriate definition in define.h.
Most computers have downward-growing C stacks, for which stack
addresses decrease as values are pushed. If you have an upward-
growing stack, for which stack addresses increase as values are
pushed, add
#define UpStack
to define.h.
Floating-Point_Arithmetic
There are three optional definitions related to floating-point
arithmetic:
Big (default: 9007199254740092.)
LogHuge (default: 309)
Precision (default: 10)
The values of Big, LogHuge, and Precision give, respectively, the
largest floating-point number that does not lose precision, the
maximum base-10 exponent + 1 of a floating-point number, and the
number of digits provided in the string representation of a
floating-point number. If the default values given above do not
suit the floating-point arithmetic on your platform, add
appropriate definitions to define.h.
Options_for_Opening_Files
The options for opening files with fopen() are given by the
following constants:
ReadBinary (default: "rb")
ReadText (default: "r")
WriteBinary (default: "wb")
WriteText (default: "w")
These defaults can be changed by definitions in define.h.
Library_Routines
Support from some library routines varies from platform to
platform, and names vary. The relevant definitions are:
IconEcvt
NoIconGcvt
NoSelect
SysMem
SysOpt
index
rindex
IPD238b - 13 - November 1, 1995
All are undefined by default.
By default, Icon uses the version of ecvt() in the C library.
If you prefer to use Icon's version, add
#define IconEcvt
to define.h.
By default, Icon provides its own version of gcvt() to
minimize the differences in the string representations of
floating-point numbers between different platforms. If you prefer
to use the version of gcvt() in your C library, add
#define NoIconGcvt
to define.h.
The Icon function delay() uses the C function select(). If
your C library does not have select(), add
#define NoSelect
to define.h. The effect of this is that delay() fails and does
not delay execution.
If SysMem is defined and IntBits == WordBits, the C library
routines memcpy() and memset() are used in place of the
corresponding Icon routines memcopy() and memfill(). SysMem is
automatically defined if Standard or StandardLib is defined.
If SysOpt is defined, the C library function getopt() is used
instead of Icon's private version.
Different C compilers use different names for the routines for
locating substrings within strings. The source code for Icon uses
index and rindex. The other possibilities are strchr and strrchr.
If your platform uses the latter names, add
#define index strchr
#define rindex strrchr
to define.h.
Icon uses unlink for the routine that deletes a file. The
other common name is remove. If your platform uses this name, for
example, add
#define unlink remove
to define.h.
IPD238b - 14 - November 1, 1995
Storage_Region_Sizes
The default sizes of Icon's run-time storage regions for
allocated data normally are the same for all implementations.
However, different values can be set:
MaxAbrSize (default: 500000)
MaxStrSize (default: 500000)
Since users can override the set values with environment
variables, it is unwise to change them from their defaults except
in unusual cases.
The sizes for Icon's main interpreter stack and co-expression
stacks also can be set:
MStackSize (default: 10000)
StackSize (default: 2000)
As for the block and string storage regions, it is unwise to
change the default values except in unusual cases.
Finally, a list used for pointers to strings during garbage
collection, can be sized:
QualLstSize (default: 5000)
Like the sizes above, this one normally is best left unchanged.
Allocation_Sizing
malloc() is used to allocate space for Icon's storage regions.
This limits region sizes to the value of the largest unsigned
int. Some platforms provide alternative allocation routines for
allocating larger regions. To change the allocation procedure
for regions, add a definition for AllocReg to define.h. For
example, the huge-memory-model implementation of Icon for
Microsoft C uses the following:
#define AllocReg(n) halloc((long)n, sizeof(char))
Note: Icon still uses malloc() for allocating other blocks. If
this is a problem, it may be possible to change this by defining
malloc in define.h, as in
#define malloc lmalloc
where lmalloc() is a local routine for allocating large blocks of
memory. If this is done, and the size of the allocation is not
unsigned int, add an appropriate definition for the type by
defining AllocType in define.h, such as
#define AllocType unsigned long int
IPD238b - 15 - November 1, 1995
It is also necessary to add a definition for the limit on the
size of an Icon region:
#define MaxBlock n
where n is the maximum size allowed (the default for MaxBlock is
MaxUnsigned, the largest unsigned int). It generally is not
advisable to set MaxBlock to the largest size an alternative
allocation routine can return. For the huge-memory-model
implementation mentioned above, MaxBlock is 256000.
File_Name_Suffixes
The suffixes used to identify Icon source programs, ucode
files, and icode files may be specified in define.h:
#define SourceSuffix(default: ".icn")
#define U1Suffix (default: ".u1")
#define U2Suffix (default: ".u2")
#define USuffix (default: ".u")
#define IcodeSuffix (default: "")
#define IcodeASuffix(default: "")
USuffix is used for the abbreviation that icont understands in
place of the complete U1Suffix or U2Suffix. IcodeASuffix is an
alternative suffix that iconx uses when searching for icode files
specified without a suffix. For example, on MS-DOS, IcodeSuffix
is ".icx" and IcodeASuffix is ".ICX".
If values other than the defaults are specified, care must be
taken not to introduce conflicts or collisions among names of
different types of files.
Paths
If icont is given a source program in a directory different
from the local one (``current working directory''), there is a
question as to where ucode and icode files should be created: in
the local directory or in the directory that contains the source
program. On most platforms, the appropriate place is in the local
directory (the user may not have write permission in the
directory that contains the source program). However, on some
platforms, the directory that contains the source file is
appropriate. By default, the directory for creating new files is
the local directory. The other choice can be selected by adding
#define TargetDir SourceDir
UNIX_Bootstrap_Headers
A bootstrap header is used to make UNIX icode files
executable. This header normally is a simple shell script. To
use an executable program for a header, as in Version 8 of Icon,
IPD238b - 16 - November 1, 1995
add
#define NoShellHeader
to define.h. The space reserved for an executable program header
is determined by
#define MaxHdr (default: 4096)
On some UNIX platforms, many routines may be included in the
header even if they are not needed. Start by assuming this is
not a problem, but if MaxHeader has to be made impractically
large, you can eliminate the header by adding
#define NoHeader
to define.h. Note: If NoHeader is defined, the values of MaxHdr
and NoShellHeader are irrelevant.
The effect of this definition is to render Icon programs non-
executable. Instead, they must be run by using the -x option
after the program name when icont is used, as in
icont prog.icn -x
Such a program also can be run as an argument of iconx, as in
iconx prog
where prog is the result of translating and linking prog.icn as
in the previous example.
Command-Line_Options
The command-line options that are supported by icont and iconc
are defined by IconOptions. The default value (see config.h) will
do for most platforms, but an alternative can be included in
define.h.
Similarly, the error message produced for erroneous command
lines is defined by TUsage for icont and CUsage for iconc. The
default values, which should correspond to the value of
IconOptions, are in config.h, but may be overridden by
definitions in define.h.
Environment_Variables
If your platform does not support environment variables (via
the run-time library routine getenv), add the following line to
define.h:
#define NoEnvVars
IPD238b - 17 - November 1, 1995
This disables Icon's ability to change internal parameters to
accommodate special user needs (such as using memory region sizes
different from the defaults), but does not otherwise interfere
with the use of Icon.
Host_Identification
The identification of the host computer as given by the Icon
keyword &host needs to be specified in define.h. The usual way
to to this is to add
#define HostStr "identification"
to define.h.
Several alternatives are available on UNIX platforms for host
identification. To use one of these, remove the definition of
HostStr and provide an alternative as follows.
On some versions of UNIX, notably Version 7 and 4.1bsd, the
file /usr/include/whoami.h contains the host name. If your system
has this file and you want to use this name, add
#define WhoHost
to define.h.
Some versions of UNIX, notably 4.2bsd and 4.3bsd, provide the
host name via the gethostname(2) system call. If your system
supports this system call and you want to use this name, add
#define GetHost
to define.h.
Some versions of UNIX, such as System V, provide the host name
via the uname(2) system call. If your system supports this call
and you want to use this name, add
#define UtsName
to define.h.
Note: Only one of these methods of specifying the host name
can be used.
Exit_Codes
Exit codes are determined by the following definitions:
NormalExit (default: 0)
ErrorExit (default: 1)
IPD238b - 18 - November 1, 1995
Clock_Rate
Hz defines the units returned by the times() function call.
Check the documentation for this function on your platform. If it
says that times are returned in terms of 1/60 second, no action
is needed. Otherwise, define Hz in define.h to be the number of
times() units in one second.
The documentation may refer you to an additional file such as
/usr/include/sys/param.h. If so, check the value there, and
define Hz accordingly.
Dynamic_Hashing_Constants
Four parameters configure the implementation of tables and
sets:
HSlots Initial number of hash buckets; it must be a
power of 2
HSegs Maximum number of hash bucket segments
MaxHLoad Maximum allowable loading factor
MinHLoad Minimum loading factor for new structures
The default values (listed below) are appropriate for most
platforms. If you want to change the values, read the discussion
that follows.
Every set or table starts with HSlots hash buckets, using one
bucket segment. When the average hash bucket exceeds MaxHLoad
entries, the number of buckets is doubled and one more segment is
consumed. This repeats until HSegs segments are in use; after
that, structure still grows but no more hash buckets are added.
MinHLoad is used only when copying a set or table or when
creating a new set through the intersection, union, or difference
of two other sets. In these cases a new set may be more lightly
loaded than otherwise, but never less than MinHLoad if it exceeds
a single bucket segment.
For all machines, the default load factors are 5 for MaxHLoad
and 1 for MinHLoad. Because splitting or combining buckets
halves or doubles the load factor, MinHLoad should be no more
than half MaxHLoad. The average number of elements in a hash
bucket over the life of a structure is about 2/3xMaxHLoad,
assuming the structure is not so huge as to be limited by HSegs.
Increasing MaxHLoad delays the creation of new hash buckets,
reducing memory demands at the expense of increased search times.
It has no effect on the memory requirements of minimally-sized
structures.
HSlots and HSegs interact to determine the minimum size of a
IPD238b - 19 - November 1, 1995
structure and its maximum efficient capacity. The size of an
empty set or table is directly related to HSegs+HSlots; smaller
values of these parameters reduce the memory needs of programs
using many small structures. Doubling HSlots delays the onset of
the first structure reorganization until twice as many elements
have been inserted. It also doubles the capacity of a structure,
as does increasing HSegs by 1.
The maximum number of hash buckets is HSlotsx(2^(HSegs-1)). A
structure can be considered ``full'' when it contains MaxHLoad
times that many entries; beyond that, lookup times gradually
increase as more elements are added. Until a structure becomes
full, the values of HSlots and HSegs do not affect lookup times.
For machines with 16-bit ints, the defaults are 4 for HSlots
and 6 for HSegs. Sets and tables grow from 4 hash buckets to a
maximum of 128, and become full at 640 elements. For other
machines, the defaults are 8 for HSlots and 10 for HSegs. sets
and tables grow from 8 hash buckets to a maximum of 4096, and
become full at 20480 elements.
Keyboard_Functions
If your platform supports the keyboard functions getch(),
getche(), and kbhit(), add
#define KeyboardFncs
to define.h.
Some UNIX platforms are capable of supporting the keyboard
functions. A UNIX platform should be able to to support the
keyboard functions if it supports ioctl() in a manner that is
compatible with either BSD/SunOS or System V. The keyboard
functions are enabled by default on platforms known to be
compatible, including SunOS, Xenix, System V/386, and a few
others.
On other platforms, in addition to adding
#define KeyboardFncs
to define.h as described above, select one of two methods for
calling ioctl() supported in the source code for Icon, and add it
to define.h:
#define HaveTioc
or
#define HaveTermio
Use HaveTioc if you have a BSD-based platform and have the system
IPD238b - 20 - November 1, 1995
include files <sys/ioctl.h>, <errno.h>, and <sys/signal.h>. The
system ioctl() call must support TIOCSETN, TIOCGETP, TIOCGETC,
and FIONREAD.
Use HaveTermio if you have a System V, Xenix 386, or
compatible platform and have the system include files
<sys/termio.h>, <sys/ioctl>, <sys/errno.h>, and <sys/signal.h>.
The system ioctl() call must support TCSETA, TCGETA, and (unless
it is a Xenix platform), FIONREAD.
If your platform supports neither of these methods, you may be
able to write your own keyboard functions. See
src/runtime/fsys.r.
Co-Expressions
The implementation of co-expressions requires an assembly-
language context switch. If your platform does not have a co-
expression context switch, you can implement one as described in
Appendix B. Alternatively, you can disable co-expressions by
adding
#define NoCoexpr
to define.h.
Other_Optional_Features
Some features of Icon are optional. Some of these normally are
enabled, while others normally are disabled. The features that
normally are enabled can be disabled to, for example, reduce the
size of the executable files. A negative form of definition is
used for these, as in
#define NoLargeInts
which can be added to define.h to disable large-integer
arithmetic. It may be necessary to disable large-integer
arithmetic on computers with a small amount of memory, since the
feature increases the size of the run-time system by 15-20%.
If your platform supports the system() function for executing
command line, add
#define SystemFnc
to define.h.
If your platform supports the dlopen() and dlsym() functions
for dynamic loading, add
#define LoadFunc
to define.h
IPD238b - 21 - November 1, 1995
X_Window_Facilities
The files needed to build Icon with X Window facilities are
not in the same places on all platforms. If Icon fails to build
because an include file needed by X cannot be found, it may be
necessary to edit src/h/sys.h to reflect the local location.
Some early versions of X Window Systems, notably X11R3, do not
support the attribute iconic. If this is the case for your
platform, add
#define NoIconify
to define.h. This disables the attribute iconic, causing
references to it to fail.
Compiler_Options
The C compiler called by the Icon compiler to process its
output defaults to cc. If you want to use a different C compiler,
add
#define CComp "name"
to define.h, where name is the name of the C compiler you want
the Icon compiler to use. Note the quotation marks surrounding
the name. For example, to use Gnu C, add
#define CComp "gcc"
By default, the C compiler is called with no options. If you
want specific options, add
#define COpts "options"
to define.h. Again, note the quotation marks. For example, to
request C optimizations, you might add
#define COpts "-O"
If your system does not have ranlib, add
#define NoRanlib
to define.h.
Debugging_Code
Icon contains some code to assist in debugging. It is enabled
by the definitions
IPD238b - 22 - November 1, 1995
#define DeBugTrans /* debugging code for the translator in icont */
#define DeBugLinker /* debugging code for the linker in icont */
#define DeBugIconx /* debugging code for the run-time */
All three of these are automatically defined if DeBug is defined.
The debugging code for the translator consists of functions
for dumping symbol tables (see icont/tsym.c). These functions are
rarely needed and there are no calls to them in the source code
as it is distributed.
The debugging code for the linker consists of a function for
dumping the code region (see icont/lcode.c) and code for
generating a debugging file that is a printable image of the
icode file produced by the linker. This debugging file, which is
produced if the option -L is given on the command line when icont
is run, may be useful if icode files are incorrect.
The debugging code for the executor consists of a few validity
checks at places where problems have been encountered in the
past. It also provides functions for dumping Icon values. See
runtime/rmisc.r and runtime/rmemmgt.r.
When installing Icon on a new operating system, it is
advisable to enable the debugging code until Icon is known to be
running properly. The code produced is innocuous and adds only a
few percent to the size of the executable files. It should be
removed by deleting the definition listed above from define.h as
the final step in the implementation for a new operating system.
IPD238b - 23 - November 1, 1995
Appendix B - Implementing a Co-Expression Context Switch
If your platform does not have a co-expression context switch,
you can implement one as described in this appendix. Note: If
your platform does not allow the C stack to be at an arbitrary
place in memory, there is probably little hope of implementing
co-expressions.
The routine coswitch() is needed for context switching. This
routine requires assembly language, since it must manipulate
hardware registers. It either can be written as a C routine with
asm directives or directly as an assembly language routine.
Calls to the context switch have the form
coswitch(old_cs,new_cs,first), where old_cs is a pointer to an
array of words (C longs) that contain C state information for the
current co-expression, new_cs is a pointer to an array of words
that hold C state information for a co-expression to be
activated, and first is 1 or 0, depending on whether or not the
new co-expression has or has not been activated before. The
zeroth element of a C state array always contains the hardware
stack pointer (sp) for that co-expression. The other elements can
be used to save any C frame pointers and any other registers your
C compiler expects to be preserved across calls.
The default size of the array for saving the C state is 15.
This number may be changed by adding
#define CStateSize n
to define.h, where n is the number of elements needed.
The first thing coswitch does is to save the current pointers
and registers in the old_cs array. Then it tests first. If first
is zero, coswitch sets sp from new_cs[0], clears the C frame
pointers, and calls new_context. If first is not zero, it loads
the (previously saved) sp, C frame pointers, and registers from
new_cs and returns.
Written in C, coswitch has the form:
IPD238b - 24 - November 1, 1995
/*
* coswitch
*/
coswitch(old_cs, new_cs, first)
long *old_cs, *new_cs;
int first;
{
.
.
.
/* save sp, frame pointers, and other registers in old_cs */
.
.
.
if (first == 0) { /* this is first activation */
.
.
.
/* load sp from new_cs[0] and clear frame pointers */
.
.
.
new_context(0, 0);
syserr("new_context() returned in coswitch");
}
else {
.
.
.
/* load sp, frame pointers, and other registers from new_cs */
.
.
.
}
}
After you implement coswitch, remove the #define NoCoexpr from
define.h. Verify that StackAlign and UpStack, if needed, are
properly defined.
To test your context switch, run the programs in
tests/general/coexpr.lst. Ideally, there should be no
differences in the comparison of outputs.
If you have trouble with your context switch, the first thing
to do is double-check the registers that your C compiler expects
to be preserved across calls - different C compilers on the same
computer may have different requirements.
Another possible source of problems is built-in stack
checking. Co-expressions rely on being able to specify an
IPD238b - 25 - November 1, 1995
arbitrary region of memory for the C stack. If your C compiler
generates code for stack probes that expects the C stack to be at
a specific location, you may need to disable this code or replace
it with something more appropriate.
IPD238b - 26 - November 1, 1995