godzil/ack
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fixup commit for branch 'hs'

Browse Source 
--HG--
branch : hs
This commit is contained in:
cvs2hg 1984-10-23 15:02:04 +00:00
parent 62f42d18f7
commit 765ebcc864
454 changed files with 0 additions and 84701 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
Copyright
View File

@ -1,17 +0,0 @@
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/

35
Makefile
View File

@ -1,35 +0,0 @@
cmp: # compile everything and compare
(cd etc ; make cmp )
(cd util ; make cmp )
(cd lang ; make cmp )
(cd mach ; make cmp )
install: # compile everything to machine code
(cd etc ; make install )
(cd util ; make install )
(cd lang/cem ; make install )
(cd mach ; make install )
(cd lang/pc ; make install )
clean: # remove all non-sources, except boot-files
(cd doc ; make clean )
(cd man ; make clean )
(cd h ; make clean )
(cd etc ; make clean )
(cd util ; make clean )
(cd lang ; make clean )
(cd mach ; make clean )
opr: # print all sources
make pr | opr
pr: # print all sources
@( pr Makefile ; \
(cd doc ; make pr ) ; \
(cd man ; make pr ) ; \
(cd h ; make pr ) ; \
(cd etc ; make pr ) ; \
(cd lang ; make pr ) ; \
(cd util ; make pr ) ; \
(cd mach ; make pr ) \
)

44
doc/Makefile
View File

@ -1,44 +0,0 @@
# $Header$
SUF=pr
PRINT=cat
RESFILES=cref.$(SUF) pcref.$(SUF) val.$(SUF) v7bugs.$(SUF) install.$(SUF)\
ack.$(SUF) cg.$(SUF) regadd.$(SUF) peep.$(SUF) toolkit.$(SUF) LLgen.$(SUF)
NROFF=nroff
MS=-ms
cref.$(SUF): cref.doc
tbl $? | $(NROFF) >$@
v7bugs.$(SUF): v7bugs.doc
$(NROFF) $(MS) $? >$@
ack.$(SUF): ack.doc
$(NROFF) $(MS) $? >$@
cg.$(SUF): cg.doc
$(NROFF) $(MS) $? >$@
regadd.$(SUF): regadd.doc
$(NROFF) $(MS) $? >$@
install.$(SUF): install.doc
$(NROFF) $(MS) $? >$@
pcref.$(SUF): pcref.doc
$(NROFF) $? >$@
peep.$(SUF): peep.doc
$(NROFF) $(MS) $? >$@
val.$(SUF): val.doc
$(NROFF) $? >$@
toolkit.$(SUF): toolkit.doc
$(NROFF) $(MS) $? >$@
LLgen.$(SUF): LLgen.doc
eqn $? | $(NROFF) $(MS) >$@
install cmp:
pr:
@make "SUF="$SUF "NROFF="$NROFF "PRINT="$PRINT $(RESFILES) \
>make.pr.out 2>&1
@$(PRINT) $(RESFILES)
opr:
make pr | opr
clean:
-rm -f *.old $(RESFILES) *.t

420
doc/ack.doc
View File

@ -1,420 +0,0 @@
.\" $Header$
.nr LL 7.5i
.tr ~
.nr PD 1v
.TL
Ack Description File
.br
Reference Manual
.AU
Ed Keizer
.AI
Wiskundig Seminarium
Vrije Universiteit
Amsterdam
.NH
Introduction
.PP
The program \fIack\fP(I) internally maintains a table of
possible transformations and a table of string variables.
The transformation table contains one entry for each possible
transformation of a file.
Which transformations are used depends on the suffix of the
source file.
Each transformation table entry tells which input suffixes are
allowed and what suffix/name the output file has.
When the output file does not already satisfy the request of the
user, with the flag \fB-c.suffix\fP, the table is scanned
starting with the next transformation in the table for another
transformation that has as input suffix the output suffix of
the previous transformation.
A few special transformations are recognized, among them is the
combiner.
A program combining several files into one.
When no stop suffix was specified (flag \fB-c.suffix\fP) \fIack\fP
stops after executing the combiner with as arguments the -
possibly transformed - input files and libraries.
\fIAck\fP will only perform the transformations in the order in
which they are presented in the table.
.LP
The string variables are used while creating the argument list
and program call name for
a particular transformation.
.NH
Which descriptions are used
.PP
\fIAck\fP always uses two description files: one to define the
front-end transformations and one for the machine dependent
back-end transformations.
Each description has a name.
First the way of determining
the name of the descriptions needed is described.
.PP
When the shell environment variable ACKFE is set \fIack\fP uses
that to determine the front-end table name, otherwise it uses
\fBfe\fP.
.PP
The way the backend table name is determined is more
convoluted.
.br
First, when the last filename in the program call name is not
one of \fIack\fP, \fIcc\fP, \fIacc\fP, \fIpc\fP or \fIapc\fP,
this filename is used as the backend description name.
Second, when the \fB-m\fP is present the \fB-m\fP is chopped of this
flag and the rest is used as the backend description name.
Third, when both failed the shell environment variable ACKM is
used.
Last, when also ACKM was not present the default backend is
used, determined by the definition of ACKM in h/local.h.
The presence and value of the definition of ACKM is
determined at compile time of \fIack\fP.
.PP
Now, we have the names, but that is only the first step.
\fIAck\fP stores a few descriptions at compile time.
This descriptions are simply files read in at compile time.
At the moment of writing this document, the descriptions
included are: pdp, fe, i86, m68k2, vax2 and int.
The name of a description is first searched for internally,
then in the directory lib/ack and finally in the current
directory of the user.
.NH
Using the description file
.PP
Before starting on a narrative of the description file,
the introduction of a few terms is necessary.
All these terms are used to describe the scanning of zero
terminated strings, thereby producing another string or
sequence of strings.
.IP Backslashing 5
.br
All characters preceded by \e are modified to prevent
recognition at further scanning.
This modification is undone before a string is passed to the
outside world as argument or message.
When reading the description files the
sequences \e\e, \e# and \e<newline> have a special meaning.
\e\e translates to a single \e, \e# translates to a single #
that is not
recognized as the start of comment, but can be used in
recognition and finally, \e<newline> translates to nothing at
all, thereby allowing continuation lines.
.nr PD 0
.IP "Variable replacement"
.br
The scan recognizes the sequences {{, {NAME} and {NAME?text}
Where NAME can be any combination if characters excluding ? and
} and text may be anything excluding }.
(~\e} is allowed of course~)
The first sequence produces an unescaped single {.
The second produces the contents of the NAME, definitions are
done by \fIack\fP and in description files.
When the NAME is not defined an error message is produced on
the diagnostic output.
The last sequence produces the contents of NAME if it is
defined and text otherwise.
.PP
.IP "Expression replacement"
.br
Syntax: (\fIsuffix sequence\fP:\fIsuffix sequence\fP=\fItext\fP)
.br
Example: (.c.p.e:.e=tail_em)
.br
If the two suffix sequences have a common member -~\&.e in this
case~- the text is produced.
When no common member is present the empty string is produced.
Thus the example given is a constant expression.
Normally, one of the suffix sequences is produced by variable
replacement.
\fIAck\fP sets three variables while performing the diverse
transformations: HEAD, TAIL and RTS.
All three variables depend on the properties \fIrts\fP and
\fIneed\fP from the transformations used.
Whenever a transformation is used for the first time,
the text following the \fIneed\fP is appended to both the HEAD and
TAIL variable.
The value of the variable RTS is determined by the first
transformation used with a \fIrts\fP property.
.LP
Two runtime flags have effect on the value of one or more of
these variables.
The flag \fB-.suffix\fP has the same effect on these three variables
as if a file with that \fBsuffix\fP was included in the argument list
and had to be translated.
The flag \fB-r.suffix\fP only has that effect on the TAIL
variable.
The program call names \fIacc\fP and \fIcc\fP have the effect
of an automatic \fB-.c\fB flag.
\fIApc\fP and \fIpc\fP have the effect of an automatic \fB-.p\fP flag.
.IP "Line splitting"
.br
The string is transformed into a sequence of strings by replacing
the blank space by string separators (nulls).
.IP "IO replacement"
.br
The > in the string is replaced by the output file name.
The < in the string is replaced by the input file name.
When multiple input files are present the string is duplicated
for each input file name.
.nr PD 1v
.LP
Each description is a sequence of variable definitions followed
by a sequence of transformation definitions.
Variable definitions use a line each, transformations
definitions consist of a sequence of lines.
Empty lines are discarded, as are lines with nothing but
comment.
Comment is started by a # character, and continues to the end
of the line.
Three special two-characters sequences exist: \e#, \e\e and
\e<newline>.
Their effect is described under 'backslashing' above.
Each - nonempty - line starts with a keyword, possibly
preceded by blank space.
The keyword can be followed by a further specification.
The two are separated by blank space.
.PP
Variable definitions use the keyword \fIvar\fP and look like this:
.DS X
var NAME=text
.DE
The name can be any identifier, the text may contain any
character.
Blank space before the equal sign is not part of the NAME.
Blank space after the equal is considered as part of the text.
The text is scanned for variable replacement before it is
associated with the variable name.
.br
.sp 2
The start of a transformation definition is indicated by the
keyword \fIname\fP.
The last line of such a definition contains the keyword
\fIend\fP.
The lines in between associate properties to a transformation
and may be presented in any order.
The identifier after the \fIname\fP keyword determines the name
of the transformation.
This name is used for debugging and by the \fB-R\fP flag.
The keywords are used to specify which input suffices are
recognized by that transformation,
the program to run, the arguments to be handed to that program
and the name or suffix of the resulting output file.
Two keywords are used to indicate which run-time startoffs and
libraries are needed.
The possible keywords are:
.IP \fIfrom\fP
.br
followed by a sequence of suffices.
Each file with one of these suffices is allowed as input file.
Preprocessor transformations, those with the \fBP\fP property
after the \fIprop\fP keyword, do not need the \fIfrom\fP
keyword. All other transformations do.
.nr PD 0
.IP \fIto\fP
.br
followed by the suffix of the output file name or in the case of a
linker -~indicated by C option after the \fIprop\fP keyword~-
the output file name.
.IP \fIprogram\fP
.br
followed by name of the load file of the program, a pathname most likely
starts with either a / or {EM}.
This keyword must be
present, the remainder of the line
is subject to backslashing and variable replacement.
.IP \fImapflag\fP
.br
The mapflags are used to grab flags given to \fIack\fP and
pass them on to a specific transformation.
This feature uses a few simple pattern matching and replacement
facilities.
Multiple occurences of this keyword are allowed.
This text following the keyword is
subjected to backslashing.
The keyword is followed by a match expression and a variable
assignment separated by blank space.
As soon as both description files are read, \fIack\fP looks
at all transformations in these files to find a match for the
flags given to \fIack\fP.
The flags \fB-m\fP, \fB-o\fP,
\fI-O\fP, \fB-r\fP, \fB-v\fP, \fB-g\fP, -\fB-c\fP, \fB-t\fP,
\fB-k\fP, \fB-R\fP and -\f-.\fP are specific to \fIack\fP and
not handed down to any transformation.
The matching is performed in the order in which the entries
appear in the definition.
The scanning stops after first match is found.
When a match is found, the variable assignment is executed.
A * in the match expression matches any sequence of characters,
a * in the right hand part of the assignment is
replaced by the characters matched by
the * in the expression.
The right hand part is also subject to variable replacement.
The variable will probably be used in the program arguments.
The \fB-l\fP flags are special,
the order in which they are presented to \fIack\fP must be
preserved.
The identifier LNAME is used in conjunction with the scanning of
\fB-l\fP flags.
The value assigned to LNAME is used to replace the flag.
The example further on shows the use all this.
.IP \fIargs\fP
.br
The keyword is followed by the program call arguments.
It is subject to backslashing, variable replacement, expression
replacement, line splitting and IO replacement.
The variables assigned to by \fImapflags\P will probably be
used here.
The flags not recognized by \fIack\fP or any of the transformations
are passed to the linker and inserted before all other arguments.
.IP \fIprop\fB
.br
This -~optional~- keyword is followed by a sequence of options,
each option is indicated by one character
signifying a special property of the transformation.
The possible options are:
.DS X
< the input file will be read from standard input
> the output file will be written on standard output
p the input files must be preprocessed
m the input files must be preprocessed when starting with #
O this transformation is an optimizer and may be skipped
P this transformation is the preprocessor
C this transformation is the linker
.DE
.IP \fIrts\fP
.br
This -~optional~- keyword indicates that the rest of the line must be
used to set the variable RTS, if it was not already set.
Thus the variable RTS is set by the first transformation
executed which such a property or as a result from \fIack\fP's program
call name (acc, cc, apc or pc) or by the \fB-.suffix\fP flag.
.IP \fIneed\fP
.br
This -~optional~- keyword indicates that the rest of the line must be
concatenated to the NEEDS variable.
This is done once for every transformation used or indicated
by one of the program call names mentioned above or indicated
by the \fB-.suffix\fP flag.
.br
.nr PD 1v
.NH
Conventions used in description files
.PP
\fIAck\fP reads two description files.
A few of the variables defined in the machine specific file
are used by the descriptions of the front-ends.
Other variables, set by \fack\fB, are of use to all
transformations.
.PP
\fIAck\fP sets the variable EM to the home directory of the
Amsterdam Compiler Kit.
The variable SOURCE is set to the name of the argument that is currently
being massaged, this is usefull for debugging.
.br
The variable M indicates the
directory in mach/{M}/lib/tail_..... and NAME is the string to
be defined by the preprocessor with -D{NAME}.
The definitions of {w}, {s}, {l}, {d}, {f} and {p} indicate
EM_WSIZE, EM_SSIZE, EM_LSIZE, EM_DSIZE, EM_FSIZE and EM_PSIZE
respectively.
.br
The variable INCLUDES is used as the last argument to \fIcpp\fP,
it is currently used to add the directory {EM}/include to
the list of directories containing #include files.
{EM}/include contains a few files used by the library routines
for part III from the
.UX
manual.
These routines are included in the kit.
.PP
The variables HEAD, TAIL and RTS are set by \fIack\fP and used
to compose the arguments for the linker.
.NH
Example
.sp 1
description for front-end
.DS X
name cpp # the C-preprocessor
# no from, it's governed by the P property
to .i # result files have suffix i
program {EM}/lib/cpp # pathname of loadfile
mapflag -I* CPP_F={CPP_F?} -I* # grab -I.. -U.. and
mapflag -U* CPP_F={CPP_F?} -U* # -D.. to use as arguments
mapflag -D* CPP_F={CPP_F?} -D* # in the variable CPP_F
args {CPP_F?} {INCLUDES?} -D{NAME} -DEM_WSIZE={w} -DEM_PSIZE={p} \
-DEM_SSIZE={s} -DEM_LSIZE={l} -DEM_FSIZE={f} -DEM_DSIZE={d} <
# The arguments are: first the -[IUD]...
# then the include dir's for this machine
# then the NAME and size valeus finally
# followed by the input file name
prop >P # Output on stdout, is preprocessor
end
name cem # the C-compiler proper
from .c # used for files with suffix .c
to .k # produces compact code files
program {EM}/lib/em_cem # pathname of loadfile
mapflag -p CEM_F={CEM_F?} -Xp # pass -p as -Xp to cem
mapflag -L CEM_F={CEM_F?} -l # pass -L as -l to cem
args -Vw{w}i{w}p{p}f{f}s{s}l{l}d{d} {CEM_F?}
# the arguments are the object sizes in
# the -V... flag and possibly -l and -Xp
prop <>p # input on stdin, output on stdout, use cpp
rts .c # use the C run-time system
need .c # use the C libraries
end
name decode # make human readable files from compact code
from .k.m # accept files with suffix .k or .m
to .e # produce .e files
program {EM}/lib/em_decode # pathname of loadfile
args < # the input file name is the only argument
prop > # the output comes on stdout
end
.DE
.DS X
Example of a backend, in this case the EM assembler/loader.
var w=2 # wordsize 2
var p=2 # pointersize 2
var s=2 # short size 2
var l=4 # long size 4
var f=4 # float size 4
var d=8 # double size 8
var M=int # Unused in this example
var NAME=int22 # for cpp (NAME=int results in #define int 1)
var LIB=mach/int/lib/tail_ # part of file name for libraries
var RT=mach/int/lib/head_ # part of file name for run-time startoff
var SIZE_FLAG=-sm # default internal table size flag
var INCLUDES=-I{EM}/include # use {EM}/include for #include files
name asld # Assembler/loader
from .k.m.a # accepts compact code and archives
to e.out # output file name
program {EM}/lib/em_ass # load file pathname
mapflag -l* LNAME={EM}/{LIB}* # e.g. -ly becomes
# {EM}/mach/int/lib/tail_y
mapflag -+* ASS_F={ASS_F?} -+* # recognize -+ and --
mapflag --* ASS_F={ASS_F?} --*
mapflag -s* SIZE_FLAG=-s* # overwrite old value of SIZE_FLAG
args {SIZE_FLAG} \
({RTS}:.c={EM}/{RT}cc) ({RTS}:.p={EM}/{RT}pc) -o > < \
(.p:{TAIL}={EM}/{LIB}pc) \
(.c:{TAIL}={EM}/{LIB}cc.1s {EM}/{LIB}cc.2g) \
(.c.p:{TAIL}={EM}/{LIB}mon)
# -s[sml] must be first argument
# the next line contains the choice for head_cc or head_pc
# and the specification of in- and output.
# the last three args lines choose libraries
prop C # This is the final stage
end
.DE
The command "ack -mint -v -v -I../h -L -ly prog.c"
would result in the following
calls (with exec(II)):
.DS X
1) /lib/cpp -I../h -I/usr/em/include -Dint22 -DEM_WSIZE=2 -DEM_PSIZE=2
-DEM_SSIZE=2 -DEM_LSIZE=4 -DEM_FSIZE=4 -DEM_DSIZE=8 prog.c
2) /usr/em/lib/em_cem -Vw2i2p2f4s2l4d8 -l
3) /usr/em/lib/em_ass -sm /usr/em/mach/int/lib/head_cc -o e.out prog.k
/usr/em/mach/int/lib/tail_y /usr/em/mach/int/lib/tail_cc.1s
/usr/em/mach/int/lib/tail_cc.2g /usr/em/mach/int/lib/tail_mon
.DE

1838
doc/cg.doc
View File

File diff suppressed because it is too large Load Diff

318
doc/cref.doc
View File

@ -1,318 +0,0 @@
.\" $Header$
.ll 72
.nr ID 4
.de hd
'sp 2
'tl ''-%-''
'sp 3
..
.de fo
'bp
..
.tr ~
. TITLE
.de TL
.sp 15
.ce
\\fB\\$1\\fR
..
. AUTHOR
.de AU
.sp 15
.ce
by
.sp 2
.ce
\\$1
..
. DATE
.de DA
.sp 3
.ce
( Dated \\$1 )
..
. INSTITUTE
.de VU
.sp 3
.ce 4
Wiskundig Seminarium
Vrije Universteit
De Boelelaan 1081
Amsterdam
..
. PARAGRAPH
.de PP
.sp
.ti +\n(ID
..
.nr CH 0 1
. CHAPTER
.de CH
.nr SH 0 1
.bp
.in 0
\\fB\\n+(CH.~\\$1\\fR
.PP
..
. SUBCHAPTER
.de SH
.sp 3
.in 0
\\fB\\n(CH.\\n+(SH.~\\$1\\fR
.PP
..
. INDENT START
.de IS
.sp
.in +\n(ID
..
. INDENT END
.de IE
.in -\n(ID
.sp
..
.de PT
.ti -\n(ID
.ta \n(ID
.fc " @
"\\$1@"\c
.fc
..
. DOUBLE INDENT START
.de DS
.sp
.in +\n(ID
.ll -\n(ID
..
. DOUBLE INDENT END
.de DE
.ll +\n(ID
.in -\n(ID
.sp
..
. EQUATION START
.de EQ
.sp
.nf
..
. EQUATION END
.de EN
.fi
.sp
..
. ITEM
.de IT
.sp
.in 0
\\fB~\\$1\\fR
.ti +5
..
.de CS
.br
~-~\\
..
.br
.fi
.TL "Ack-C reference manual"
.AU "Ed Keizer"
.DA "September 12, 1983"
.VU
.wh 0 hd
.wh 60 fo
.CH "Introduction"
The C frontend included in the Amsterdam Compiler Kit
translates UNIX-V7 C into compact EM code [1].
The language accepted is described in [2] and [3].
This document describes which implementation dependent choices were
made in the Ack-C frontend and
some restrictions and additions.
.CH "The language"
.PP
Under the same heading as used in [2] we describe the
properties of the Ack-C frontend.
.IT "2.2 Identifiers"
External identifiers are unique up to 7 characters and allow
both upper and lower case.
.IT "2.4.3 Character constants"
The ASCII-mapping is used when a character is converted to an
integer.
.IT "2.4.4 Floating constants"
To prevent loss of precision the compiler does not perform
floating point constant folding.
.IT "2.6 Hardware characteristics"
The size of objects of the several arithmetic types and the two
pointer types depend on the EM-implementation used.
The ranges of the arithmetic types depend on the size used,
the C-frontend assumes two's complement representation for the
integral types. All sizes are multiples of bytes.
The calling program \fIack\fP[4] passes information about the
size of the types to the compiler proper.
.br
However, a few general remarks must be made:
.sp 1
.IS
.PT (a)
Two different pointer types exist: pointers to data and
pointers to functions.
The latter type is twice as large as the former.
Pointers to functions use the same format as Pascal procedure
parameters, thereby allowing C to use Pascal procedure
parameters and vice-versa.
The extra information passed indicates the scope level of the
procedure.
.PT (b)
The size of pointers to data is a multiple of
(or equal to) the size of an \fIint\fP.
.PT (c)
The following relations exist for the sizes of the types
mentioned:
.br
.ti +5
\fIchar<=short<=int<=long\fP
.PT (d)
Objects of type \fIchar\fP use one 8-bit byte of storage,
although several bytes are allocated sometimes.
.PT (e)
All sizes are in multiples of bytes.
.PT (f)
Most EM implementations use 4 bytes for floats and 8 bytes
for doubles, but exceptions to this rule occur.
.IE
.IT "6.1 Characters and integers"
Objects of type \fIchar\fP are unsigned and do not cause
sign-extension when converted to \fIint\fP.
The range of characters values is from 0 to 255.
.IT "6.3 Floating and integral"
Floating point numbers are truncated towards zero when
converted to the integral types.
.IT "6.4 Pointers and integers"
When a \fIlong\fP is added to or subtracted from a pointer and
longs are larger then data pointers the \fIlong\fP is converted to an
\fIint\fP before the operation is performed.
.IT "8.5 Structure and union declarations"
The only type allowed for fields is \fIint\fP.
Fields with exactly the size of \fIint\fP are signed,
all other fields are unsigned.
.br
The size of any single structure must be less then 4096 bytes.
.IT "8.6 Initialization"
Initialization of structures containing bit fields is not
allowed.
There is one restriction when using an 'address expression' to initialize
an integral variable.
The integral variable must have the size of a data pointer.
Conversions altering the size of the address expression are not allowed.
.IT "10.1 External function definitions"
The total amount for storage used for parameters
in any function must be less then 4096 bytes.
The same holds for the total amount of storage occupied by the
automatic variables declared inside any function.
.sp
Using formal parameters whose size is smaller the the size of an int
is less efficient on several machines.
At procedure entry these parameters are converted from integer to the
declared type, because the compiler doesn't know where the least
significant bytes are stored in the int.
.IT "11.2 Scope of externals"
Most C compilers are rather lax in enforcing the restriction
that only one external definition without the keyword
\fIextern\fP is allowed in a program.
The Ack-C frontend is very strict in this.
The only exception is that declarations of arrays with a
missing first array bounds expression are regarded to have an
explicit keyword \fIextern\fP.
.IT "14.4 Explicit pointer conversions"
Pointers may be larger the ints, thus assigning a pointer to an
int and back will not always result in the same pointer.
The process mentioned above works with integrals
of the same size or larger as pointers in all EM implementations
having such integrals.
Note that pointers to functions have
twice the size of pointers to data.
When converting data pointers to an integral type or vice-versa,
the pointers is seen as an unsigned with the same size a data-pointer.
When converting function pointers to anything else the static link part
of the pointer is discarded,
the resulting value is treated as if it were a data pointer.
When converting a data pointer or object of integral type to a function pointer
a static link with the value 0 is added to complete the function pointer.
.br
EM guarantees that any object can be placed at a word boundary,
this allows the C-programs to use \fIint\fP pointers
as pointers to objects of any type not smaller than an \fIint\fP.
.CH "Frontend options"
The C-frontend has a few options, these are controlled
by flags:
.IS
.PT -V
This flag is followed by a sequence of letters each followed by
positive integers. Each letter indicates a
certain type, the integer following it specifies the size of
objects of that type. One letter indicates the wordsize used.
.IS
.sp 1
.TS
center tab(:);
l l16 l l.
letter:type:letter:type
w:wordsize:i:int
s:short:l:long
f:float:d:double
p:pointer::
.TE
.sp 1
All existing implementations use an integer size equal to the
wordsize.
.IE
The calling program \fIack\fP[4] provides the frontend with
this flag, with values depending on the machine used.
.sp 1
.PT -l
The frontend normally generates code to keep track of the line
number and source file name at runtime for debugging purposes.
Currently a pointer to a
string containing the filename is stored at a fixed place in
memory at each function
entry and the line number at the start of every expression.
At the return from a function these memory locations are not reset to
the values they had before the call.
Most library routines do not use this feature and thus do not
ruin the current line number and filename when called.
However, you are really unlucky when your program crashes due
to a bug in such a library function, because the line number
and filename do not indicate that something went wrong inside
the library function.
.br
Providing the flag -l to the frontend tells it not to generate
the code updating line number and file name.
This is, for example, used when translating the stdio library.
.br
When the \fIack\fP[4] is called with the -L flag it provides
the frontend with this flag.
.sp 1
.PT -Xp
When this flag is present the frontend generates a call to
the function \fBprocentry\fP at each function entry and a
call to \fBprocexit\fP at each function exit.
Both functions are provided with one parameter,
a pointer to a string containing the function name.
.br
When \fIack\fP is called with the -p flag it provides the
frontend with this flag.
.IE
.CH References
.IS
.PT [1]
A.S. Tanenbaum, Hans van Staveren, Ed Keizer and Johan
Stevenson \fIDescription of a machine architecture for use with
block structured languages\fP Informatica report IR-81.
.sp 1
.PT [2]
B.W. Kernighan and D.M. Ritchie, \fIThe C Programming
language\fP, Prentice-Hall, 1978
.PT [3]
D.M. Ritchie, \fIC Reference Manual\fP
.sp
.PT [4]
UNIX manual ack(I).

28
doc/em/Makefile
View File

@ -1,28 +0,0 @@
head: doc.pr
NROFF=nroff
FILES = macr.nr title.nr intro.nr mem.nr ispace.nr dspace.nr mapping.nr types.nr descr.nr iotrap.nr mach.nr assem.nr app.nr
IOP=../../util/ass/ip_spec.t
doc.pr: $(FILES) itables em.i
tbl $(FILES) | $(NROFF) >doc.pr
opr: doc.pr
make pr | opr
pr:
@make "NROFF="$NROFF doc.pr >makepr.out 2>&1
@cat doc.pr
app.t: itables em.i
em.i: int/em.p
@echo Sorry, this copy was edited by hand from int/em.p
itables: $(IOP)
awk -f ip.awk $(IOP) | tbl >itables
.SUFFIXES : .pr .nr
.nr.pr: ; tbl macr.nr $*.nr | $(NROFF) >$@
cont.t intro.t mem.t ispace.t dspace.t mapping.t succ.t descr.t iotrap.t mach.t assem.t kern.t app.t: macr.nr

1
doc/em/READ_ME
View File

@ -1 +0,0 @@
Sorry, the kun macro package is not ours to distribute.

1121
doc/em/addend.n
View File

File diff suppressed because it is too large Load Diff

488
doc/em/app.nr
View File

@ -1,488 +0,0 @@
.BP
.AP "EM INTERPRETER"
.nf
.ta 8 16 24 32 40 48 56 64 72 80
.so em.i
.fi
.BP
.AP "EM CODE TABLES"
The following table is used by the assembler for EM machine
language.
It specifies the opcodes used for each instruction and
how arguments are mapped to machine language arguments.
The table is presented in three columns,
each line in each column contains three or four fields.
Each line describes a range of interpreter opcodes by
specifying for which instruction the range is used, the type of the
opcodes (mini, shortie, etc..) and range for the instruction
argument.
.A
The first field on each line gives the EM instruction mnemonic,
the second field gives some flags.
If the opcodes are minis or shorties the third field specifies
how many minis/shorties are used.
The last field gives the number of the (first) interpreter
opcode.
.N 1
Flags :
.IS 3
.N 1
Opcode type, only one of the following may be specified.
.PS - 5 " "
.PT -
opcode without argument
.PT m
mini
.PT s
shortie
.PT 2
opcode with 2-byte signed argument
.PT 4
opcode with 4-byte signed argument
.PT 8
opcode with 8-byte signed argument
.PE
Secondary (escaped) opcodes.
.PS - 5 " "
.PT e
The opcode thus marked is in the secondary opcode group instead
of the primary
.PE
restrictions on arguments
.PS - 5 " "
.PT N
Negative arguments only
.PT P
Positive and zero arguments only
.PE
mapping of arguments
.PS - 5 " "
.PT w
argument must be divisible by the wordsize and is divided by the
wordsize before use as opcode argument.
.PT o
argument ( possibly after division ) must be >= 1 and is
decremented before use as opcode argument
.PE
.IE
If the opcode type is 2,4 or 8 the resulting argument is used as
opcode argument (least significant byte first).
.N
If the opcode type is mini, the argument is added
to the first opcode - if in range - .
If the argument is negative, the absolute value minus one is
used in the algorithm above.
.N
For shorties with positive arguments the first opcode is used
for arguments in the range 0..255, the second for the range
256..511, etc..
For shorties with negative arguments the first opcode is used
for arguments in the range -1..-256, the second for the range
-257..-512, etc..
The byte following the opcode contains the least significant
byte of the argument.
First some examples of these specifications.
.PS - 5
.PT "aar mwPo 1 34"
Indicates that opcode 34 is used as a mini for Positive
instruction arguments only.
The w and o indicate division and decrementing of the
instruction argument.
Because the resulting argument must be zero ( only opcode 34 may be used
), this mini can only be used for instruction argument 2.
Conclusion: opcode 34 is for "AAR 2".
.PT "adp sP 1 41"
Opcode 41 is used as shortie for ADP with arguments in the range
0..255.
.PT "bra sN 2 60"
Opcode 60 is used as shortie for BRA with arguments -1..-256,
61 is used for arguments -257..-512.
.PT "zer e- 145"
Escaped opcode 145 is used for ZER.
.PE
The interpreter opcode table:
.N 1
.IS 3
.DS B
.so itables
.DE 0
.IE
.P
The table above results in the following dispatch tables.
Dispatch tables are used by interpreters to jump to the
routines implementing the EM instructions, indexed by the next opcode.
Each line of the dispatch tables gives the routine names
of eight consecutive opcodes, preceded by the first opcode number
on that line.
Routine names consist of an EM mnemonic followed by a suffix.
The suffices show the encoding used for each opcode.
.N
The following suffices exist:
.N 1
.VS 1 0
.IS 4
.PS - 11
.PT .z
no arguments
.PT .l
16-bit argument
.PT .lw
16-bit argument divided by the wordsize
.PT .p
positive 16-bit argument
.PT .pw
positive 16-bit argument divided by the wordsize
.PT .n
negative 16-bit argument
.PT .nw
negative 16-bit argument divided by the wordsize
.PT .s<num>
shortie with <num> as high order argument byte
.PT .sw<num>
shortie with argument divided by the wordsize
.PT .<num>
mini with <num> as argument
.PT .<num>W
mini with <num>*wordsize as argument
.PE 3
<num> is a possibly negative integer.
.VS 1 1
.IE
The dispatch table for the 256 primary opcodes:
.DS B
0 loc.0 loc.1 loc.2 loc.3 loc.4 loc.5 loc.6 loc.7
8 loc.8 loc.9 loc.10 loc.11 loc.12 loc.13 loc.14 loc.15
16 loc.16 loc.17 loc.18 loc.19 loc.20 loc.21 loc.22 loc.23
24 loc.24 loc.25 loc.26 loc.27 loc.28 loc.29 loc.30 loc.31
32 loc.32 loc.33 aar.1W adf.s0 adi.1W adi.2W adp.l adp.1
40 adp.2 adp.s0 adp.s-1 ads.1W and.1W asp.1W asp.2W asp.3W
48 asp.4W asp.5W asp.w0 beq.l beq.s0 bge.s0 bgt.s0 ble.s0
56 blm.s0 blt.s0 bne.s0 bra.l bra.s-1 bra.s-2 bra.s0 bra.s1
64 cal.1 cal.2 cal.3 cal.4 cal.5 cal.6 cal.7 cal.8
72 cal.9 cal.10 cal.11 cal.12 cal.13 cal.14 cal.15 cal.16
80 cal.17 cal.18 cal.19 cal.20 cal.21 cal.22 cal.23 cal.24
88 cal.25 cal.26 cal.27 cal.28 cal.s0 cff.z cif.z cii.z
96 cmf.s0 cmi.1W cmi.2W cmp.z cms.s0 csa.1W csb.1W dec.z
104 dee.w0 del.w-1 dup.1W dvf.s0 dvi.1W fil.l inc.z ine.lw
112 ine.w0 inl.-1W inl.-2W inl.-3W inl.w-1 inn.s0 ior.1W ior.s0
120 lae.l lae.w0 lae.w1 lae.w2 lae.w3 lae.w4 lae.w5 lae.w6
128 lal.p lal.n lal.0 lal.-1 lal.w0 lal.w-1 lal.w-2 lar.W
136 ldc.0 lde.lw lde.w0 ldl.0 ldl.w-1 lfr.1W lfr.2W lfr.s0
144 lil.w-1 lil.w0 lil.0 lil.1W lin.l lin.s0 lni.z loc.l
152 loc.-1 loc.s0 loc.s-1 loe.lw loe.w0 loe.w1 loe.w2 loe.w3
160 loe.w4 lof.l lof.1W lof.2W lof.3W lof.4W lof.s0 loi.l
168 loi.1 loi.1W loi.2W loi.3W loi.4W loi.s0 lol.pw lol.nw
176 lol.0 lol.1W lol.2W lol.3W lol.-1W lol.-2W lol.-3W lol.-4W
184 lol.-5W lol.-6W lol.-7W lol.-8W lol.w0 lol.w-1 lxa.1 lxl.1
192 lxl.2 mlf.s0 mli.1W mli.2W rck.1W ret.0 ret.1W ret.s0
200 rmi.1W sar.1W sbf.s0 sbi.1W sbi.2W sdl.w-1 set.s0 sil.w-1
208 sil.w0 sli.1W ste.lw ste.w0 ste.w1 ste.w2 stf.l stf.W
216 stf.2W stf.s0 sti.1 sti.1W sti.2W sti.3W sti.4W sti.s0
224 stl.pw stl.nw stl.0 stl.1W stl.-1W stl.-2W stl.-3W stl.-4W
232 stl.-5W stl.w-1 teq.z tgt.z tlt.z tne.z zeq.l zeq.s0
240 zeq.s1 zer.s0 zge.s0 zgt.s0 zle.s0 zlt.s0 zne.s0 zne.s-1
248 zre.lw zre.w0 zrl.-1W zrl.-2W zrl.w-1 zrl.nw escape1 escape2
.DE 2
The list of secondary opcodes (escape1):
.N 1
.DS B
0 aar.l aar.z adf.l adf.z adi.l adi.z ads.l ads.z
8 adu.l adu.z and.l and.z asp.lw ass.l ass.z bge.l
16 bgt.l ble.l blm.l bls.l bls.z blt.l bne.l cai.z
24 cal.l cfi.z cfu.z ciu.z cmf.l cmf.z cmi.l cmi.z
32 cms.l cms.z cmu.l cmu.z com.l com.z csa.l csa.z
40 csb.l csb.z cuf.z cui.z cuu.z dee.lw del.pw del.nw
48 dup.l dus.l dus.z dvf.l dvf.z dvi.l dvi.z dvu.l
56 dvu.z fef.l fef.z fif.l fif.z inl.pw inl.nw inn.l
64 inn.z ior.l ior.z lar.l lar.z ldc.l ldf.l ldl.pw
72 ldl.nw lfr.l lil.pw lil.nw lim.z los.l los.z lor.s0
80 lpi.l lxa.l lxl.l mlf.l mlf.z mli.l mli.z mlu.l
88 mlu.z mon.z ngf.l ngf.z ngi.l ngi.z nop.z rck.l
96 rck.z ret.l rmi.l rmi.z rmu.l rmu.z rol.l rol.z
104 ror.l ror.z rtt.z sar.l sar.z sbf.l sbf.z sbi.l
112 sbi.z sbs.l sbs.z sbu.l sbu.z sde.l sdf.l sdl.pw
120 sdl.nw set.l set.z sig.z sil.pw sil.nw sim.z sli.l
128 sli.z slu.l slu.z sri.l sri.z sru.l sru.z sti.l
136 sts.l sts.z str.s0 tge.z tle.z trp.z xor.l xor.z
144 zer.l zer.z zge.l zgt.l zle.l zlt.l zne.l zrf.l
152 zrf.z zrl.pw dch.z exg.s0 exg.l exg.z lpb.z gto.l
.DE 2
Finally, the list of opcodes with four byte arguments (escape2).
.DS
0 loc
.DE 0
.BP
.AP "AN EXAMPLE PROGRAM"
.DS B
1 program example(output);
2 {This program just demonstrates typical EM code.}
3 type rec = record r1: integer; r2:real; r3: boolean end;
4 var mi: integer; mx:real; r:rec;
5
6 function sum(a,b:integer):integer;
7 begin
8 sum := a + b
9 end;
10
11 procedure test(var r: rec);
12 label 1;
13 var i,j: integer;
14 x,y: real;
15 b: boolean;
16 c: char;
17 a: array[1..100] of integer;
18
19 begin
20 j := 1;
21 i := 3 * j + 6;
22 x := 4.8;
23 y := x/0.5;
24 b := true;
25 c := 'z';
26 for i:= 1 to 100 do a[i] := i * i;
27 r.r1 := j+27;
28 r.r3 := b;
29 r.r2 := x+y;
30 i := sum(r.r1, a[j]);
31 while i > 0 do begin j := j + r.r1; i := i - 1 end;
32 with r do begin r3 := b; r2 := x+y; r1 := 0 end;
33 goto 1;
34 1: writeln(j, i:6, x:9:3, b)
35 end; {test}
36 begin {main program}
37 mx := 15.96;
38 mi := 99;
39 test(r)
40 end.
.DE 0
.BP
The EM code as produced by the Pascal-VU compiler is given below. Comments
have been added manually. Note that this code has already been optimized.
.DS B
mes 2,2,2 ; wordsize 2, pointersize 2
.1
rom 't.p\e000' ; the name of the source file
hol 552,-32768,0 ; externals and buf occupy 552 bytes
exp $sum ; sum can be called from other modules
pro $sum,2 ; procedure sum; 2 bytes local storage
lin 8 ; code from source line 8
ldl 0 ; load two locals ( a and b )
adi 2 ; add them
ret 2 ; return the result
end 2 ; end of procedure ( still two bytes local storage )
.2
rom 1,99,2 ; descriptor of array a[]
exp $test ; the compiler exports all level 0 procedures
pro $test,226 ; procedure test, 226 bytes local storage
.3
rom 4.8F8 ; assemble Floating point 4.8 (8 bytes) in
.4 ; global storage
rom 0.5F8 ; same for 0.5
mes 3,-226,2,2 ; compiler temporary not referenced by address
mes 3,-24,2,0 ; the same is true for i, j, b and c in test
mes 3,-22,2,0
mes 3,-4,2,0
mes 3,-2,2,0
mes 3,-20,8,0 ; and for x and y
mes 3,-12,8,0
lin 20 ; maintain source line number
loc 1
stl -4 ; j := 1
lni ; lin 21 prior to optimization
lol -4
loc 3
mli 2
loc 6
adi 2
stl -2 ; i := 3 * j + 6
lni ; lin 22 prior to optimization
lae .3
loi 8
lal -12
sti 8 ; x := 4.8
lni ; lin 23 prior to optimization
lal -12
loi 8
lae .4
loi 8
dvf 8
lal -20
sti 8 ; y := x / 0.5
lni ; lin 24 prior to optimization
loc 1
stl -22 ; b := true
lni ; lin 25 prior to optimization
loc 122
stl -24 ; c := 'z'
lni ; lin 26 prior to optimization
loc 1
stl -2 ; for i:= 1
2
lol -2
dup 2
mli 2 ; i*i
lal -224
lol -2
lae .2
sar 2 ; a[i] :=
lol -2
loc 100
beq *3 ; to 100 do
inl -2 ; increment i and loop
bra *2
3
lin 27
lol -4
loc 27
adi 2 ; j + 27
sil 0 ; r.r1 :=
lni ; lin 28 prior to optimization
lol -22 ; b
lol 0
stf 10 ; r.r3 :=
lni ; lin 29 prior to optimization
lal -20
loi 16
adf 8 ; x + y
lol 0
adp 2
sti 8 ; r.r2 :=
lni ; lin 23 prior to optimization
lal -224
lol -4
lae .2
lar 2 ; a[j]
lil 0 ; r.r1
cal $sum ; call now
asp 4 ; remove parameters from stack
lfr 2 ; get function result
stl -2 ; i :=
4
lin 31
lol -2
zle *5 ; while i > 0 do
lol -4
lil 0
adi 2
stl -4 ; j := j + r.r1
del -2 ; i := i - 1
bra *4 ; loop
5
lin 32
lol 0
stl -226 ; make copy of address of r
lol -22
lol -226
stf 10 ; r3 := b
lal -20
loi 16
adf 8
lol -226
adp 2
sti 8 ; r2 := x + y
loc 0
sil -226 ; r1 := 0
lin 34 ; note the abscence of the unnecesary jump
lae 22 ; address of output structure
lol -4
cal $_wri ; write integer with default width
asp 4 ; pop parameters
lae 22
lol -2
loc 6
cal $_wsi ; write integer width 6
asp 6
lae 22
lal -12
loi 8
loc 9
loc 3
cal $_wrf ; write fixed format real, width 9, precision 3
asp 14
lae 22
lol -22
cal $_wrb ; write boolean, default width
asp 4
lae 22
cal $_wln ; writeln
asp 2
ret 0 ; return, no result
end 226
exp $_main
pro $_main,0 ; main program
.6
con 2,-1,22 ; description of external files
.5
rom 15.96F8
fil .1 ; maintain source file name
lae .6 ; description of external files
lae 0 ; base of hol area to relocate buffer addresses
cal $_ini ; initialize files, etc...
asp 4
lin 37
lae .5
loi 8
lae 2
sti 8 ; mx := 15.96
lni ; lin 38 prior to optimization
loc 99
ste 0 ; mi := 99
lni ; lin 39 prior to optimization
lae 10 ; address of r
cal $test
asp 2
loc 0 ; normal exit
cal $_hlt ; cleanup and finish
asp 2
end 0
mes 5 ; reals were used
.DE 0
The compact code corresponding to the above program is listed below.
Read it horizontally, line by line, not column by column.
Each number represents a byte of compact code, printed in decimal.
The first two bytes form the magic word.
.N 1
.IS 3
.DS B
173 0 159 122 122 122 255 242 1 161 250 124 116 46 112 0
255 156 245 40 2 245 0 128 120 155 249 123 115 117 109 160
249 123 115 117 109 122 67 128 63 120 3 122 88 122 152 122
242 2 161 121 219 122 255 155 249 124 116 101 115 116 160 249
124 116 101 115 116 245 226 0 242 3 161 253 128 123 52 46
56 255 242 4 161 253 128 123 48 46 53 255 159 123 245 30
255 122 122 255 159 123 96 122 120 255 159 123 98 122 120 255
159 123 116 122 120 255 159 123 118 122 120 255 159 123 100 128
120 255 159 123 108 128 120 255 67 140 69 121 113 116 68 73
116 69 123 81 122 69 126 3 122 113 118 68 57 242 3 72
128 58 108 112 128 68 58 108 72 128 57 242 4 72 128 44
128 58 100 112 128 68 69 121 113 98 68 69 245 122 0 113
96 68 69 121 113 118 182 73 118 42 122 81 122 58 245 32
255 73 118 57 242 2 94 122 73 118 69 220 10 123 54 118
18 122 183 67 147 73 116 69 147 3 122 104 120 68 73 98
73 120 111 130 68 58 100 72 136 2 128 73 120 4 122 112
128 68 58 245 32 255 73 116 57 242 2 59 122 65 120 20
249 123 115 117 109 8 124 64 122 113 118 184 67 151 73 118
128 125 73 116 65 120 3 122 113 116 41 118 18 124 185 67
152 73 120 113 245 30 255 73 98 73 245 30 255 111 130 58
100 72 136 2 128 73 245 30 255 4 122 112 128 69 120 104
245 30 255 67 154 57 142 73 116 20 249 124 95 119 114 105
8 124 57 142 73 118 69 126 20 249 124 95 119 115 105 8
126 57 142 58 108 72 128 69 129 69 123 20 249 124 95 119
114 102 8 134 57 142 73 98 20 249 124 95 119 114 98 8
124 57 142 20 249 124 95 119 108 110 8 122 88 120 152 245
226 0 155 249 125 95 109 97 105 110 160 249 125 95 109 97
105 110 120 242 6 151 122 119 142 255 242 5 161 253 128 125
49 53 46 57 54 255 50 242 1 57 242 6 57 120 20 249
124 95 105 110 105 8 124 67 157 57 242 5 72 128 57 122
112 128 68 69 219 110 120 68 57 130 20 249 124 116 101 115
116 8 122 69 120 20 249 124 95 104 108 116 8 122 152 120
159 124 160 255 159 125 255
.DE 0
.IE
.MS T A 0
.ME
.BP
.MS B A 0
.ME
.CT

762
doc/em/assem.nr
View File

@ -1,762 +0,0 @@
.BP
.SN 11
.S1 "EM ASSEMBLY LANGUAGE"
We use two representations for assembly language programs,
one is in ASCII and the other is the compact assembly language.
The latter needs less space than the first for the same program
and therefore allows faster processing.
Our only program accepting ASCII assembly
language converts it to the compact form.
All other programs expect compact assembly input.
The first part of the chapter describes the ASCII assembly
language and its semantics.
The second part describes the syntax of the compact assembly
language.
The last part lists the EM instructions with the type of
arguments allowed and an indication of the function.
Appendix A gives a detailed description of the effect of all
instructions in the form of a Pascal program.
.S2 "ASCII assembly language"
An assembly language program consists of a series of lines, each
line may be blank, contain one (pseudo)instruction or contain one
label.
Input to the assembler is in lower case.
Upper case is used in this
document merely to distinguish keywords from the surrounding prose.
Comment is allowed at the end of each line and starts with a semicolon ";".
This kind of comment does not exist in the compact form.
.A
Labels must be placed all by themselves on a line and start in
column 1.
There are two kinds of labels, instruction and data labels.
Instruction labels are unsigned positive integers.
The scope of an instruction label is its procedure.
.A
The pseudoinstructions CON, ROM and BSS may be preceded by a
line containing a
1-8 character data label, the first character of which is a
letter, period or underscore.
The period may only be followed by
digits, the others may be followed by letters, digits and underscores.
The use of the character "." followed by a constant,
which must be in the range 1 to 32767 (e.g. ".40") is recommended
for compiler
generated programs.
These labels are considered as a special case and handled
more efficiently in compact assembly language (see below).
Note that a data label on its own or two consecutive labels are not
allowed.
.P
Each statement may contain an instruction mnemonic or pseudoinstruction.
These must begin in column 2 or later (not column 1) and must be followed
by a space, tab, semicolon or LF.
Everything on the line following a semicolon is
taken as a comment.
.P
Each input file contains one module.
A module may contain many procedures,
which may be nested.
A procedure consists of
a PRO statement, a (possibly empty)
collection of instructions and pseudoinstructions and finally an END
statement.
Pseudoinstructions are also allowed between procedures.
They do not belong to a specific procedure.
.P
All constants in EM are interpreted in the decimal base.
The ASCII assembly language accepts constant expressions
wherever constants are allowed.
The operators recognized are: +, -, *, % and / with the usual
precedence order.
Use of the parentheses ( and ) to alter the precedence order is allowed.
.S3 "Instruction arguments"
Unlike many other assembly languages, the EM assembly
language requires all arguments of normal and pseudoinstructions
to be either a constant or an identifier, but not a combination
of these two.
There is one exception to this rule: when a data label is used
for initialization or as an instruction argument,
expressions of the form 'label+constant' and 'label-constant'
are allowed.
This makes it possible to address, for example, the
third word of a ten word BSS block
directly.
Thus LOE LABEL+4 is permitted and so is CON LABEL+3.
The resulting address is must be in the same fragment as the label.
It is not allowed to add or subtract from instruction labels or procedure
identifiers,
which certainly is not a severe restriction and greatly aids
optimization.
.P
Instruction arguments can be constants,
data labels, data labels offsetted by a constant, instruction
labels and procedure identifiers.
The range of integers allowed depends on the instruction.
Most instructions allow only integers
(signed or unsigned)
that fit in a word.
Arguments used as offsets to pointers should fit in a
pointer-sized integer.
Finally, arguments to LDC should fit in a double-word integer.
.P
Several instructions have two possible forms:
with an explicit argument and with an implicit argument on top of the stack.
The size of the implicit argument is the wordsize.
The implicit argument is always popped before all other operands.
For example: 'CMI 4' specifies that two four-byte signed
integers on top of the stack are to be compared.
\&'CMI' without an argument expects a wordsized integer
on top of the stack that specifies the size of the integers to
be compared.
Thus the following two sequences are equivalent:
.N 2
.TS
center, tab(:) ;
l r 30 l r.
LDL:-10:LDL:-10
LDL:-14:LDL:-14
::LOC:4
CMI:4:CMI:
ZEQ:*1:ZEQ:*1
.TE 2
Section 11.1.6 shows the arguments allowed for each instruction.
.S3 "Pseudoinstruction arguments"
Pseudoinstruction arguments can be divided in two classes:
Initializers and others.
The following initializers are allowed: signed integer constants,
unsigned integer constants, floating-point constants, strings,
data labels, data labels offsetted by a constant, instruction
labels and procedure identifiers.
.P
Constant initializers in BSS, HOL, CON and ROM pseudoinstructions
can be followed by a letter I, U or F.
This indicator
specifies the type of the initializer: Integer, Unsigned or Float.
If no indicator is present I is assumed.
The size of the initializer is the wordsize unless
the indicator is followed by an integer specifying the
initializer's size.
This integer is governed by the same restrictions as for
transfer of objects to/from memory.
As in instruction arguments, initializers include expressions of the form:
\&"LABEL+offset" and "LABEL-offset".
The offset must be an unsigned decimal constant.
The 'IUF' indicators cannot be used in the offsets.
.P
Data labels are referred to by their name.
.P
Strings are surrounded by double quotes (").
Semicolon's in string do not indicate the start of comment.
In the ASCII representation the escape character \e (backslash)
alters the meaning of subsequent character(s).
This feature allows inclusion of zeroes, graphic characters and
the double quote in the string.
The following escape sequences exist:
.DS
.TS
center, tab(:);
l l l.
newline:NL\|(LF):\en
horizontal tab:HT:\et
backspace:BS:\eb
carriage return:CR:\er
form feed:FF:\ef
backslash:\e:\e\e
double quote:":\e"
bit pattern:\fBddd\fP:\e\fBddd\fP
.TE
.DE
The escape \fBddd\fP consists of the backslash followed by 1,
2, or 3 octal digits specifing the value of
the desired character.
If the character following a backslash is not one of those
specified,
the backslash is ignored.
Example: CON "hello\e012\e0".
Each string element initializes a single byte.
The ASCII character set is used to map characters onto values.
.P
Instruction labels are referred to as *1, *2, etc. in both branch
instructions and as initializers.
.P
The notation $procname means the identifier for the procedure
with the specified name.
This identifier has the size of a pointer.
.S3 Notation
First, the notation used for the arguments, classes of
instructions and pseudoinstructions.
.IS 2
.TS
tab(:);
l l l.
<cst>:\&=:integer constant (current range -2**31..2**31-1)
<dlb>:\&=:data label
<arg>:\&=:<cst> or <dlb> or <dlb>+<cst> or <dlb>-<cst>
<con>:\&=:integer constant, unsigned constant, floating-point constant
<str>:\&=:string constant (surrounded by double quotes),
<ilb>:\&=:instruction label
::'*' followed by an integer in the range 0..32767.
<pro>:\&=:procedure number ('$' followed by a procedure name)
<val>:\&=:<arg>, <con>, <pro> or <ilb>.
<par>:\&=:<val> or <str>
<...>*:\&=:zero or more of <...>
<...>+:\&=:one or more of <...>
[...]:\&=:optional ...
.TE
.IE
.S3 "Pseudoinstructions"
.S4 Storage declaration
Initialized global data is allocated by the pseudoinstruction CON,
which needs at least one argument.
Each argument is used to allocate and initialize a number of
consequtive bytes in data memory.
The number of bytes to be allocated and the alignment depend on the type
of the argument.
For each argument, an integral number of words,
determined by the argument type, is allocated and initialized.
.P
The pseudoinstruction ROM is the same as CON,
except that it guarantees that the initialized words
will not change during the execution of the program.
This information allows optimizers to do
certain calculations such as array indexing and
subrange checking at compile time instead
of at run time.
.P
The pseudoinstruction BSS allocates
uninitialized global data or large blocks of data initialized
by the same value.
The first argument to this pseudo is the number
of bytes required, which must be a multiple of the wordsize.
The other arguments specify the value used for initialization and
whether the initialization is only for convenience or a strict necessity.
The pseudoinstruction HOL is similar to BSS in that it requests an
(un)initialized global data block.
Addressing of a HOL block, however, is quasi absolute.
The first byte is addressed by 0,
the second byte by 1 etc. in assembly language.
The assembler/loader adds the base address of
the HOL block to these numbers to obtain the
absolute address in the machine language.
.P
The scope of a HOL block starts at the HOL pseudo and
ends at the next HOL pseudo or at the end of a module
whatever comes first.
Each instruction falls in the scope of at most one
HOL block, the current HOL block.
It is not allowed to have more than one HOL block per procedure.
.P
The alignment restrictions are enforced by the
pseudoinstructions.
All initializers are aligned on a multiple of their size or the wordsize
whichever is smaller.
Strings form an exception, they are to be seen as a sequence of initializers
each for one byte, i.e. strings are not padded with zero bytes.
Switching to another type of fragment or placing a label forces
word-alignment.
There are three types of fragments in global data space: CON, ROM and
BSS/HOL.
.N 2
.IS 2
.PS - 4
.PT "BSS <cst1>,<val>,<cst2>"
Reserve <cst1> bytes.
<val> is the value used to initialize the area.
<cst1> must be a multiple of the size of <val>.
<cst2> is 0 if the initialization is not strictly necessary,
1 if it is.
.PT "HOL <cst1>,<val>,<cst2>"
Idem, but all following absolute global data references will
refer to this block.
Only one HOL is allowed per procedure,
it has to be placed before the first instruction.
.PT "CON <val>+"
Assemble global data words initialized with the <val> constants.
.PT "ROM <val>+"
Idem, but the initialized data will never be changed by the program.
.PE
.IE
.S4 Partitioning
Two pseudoinstructions partition the input into procedures:
.IS 2
.PS - 4
.PT "PRO <pro>[,<cst>]"
Start of procedure.
<pro> is the procedure name.
<cst> is the number of bytes for locals.
The number of bytes for locals must be specified in the PRO or
END pseudoinstruction.
When specified in both, they must be identical.
.PT "END [<cst>]"
End of Procedure.
<cst> is the number of bytes for locals.
The number of bytes for locals must be specified in either the PRO or
END pseudoinstruction or both.
.PE
.IE
.S4 Visibility
Names of data and procedures in an EM module can either be
internal or external.
External names are known outside the module and are used to link
several pieces of a program.
Internal names are not known outside the modules they are used in.
Other modules will not 'see' an internal name.
.A
To reduce the number of passes needed,
it must be known at the first occurrence whether
a name is internal or external.
If the first occurrence of a name is in a definition,
the name is considered to be internal.
If the first occurrence of a name is a reference,
the name is considered to be external.
If the first occurrence is in one of the following pseudoinstructions,
the effect of the pseudo has precedence.
.IS 2
.PS - 4
.PT "EXA <dlb>"
External name.
<dlb> is known, possibly defined, outside this module.
Note that <dlb> may be defined in the same module.
.PT "EXP <pro>"
External procedure identifier.
Note that <pro> may be defined in the same module.
.PT "INA <dlb>"
Internal name.
<dlb> is internal to this module and must be defined in this module.
.PT "INP <pro>"
Internal procedure.
<pro> is internal to this module and must be defined in this module.
.PE
.IE
.S4 Miscellaneous
Two other pseudoinstructions provide miscellaneous features:
.IS 2
.PS - 4
.PT "EXC <cst1>,<cst2>"
Two blocks of instructions preceding this one are
interchanged before being processed.
<cst1> gives the number of lines of the first block.
<cst2> gives the number of lines of the second one.
Blank and pure comment lines do not count.
.PT "MES <cst>[,<par>]*"
A special type of comment.
Used by compilers to communicate with the
optimizer, assembler, etc. as follows:
.VS 1 0
.PS - 4
.PT "MES 0"
An error has occurred, stop further processing.
.PT "MES 1"
Suppress optimization.
.PT "MES 2,<cst1>,<cst2>"
Use wordsize <cst1> and pointer size <cst2>.
.PT "MES 3,<cst1>,<cst2>,<cst3>,<cst4>"
Indicates that a local variable is never referenced indirectly.
Used to indicate that a register may be used for a specific
variable.
<cst1> is offset in bytes from AB if positive
and offset from LB if negative.
<cst2> gives the size of the variable.
<cst3> indicates the class of the variable.
The following values are currently recognized:
.PS
.PT 0
The variable can be used for anything.
.PT 1
The variable is used as a loopindex.
.PT 2
The variable is used as a pointer.
.PT 3
The variable is used as a floating point number.
.PE 0
<cst4> gives the priority of the variable,
higher numbers indicate better candidates.
.PT "MES 4,<cst>,<str>"
Number of source lines in file <str> (for profiler).
.PT "MES 5"
Floating point used.
.PT "MES 6,<val>*"
Comment. Used to provide comments in compact assembly language.
.PT "MES 7,....."
Reserved.
.PT "MES 8,<pro>[,<dlb>]..."
Library module. Indicates that the module may only be loaded
if it is useful, that is, if it can satisfy any unresolved
references during the loading process.
May not be preceded by any other pseudo, except MES's.
.PT "MES 9,<cst>"
Guarantees that no more than <cst> bytes of parameters are
accessed, either directly or indirectly.
.PE 1
.VS 1 1
Each backend is free to skip irrelevant MES pseudos.
.PE
.IE
.S2 "The Compact Assembly Language"
The assembler accepts input in a highly encoded form.
This
form is intended to reduce the amount of file transport between the
front ends, optimizers
and back ends, and also reduces the amount of storage required for storing
libraries.
Libraries are stored as archived compact assembly language, not machine
language.
.P
When beginning to read the input, the assembler is in neutral state, and
expects either a label or an instruction (including the pseudoinstructions).
The meaning of the next byte(s) when in neutral state is as follows, where
b1, b2
etc. represent the succeeding bytes.
.N 1
.DS
.TS
tab(:) ;
rw17 4 l.
0:Reserved for future use
1-129:Machine instructions, see Appendix A, alphabetical list
130-149:Reserved for future use
150-161:BSS,CON,END,EXA,EXC,EXP,HOL,INA,INP,MES,PRO,ROM
162-179:Reserved for future pseudoinstructions
180-239:Instruction labels 0 - 59 (180 is local label 0 etc.)
240-244:See the Common Table below
245-255:Not used
.TE 1
.DE 0
After a label, the assembler is back in neutral state; it can immediately
accept another label or an instruction in the next byte.
No linefeeds are used to separate lines.
.P
If an opcode expects no arguments,
the assembler is back in neutral state after
reading the one byte containing the instruction number.
If it has one or
more arguments (only pseudos have more than 1), the arguments follow directly,
encoded as follows:
.N 1
.IS 2
.TS
tab(:);
r l.
0-239:Offsets from -120 to 119
240-255:See the Common Table below
.TE 1
Absence of an optional argument is indicated by a special
byte.
.IE 2
.CS
Common Table for Neutral State and Arguments
.CE
.TS
tab(:);
c c s c
l8 l l8 l.
class:bytes:description
<ilb>:240:b1:Instruction label b1 (Not used for branches)
<ilb>:241:b1 b2:16 bit instruction label (256*b2 + b1)
<dlb>:242:b1:Global label .0-.255, with b1 being the label
<dlb>:243:b1 b2:Global label .0-.32767
:::with 256*b2+b1 being the label
<dlb>:244:<string>:Global symbol not of the form .nnn
<cst>:245:b1 b2:16 bit constant
<cst>:246:b1 b2 b3 b4:32 bit constant
<cst>:247:b1 .. b8:64 bit constant
<arg>:248:<dlb><cst>:Global label + (possibly negative) constant
<pro>:249:<string>:Procedure name (not including $)
<str>:250:<string>:String used in CON or ROM (no quotes-no escapes)
<con>:251:<cst><string>:Integer constant, size <cst> bytes
<con>:252:<cst><string>:Unsigned constant, size <cst> bytes
<con>:253:<cst><string>:Floating constant, size <cst> bytes
:254::unused
<end>:255::Delimiter for argument lists or
:::indicates absence of optional argument
.TE 1
.P
The bytes specifying the value of a 16, 32 or 64 bit constant
are presented in two's complement notation, with the least
significant byte first. For example: the value of a 32 bit
constant is ((s4*256+b3)*256+b2)*256+b1, where s4 is b4-256 if
b4 is greater than 128 else s4 takes the value of b4.
A <string> consists of a <cst> inmediatly followed by
a sequence of bytes with length <cst>.
.P
.ne 8
The pseudoinstructions fall into several categories, depending on their
arguments:
.N 1
.DS
Group 1 -- EXC, BSS, HOL have a known number of arguments
Group 2 -- EXA, EXP, INA, INP have a string as argument
Group 3 -- CON, MES, ROM have a variable number of various things
Group 4 -- END, PRO have a trailing optional argument.
.DE 1
Groups 1 and 2
use the encoding described above.
Group 3 also uses the encoding listed above, with an <end> byte after the
last argument to indicate the end of the list.
Group 4 uses
an <end> byte if the trailing argument is not present.
.N 2
.IS 2
.TS
tab(|);
l s l
l s s
l 2 lw(46) l.
Example ASCII|Example compact
(LOC = 69, BRA = 18 here):
2||182
1||181
LOC|10|69 130
LOC|-10|69 110
LOC|300|69 245 44 1
BRA|*19|18 139
300||241 44 1
.3||242 3
CON|4,9,*2,$foo|151 124 129 240 2 249 123 102 111 111 255
CON|.35|151 242 35 255
.TE 0
.IE 0
.BP
.S2 "Assembly language instruction list"
.P
For each instruction in the list the range of argument values
in the assembly language is given.
The column headed \fIassem\fP contains the mnemonics defined
in 11.1.3.
The following column specifies restrictions of the argument
value.
Addresses have to obey the restrictions mentioned in chapter 2.
The classes of arguments
are indicated by letters:
.ds b \fBb\fP
.ds c \fBc\fP
.ds d \fBd\fP
.ds g \fBg\fP
.ds f \fBf\fP
.ds l \fBl\fP
.ds n \fBn\fP
.ds w \fBw\fP
.ds p \fBp\fP
.ds r \fBr\fP
.ds s \fBs\fP
.ds z \fBz\fP
.ds o \fBo\fP
.ds - \fB-\fP
.N 1
.TS
tab(:);
c s l l
l l 15 l l.
\fIassem\fP:constraints:rationale
\&\*c:cst:fits word:constant
\&\*d:cst:fits double word:constant
\&\*l:cst::local offset
\&\*g:arg:>= 0:global offset
\&\*f:cst::fragment offset
\&\*n:cst:>= 0:counter
\&\*s:cst:>0 , word multiple:object size
\&\*z:cst:>= 0 , zero or word multiple:object size
\&\*o:cst:>= 0 , word multiple or fraction:object size
\&\*w:cst:> 0 , word multiple:object size *
\&\*p:pro::pro identifier
\&\*b:ilb:>= 0:label number
\&\*r:cst:0,1,2:register number
\&\*-:::no argument
.TE 1
.P
The * at the rationale for \*w indicates that the argument
can either be given as argument or on top of the stack.
If the argument is omitted, the argument is fetched from the
stack;
it is assumed to be a wordsized unsigned integer.
Instructions that check for undefined integer or floating-point
values and underflow or overflow
are indicated below by (*).
.N 1
.DS B
GROUP 1 - LOAD
LOC \*c : Load constant (i.e. push one word onto the stack)
LDC \*d : Load double constant ( push two words )
LOL \*l : Load word at \*l-th local (\*l<0) or parameter (\*l>=0)
LOE \*g : Load external word \*g
LIL \*l : Load word pointed to by \*l-th local or parameter
LOF \*f : Load offsetted (top of stack + \*f yield address)
LAL \*l : Load address of local or parameter
LAE \*g : Load address of external
LXL \*n : Load lexical (address of LB \*n static levels back)
LXA \*n : Load lexical (address of AB \*n static levels back)
LOI \*o : Load indirect \*o bytes (address is popped from the stack)
LOS \*w : Load indirect, \*w-byte integer on top of stack gives object size
LDL \*l : Load double local or parameter (two consecutive words are stacked)
LDE \*g : Load double external (two consecutive externals are stacked)
LDF \*f : Load double offsetted (top of stack + \*f yield address)
LPI \*p : Load procedure identifier
GROUP 2 - STORE
STL \*l : Store local or parameter
STE \*g : Store external
SIL \*l : Store into word pointed to by \*l-th local or parameter
STF \*f : Store offsetted
STI \*o : Store indirect \*o bytes (pop address, then data)
STS \*w : Store indirect, \*w-byte integer on top of stack gives object size
SDL \*l : Store double local or parameter
SDE \*g : Store double external
SDF \*f : Store double offsetted
GROUP 3 - INTEGER ARITHMETIC
ADI \*w : Addition (*)
SBI \*w : Subtraction (*)
MLI \*w : Multiplication (*)
DVI \*w : Division (*)
RMI \*w : Remainder (*)
NGI \*w : Negate (two's complement) (*)
SLI \*w : Shift left (*)
SRI \*w : Shift right (*)
GROUP 4 - UNSIGNED ARITHMETIC
ADU \*w : Addition
SBU \*w : Subtraction
MLU \*w : Multiplication
DVU \*w : Division
RMU \*w : Remainder
SLU \*w : Shift left
SRU \*w : Shift right
GROUP 5 - FLOATING POINT ARITHMETIC
ADF \*w : Floating add (*)
SBF \*w : Floating subtract (*)
MLF \*w : Floating multiply (*)
DVF \*w : Floating divide (*)
NGF \*w : Floating negate (*)
FIF \*w : Floating multiply and split integer and fraction part (*)
FEF \*w : Split floating number in exponent and fraction part (*)
GROUP 6 - POINTER ARITHMETIC
ADP \*f : Add \*f to pointer on top of stack
ADS \*w : Add \*w-byte value and pointer
SBS \*w : Subtract pointers in same fragment and push diff as size \*w integer
GROUP 7 - INCREMENT/DECREMENT/ZERO
INC \*- : Increment word on top of stack by 1 (*)
INL \*l : Increment local or parameter (*)
INE \*g : Increment external (*)
DEC \*- : Decrement word on top of stack by 1 (*)
DEL \*l : Decrement local or parameter (*)
DEE \*g : Decrement external (*)
ZRL \*l : Zero local or parameter
ZRE \*g : Zero external
ZRF \*w : Load a floating zero of size \*w
ZER \*w : Load \*w zero bytes
GROUP 8 - CONVERT (stack: source, source size, dest. size (top))
CII \*- : Convert integer to integer (*)
CUI \*- : Convert unsigned to integer (*)
CFI \*- : Convert floating to integer (*)
CIF \*- : Convert integer to floating (*)
CUF \*- : Convert unsigned to floating (*)
CFF \*- : Convert floating to floating (*)
CIU \*- : Convert integer to unsigned
CUU \*- : Convert unsigned to unsigned
CFU \*- : Convert floating to unsigned
GROUP 9 - LOGICAL
AND \*w : Boolean and on two groups of \*w bytes
IOR \*w : Boolean inclusive or on two groups of \*w bytes
XOR \*w : Boolean exclusive or on two groups of \*w bytes
COM \*w : Complement (one's complement of top \*w bytes)
ROL \*w : Rotate left a group of \*w bytes
ROR \*w : Rotate right a group of \*w bytes
GROUP 10 - SETS
INN \*w : Bit test on \*w byte set (bit number on top of stack)
SET \*w : Create singleton \*w byte set with bit n on (n is top of stack)
GROUP 11 - ARRAY
LAR \*w : Load array element, descriptor contains integers of size \*w
SAR \*w : Store array element
AAR \*w : Load address of array element
GROUP 12 - COMPARE
CMI \*w : Compare \*w byte integers, Push negative, zero, positive for <, = or >
CMF \*w : Compare \*w byte reals
CMU \*w : Compare \*w byte unsigneds
CMS \*w : Compare \*w byte values, can only be used for bit for bit equality test
CMP \*- : Compare pointers
TLT \*- : True if less, i.e. iff top of stack < 0
TLE \*- : True if less or equal, i.e. iff top of stack <= 0
TEQ \*- : True if equal, i.e. iff top of stack = 0
TNE \*- : True if not equal, i.e. iff top of stack non zero
TGE \*- : True if greater or equal, i.e. iff top of stack >= 0
TGT \*- : True if greater, i.e. iff top of stack > 0
GROUP 13 - BRANCH
BRA \*b : Branch unconditionally to label \*b
BLT \*b : Branch less (pop 2 words, branch if top > second)
BLE \*b : Branch less or equal
BEQ \*b : Branch equal
BNE \*b : Branch not equal
BGE \*b : Branch greater or equal
BGT \*b : Branch greater
ZLT \*b : Branch less than zero (pop 1 word, branch negative)
ZLE \*b : Branch less or equal to zero
ZEQ \*b : Branch equal zero
ZNE \*b : Branch not zero
ZGE \*b : Branch greater or equal zero
ZGT \*b : Branch greater than zero
GROUP 14 - PROCEDURE CALL
CAI \*- : Call procedure (procedure identifier on stack)
CAL \*p : Call procedure (with identifier \*p)
LFR \*s : Load function result
RET \*z : Return (function result consists of top \*z bytes)
GROUP 15 - MISCELLANEOUS
ASP \*f : Adjust the stack pointer by \*f
ASS \*w : Adjust the stack pointer by \*w-byte integer
BLM \*z : Block move \*z bytes; first pop destination addr, then source addr
BLS \*w : Block move, size is in \*w-byte integer on top of stack
CSA \*w : Case jump; address of jump table at top of stack
CSB \*w : Table lookup jump; address of jump table at top of stack
DCH \*- : Follow dynamic chain, convert LB to LB of caller
DUP \*s : Duplicate top \*s bytes
DUS \*w : Duplicate top \*w bytes
EXG \*w : Exchange top \*w bytes
FIL \*g : File name (external 4 := \*g)
GTO \*g : Non-local goto, descriptor at \*g
LIM \*- : Load 16 bit ignore mask
LIN \*n : Line number (external 0 := \*n)
LNI \*- : Line number increment
LOR \*r : Load register (0=LB, 1=SP, 2=HP)
LPB \*- : Convert local base to argument base
MON \*- : Monitor call
NOP \*- : No operation
RCK \*w : Range check; trap on error
RTT \*- : Return from trap
SIG \*- : Trap errors to proc identifier on top of stack, -2 resets default
SIM \*- : Store 16 bit ignore mask
STR \*r : Store register (0=LB, 1=SP, 2=HP)
TRP \*- : Cause trap to occur (Error number on stack)
.DE 0

163
doc/em/descr.nr
View File

@ -1,163 +0,0 @@
.SN 7
.BP
.S1 "DESCRIPTORS"
Several instructions use descriptors, notably the range check instruction,
the array instructions, the goto instruction and the case jump instructions.
Descriptors reside in data space.
They may be constructed at run time, but
more often they are fixed and allocated in ROM data.
.P
All instructions using descriptors, except GTO, have as argument
the size of the integers in the descriptor.
All implementations have to allow integers of the size of a
word in descriptors.
All integers popped from the stack and used for indexing or comparing
must have the same size as the integers in the descriptor.
.S2 "Range check descriptors"
Range check descriptors consist of two integers:
.IS 2
.PS 1 4 "" .
.PT
lower bound~~~~~~~signed
.PT
upper bound~~~~~~~signed
.PE
.IE
The range check instruction checks an integer on the stack against
these bounds and causes a trap if the value is outside the interval.
The value itself is neither changed nor removed from the stack.
.S2 "Array descriptors"
Each array descriptor describes a single dimension.
For multi-dimensional arrays, several array instructions are
needed to access a single element.
Array descriptors contain the following three integers:
.IS 2
.PS 1 4 "" .
.PT
lower bound~~~~~~~~~~~~~~~~~~~~~signed
.PT
upper bound - lower bound~~~~~~~unsigned
.PT
number of bytes per element~~~~~unsigned
.PE
.IE
The array instructions LAR, SAR and AAR have the pointer to the start
of the descriptor as operand on the stack.
.sp
The element A[I] is fetched as follows:
.IS 2
.PS 1 4 "" .
.PT
Stack the address of A (e.g., using LAE or LAL)
.PT
Stack the value of I (n-byte integer)
.PT
Stack the pointer to the descriptor (e.g., using LAE)
.PT
LAR n (n is the size of the integers in the descriptor and I)
.PE
.IE
All array instructions first pop the address of the descriptor
and the index.
If the index is not within the bounds specified, a trap occurs.
If ok, (I~-~lower bound) is multiplied
by the number of bytes per element (the third word). The result is added
to the address of A and replaces A on the stack.
.A
At this point LAR, SAR and AAR diverge.
AAR is finished. LAR pops the address and fetches the data
item,
the size being specified by the descriptor.
The usual restrictions for memory access must be obeyed.
SAR pops the address and stores the
data item now exposed.
.S2 "Non-local goto descriptors"
The GTO instruction provides a way of returning directly to any
active procedure invocation.
The argument of the instruction is the address of a descriptor
containing three pointers:
.IS 2
.PS 1 4 "" .
.PT
value of PC after the jump
.PT
value of SP after the jump
.PT
value of LB after the jump
.PE
.IE
GTO replaces the loads PC, SP and LB from the descriptor,
thereby jumping to a procedure
and removing zeor or more frames from the stack.
The LB, SP and PC in the descriptor must belong to a
dynamically enclosing procedure,
because some EM implementations will need to backtrack through
the dynamic chain and use the implementation dependent data
in frames to restore registers etc.
.S2 "Case descriptors"
The case jump instructions CSA and CSB both
provide multiway branches selected by a case index.
Both fetch two operands from the stack:
first a pointer to the low address of the case descriptor
and then the case index.
CSA uses the case index as index in the descriptor table, but CSB searches
the table for an occurrence of the case index.
Therefore, the descriptors for CSA and CSB,
as shown in figure 4, are different.
All pointers in the table must be addresses of instructions in the
procedure executing the case instruction.
.P
CSA selects the new PC by indexing.
If the index, a signed integer, is greater than or equal to
the lower bound and less than or equal to the upper bound,
then fetch the new PC from the list of instruction pointers by indexing with
index-lower.
The table does not contain the value of the upper bound,
but the value of upper-lower as an unsigned integer.
The default instruction pointer is used when the index is out of bounds.
If the resulting PC is 0, then trap.
.P
CSB selects the new PC by searching.
The table is searched for an entry with index value equal to the case index.
That entry or, if none is found, the default entry contains the
new PC.
When the resulting PC is 0, a trap is performed.
.P
The choice of which case instruction to use for
each source language case statement
is up to the front end.
If the range of the index value is dense, i.e
.DS
(highest value - lowest value) / number of cases
.DE 1
is less than some threshold, then CSA is the obvious choice.
If the range is sparse, CSB is better.
.N 2
.DS
|--------------------| |--------------------| high address
| pointer for upb | | pointer n-1 |
|--------------------| |- - - - - - - |
| . | | index n-1 |
| . | |--------------------|
| . | | . |
| . | | . |
| . | | . |
| . | |--------------------|
| . | | pointer 1 |
|--------------------| |- - - - - - - |
| pointer for lwb+1 | | index 1 |
|--------------------| |--------------------|
| pointer for lwb | | pointer 0 |
|--------------------| |- - - - - - - |
| upper - lower | | index 0 |
|--------------------| |--------------------|
| lower bound | | number of entries |
|--------------------| |--------------------|
| default pointer | | default pointer | low address
|--------------------| |--------------------|
CSA descriptor CSB descriptor
Figure 4. Descriptor layout for CSA and CSB
.DE

377
doc/em/dspace.nr
View File

@ -1,377 +0,0 @@
.BP
.SN 4
.S1 "DATA ADDRESS SPACE"
The data address space is divided into three parts, called 'areas',
each with its own addressing method:
global data area,
local data area (including the stack),
and heap data area.
These data areas must be part of the same
address space because all data is accessed by
the same type of pointers.
.P
Space for global data is reserved using several pseudoinstructions in the
assembly language, as described in
the next paragraph and chapter 11.
The size of the global data area is fixed per program.
.A
Global data is addressed absolutely in the machine language.
Many instructions are available to address global data.
They all have an absolute address as argument.
Examples are LOE, LAE and STE.
.P
Part of the global data area is initialized by the
compiler, the
rest is not initialized at all or is initialized
with a value, typically -32768 or 0.
Part of the initialized global data may be made read-only
if the implementation supports protection.
.P
The local data area is used as a stack,
which grows from high to low addresses
and contains some data for each active procedure
invocation, called a 'frame'.
The size of the local data area varies dynamically during
execution.
Below the current procedure frame resides the operand stack.
The stack pointer SP always points to the bottom of
the local data area.
Local data is addressed by offsetting from the local base pointer LB.
LB always points to the frame of the current procedure.
Only the words of the current frame and the parameters
can be addressed directly.
Variables in other active procedures are addressed by following
the chain of statically enclosing procedures using the LXL or LXA instruction.
The variables in dynamically enclosing procedures can be
addressed with the use of the DCH instruction.
.A
Many instructions have offsets to LB as argument,
for instance LOL, LAL and STL.
The arguments of these instructions range from -1 to some
(negative) minimum
for the access of local storage and from 0 to some (positive)
maximum for parameter access.
.P
The procedure call instructions CAL and CAI each create a new frame
on the stack.
Each procedure has an assembly-time parameter specifying
the number of bytes needed for local storage.
This storage is allocated each time the procedure is called and
must be a multiple of the wordsize.
Each procedure, therefore, starts with a stack with the local variables
already allocated.
The return instructions RET and RTT remove a frame.
The actual parameters must be removed by the calling procedure.
.P
RET may copy some words from the stack of
the returning procedure to an unnamed 'function return area'.
This area is available for 'READ-ONCE' access using the LFR instruction.
The result of a LFR is only defined if the size used to fetch
is identical to the size used in the last return.
The instruction ASP, used to remove the parameters from the
stack, the branch instruction BRA and the non-local goto
instrucion GTO are the only ones that leave the contents of
the 'function return area' intact.
All other instructions are allowed to destroy the function
return area.
Thus parameters can be popped before fetching the function result.
The maximum size of all function return areas is
implementation dependent,
but should allow procedure instance identifiers and all
implemented objects of type integer, unsigned, float
and pointer to be returned.
In most implementations
the maximum size of the function return
area is twice the pointer size,
because we want to be able to handle 'procedure instance
identifiers' which consist of a procedure identifier and the LB
of a frame belonging to that procedure.
.P
The heap data area grows upwards, to higher numbered
addresses.
It is initially empty.
The initial value of the heap pointer HP
marks the low end.
The heap pointer may be manipulated
by the LOR and STR instructions.
The heap can only be addressed indirectly,
by pointers derived from previous values of HP.
.S2 "Global data area"
The initial size of the global data area is determined at assembly time.
Global data is allocated by several
pseudoinstructions in the EM assembly
language.
Each pseudoinstruction allocates one or more bytes.
The bytes allocated for a single pseudo form
a 'block'.
A block differs from a fragment, because,
under certain conditions, several blocks are allocated
in a single fragment.
This guarantees that the bytes of these blocks
are consecutive.
.P
Global data is addressed absolutely in binary
machine language.
Most compilers, however,
cannot assign absolute addresses to their global variables,
especially not if the language
allows programs to be composed of several separately compiled modules.
The assembly language therefore allows the compiler to name
the first address of a global data block with an alphanumeric label.
Moreover, the only way to address such a named global data block
in the assembly language is by using its name.
It is the task of the assembler/loader to
translate these labels into absolute addresses.
These labels may also be used
in CON and ROM pseudoinstructions to initialize pointers.
.P
The pseudoinstruction CON allocates initialized data.
ROM acts like CON but indicates that the initialized data will
not change during execution of the program.
The pseudoinstruction BSS allocates a block of uninitialized
or identically initialized
data.
The pseudoinstruction HOL is similar to BSS,
but it alters the meaning of subsequent absolute addressing in
the assembly language.
.P
Another type of global data is a small block,
called the ABS block, with an implementation defined size.
Storage in this type of block can only be addressed
absolutely in assembly language.
The first word has address 0 and is used to maintain the
source line number.
Special instructions LIN and LNI are provided to
update this counter.
A pointer at location 4 points to a string containing the
current source file name.
The instruction FIL can be used to update the pointer.
.P
All numeric arguments of the instructions that address
the global data area refer to locations in the
ABS block unless
they are preceded by at least one HOL pseudo in the same
module,
in which case they refer to the storage area allocated by the
last HOL pseudoinstruction.
Thus LOE 0 loads the zeroth word of the most recent HOL, unless no HOL has
appeared in the current file so
far, in which case it loads the zeroth word of the
ABS fragment.
.P
The global data area is highly fragmented.
The ABS block and each HOL and BSS block are separate fragments.
The way fragments are formed from CON and ROM blocks is more complex.
The assemblers group several blocks into a single fragment.
A fragment only contains blocks of the same type: CON or ROM.
It is guaranteed that the bytes allocated for two consecutive CON pseudos are
allocated consecutively in a single fragment, unless
these CON pseudos are separated in the assembly language program
by a data label definition or one or more of the following pseudos:
.DS
ROM, BSS, HOL and END
.DE
An analogous rule holds for ROM pseudos.
.S2 "Local data area"
The local data area consists of a sequence of frames, one for
each active procedure.
Below the frame of the current procedure resides the
expression stack.
Frames are generated by procedure calls and are
removed by procedure returns.
A procedure frame consists of six 'zones':
.DS
1. The return status block
2. The local variables and compiler temporaries
3. The register save block
4. The dynamic local generators
5. The operand stack.
6. The parameters of a procedure one level deeper
.DE
A sample frame is shown in Figure 1.
.P
Before a procedure call is performed the actual
parameters are pushed onto the stack of the calling procedure.
The exact details are compiler dependent.
EM allows procedures to be called with a variable number of
parameters.
The implementation of the C-language almost forces its runtime
system to push the parameters in reverse order, that is,
the first positional parameter last.
Most compilers use the C calling convention to be compatible.
The parameters of a procedure belong to the frame of the
calling procedure.
Note that the evaluation of the actual parameters may imply
the calling of procedures.
The parameters can be accessed with certain instructions using
offsets of 0 and greater.
The first byte of the last parameter pushed has offset 0.
Note that the parameter at offset 0 has a special use in the
instructions following the static chain (LXL and LXA).
These instructions assume that this parameter contains the LB of
the statically enclosing procedure.
Procedures that do not have a dynamically enclosing procedure
do not need a static link at offset 0.
.P
Two instructions are available to perform procedure calls, CAL
and CAI.
Several tasks are performed by these call instructions.
.A
First, a part of the status of the calling procedure is
saved on the stack in the return status block.
This block should contain the return address of the calling
procedure, its LB and other implementation dependent data.
The size of this block is fixed for any given implementation
because the lexical instructions LPB, LXL and LXA must be able to
obtain the base addresses of the procedure parameters \fBand\fP local
variables.
An alternative solution can be used on machines with a highly
segmented address space.
The stack frames need not be contiguous then and the first
status save area can contain the parameter base AB,
which has the value of SP just after the last parameter has
been pushed.
.A
Second, the LB is changed to point to the
first word above the local variables.
The new LB is a copy of the SP after the return status
block has been pushed.
.A
Third, the amount of local storage needed by the procedure is
reserved.
The parameters and local storage are accessed by the same instructions.
Negative offsets are used for access to local variables.
The highest byte, that is the byte nearest
to LB, has to be accessed with offset -1.
The pseudoinstruction specifying the entry point of a
procedure, has an argument that specifies the amount of local
storage needed.
The local variables allocated by the CAI or CAL instructions
are the only ones that can be accessed with a fixed negative offset.
The initial value of the allocated words is
not defined, but implementations that check for undefined
values will probably initialize them with a
special 'undefined' pattern, typically -32768.
.A
Fourth, any EM implementation is allowed to reserve a variable size
block beneath the local variables.
This block could, for example, be used to save a variable number
of registers.
.A
Finally, the address of the entry point of the called procedure
is loaded into the Program Counter.
.P
The ASP instruction can be used to allocate further (dynamic)
local storage.
The base address of such storage must be obtained with a LOR~SP
instruction.
This same instruction ASP may also be used
to remove some words from the stack.
.P
There is a version of ASP, called ASS, which fetches the number
of bytes to allocate from the stack.
It can be used to allocate space for local
objects whose size is unknown at compile time,
so called 'dynamic local generators'.
.P
Control is returned to the calling procedure with a RET instruction.
Any return value is then copied to the 'function return area'.
The frame created by the call is deallocated and the status of
the calling procedure is restored.
The value of SP just after the return value has been popped must
be the same as the
value of SP just before executing the first instruction of this
invocation.
This means that when a RET is executed the operand stack can
only contain the return value and all dynamically generated locals must be
deallocated.
Violating this restriction might result in hard to detect
errors.
The calling procedure has to remove the parameters from the stack.
This can be done with the aforementioned ASP instruction.
.P
Each procedure frame is a separate fragment.
Because any fragment may be placed anywhere in memory,
procedure frames need not be contiguous.
.DS
|===============================|
| actual parameter n-1 |
|-------------------------------|
| . |
| . |
| . |
|-------------------------------|
| actual parameter 0 | ( <- AB )
|===============================|
|===============================|
|///////////////////////////////|
|///// return status block /////|
|///////////////////////////////| <- LB
|===============================|
| |
| local variables |
| |
|-------------------------------|
| |
| compiler temporaries |
| |
|===============================|
|///////////////////////////////|
|///// register save block /////|
|///////////////////////////////|
|===============================|
| |
| dynamic local generators |
| |
|===============================|
| operand |
|-------------------------------|
| operand |
|===============================|
| parameter m-1 |
|-------------------------------|
| . |
| . |
| . |
|-------------------------------|
| parameter 0 | <- SP
|===============================|
Figure 1. A sample procedure frame and parameters.
.DE
.S2 "Heap data area"
The heap area starts empty, with HP
pointing to the low end of it.
HP always contains a word address.
A copy of HP can always be obtained with the LOR instruction.
A new value may be stored in the heap pointer using the STR instruction.
If the new value is greater than the old one,
then the heap grows.
If it is smaller, then the heap shrinks.
HP may never point below its original value.
All words between the current HP and the original HP
are allocated to the heap.
The heap may not grow into a part of memory that is already allocated
for the stack.
When this is attempted, the STR instruction will cause a trap to occur.
.P
The only way to address the heap is indirectly.
Whenever an object is allocated by increasing HP,
then the old HP value must be saved and can be used later to address
the allocated object.
If, in the meantime, HP is decreased so that the object
is no longer part of the heap, then an attempt to access
the object is not allowed.
Furthermore, if the heap pointer is increased again to above
the object address, then access to the old object gives undefined results.
.P
The heap is a single fragment.
All bytes have consecutive addresses.
No limits are imposed on the size of the heap as long as it fits
in the available data address space.

1665
doc/em/em.i
View File

File diff suppressed because it is too large Load Diff

9
doc/em/even.c
View File

@ -1,9 +0,0 @@
main() {
register int l,j ;
for ( j=0 ; (l=getchar()) != -1 ; j++ ) {
if ( j%16 == 15 ) printf("%3d\n",l&0377 ) ;
else printf("%3d ",l&0377 ) ;
}
printf("\n") ;
}

178
doc/em/exam.e
View File

@ -1,178 +0,0 @@
mes 2,2,2 ; wordsize 2, pointersize 2
.1
rom 't.p\000' ; the name of the source file
hol 552,-32768,0 ; externals and buf occupy 552 bytes
exp $sum ; sum can be called from other modules
pro $sum,2 ; procedure sum; 2 bytes local storage
lin 8 ; code from source line 8
ldl 0 ; load two locals ( a and b )
adi 2 ; add them
ret 2 ; return the result
end 2 ; end of procedure ( still two bytes local storage )
.2
rom 1,99,2 ; descriptor of array a[]
exp $test ; the compiler exports all level 0 procedures
pro $test,226 ; procedure test, 226 bytes local storage
.3
rom 4.8F8 ; assemble Floating point 4.8 (8 bytes) in
.4 ; global storage
rom 0.5F8 ; same for 0.5
mes 3,-226,2,2 ; compiler temporary not referenced indirect
mes 3,-24,2,0 ; the same is true for i, j, b and c in test
mes 3,-22,2,0
mes 3,-4,2,0
mes 3,-2,2,0
mes 3,-20,8,0 ; and for x and y
mes 3,-12,8,0
lin 20 ; maintain source line number
loc 1
stl -4 ; j := 1
lni ; was lin 21 prior to optimization
lol -4
loc 3
mli 2
loc 6
adi 2
stl -2 ; i := 3 * j + 6
lni ; was lin 22 prior to optimization
lae .3
loi 8
lal -12
sti 8 ; x := 4.8
lni ; was lin 23 prior to optimization
lal -12
loi 8
lae .4
loi 8
dvf 8
lal -20
sti 8 ; y := x / 0.5
lni ; was lin 24 prior to optimization
loc 1
stl -22 ; b := true
lni ; was lin 25 prior to optimization
loc 122
stl -24 ; c := 'z'
lni ; was lin 26 prior to optimization
loc 1
stl -2 ; for i:= 1
2
lol -2
dup 2
mli 2 ; i*i
lal -224
lol -2
lae .2
sar 2 ; a[i] :=
lol -2
loc 100
beq *3 ; to 100 do
inl -2 ; increment i and loop
bra *2
3
lin 27
lol -4
loc 27
adi 2 ; j + 27
sil 0 ; r.r1 :=
lni ; was lin 28 prior to optimization
lol -22 ; b
lol 0
stf 10 ; r.r3 :=
lni ; was lin 29 prior to optimization
lal -20
loi 16
adf 8 ; x + y
lol 0
adp 2
sti 8 ; r.r2 :=
lni ; was lin 23 prior to optimization
lal -224
lol -4
lae .2
lar 2 ; a[j]
lil 0 ; r.r1
cal $sum ; call now
asp 4 ; remove parameters from stack
lfr 2 ; get function result
stl -2 ; i :=
4
lin 31
lol -2
zle *5 ; while i > 0 do
lol -4
lil 0
adi 2
stl -4 ; j := j + r.r1
del -2 ; i := i - 1
bra *4 ; loop
5
lin 32
lol 0
stl -226 ; make copy of address of r
lol -22
lol -226
stf 10 ; r3 := b
lal -20
loi 16
adf 8
lol -226
adp 2
sti 8 ; r2 := x + y
loc 0
sil -226 ; r1 := 0
lin 34 ; note the abscence of the unnecesary jump
lae 22 ; address of output structure
lol -4
cal $_wri ; write integer with default width
asp 4 ; pop parameters
lae 22
lol -2
loc 6
cal $_wsi ; write integer width 6
asp 6
lae 22
lal -12
loi 8
loc 9
loc 3
cal $_wrf ; write fixed format real, width 9, precision 3
asp 14
lae 22
lol -22
cal $_wrb ; write boolean, default width
asp 4
lae 22
cal $_wln ; writeln
asp 2
ret 0 ; return, no result
end 226
exp $_main
pro $_main,0 ; main program
.6
con 2,-1,22 ; description of external files
.5
rom 15.96F8
fil .1 ; maintain source file name
lae .6 ; description of external files
lae 0 ; base of hol area to relocate buffer addresses
cal $_ini ; initialize files, etc...
asp 4
lin 37
lae .5
loi 8
lae 2
sti 8 ; x := 15.9
lni ; was lin 38 prior to optimization
loc 99
ste 0 ; mi := 99
lni ; was lin 39 prior to optimization
lae 10 ; address of r
cal $test
asp 2
loc 0 ; normal exit
cal $_hlt ; cleanup and finish
asp 2
end 0
mes 4,40 ; length of source file is 40 lines
mes 5 ; reals were used

40
doc/em/exam.p
View File

@ -1,40 +0,0 @@
program example(output);
{This program just demonstrates typical EM code.}
type rec = record r1: integer; r2:real; r3: boolean end;
var mi: integer; mx:real; r:rec;
function sum(a,b:integer):integer;
begin
sum := a + b
end;
procedure test(var r: rec);
label 1;
var i,j: integer;
x,y: real;
b: boolean;
c: char;
a: array[1..100] of integer;
begin
j := 1;
i := 3 * j + 6;
x := 4.8;
y := x/0.5;
b := true;
c := 'z';
for i:= 1 to 100 do a[i] := i * i;
r.r1 := j+27;
r.r3 := b;
r.r2 := x+y;
i := sum(r.r1, a[j]);
while i > 0 do begin j := j + r.r1; i := i - 1 end;
with r do begin r3 := b; r2 := x+y; r1 := 0 end;
goto 1;
1: writeln(j, i:6, x:9:3, b)
end; {test}
begin {main program}
mx := 15.96;
mi := 99;
test(r)
end.

32
doc/em/int/Makefile
View File

@ -1,32 +0,0 @@
CFLAGS=-O
HOME=../../..
install \
all: em emdmp tables
tables: mktables $(HOME)/util/ass/ip_spec.t
mktables $(HOME)/util/ass/ip_spec.t tables
mktables: mktables.c $(HOME)/h/em_spec.h $(HOME)/h/em_flag.h \
$(HOME)/util/data/em_data.a $(HOME)/util/ass/ip_spec.h
cc -O -o mktables mktables.c $(HOME)/util/data/em_data.a
em.out: em.p
apc -mint -O em.p >emerrs ; mv e.out em.out
em: em.p
apc -O -i em.p >emerrs ; mv a.out em
nem.p: em.p
sed -e '/maxadr = t16/s//maxadr =t15/' -e '/maxdata = 8191; /s//maxdata = 14335;/' -e '/ adr=.*long/s// adr= 0..maxadr/' <em.p >nem.p
nem: nem.p
apc -O -i nem.p >emerrs ; mv a.out nem
emdmp: emdmp.c
cc -o emdmp -O emdmp.c
cmp:
pr:
@pr em.p mktables.c emdmp.c

5
doc/em/int/READ_ME
View File

@ -1,5 +0,0 @@
This interpreter is meant for inclusion in the EM manual.
Although slow, it showed decent behaviour on several tests.
The only monitor calls implemented are exit, read(untested),
write and ioctl - just reurns the correct code for telling it's
a terminal -

1767
doc/em/int/em.p
View File

File diff suppressed because it is too large Load Diff

210
doc/em/int/emdmp.c
View File

@ -1,210 +0,0 @@
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: E.G. Keizer */
/* Print a readable version of the data in the post mortem dump */
/* dmpc [-s] [-dn,m] [file] */
#include "/usr/em/h/local.h"
#include <stdio.h>
#include <ctype.h>
int dflag = 0 ;
long l_low,l_high;
int sflag;
int wsize,asize;
long tsize,dsize;
long ignmask,uerrorproc,cause;
long pc,sp,lb,hp,pd,pb;
char *cstr[] = {
"Array bound error",
"Range bound error",
"Set error",
"Integer overflow",
"Float overflow",
"Float underflow",
"Divide by 0",
"Divide by 0.0",
"Integer undefined",
"Float undefined",
"Conversion error",
"User error 11",
"User error 12",
"User error 13",
"User error 14",
"User error 15",
"Stack overflow",
"Heap overflow",
"Illegal instruction",
"Illegal size parameter",
"Case error",
"Memory fault",
"Illegal pointer",
"Illegal pc",
"Bad argument of LAE",
"Bad monitor call",
"Bad line number",
"GTO descriptor error"
};
FILE *fcore;
char *core = "core" ;
int nbyte=0;
char *pname;
int readbyte();
int read2();
long readaddr();
long readword();
unsigned getbyte();
long getword();
long getaddr();
main(argc,argv) char **argv;
{
register i ;
long line,fileaddr;
char tok ;
scanargs(argc,argv); fcore=fopen(core,"r") ;
if ( fcore==NULL ) fatal("Can't open %s",core) ;
if ( read2()!=010255 ) fatal("not a post mortem dump");
if ( read2()!=VERSION ) fatal("wrong version dump file");
wsize=read2(); asize=read2();
if ( wsize>4 ) fatal("cannot handle word size %d",wsize) ;
if ( asize>4 ) fatal("cannot handle pointer size %d",asize) ;
tsize=readaddr(); dsize=readaddr();
ignmask=readaddr(); uerrorproc=readaddr(); cause=readaddr();
pc=readaddr(); sp=readaddr(); lb=readaddr(); hp=readaddr();
pd=readaddr(); pb=readaddr();
if ( sflag==0 ) {
line=getword(0L);
fileaddr=getaddr(4L);
if ( fileaddr ) {
for ( i=0 ; i<40 ; i++ ) {
tok=getbyte(fileaddr++) ;
if ( !isprint(tok) ) break ;
putc(tok,stdout);
}
printf(" ");
}
if ( line ) {
printf("line %D",line) ;
}
if ( fileaddr || line ) printf(", ");
fseek(fcore,512L,0);
if ( cause>27 ) {
printn("cause",cause) ;
} else {
prints("cause",cstr[(int)cause]);
}
printn("pc",pc);printn("sp",sp);printn("lb",lb);
printn("hp",hp);
if ( pd ) printn("pd",pd) ;
if ( pb ) printn("pb",pb) ;
printn("errproc",uerrorproc) ;
printn("ignmask",ignmask) ;
if ( tsize ) printn("Text size",tsize) ;
if ( dsize ) printn("Data size",dsize) ;
}
if ( dflag==0 ) return 0;
fatal("d-flag not implemeted (yet)");
return 1 ;
}
scanargs(argc,argv) char **argv ; {
pname=argv[0];
while ( argv++, argc-- > 1 ) {
switch( argv[0][0] ) {
case '-': switch( argv[0][1] ) {
case 's': sflag++ ; break ;
case 'l': dflag++ ; break ;
default : fatal(": [-s] [-ln.m] [file]") ;
} ;
break ;
default :core=argv[0] ;
}
}
}
prints(s1,s2) char *s1,*s2; {
printf("%-15s %s\n",s1,s2);
}
printn(s1,d) char *s1; long d; {
printf("%-15s %15ld\n",s1,d);
}
/* VARARGS1 */
fatal(s1,p1,p2,p3,p4,p5) char *s1 ; {
fprintf(stderr,"%s: ",pname);
fprintf(stderr,s1,p1,p2,p3,p4,p5) ;
fprintf(stderr,"\n") ;
exit(1) ;
}
int getb() {
int i ;
i=getc(fcore) ;
if ( i==EOF ) fatal("Premature EOF");
return i&0377 ;
}
int read2() {
int i ;
i=getb() ; return getb()*256 + i ;
}
long readaddr() {
long res ;
register int i ;
res=0 ;
for (i=0 ; i<asize ; i++ ) res |= getb()<<(8*i) ;
return res ;
}
long readword() {
long res ;
register int i ;
res=0 ;
for (i=0 ; i<wsize ; i++ ) res |= getb()<<(8*i) ;
return res ;
}
unsigned getbyte(a) long a ; {
fseek(fcore,a+512,0) ;
return getb() ;
}
long getword(a) long a ; {
fseek(fcore,a+512,0) ;
return readword() ;
}
long getaddr(a) long a ; {
fseek(fcore,a+512,0) ;
return readaddr() ;
}

244
doc/em/int/mktables.c
View File

@ -1,244 +0,0 @@
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: E.G. Keizer */
#include <stdio.h>
#include "/usr/em/util/ass/ip_spec.h"
#include "/usr/em/h/em_spec.h"
#include "/usr/em/h/em_flag.h"
/* This program reads the human readable interpreter specification
and produces a efficient machine representation that can be
translated by a C-compiler.
*/
#define ESCAP 256
int nerror = 0 ;
int atend = 0 ;
int line = 1 ;
int maxinsl= 0 ;
extern char em_mnem[][4] ;
char esca[] = "escape" ;
#define ename(no) ((no)==ESCAP?esca:em_mnem[(no)])
extern char em_flag[] ;
main(argc,argv) char **argv ; {
if ( argc>1 ) {
if ( freopen(argv[1],"r",stdin)==NULL) {
fatal("Cannot open %s",argv[1]) ;
}
}
if ( argc>2 ) {
if ( freopen(argv[2],"w",stdout)==NULL) {
fatal("Cannot create %s",argv[2]) ;
}
}
if ( argc>3 ) {
fatal("%s [ file [ file ] ]",argv[0]) ;
}
atend=0 ;
readin();
atend=1 ;
return nerror ;
}
readin() {
char *ident();
char *firstid ;
int opcode,flags;
int c;
while ( !feof(stdin) ) {
firstid=ident() ;
if ( *firstid=='\n' || feof(stdin) ) continue ;
opcode = getmnem(firstid) ;
printf("%d ",opcode+1) ;
flags = decflag(ident(),opcode) ;
switch(em_flag[opcode]&EM_PAR) {
case PAR_D: case PAR_F: case PAR_B: case PAR_L: case PAR_C:
putchar('S') ;
}
putchar(' ');
while ( (c=readchar())!='\n' && c!=EOF ) putchar(c) ;
putchar('\n') ;
}
}
char *ident() {
/* skip spaces and tabs, anything up to space,tab or eof is
a identifier.
Anything from # to end-of-line is an end-of-line.
End-of-line is an identifier all by itself.
*/
static char array[200] ;
register int c ;
register char *cc ;
do {
c=readchar() ;
} while ( c==' ' || c=='\t' ) ;
for ( cc=array ; cc<&array[(sizeof array) - 1] ; cc++ ) {
if ( c=='#' ) {
do {
c=readchar();
} while ( c!='\n' && c!=EOF ) ;
}
*cc = c ;
if ( c=='\n' && cc==array ) break ;
c=readchar() ;
if ( c=='\n' ) {
pushback(c) ;
break ;
}
if ( c==' ' || c=='\t' || c==EOF ) break ;
}
*++cc=0 ;
return array ;
}
int getmnem(str) char *str ; {
char (*ptr)[4] ;
for ( ptr = em_mnem ; *ptr<= &em_mnem[sp_lmnem][0] ; ptr++ ) {
if ( strcmp(*ptr,str)==0 ) return (ptr-em_mnem) ;
}
error("Illegal mnemonic") ;
return 0 ;
}
error(str,a1,a2,a3,a4,a5,a6) /* VARARGS1 */ char *str ; {
if ( !atend ) fprintf(stderr,"line %d: ",line) ;
fprintf(stderr,str,a1,a2,a3,a4,a5,a6) ;
fprintf(stderr,"\n");
nerror++ ;
}
mess(str,a1,a2,a3,a4,a5,a6) /* VARARGS1 */ char *str ; {
if ( !atend ) fprintf(stderr,"line %d: ",line) ;
fprintf(stderr,str,a1,a2,a3,a4,a5,a6) ;
fprintf(stderr,"\n");
}
fatal(str,a1,a2,a3,a4,a5,a6) /* VARARGS1 */ char *str ; {
error(str,a1,a2,a3,a4,a5,a6) ;
exit(1) ;
}
#define ILLGL -1
check(val) int val ; {
if ( val!=ILLGL ) error("Illegal flag combination") ;
}
int decflag(str,opc) char *str ; {
int type ;
int escape ;
int range ;
int wordm ;
int notzero ;
char c;
type=escape=range=wordm=notzero= ILLGL ;
while ( c= *str++ ) {
switch ( c ) {
case 'm' :
check(type) ; type=OPMINI ; break ;
case 's' :
check(type) ; type=OPSHORT ; break ;
case '-' :
check(type) ; type=OPNO ;
if ( (em_flag[opc]&EM_PAR)==PAR_W ) c='i' ;
break ;
case '1' :
check(type) ; type=OP8 ; break ;
case '2' :
check(type) ; type=OP16 ; break ;
case '4' :
check(type) ; type=OP32 ; break ;
case '8' :
check(type) ; type=OP64 ; break ;
case 'e' :
check(escape) ; escape=0 ; break ;
case 'N' :
check(range) ; range= 2 ; break ;
case 'P' :
check(range) ; range= 1 ; break ;
case 'w' :
check(wordm) ; wordm=0 ; break ;
case 'o' :
check(notzero) ; notzero=0 ; break ;
default :
error("Unknown flag") ;
}
putchar(c);
}
if ( type==ILLGL ) error("Type must be specified") ;
switch ( type ) {
case OP64 :
case OP32 :
if ( escape!=ILLGL ) error("Conflicting escapes") ;
escape=ILLGL ;
case OP16 :
case OP8 :
case OPSHORT :
case OPNO :
if ( notzero!=ILLGL ) mess("Improbable OPNZ") ;
if ( type==OPNO && range!=ILLGL ) {
mess("No operand in range") ;
}
}
if ( escape!=ILLGL ) type|=OPESC ;
if ( wordm!=ILLGL ) type|=OPWORD ;
switch ( range) {
case ILLGL : type|=OP_BOTH ; break ;
case 1 : type|=OP_POS ; break ;
case 2 : type|=OP_NEG ; break ;
}
if ( notzero!=ILLGL ) type|=OPNZ ;
return type ;
}
static int pushchar ;
static int pushf ;
int readchar() {
int c ;
if ( pushf ) {
pushf=0 ;
c = pushchar ;
} else {
if ( feof(stdin) ) return EOF ;
c=getc(stdin) ;
}
if ( c=='\n' ) line++ ;
return c ;
}
pushback(c) {
if ( pushf ) {
fatal("Double pushback") ;
}
pushf++ ;
pushchar=c ;
if ( c=='\n' ) line-- ;
}

180
doc/em/intro.nr
View File

@ -1,180 +0,0 @@
.BP
.S1 "INTRODUCTION"
EM is a family of intermediate languages designed for producing
portable compilers.
The general strategy is for a program called
.B front end
to translate the source program to EM.
Another program,
.B back
.BW end
translates EM to target assembly language.
Alternatively, the EM code can be assembled to a binary form
and interpreted.
These considerations led to the following goals:
.IS 2 10
.PS 1 4
.PT
The design should allow translation to,
or interpretation on, a wide range of existing machines.
Design decisions should be delayed as far as possible
and the implications of these decisions should
be localized as much as possible.
.N
The current microcomputer technology offers 8, 16 and 32 bit machines
with various sizes of address space.
EM should be flexible enough to be useful on most of these
machines.
The differences between the members of the EM family should only
concern the wordsize and address space size.
.PT
The architecture should ease the task of code generation for
high level languages such as Pascal, C, Ada, Algol 68, BCPL.
.PT
The instruction set used by the interpreter should be compact,
to reduce the amount of memory needed
for program storage, and to reduce the time needed to transmit
programs over communication lines.
.PT
It should be designed with microprogrammed implementations in
mind; in particular, the use of many short fields within
instruction opcodes should be avoided, because their extraction by the
microprogram or conversion to other instruction formats is inefficient.
.PE
.IE
.A
The basic architecture is based on the concept of a stack. The stack
is used for procedure return addresses, actual parameters, local variables,
and arithmetic operations.
There are several built-in object types,
for example, signed and unsigned integers,
floating point numbers, pointers and sets of bits.
There are instructions to push and pop objects
to and from the stack.
The push and pop instructions are not typed.
They only care about the size of the objects.
For each built-in type there are
reverse Polish type instructions that pop one or more
objects from the top of
the stack, perform an operation, and push the result back onto the
stack.
For all types except pointers,
these instructions have the object size
as argument.
.P
There are no visible general registers used for arithmetic operands
etc. This is in contrast to most third generation computers, which usually
have 8 or 16 general registers. The decision not to have a group of
general registers was fully intentional, and follows W.L. Van der
Poel's dictum that a machine should have 0, 1, or an infinite
number of any feature. General registers have two primary uses: to hold
intermediate results of complicated expressions, e.g.
.IS 5 0 1
((a*b + c*d)/e + f*g/h) * i
.IE 1
and to hold local variables.
.P
Various studies
have shown that the average expression has fewer than two operands,
making the former use of registers of doubtful value. The present trend
toward structured programs consisting of many small
procedures greatly reduces the value of registers to hold local variables
because the large number of procedure calls implies a large overhead in
saving and restoring the registers at every call.
.BP
.P
Although there are no general purpose registers, there are a
few internal registers with specific functions as follows:
.IS 2
.N 1
.TS
tab(:);
l 1 l l.
PC:-:Program Counter:Pointer to next instruction
LB:-:Local Base:Points to base of the local variables \
in the current procedure.
SP:-:Stack Pointer:Points to the highest occupied word on the stack.
HP:-:Heap Pointer:Points to the top of the heap area.
.TE 1
.IE
.A
Furthermore, reverse Polish code is much easier to generate than
multi-register machine code, especially if highly efficient code is
desired.
When translating to assembly language the back end can make
good use of the target machine's registers.
An EM machine can
achieve high performance by keeping part of the stack
in high speed storage (a cache or microprogram scratchpad memory) rather
than in primary memory.
.P
Again according to van der Poel's dictum,
all EM instructions have zero or one argument.
We believe that instructions needing two arguments
can be split into two simpler ones.
The simpler ones can probably be used in other
circumstances as well.
Moreover, these two instructions together often
have a shorter encoding than the single
instruction before.
.P
This document describes EM at three different levels:
the abstract level, the assembly language level and
the machine language level.
.A
The most important level is that of the abstract EM architecture.
This level deals with the basic design issues.
Only the functional capabilities of instructions are relevant, not their
format or encoding.
Most chapters of this document refer to the abstract level
and it is explicitly stated whenever
another level is described.
.A
The assembly language is intended for the compiler writer.
It presents a more or less orthogonal instruction
set and provides symbolic names for data.
Moreover, it facilitates the linking of
separately compiled 'modules' into a single program
by providing several pseudoinstructions.
.A
The machine language is designed for interpretation with a compact
program text and easy decoding.
The binary representation of the machine language instruction set is
far from orthogonal.
Frequent instructions have a short opcode.
The encoding is fully byte oriented.
These bytes do not contain small bit fields, because
bit fields would slow down decoding considerably.
.P
A common use for EM is for producing portable (cross) compilers.
When used this way, the compilers produce
EM assembly language as their output.
To run the compiled program on the target machine,
the back end, translates the EM assembly language to
the target machine's assembly language.
When this approach is used, the format of the EM
machine language instructions is irrelevant.
On the other hand, when writing an interpreter for EM machine language
programs, the interpreter must deal with the machine language
and not with the symbolic assembly language.
.P
As mentioned above, the
current microcomputer technology offers 8, 16 and 32 bit
machines with address spaces ranging from 2\v'-0.5m'16\v'0.5m'
to 2\v'-0.5m'32\v'0.5m' bytes.
Having one size of pointers and integers restricts
the usefulness of the language.
We decided to have a different language for each combination of
word and pointer size.
All languages offer the same instruction set and differ only in
memory alignment restrictions and the implicit size assumed in
several instructions.
The languages
differ slightly for the
different size combinations.
For example: the
size of any object on the stack and alignment restrictions.
The wordsize is restricted to powers of 2 and
the pointer size must be a multiple of the wordsize.
Almost all programs handling EM will be parametrized with word
and pointer size.

376
doc/em/iotrap.nr
View File

@ -1,376 +0,0 @@
.SN 8
.VS 1 0
.BP
.S1 "ENVIRONMENT INTERACTIONS"
EM programs can interact with their environment in three ways.
Two, starting/stopping and monitor calls, are dealt with in this chapter.
The remaining way to interact, interrupts, will be treated
together with traps in chapter 9.
.S2 "Program starting and stopping"
EM user programs start with a call to a procedure called
m_a_i_n.
The assembler and backends look for the definition of a procedure
with this name in their input.
The call passes three parameters to the procedure.
The parameters are similar to the parameters supplied by the
UNIX
.FS
UNIX is a Trademark of Bell Laboratories.
.FE
operating system to C programs.
These parameters are often called
.BW argc ,
.B argv
and
.BW envp .
Argc is the parameter nearest to LB and is a wordsized integer.
The other two are pointers to the first element of an array of
string pointers.
.N
The
.B argv
array contains
.B argc
strings, the first of which contains the program call name.
The other strings in the
.B argv
array are the program parameters.
.P
The
.B envp
array contains strings in the form "name=string", where 'name'
is the name of an environment variable and string its value.
The
.B envp
is terminated by a zero pointer.
.P
An EM user program stops if the program returns from the first
invocation of m_a_i_n.
The contents of the function return area are used to procure a
wordsized program return code.
EM programs also stop when traps and interrupts occur that are
not caught and when the exit monitor call is executed.
.S2 "Input/Output and other monitor calls"
EM differs from most conventional machines in that it has high level i/o
instructions.
Typical instructions are OPEN FILE and READ FROM FILE instead
of low level instructions such as setting and clearing
bits in device registers.
By providing such high level i/o primitives, the task of implementing
EM on various non EM machines is made considerably easier.
.P
I/O is initiated by the MON instruction, which expects an iocode on top
of the stack.
Often there are also parameters which are pushed on the
stack in reverse order, that is: last
parameter first.
Some i/o functions also provide results, which are returned on the stack.
In the list of monitor calls we use several types of parameters and results,
these types consist of integers and unsigneds of varying sizes, but never
smaller than the wordsize, and the two pointer types.
.N 1
The names of the types used are:
.IS 4
.PS - 10
.PT int
an integer of wordsize
.PT int2
an integer whose size is the maximum of the wordsize and 2
bytes
.PT int4
an integer whose size is the maximum of the wordsize and 4
bytes
.PT intp
an integer with the size of a pointer
.PT uns2
an unsigned integer whose size is the maximum of the wordsize and 2
.PT unsp
an unsigned integer with the size of a pointer
.PT ptr
a pointer into data space
.PE 1
.IE 0
The table below lists the i/o codes with their results and
parameters.
This list is similar to the system calls of the UNIX Version 7
operating system.
.BP
.A
To execute a monitor call, proceed as follows:
.IS 2
.N 1
.PS a 4 "" )
.PT
Stack the parameters, in reverse order, last parameter first.
.PT
Push the monitor call number (iocode) onto the stack.
.PT
Execute the MON instruction.
.PE 1
.IE
An error code is present on the top of the stack after
execution of most monitor calls.
If this error code is zero, the call performed the action
requested and the results are available on top of the stack.
Non-zero error codes indicate a failure, in this case no
results are available and the error code has been pushed twice.
This construction enables programs to test for failure with a
single instruction (~TEQ or TNE~) and still find out the cause of
the failure.
The result name 'e' is reserved for the error code.
.N 1
List of monitor calls.
.DS B
number name parameters results function
1 Exit status:int Terminate this process
2 Fork e,flag,pid:int Spawn new process
3 Read fildes:int;buf:ptr;nbytes:unsp
e:int;rbytes:unsp Read from file
4 Write fildes:int;buf:ptr;nbytes:unsp
e:int;wbytes:unsp Write on a file
5 Open string:ptr;flag:int
e,fildes:int Open file for read and/or write
6 Close fildes:int e:int Close a file
7 Wait e:int;status,pid:int2
Wait for child
8 Creat string:ptr;mode:int
e,fildes:int Create a new file
9 Link string1,string2:ptr
e:int Link to a file
10 Unlink string:ptr e:int Remove directory entry
12 Chdir string:ptr e:int Change default directory
14 Mknod string:ptr;mode,addr:int2
e:int Make a special file
15 Chmod string:ptr;mode:int2
e:int Change mode of file
16 Chown string:ptr;owner,group:int2
e:int Change owner/group of a file
18 Stat string,statbuf:ptr
e:int Get file status
19 Lseek fildes:int;off:int4;whence:int
e:int;oldoff:int4 Move read/write pointer
20 Getpid pid:int2 Get process identification
21 Mount special,string:ptr;rwflag:int
e:int Mount file system
22 Umount special:ptr e:int Unmount file system
23 Setuid userid:int2 e:int Set user ID
24 Getuid e_uid,r_uid:int2 Get user ID
25 Stime time:int4 e:int Set time and date
26 Ptrace request:int;pid:int2;addr:ptr;data:int
e,value:int Process trace
27 Alarm seconds:uns2 previous:uns2 Schedule signal
28 Fstat fildes:int;statbuf:ptr
e:int Get file status
29 Pause Stop until signal
30 Utime string,timep:ptr
e:int Set file times
33 Access string,mode:int e:int Determine file accessibility
34 Nice incr:int Set program priority
35 Ftime bufp:ptr e:int Get date and time
36 Sync Update filesystem
37 Kill pid:int2;sig:int
e:int Send signal to a process
41 Dup fildes,newfildes:int
e,fildes:int Duplicate a file descriptor
42 Pipe e,w_des,r_des:int Create a pipe
43 Times buffer:ptr Get process times
44 Profil buff:ptr;bufsiz,offset,scale:intp Execution time profile
46 Setgid gid:int2 e:int Set group ID
47 Getgid e_gid,r_gid:int Get group ID
48 Sigtrp trapno,signo:int
e,prevtrap:int See below
51 Acct file:ptr e:int Turn accounting on or off
53 Lock flag:int e:int Lock a process
54 Ioctl fildes,request:int;argp:ptr
e:int Control device
56 Mpxcall cmd:int;vec:ptr e:int Multiplexed file handling
59 Exece name,argv,envp:ptr
e:int Execute a file
60 Umask complmode:int2 oldmask:int2 Set file creation mode mask
61 Chroot string:ptr e:int Change root directory
.DE 1
Codes 0, 11, 13, 17, 31, 32, 38, 39, 40, 45, 49, 50, 52,
55, 57, 58, 62, and 63 are
not used.
.P
All monitor calls, except fork and sigtrp
are the same as the UNIX version 7 system calls.
.P
The sigtrp entry maps UNIX signals onto EM interrupts.
Normally, trapno is in the range 0 to 252.
In that case it requests that signal signo
will cause trap trapno to occur.
When given trap number -2, default signal handling is reset, and when given
trap number -3, the signal is ignored.
.P
The flag returned by fork is 1 in the child process and 0 in
the parent.
The pid returned is the process-id of the other process.
.BP
.S1 "TRAPS AND INTERRUPTS"
EM provides a means for the user program to catch all traps
generated by the program itself, the hardware, or external conditions.
This mechanism uses five instructions: LIM, SIM, SIG, TRP and RTT.
This section of the manual may be omitted on the first reading since it
presupposes knowledge of the EM instruction set.
.P
The action taken when a trap occures is determined by the value
of an internal EM trap register.
This register contains a pointer to a procedure.
Initially the pointer used is zero and all traps halt the
program with, hopefully, a useful message to the outside world.
The SIG instruction can be used to alter the trap register,
it pops a procedure pointer from the
stack into the trap register.
When a trap occurs after storing a nonzero value in the trap
register, the procedure pointed to by the trap register
is called with the trap number
as the only parameter (see below).
SIG returns the previous value of the trap register on the
stack.
Two consecutive SIGs are a no-op.
When a trap occurs, the trap register is reset to its initial
condition, to prevent recursive traps from hanging the machine up,
e.g. stack overflow in the stack overflow handling procedure.
.P
The runtime systems for some languages need to ignore some EM
traps.
EM offers a feature called the ignore mask.
It contains one bit for each of the lowest 16 trap numbers.
The bits are numbered 0 to 15, with the least significant bit
having number 0.
If a certain bit is 1 the corresponding trap never
occurs and processing simply continues.
The actions performed by the offending instruction are
described by the Pascal program in appendix A.
.N
If the bit is 0, traps are not ignored.
The instructions LIM and SIM allow copying and replacement of
the ignore mask.~
.P
The TRP instruction generates a trap, the trap number being found on the
stack.
This is, among other things,
useful for library procedures and runtime systems.
It can also be used by a low level trap procedure to pass the trap to a
higher level one (see example below).
.P
The RTT instruction returns from the trap procedure and continues after the
trap.
In the list below all traps marked with an asterisk ('*') are
considered to be fatal and it is explicitly undefined what happens if
you try to restart after the trap.
.P
The way a trap procedure is called is completely compatible
with normal calling conventions. The only way a trap procedure
differs from normal procedures is the return. It has to use RTT instead
of RET. This is necessary because the complete runtime status is saved on the
stack before calling the procedure and all this status has to be reloaded.
Error numbers are in the range 0 to 252.
The trap numbers are divided into three categories:
.IS 4
.N 1
.PS - 10
.PT ~~0-~63
EM machine errors, e.g. illegal instruction.
.PS - 8
.PT ~0-15
maskable
.PT 16-63
not maskable
.PE
.PT ~64-127
Reserved for use by compilers, run time systems, etc.
.PT 128-252
Available for user programs.
.PE 1
.IE
EM machine errors are numbered as follows:
.DS I 5
.TS
tab(@);
n l l.
0@EARRAY@Array bound error
1@ERANGE@Range bound error
2@ESET@Set bound error
3@EIOVFL@Integer overflow
4@EFOVFL@Floating overflow
5@EFUNFL@Floating underflow
6@EIDIVZ@Divide by 0
7@EFDIVZ@Divide by 0.0
8@EIUND@Undefined integer
9@EFUND@Undefined float
10@ECONV@Conversion error
16*@ESTACK@Stack overflow
17*@EHEAP@Heap overflow
18*@EILLINS@Illegal instruction
19*@EODDZ@Illegal size argument
20*@ECASE@Case error
21*@EMEMFLT@Addressing non existent memory
22*@EBADPTR@Bad pointer used
23*@EBADPC@Program counter out of range
24@EBADLAE@Bad argument of LAE
25@EBADMON@Bad monitor call
26@EBADLIN@Argument of LIN too high
27@EBADGTO@GTO descriptor error
.TE
.DE 0
.P
As an example,
suppose a subprocedure has to be written to do a numeric
calculation.
When an overflow occurs the computation has to be stopped and
the higher level procedure must be resumed.
This can be programmed as follows using the mechanism described above:
.DS B
mes 2,2,2 ; set sizes
ersave
bss 2,0,0 ; Room to save previous value of trap procedure
msave
bss 2,0,0 ; Room to save previous value of trap mask
pro calcule,0 ; entry point
lxl 0 ; fill in non-local goto descriptor with LB
ste jmpbuf+4
lor 1 ; and SP
ste jmpbuf+2
lim ; get current ignore mask
ste msave ; save it
lim
loc 4 ; bit for EFOVFL
ior 2 ; set in mask
sim ; ignore EFOVFL from now on
lpi $catch ; load procedure identifier
sig ; catch wil get all traps now
ste ersave ; save previous trap procedure identifier
; perform calculation now, possibly generating overflow
1 ; label jumped to by catch procedure
loe ersave ; get old trap procedure
sig ; refer all following trap to old procedure
asp 2 ; remove result of sig
loe msave ; restore previous mask
sim ; done now
; load result of calculation
ret 2 ; return result
jmpbuf
con *1,0,0
end
.DE 0
.VS 1 1
.DS
Example of catch procedure
pro catch,0 ; Local procedure that must catch the overflow trap
lol 2 ; Load trap number
loc 4 ; check for overflow
bne *1 ; if other trap, call higher trap procedure
gto jmpbuf ; return to procedure calcule
1 ; other trap has occurred
loe ersave ; previous trap procedure
sig ; other procedure will get the traps now
asp 2 ; remove the result of sig
lol 2 ; stack trap number
trp ; call other trap procedure
rtt ; if other procedure returns, do the same
end
.DE

6
doc/em/ip.awk
View File

@ -1,6 +0,0 @@
BEGIN { printf ".TS\nlw(6) lw(8) rw(3) rw(6) 14 lw(6) lw(8) rw(3) rw(6) 14 lw(6) lw(8) rw(3) rw(6).\n" }
NF == 4 { printf "%s\t%s\t%d\t%d",$1,$2,$3,$4 }
NF == 3 { printf "%s\t%s\t\t%d",$1,$2,$3 }
{ if ( NR%3 == 0 ) printf("\n") ; else printf("\t"); }
END { if ( NR%3 != 0 ) printf("\n")
printf ".TE\n" }

61
doc/em/ispace.nr
View File

@ -1,61 +0,0 @@
.SN 3
.BP
.S1 "INSTRUCTION ADDRESS SPACE"
The instruction space of the EM machine contains
the code for procedures.
Tables necessary for the execution of this code, for example, procedure
descriptor tables, may also be present.
The instruction space does not change during
the execution of a program, so that it may be
protected.
No further restrictions to the instruction address space are
necessary for the abstract and assembly language level.
.P
Each procedure has a single entry point: the first instruction.
A special type of pointer identifies a procedure.
Pointers into the instruction
address space have the same size as pointers into data space and
can, for example, contain the address of the first instruction
or an index in a procedure descriptor table.
.A
There is a single EM program counter, PC, pointing
to the next instruction to be executed.
The procedure pointed to by PC is
called the 'current' procedure.
A procedure may call another procedure using the CAL or CAI
instruction.
The calling procedure remains 'active' and is resumed whenever the called
procedure returns.
Note that a procedure has several 'active' invocations when
called recursively.
.P
Each procedure must return properly.
It is not allowed to fall through to the
code of the next procedure.
There are several ways to exit from a procedure:
.IS 3
.PS
.PT
the RET instruction, which returns to the
calling procedure.
.PT
the RTT instruction, which exits a trap handling routine and resumes
the trapping instruction (see next chapter).
.PT
the GTO instruction, which is used for non-local goto's.
It can remove several frames from the stack and transfer
control to an active procedure.
.PE
.IE
.P
All branch instructions can transfer control
to any label within the same procedure.
Branch instructions can never jump out of a procedure.
.P
Several language implementations use a so called procedure
instance identifier, a combination of a procedure identifier and
the LB of a stack frame, also called static link.
.P
The program text for each procedure, as well as any tables,
are fragments and can be allocated anywhere
in the instruction address space.

2525
doc/em/itables
View File

File diff suppressed because it is too large Load Diff

390
doc/em/mach.nr
View File

@ -1,390 +0,0 @@
.BP
.SN 10
.S1 "EM MACHINE LANGUAGE"
The EM machine language is designed to make program text compact
and to make decoding easy.
Compact program text has many advantages: programs execute faster,
programs occupy less primary and secondary storage and loading
programs into satellite processors is faster.
The decoding of EM machine language is so simple,
that it is feasible to use interpreters as long as EM hardware
machines are not available.
This chapter is irrelevant when back ends are used to
produce executable target machine code.
.S2 "Instruction encoding"
A design goal of EM is to make the
program text as compact as possible.
Decoding must be easy, however.
The encoding is fully byte oriented, without any small bit fields.
There are 256 primary opcodes, two of which are an escape to
two groups of 256 secondary opcodes each.
.A
EM instructions without arguments have a single opcode assigned,
possibly escaped:
.DS
|--------------|
| opcode |
|--------------|
or
|--------------|--------------|
| escape | opcode |
|--------------|--------------|
.DE
The encoding for instructions with an argument is more complex.
Several instructions have an address from the global data area
as argument.
Other instructions have different opcodes for positive
and negative arguments.
.N 1
There is always an opcode that takes the next two bytes as argument,
high byte first:
.DS
|--------------|--------------|--------------|
| opcode | hibyte | lobyte |
|--------------|--------------|--------------|
or
|--------------|--------------|--------------|--------------|
| escape | opcode | hibyte | lobyte |
|--------------|--------------|--------------|--------------|
.DE
.DS
An extra escape is provided for instructions with four or eight byte arguments.
|--------------|--------------|--------------| |--------------|
| ESCAPE | opcode | hibyte |...| lobyte |
|--------------|--------------|--------------| |--------------|
.DE
For most instructions some argument values predominate.
The most frequent combinations of instruction and argument
will be encoded in a single byte, called a mini:
.DS
|---------------|
|opcode+argument| (mini)
|---------------|
.DE
The number of minis is restricted, because only
254 primary opcodes are available.
Many instructions have the bulk of their arguments
fall in the range 0 to 255.
Instructions that address global data have their arguments
distributed over a wider range,
but small values of the high byte are common.
For all these cases there is another encoding
that combines the instruction and the high byte of the argument
into a single opcode.
These opcodes are called shorties.
Shorties may be escaped.
.DS
|--------------|--------------|
| opcode+high | lobyte | (shortie)
|--------------|--------------|
or
|--------------|--------------|--------------|
| escape | opcode+high | lobyte |
|--------------|--------------|--------------|
.DE
Escaped shorties are useless if the normal encoding has a primary opcode.
Note that for some instruction-argument combinations
several different encodings are available.
It is the task of the assembler to select the shortest of these.
The savings by these mini and shortie
opcodes are considerable, about 55%.
.P
Further improvements are possible:
the arguments of
many instructions are a multiple of the wordsize.
Some do also not allow zero as an argument.
If these arguments are divided by the wordsize and,
when zero is not allowed, then decremented by 1, more of them can
be encoded as shortie or mini.
The arguments of some other instructions
rarely or never assume the value 0, but start at 1.
The value 1 is then encoded as 0,
2 as 1 and so on.
.P
Assigning opcodes to instructions by the assembler is completely
table driven.
For details see appendix B.
.S2 "Procedure descriptors"
The procedure identifiers used in the interpreter are indices
into a table of procedure descriptors.
Each descriptor contains:
.IS 6
.PS - 4
.PT 1.
the number of bytes to be reserved for locals at each
invocation.
.N
This is a pointer-szied integer.
.PT 2.
the start address of the procedure
.PE
.IE
.S2 "Load format"
The EM machine language load format defines the interface between
the EM assembler/loader and the EM machine itself.
A load file consists of a header, the program text to be executed,
a description of the global data area and the procedure descriptor table,
in this order.
All integers in the load file are presented with the
least significant byte first.
.P
The header has two parts: the first half (eight 16-bit integers)
aids in selecting
the correct EM machine or interpreter.
Some EM machines, for instance, may have hardware floating point
instructions.
.N
The header entries are as follows (bit 0 is rightmost):
.IS 2
.VS 1 0
.PS 1 4 "" :
.PT
magic number (07255)
.PT
flag bits with the following meaning:
.PS - 7 "" :
.PT bit 0
TEST; test for integer overflow etc.
.PT bit 1
PROFILE; for each source line: count the number of memory
cycles executed.
.PT bit 2
FLOW; for each source line: set a bit in a bit map table if
instructions on that line are executed.
.PT bit 3
COUNT; for each source line: increment a counter if that line
is entered.
.PT bit 4
REALS; set if a program uses floating point instructions.
.PT bit 5
EXTRA; more tests during compiler debugging.
.PE
.PT
number of unresolved references.
.PT
version number; used to detect obsolete EM load files.
.PT
wordsize ; the number of bytes in each machine word.
.PT
pointer size ; the number of bytes available for addressing.
.PT
unused
.PT
unused
.PE
.IE
The second part of the header (eight entries, of pointer size bytes each)
describes the load file itself:
.IS 2
.PS 1 4 "" :
.PT
NTEXT; the program text size in bytes.
.PT
NDATA; the number of load-file descriptors (see below).
.PT
NPROC; the number of entries in the procedure descriptor table.
.PT
ENTRY; procedure number of the procedure to start with.
.PT
NLINE; the maximum source line number.
.PT
SZDATA; the address of the lowest uninitialized data byte.
.PT
unused
.PT
unused
.PE
.IE
.P
The program text consists of NTEXT bytes.
NTEXT is always a multiple of the wordsize.
The first byte of the program text is the
first byte of the instruction address
space, i.e. it has address 0.
Pointers into the program text are found in the procedure descriptor
table where relocation is simple and in the global data area.
The initialization of the global data area allows easy
relocation of pointers into both address spaces.
.P
The global data area is described by the NDATA descriptors.
Each descriptor describes a number of consecutive words (of~wordsize)
and consists of a sequence of bytes.
While reading the descriptors from the load file, one can
initialize the global data area from low to high addresses.
The size of the initialized data area is given by SZDATA,
this number can be used to check the initialization.
.N
The header of each descriptor consists of a byte, describing the type,
and a count.
The number of bytes used for this (unsigned) count depends on the
type of the descriptor and
is either a pointer-sized integer
or one byte.
The meaning of the count depends on the descriptor type.
At load time an interpreter can
perform any conversion deemed necessary, such as
reordering bytes in integers
and pointers and adding base addresses to pointers.
.BP
.A
In the following pictures we show a graphical notation of the
initializers.
The leftmost rectangle represents the leading byte.
.N 1
.DS
.PS - 4 " "
Fields marked with
.N 1
.PT n
contain a pointer-sized integer used as a count
.PT m
contain a one-byte integer used as a count
.PT b
contain a one-byte integer
.PT w
contain a wordsized integer
.PT p
contain a data or instruction pointer
.PT s
contain a null terminated ASCII string
.PE 1
.DE 0
.VS 1 1
.DS
-------------------
| 0 | n | repeat last initialization n times
-------------------
.DE
.DS
---------
| 1 | m | m uninitialized words
---------
.DE
.DS
____________
/ bytes \e
----------------- -----
| 2 | m | b | b |...| b | m initialized bytes
----------------- -----
.DE
.DS
_________
/ word \e
-----------------------
| 3 | m | w |... m initialized wordsized integers
-----------------------
.DE
.DS
_________
/ pointer \e
-----------------------
| 4 | m | p |... m initialized data pointers
-----------------------
.DE
.DS
_________
/ pointer \e
-----------------------
| 5 | m | p |... m initialized instruction pointers
-----------------------
.DE
.DS
____________
/ bytes \e
-------------------------
| 6 | m | b | b |...| b | initialized integer of size m
-------------------------
.DE
.DS
____________
/ bytes \e
-------------------------
| 7 | m | b | b |...| b | initialized unsigned of size m
-------------------------
.DE
.DS
____________
/ string \e
-------------------------
| 8 | m | s | initialized float of size m
-------------------------
.DE 3
.PS - 8
.PT type~0:
If the last initialization initialized k bytes starting
at address \fIa\fP, do the same initialization again n times,
starting at \fIa\fP+k, \fIa\fP+2*k, .... \fIa\fP+n*k.
This is the only descriptor whose starting byte
is followed by an integer with the
size of a
pointer,
in all other descriptors the first byte is followed by a one-byte count.
This descriptor must be preceded by a descriptor of
another type.
.PT type~1:
Reserve m words, not explicitly initialized (BSS and HOL).
.PT type~2:
The m bytes following the descriptor header are
initializers for the next m bytes of the
global data area.
m is divisible by the wordsize.
.PT type~3:
The m words following the header are initializers for the next m words of the
global data area.
.PT type~4:
The m data address space pointers following the header are
initializers for the next
m data pointers in the global data area.
Interpreters that represent EM pointers by
target machine addresses must relocate all data pointers.
.PT type~5:
The m instruction address space pointers following the header are
initializers for the next
m instruction pointers in the global data area.
Interpreters that represent EM instruction pointers by
target machine addresses must relocate these pointers.
.PT type~6:
The m bytes following the header form
a signed integer number with a size of m bytes,
which is an initializer for the next m bytes
of the global data area.
m is governed by the same restrictions as for
transfer of objects to/from memory.
.PT type~7:
The m bytes following the header form
an unsigned integer number with a size of m bytes,
which is an initializer for the next m bytes
of the global data area.
m is governed by the same restrictions as for
transfer of objects to/from memory.
.PT type~8:
The header is followed by an ASCII string, null terminated, to
initialize, in global data,
a floating point number with a size of m bytes.
m is governed by the same restrictions as for
transfer of objects to/from memory.
The ASCII string contains the notation of a real as used in the
Pascal language.
.PE
.P
The NPROC procedure descriptors on the load file consist of
an instruction space address (of~pointer~size) and
an integer (of~pointer~size) specifying the number of bytes for
locals.

16
doc/em/macr.nr
View File

@ -1,16 +0,0 @@
.so /usr/lib/tmac/tmac.kun
.SS 6
.RP
.PL 12i 11i
.LL 89
.MS T E
\!.TL '%'''
.ME
.MS T O
\!.TL '''%'
.ME
.MS B
.sp 1
.ME
.SM S1 B
.SM S2 B

245
doc/em/mapping.nr
View File

@ -1,245 +0,0 @@
.SN 5
.BP
.S1 "MAPPING OF EM DATA MEMORY ONTO TARGET MACHINE MEMORY"
The EM architecture is designed to be implemented
on many existing and future machines.
EM memory is highly fragmented to make
adaptation to various memory architectures possible.
Format and encoding of pointers is explicitly undefined.
.P
This chapter gives solutions to some of the
anticipated problems.
First, we describe a possible memory layout for machines
with 64K bytes of address space.
Here we use a member of the EM family with 2-byte word and pointer
size.
The most straightforward layout is shown in figure 2.
.N 1
.DS
65534 -> |-------------------------------|
|///////////////////////////////|
|//// unimplemented memory /////|
|///////////////////////////////|
ML -> |-------------------------------|
| |
| | <- LB
| stack and local area |
| |
|-------------------------------| <- SP
|///////////////////////////////|
|//////// inaccessible /////////|
|///////////////////////////////|
|-------------------------------| <- HP
| |
| heap area |
| |
| |
HB -> |-------------------------------|
| |
| global data area |
| |
EB -> |-------------------------------|
| |
| program text | <- PC
| |
| ( and tables ) |
| |
| |
PB -> |-------------------------------|
|///////////////////////////////|
|////////// undefined //////////|
|///////////////////////////////|
0 -> |-------------------------------|
Figure 2. Memory layout showing typical register
positions during execution of an EM program.
.DE 2
The base registers for the various memory pieces can be stored
in target machine registers or memory.
.IS
.N 1
.TS
tab(;);
l 1 l l l.
PB;:;program base;points to the base of the instruction address space.
EB;:;external base;points to the base of the data address space.
HB;:;heap base;points to the base of the heap area.
ML;:;memory limit;marks the high end of the addressable data space.
.TE 1
.IE
The stack grows from high
EM addresses to low EM addresses, and the heap the
other way.
The memory between SP and HP is not accessible,
but may be allocated later to the stack or the heap if needed.
The local data area is allocated starting at the high end of
memory.
.P
Because EM address 0 is not mapped onto target
address 0, a problem arises when pointers are used.
If a program pushed a constant, say 6, onto the stack,
and then tried to indirect through it,
the wrong word would be fetched,
because EM address 6 is mapped onto target address EB+6
and not target address 6 itself.
This particular problem is solved by explicitly declaring
the format of a pointer to be undefined,
so that using a constant as a pointer is completely illegal.
However, the general problem of mapping pointers still exists.
.P
There are two possible solutions.
In the first solution, EM pointers are represented
in the target machine as true EM addresses,
for example, a pointer to EM address 6 really is
stored as a 6 in the target machine.
This solution implies that every time a pointer is fetched
EB must be added before referencing
the target machine's memory.
If the target machine has powerful indexing
facilities, EB can be kept in a target machine register,
and the relocation can indeed be done on
every reference to the data address space
at a modest cost in speed.
.P
The other solution consists of having EM pointers
refer to the true target machine address.
Thus the instruction LAE 6 (Load Address of External 6)
would push the value of EB+6 onto the stack.
When this approach is chosen, back ends must know
how to offset from EB, to translate all
instructions that manipulate EM addresses.
However, the problem is not completely solved,
because a front end may have to initialize a pointer
in CON or ROM data to point to a global address.
This pointer must also be relocated by the back end or the interpreter.
.P
Although the EM stack grows from high to low EM addresses,
some machines have hardware PUSH and POP
instructions that require the stack to grow upwards.
If reasons of efficiency urge you to use these
instructions, then EM
can be implemented with the memory layout
upside down, as shown in figure 3.
This is possible because the pointer format is explicitly undefined.
The first element of a word array will have a
lower physical address than the second element.
.N 2
.DS
| | | |
| EB=60 | | ^ |
| | | | |
|-----------------| |-----------------|
105 | 45 | 44 | 104 214 | 41 | 40 | 215
|-----------------| |-----------------|
103 | 43 | 42 | 102 212 | 43 | 42 | 213
|-----------------| |-----------------|
101 | 41 | 40 | 100 210 | 45 | 44 | 211
|-----------------| |-----------------|
| | | | |
| v | | EB=255 |
| | | |
Type A Type B
.sp 2
Figure 3. Two possible memory implementations.
Numbers within the boxes are EM addresses.
The other numbers are physical addresses.
.DE 2
.A 0 0
So, we have two different EM memory implementations:
.IS
.PS - 4
.PT A~-
stack downwards
.PT B~-
stack upwards
.PE
.IE
.P
For each of these two possibilities we give the translation of
the EM instructions to push the third byte of a global data
block starting at EM address 40 onto the stack and to load the
word at address 40.
All translations assume a word and pointer size of two bytes.
The target machine used is a PDP-11 augmented with push and pop instructions.
Registers 'r0' and 'r1' are used and suffer from sign extension for byte
transfers.
Push $40 means push the constant 40, not word 40.
.P
The translation of the EM instructions depends on the pointer representation
used.
For each of the two solutions explained above the translation is given.
.P
First, the translation for the two implementations using EM addresses as
pointer representation:
.DS
.TS
tab(:), center;
l s l s l s
_ s _ s _ s
l 2 l 6 l 2 l 6 l 2 l.
EM:type A:type B
LAE:40:push:$40:push:$40
ADP:3:pop:r0:pop:r0
::add:$3,r0:add:$3,r0
::push:r0:push:r0
LOI:1:pop:r0:pop:r0
::-::neg:r0
::clr:r1:clr:r1
::bisb:eb(r0),r1:bisb:eb(r0),r1
::push:r1:push:r1
LOE:40:push:eb+40:push:eb-41
.TE
.DE
.BP
.P
The translation for the two implementations, if the target machine address is
used as pointer representation, is:
.N 1
.DS
.TS
tab(:), center;
l s l s l s
_ s _ s _ s
l 2 l 6 l 2 l 6 l 2 l.
EM:type A:type B
LAE:40:push:$eb+40:push:$eb-40
ADP:3:pop:r0:pop:r0
::add:$3,r0:sub:$3,r0
::push:r0:push:r0
LOI:1:pop:r0:pop:r0
::clr:r1:clr:r1
::bisb:(r0),r1:bisb:(r0),r1
::push:r1:push:r1
LOE:40:push:eb+40:push:eb-41
.TE
.DE
.P
The translation presented above is not intended to be optimal.
Most machines can handle these simple cases in one or two instructions.
It demonstrates, however, the flexibility of the EM design.
.P
There are several possibilities to implement EM on machines with
address spaces larger than 64k bytes.
For EM with two byte pointers one could allocate instruction and
data space each in a separate 64k piece of memory.
EM pointers still have to fit in two bytes,
but the base registers PB and EB may be loaded in hardware registers
wider than 16 bits, if available.
EM implementations can also make efficient use of a machine
with separate instruction and data space.
.P
EM with 32 bit pointers allows one to make use of machines
with large address spaces.
In a virtual, segmented memory system one could use a separate
segment for each fragment.

80
doc/em/mem.nr
View File

@ -1,80 +0,0 @@
.BP
.SN 2
.S1 MEMORY
The EM machine has two distinct address spaces,
one for instructions and one for data.
The data space is divided up into 8-bit bytes.
The smallest addressable unit is a byte.
Bytes are numbered consecutively from 0 to some maximum.
All sizes in EM are expressed in bytes.
.P
Some EM instructions can transfer objects containing several bytes
to and/or from memory.
The size of all objects larger than a word must be a multiple of
the wordsize.
The size of all objects smaller than a word must be a divisor
of the wordsize.
For example: if the wordsize is 2 bytes, objects of the sizes 1,
2, 4, 6,... are allowed.
The address of such an object is the lowest address of all bytes it contains.
For objects smaller than the wordsize, the
address must be a multiple of the object size.
For all other objects the address must be a multiple of the
wordsize.
For example, if an instruction transfers a 4-byte object to memory at
location \fIm\fP and the wordsize is 2,
\fIm\fP must be a multiple of 2 and the bytes at
locations \fIm\fP, \fIm\fP\|+\|1,\fIm\fP\|+\|2 and
\fIm\fP\|+\|3 are overwritten.
.P
The size of almost all objects in EM
is an integral number of words.
Only two operations are allowed on
objects whose size is a divisor of the wordsize:
push it onto the stack and pop it from the stack.
The addressing of these objects in memory is always indirect.
If such a small object is pushed onto the stack
it is assumed to be a small integer and stored
in the least significant part of a word.
The rest of the word is cleared to zero,
although
EM provides a way to sign-extend a small integer.
Popping a small object from the stack removes a word
from the stack, stores the least significant byte(s)
of this word in memory and discards the rest of the word.
.P
The format of pointers into both address spaces is explicitly undefined.
The size of a pointer, however, is fixed for a member of EM, so that
the compiler writer knows how much storage to allocate for a pointer.
.P
A minor problem is raised by the undefined pointer format.
Some languages, notably Pascal, require a special,
otherwise illegal, pointer value to represent the nil pointer.
The current Pascal-VU compiler uses the
integer value 0 as nil pointer.
This value is also used by many C programs as a normally impossible address.
A better solution would be to have a special
instruction loading an illegal pointer value,
but it is hard to imagine an implementation
for which the current solution is inadequate,
especially because the first word in the EM data space
is special and probably not the target of any pointer.
.P
The next two chapters describe the EM memory
in more detail.
One describes the instruction address space,
the other the data address space.
.P
A design goal of EM has been to allow
its implementation on a wide range of existing machines,
as well as allowing a new one to be built in hardware.
To this extent we have tried to minimize the demands
of EM on the memory structure of the target machine.
Therefore, apart from the logical partitioning,
EM memory is divided into 'fragments'.
A fragment consists of consecutive machine
words and has a base address and a size.
Pointer arithmetic is only defined within a fragment.
The only exception to this rule is comparison with the null
pointer.
All fragments must be word aligned.

5
doc/em/print
View File

@ -1,5 +0,0 @@
case $# in
1) make "$1".t ; ntlp "$1".t^lpr ;;
*) echo $0 heeft een argument nodig ;;
esac

4
doc/em/show
View File

@ -1,4 +0,0 @@
case $# in
1) make $1.t ; ntout $1.t ;;
*) echo $0 heeft een argument nodig ;;
esac

38
doc/em/title.nr
View File

@ -1,38 +0,0 @@
.po 0
.TP 1
.ll 79
.sp 15
.ce 4
DESCRIPTION OF A MACHINE
ARCHITECTURE FOR USE WITH
BLOCK STRUCTURED LANGUAGES
.sp 6
.ce 4
Andrew S. Tanenbaum
Hans van Staveren
Ed G. Keizer
Johan W. Stevenson\v'-0.5m'*\v'0.5m'
.sp 2
.ce
August 1983
.sp 2
.ce
Informatica Rapport IR-81
.sp 13
Abstract
.sp 2
.ti +5
EM is a family of intermediate languages
designed for producing portable compilers.
A program called
.B front end
translates source programs to EM.
Another program,
.B back
.BW end ,
translates EM to the assembly language of the target machine.
Alternatively, the EM program can be assembled to a highly
efficient binary format for interpretation.
This document describes the EM languages in detail.
.sp 4
\v'-0.5m'*\v'0.5m' Present affiliation: NV Philips, Eindhoven

130
doc/em/types.nr
View File

@ -1,130 +0,0 @@
.SN 6
.BP
.S1 "TYPE REPRESENTATIONS"
The representations used for typed objects are not precisely
specified by EM.
Sometimes we only specify that a typed object occupies a
certain amount of space and state no further restrictions.
If one wants to have a different representation of the value of
an object on the stack one has to use a convert instruction
in most cases.
We do specify some relations between the representations of
types.
This allows some intermixed use of operators for different types
on the same object(s).
For example, the instruction ZER pushes signed and
unsigned integers with the value zero and empty sets.
ZER has as only argument the size of the object.
.A
The representation of floating point numbers is a good example,
it allows widely varying implementations.
The only ways to create floating point numbers are via
initialization and via conversions from integer numbers.
Only by using conversions to integers and comparing
two floating point numbers with each other, can these numbers
be converted to human readable output.
Implementations may use base 10, base 2 or any other
base for exponents, and have freedom in choosing the range of
exponent and mantissa.
.A
Other types are more precisely described.
In the following paragraphs a description will be given of the
restrictions imposed on the representation of the types used.
A number \fBn\fP used in these paragraphs indicates the size of
the object in \fIbits\fP.
.S2 "Unsigned integers"
The range of unsigned integers is 0..2\v'-0.5m'\fBn\fP\v'0.5m'-1.
A binary representation is assumed.
The order of the bits within an object is knowingly left
unspecified.
Discussing bit order within each 8-bit byte is academic,
so the only real freedom of this specification lies in the byte
order.
We really do not care whether an implementation of a 4-byte
integer has its bytes in a particular order of significance.
This of course means that some sequences of instructions have
unpredictable effects.
For example:
.DS
LOC 258 ; STL 0 ; LAL 0 ; LOI 1 ( wordsize >=2 )
.DE
The value on the stack after executing this sequence
can be anything,
but will most likely be 1 or 2.
.A
Conversion between unsigned integers of different sizes have to
be done with explicit convert instructions.
One cannot simply pad an unsigned integer with zero's at either end
and expect a correct result.
.A
We assume existence of at least single word unsigned arithmetic
in any implementation.
.S2 "Signed Integers"
The range of signed integers is -2\v'-0.5m'\fBn\fP-1\v'0.5m'~..~2\v'-0.5m'\fBn\fP-1\v'0.5m'-1,
in other words the range of signed integers of \fBn\fP bits
using two's complement arithmetic.
The representation is the same as for unsigned integers except
the range 2\v'-0.5m'\fBn\fP-1\v'0.5m'~..~2\v'-0.5m'\fBn\fP\v'0.5m'-1 is mapped on the
range -2\v'-0.5m'\fBn\fP-1\v'0.5m'~..~-1.
In other words, the most significant bit is used as sign bit.
The convert instructions between signed and unsigned integers
of the same size can be used to catch errors.
.A
The value -2\v'-0.5m'\fBn\fP-1\v'0.5m' is used for undefined
signed integers.
EM implementations should trap when this value is used in an
operation on signed integers.
The instruction mask, accessed with SIM and LIM -~see chapter 9~- ,
can be used to disable such traps.
.A
We assume existence of at least single word signed arithmetic
in any implementation.
.BP
.S2 "Floating point values"
Floating point values must have a signed mantissa and a signed
exponent.
Although no base is specified, base 2 is the normal choice,
because the FEF instruction pushes the exponent in base 2.
.A
The implementation of floating point arithmetic is optional.
The compilers currently in use have runtime parameters for the
size of the floating point values they should use.
Common choices are 4 and/or 8 bytes.
.S2 Pointers
EM has two kinds of pointers: for instruction and for data
space.
Each kind can only be used for its own space, conversion between
these two subtypes is impossible.
We assume that pointers have a range from 0 upwards.
Any implementation may have holes in the pointer range between
fragments.
One can of course not expect to be able to address two megabyte
of memory using a 2-byte pointer.
Normally, a 2-byte pointer allows up to 65536 bytes of
addressable memory.
.A
Pointer representation has one restriction.
The pointer with the same representation as the integer zero of
the same size should be invalid.
Some languages and/or runtime systems represent the nil
pointer as zero.
.S2 "Bit sets"
All bit sets of size \fBn\fP are subsets of the set
{~i~|~i>=0,~i<\fBn\fP~}.
A bit set contains a bit for each element showing its
presence or absence.
Bit sets are subdivided into words.
The word with the lowest EM address governs the subset
{~i~|~i>=0,~i<\fBm\fP~}, where \fBm\fP is the number of bits in
a word.
The next higher words each govern the next higher \fBm\fP set elements.
The relation between a set with size of
a word and an unsigned integer word is that
the value of the unsigned integer is the summation of the
2\v'-0.5m'i\v'0.5m' where i is in the set.
.A
Example: a 2-word bit set (wordsize 2) containing the
elements 1, 6, 8, 15, 18, 21, 27 and 28 is composed of two
integers, e.g. at addresses 40 and 42.
The word at 40 contains the value 33090 (or~-32446),
the word at 42 contains the value 6180.

621
doc/install.doc
View File

@ -1,621 +0,0 @@
.\" $Header$
.nr LL 7.5i
.nr PD 1v
.TL
Amsterdam Compiler Kit installation guide
.AU
Ed Keizer
.AI
Wiskundig Seminarium
Vrije Universiteit
Amsterdam
.NH
Introduction
.PP
This document
describes the process of installing Amsterdam Compiler Kit.
It depends on your combination of hard- and software how
hard it will be to install the kit.
This description is intended for a PDP 11/44 running
.UX
Version 7.
Installation on other PDP 11's should be easy, as long
as they have separate instruction and data space.
Installation on machine's without this feature, like PDP 11/34,
PDP 11/60 requires extensive surgery on some programs and is
thought of as impossible.
See chapter 6 for installation on other systems.
.NH
Restoring tree
.PP
The process of installing Amsterdam Compiler Kit is quite simple.
It is important that the original Amsterdam Compiler Kit
distribution tree structure is restored.
Proceed as follows
.IP " -" 10
Create a directory, for example /usr/em, on a device
with at least 20000 blocks left.
.IP " -"
Change to that directory (cd ...); it will be the working directory.
.IP " -"
Extract all files from the distribution medium, for instance
magtape:
\fBtar x\fP.
.IP " -"
Keep a copy of the original distribution to be able to repeat the process
of installation in case of disasters.
This copy is also useful as a reference point for diff-listings.
.LP
The directories in the tree contain the following information:
.nr PD 1v
.IP "lib" 14
.br
almost all binaries and shell files used by commands and
library em_data.a from misc/data
.IP "lib/ack"
.br
The command descriptor files used by the program ack.
.nr PD 0
.IP "bin"
.br
the few utilities that knot things together
.IP "etc"
.br
The MAIN description of EM sits here.
contains files (e.g. em_table) describing
the opcodes and pseudos in use,
the operands allowed, effect in stack etc. etc.
Make in this directory creates most of the files in h
.IP "include"
.br
More or less system independent include files needed by modules
in the C library from lang/cem/libcc.
Especially needed for "stdio".
.IP "h"
.br
The #include files for:
.nf
as_spec.h Used by EM assembler and interpreters.
em_abs.h Contains trap numbers and address for lin and fil
em_flag.h Definition of bits in array em_flag in lib/em_data.a
Describes parameters effect on flow of instructions
em_mes.h Definition of names for mes pseudo numbers
em_mnem.h instruction => compact mapping.
em_pseu.h pseudo instruction => compact mapping
em_ptyp.h Useful for compact code reading/writing,
defines classes of parameters
em_spec.h Definition of constants used in compact code
local.h Various definitions for local versions
pc_err.h Definitions of error numbers in Pascal
pc_file.h Macro's used in file handling in Pascal
em_path.h Pathnames used by \fIack\fP, intended
for all utilities
pc_size.h Sizes of objects used by Pascal compiler and
run-time system.
em_reg.h Definition of names for register types.
.IP "doc"
.br
Documentation
.nf
cg.doc Use and internal specification of the backend.
.br
regadd.doc Update for cg.doc concerning register variables
.br
regadd.doc Description of steps to add register variables.
.br
ack.doc Layout of description files needed for each machine.
.br
cref.doc C reference manual, addendum
.br
install.doc Ack Installation Guide
.br
pcref.doc Pascal reference manual, addendum
.br
peep.doc Description of the peephole optimizer
.br
em.doc EM reference manual
.br
toolkit.doc A general overview of the toolkit
.br
v7bugs.doc Bugs in the standard V7 system
.br
val.doc Pascal validation suite version 3 report
.nf
.IP "doc/em.doc"
.br
The EM-manual IR-81
.IP "doc/em.doc/int"
.br
The EM interpreter written in pascal
.IP "mkun"
.br
The PUBMAC macro package for nroff/troff from the Katholieke Universiteit at
Nijmegen.
It is used for the EM reference manual,
the Makefile installs the macro package in
/usr/lib/tmac/tmac.mkun*.
This package is in the public domain.
.IP "mach"
.br
just there to group the directories for all machines
these directories have sub-directories named:
.nf
as the assembler ( *.s + libraries => a.out )
cg the new backend ( *.m => *.s )
lib the libraries for all run-time systems
these libraries are used by the assembler.
libpc Used to create Pascal run-time system in 'lib'
libcc Used to create C run-time system in 'lib'
libem Sources for EM runtime system, result sits in 'lib'
test Various tests
dl Down-load programs
int Source for an interpreter
available are:
PMDS II 68000, wordsize 2, ptrsize 4
mach/m68k2
mach/m68k2/as
mach/m68k2/cg
mach/m68k2/libem
mach/m68k2/lib
mach/m68k2/dl
mach/m68k2/libpc
mach/m68k2/libcc
mach/m68k2/libsys
bare 6809
mach/6809
mach/6809/as
8080, wordsize 2, ptrsize 2
mach/8080
mach/8080/as
mach/8080/test
mach/8080/libcc
mach/8080/lib
bare 8086, wordsize 2, ptrsize 2
mach/i86
mach/i86/as
mach/i86/lib
mach/i86/libcc
mach/i86/dl
mach/i86/libem
mach/i86/libpc
mach/i86/saio (library for stand-alone EM on 86/12A )
pdp 11, UNIX/V7, wordsize 2, ptrsize 2
mach/pdp
mach/pdp/test
mach/pdp/libem
mach/pdp/lib
mach/pdp/libcc
mach/pdp/libpc
mach/pdp/cg
mach/pdp/int -PDP 11/44 EM interpreter
vax 780, UNIX V7, wordsize 4, ptrsize 4
mach/vax4
mach/vax4/cg
mach/vax4/lib
mach/vax4/libcc
mach/vax4/libem
mach/vax4/libpc
z80, CP/M, wordsize 2, ptrsize 2
mach/z80
mach/z80/as
mach/z80/libem
mach/z80/lib
mach/z80/libcc
mach/z80/libpc
mach/z80/int -Z80 EM interpreter
z80, nascom
mach/z80a
mach/z80a/dl
vax 11/780, Berkeley UNIX, wordsize 2, ptrsize 4
mach/vax2
mach/vax2/cg
mach/vax2/lib
mach/vax2/libpc
mach/vax2/libem
bare 6500, wordsize 2, ptrsize 2
mach/6500
mach/6500/as
mach/6500/dl
mach/6500/libem
mach/6500/lib
bare 6800, wordsize 2, ptrsize 2
mach/6800
mach/6800/as
EM virtual machine code, wordsize 2, ptrsize 2
mach/int
mach/int/libcc
mach/int/libpc
mach/int/lib
mach/int/test
The directory proto contains files used by most machines.
e.g. makefiles for libraries for C and Pascal
mach/proto
mach/proto/libg
.fi
.IP "emtest"
.br
Contains prototype of em test set.
.IP "man"
.br
Man files for various utilities
.IP "lang"
.br
just there to group the directories for all front-ends
.IP "lang/pc"
.br
Pascal front-end
.IP "lang/pc/libpc"
.br
Source of Pascal run-time system ( in EM or C )
.IP "lang/pc/test"
.br
Some test programs written in Pascal
.IP "lang/pc/pem"
.br
The compiler proper
.IP "lang/cem"
.br
C front-end
.IP "lang/cem/libcc"
.br
Directories with sources of C runtime system, libraries (in EM or C)
.IP "lang/cem/libcc/gen"
.br
Sources for routines in chapter III of UNIX programmers manual,
excluding STDIO
.IP "lang/cem/libcc/stdio"
.br
STDIO sources
.IP "lang/cem/libcc/mon"
.br
Sources for routines in chapter II, written in EM
.IP "lang/cem/comp"
.br
The compiler proper
.IP "lang/cem/ctest"
.br
C test set
.IP "lang/cem/ctest/cterr"
.br
Programs developed for pinpointing previous errors
.IP "lang/cem/ctest/ct*"
.br
The test programs.
.IP "util"
.br
Contains directories with various utilities
.IP "util/opt"
.br
EM peephole optimizer (*.k => *.m)
.IP "util/misc"
.br
Decode (*.[km] => *.e) + encode (*.e => *.k)
.IP "util/data"
.br
The C-code for `lib/em_data.a`
These sources are created by the Makefile in `etc`
.IP "util/ass"
.br
The EM assembler ( *.[km] + libraries => e.out )
.IP "util/arch"
.br
The archiver to be used for ALL EM utilities
.IP "util/cgg"
.br
A program needed for compiling backends.
.IP "util/cpp"
.br
The V7 C preprocessor.
.LP
All pathnames mentioned in the text of this document are relative to the
working directory, unless they start with '/'.
.PP
The person doing the installation needs permission to write in the
directories of the Amsterdam Compiler Kit distribution tree.
Preferably you should log in as sys (uid=3,gid=0).
.NH
Pathnames
.PP
Absolute pathnames are concentrated in "h/em_path.h".
Only the pascal runtime system and the utility \fIack\fP use
absolute pathnames to access files in the kit.
The tree is distributed with /usr/em as the working
directory.
The definition of EM_DIR in em_path.h should be altered to
specify the root
directory for the Compiler Kit distribution on your system.
Em_path.h also specifies which directory should be used for
temporary files.
Most programs from the kit do indeed use that directory
although some remain stubborn and use /tmp or /usr/tmp.
.LP
The shape of the tree should not be altered lightly because
most Makefiles and the
utility \fIack\fP know the shape of the ACK tree.
All pathnames in all Makefiles are relative, that is do not
have "/" as the first character.
The knowledge of the utility \fIack\fP about the shape of the tree is
concentrated in the files in the directory lib/ack.
.NH
Commands
.PP
The kit is distributed with all available commands in the bin
directory.
The commands distributed are:
.IP "\fIack\fP, \fIacc\fP, \fIapc\fP and their links"
.br
They are used to compile the Pascal, C, etc... programs.
.IP \fIarch\fP
.br
The archiver used for the EM- and universal assembler.
.IP "\fIem\fP and \fIeminform\fP"
.br
The EM interpretator for the PDP-11 and the program to unravel
its post-mortem information.
.LP
We currently make the kit available to our users by telling
them that they should include the bin directory of the kit in
their PATH shell variable.
The programs will still work when moved to a different
directory.
The copying should preferably be done with tar, since links are
heavily used.
Renaming of the programs linked to \fIack\fP will not always
produce the desired result.
This program uses its call name as an argument.
Any call name not being \fIcc\fP, \fIacc\fP, \fIpc\fP or \fIapc\fP will be
interpreted as the name of a 'machine description' and the
program will try to find a description file with that name.
All recompilations will only touch the utilities in the bin
directory, not your own copies.
.NH
Options
.PP
There is one important option in h/local.h.
The utility \fIack\fP uses a default machine name when called
as \fIacc\fP, \fIcc\fP, \fIapc\fP, \fIpc\fP or \fIack\fP.
The machine name used for default is determined by the
definition of ACKM in h/local.h.
The current definition is \fIpdp\fP.
.PP
The distribution is tailored to one specific opreating system per CPU type.
For some of these CPU's it is possible to tailor the distribution to another
operating system.
The steps to be taken are described in READ_ME (or README) files in the
subdirectories of the directory in EM_DIR/mach for that particular machine.
For example: The vax2 distribution is tailoerd to BSD4.1, but has #define's
for BSD4.1c and BSD4.2.
For the names and places of these define's look in EM_DIR/mach/vax2/cg and
EM_DIR/mach/vax2/libem.
.NH
Recompilation
.PP
The kit comes with binaries in the directories \fBbin\fP and
\fBlib\fP.
Some directories among mach/*/lib contain archives with object files,
notably mach/pdp/lib.
The binaries and object files are for a PDP 11/44 with floating
point running UNIX V7.
.PP
Almost all directories contain a "Makefile" or a shell command file called
"make".
Apart from commands applying to that specific directory these
files all recognize a few special commands.
When called with one of these they will apply the command to
their own directory and all subdirectories.
The special commands are:
.IP "install" 20
recompile and install all binaries and libraries.
.br
Some Makefiles allow errors to occur in the programs they call.
They ignore such errors and notify the user with the message
"~....... error code n: ignored".
Whenever such a message appears in the output you can ignore it
too.
.br
The installation of the PUBMAC macro package is not done
automatically from the higher level directory.
.IP "cmp"
recompile all binaries and libraries and compare them to the
ones already installed.
.IP pr
print the sources and documentation on the standard output.
.IP opr
make pr | opr
.br
Opr should be an off-line printer daemon.
On some systems it exists under another name e.g. lpr.
The easiest way to call such a spooler is using a shell script
with the name opr that calls lpr.
This script should be placed in /usr/bin or EM_DIR/bin or
one of the directories in your PATH.
.IP clean
remove all files not needed for day-to-day use,
that is binaries not in bin or lib, object files etc.
.LP
Example:
.nf
.sp 1
make install
.sp 1
.fi
given as command in the home directory will cause
recompilation of all programs in the kit.
.LP
Recompilation of the complete kit lasts about 9 hours an a PDP
11/44.
.NH 2
Recompilation on a different machine.
.PP
Installation on other systems will often require recompilation
of all programs.
The presence of a C compiler is essential for recompilation.
Except the Pascal compiler proper all programs are written in C.
Some modules are derived from \fIyacc\fP sources.
Retranslating these programs from that yacc source is not
necessary, although it might improve performance.
Some versions of \fIyacc\fP 'know' that the resulting C programs will
run on a 32-bit int machine.
C modules produced by such a \fIyacc\fP are not portable and
should not be used to (cross)compile programs for 16-bit machines.
We assume a version UNIX which, apart from the C-compiler,
contains most normal utilities, like ed, sed, grep, make, the
Bourne shell etc.
All Makefiles use the system C-compiler.
The existence of a backend for your system is of course essential
if you wish to produce executable files for that system.
When the backend exists it is also possible to boot the Pascal
Compiler,
that is written in Pascal itself.
The kit contains the compact code files for the 2/2 and 2/4
versions of the Pascal compiler.
The current version of this compiler can only be used on machines
with a 16-bit word size and 16- or 32-bit pointers.
The Makefile automatically tries to boot the Pascal compiler
from one of these compact code files, if the compiler proves
unable to compile itself.
.PP
The native assemblers and loaders are used on PDP-11 and VAX.
The description files in lib/ack for other systems use our
universal assembler.
The load file produced by this assembler is not directly
usable in any system known to us,
but has to be converted before it can be put to use.
The \fIdl\fP programs present for some machines unravel
these load files and transmit commands to load memory
to a microprocessor over a serial line.
The PDP-11 version of our universal assembler is supplied
with a conversion program.
The file man/a.out.5 contains a description of the format of
the universal assembler load file,
it might be useful to those who wish or need to write their
own conversion programs.
.br
Berkeley UNIX for the VAX'en has (at least) three different
versions, BSD4.1a, BSD4.1c and BSD4.2. The READ_ME files in the
directories mach/vax2/cg, mach/vax2/libem, mach/vax4/cg and
mach/vax4/libem tell you how to adapt the vax2 and vax4 backend
to these versions.
.NH 2
Recompiling libraries
.PP
The kit contains sources for part II and III of the C-library, except
the math functions, they are grabbed from our V7 system and sometimes
altered in a EM dependent way or replaced altogether when the original
was in assembly.
These files can be used to make libraries for the Ack C-compiler.
The recompilation process uses a few include files.
The include directory in the EM home directory contains a few more
or less system independent include files.
The system dependent include files are fetched from /usr/include
on the system you use to recompile.
This may lead to several problems.
Sometimes the system differs so much from V7 that certain manifest constants
do not exist any more.
At other times these include files were written for a compiler without
a restriction on name length.
In that case - I've seen it happen - people tend to use differing
identifiers that are identical in the first eight characters.
All these problems you have to solve yourself,
the libraries are only included as an extra and too much system
dependent to give any guarantees.
.NH
Fixes to the UNIX V7 system
.PP
UNIX System V7 has a few bugs that prevent a part of or the whole kit
from working properly.
To be honest, we do not know which of the following changes are
essential to the functioning of our kit.
.PP
The file "doc/v7bugs.doc" gives for each of the following bugs
a small test program and a diff listing of the source files that have to be
modified.
.IP 1
Bug in the C optimizer for unsigned comparison
.nr PD 0
.IP 2
The loader 'ld' fails for large data and text portions
.IP 3
Floating point registers are not saved if more memory is needed.
.IP 4
Floating point registers are not copied to child in fork().
.nr PD 1v
.LP
Use the test programs to see if the errors are present in your system
and to check if the modifications are effective.
.NH
Testing
.PP
Test sets are available in Pascal, C and EM assembly.
.IP em 8
.br
The directory emtest contains a few EM test programs.
The EM assembly files in these tests must be transformed into
load files, thereby avoiding use of the EM optimizer.
These tests use the LIN and NOP instructions to mark the passing of each
test.
The NOP instruction prints the current line number during the
test phase.
Each test notifies its correctness by calling LIN with a unique
number followed by a NOP which prints this line number.
The test finishes normally with 0 as the last number printed
In all other cases a bug showed its
existence.
.IP Pascal
.br
The directory lang/pc/test contains a few pascal test programs.
All these programs print the number of errors found and a
identification of these errors.
.IP C
.br
The sub-directories in lang/cem/ctest contain C test programs.
The idea behind these tests is:
when you have a program called xx.c, compile it into xx.cem.
Run it with standard output to xx.cem.r, compare this file to
xx.cem.g, a file containing the 'ideal' output.
Any differences will point to implementation differences or
bugs.
Giving the command "run gen" or plain "run" starts this
process.
The differences will be presented on standard output.
The contents of the result files depend on the wordsize,
the xx.cem.g files on the distribution are intended for a
16-bit machine.
.NH
Documentation
.PP
Manual pages for Amsterdam Compiler Kit can be copied
to "/usr/man/man?" by the
following commands:
.DS
cd man
make install
.DE
.LP
Several documents are provided:
.DS
doc/toolkit.doc: a general overview
doc/pcref.doc: the Pascal-frontend reference manual
doc/val.doc: the results of running the Pascal Validation Suite
doc/cref.doc: the C-frontend manual
doc/em.doc: a description of the EM machine architecture
doc/peep.doc: internal documentation for the peephole optimizer
doc/cg.doc: documentation for backend writers and maintainers
doc/regadd.doc: addendum to previous document describing register variables
doc/install.doc: this document
.DE
.LP
The Validation Suite is a collection of more than 200 Pascal programs,
designed by Brian Wichmann and Arthur Sale to test Pascal compilers.
We are not allowed to distribute it, but you may
request a copy from
.DS
Richard J. Cichelli
A.N.P.A.
1350 Sullivan Trail
P.O. Box 598
Easton, Pennsylvania 18042
USA
.DE
.LP
Good luck.

1512
doc/pcref.doc
View File

File diff suppressed because it is too large Load Diff

506
doc/peep.doc
View File

@ -1,506 +0,0 @@
.\" $Header$
.TL
Internal documentation on the peephole optimizer
.br
from the Amsterdam Compiler Kit
.NH 1
Introduction
.PP
Part of the Amsterdam Compiler Kit is a program to do
peephole optimization on an EM program.
The optimizer scans the program to match patterns from a table
and if found makes the optimization from the table,
and with the result of the optimization
it tries to find yet another optimization
continuing until no more optimizations are found.
.PP
Furthermore it does some optimizations that can not be called
peephole optimizations for historical reasons,
like branch chaining and the deletion of unreachable code.
.PP
The peephole optimizer consists of three parts
.IP 1)
A driving table
.IP 2)
A program translating the table to internal format
.IP 3)
C code compiled with the table to make the optimizer proper
.PP
In this document the table format, internal format and
data structures in the optimizer will be explained,
plus a hint on what the code does where it might not be obvious.
It is a simple program mostly.
.NH 1
Table format
.PP
The driving table consists of pattern/replacement pairs,
in principle one per line,
although a line starting with white space is considered
a continuation line for the previous.
The general format is:
.DS
optimization : pattern ':' replacement '\en'
.sp
pattern : EMlist optional_boolean_expression
.sp
replacement : EM_plus_operand_list
.DE
Example of a simple one
.DS
loc stl $1==0 : zrl $2
.DE
There is no real limit for the length of the pattern or the replacement,
the replacement might even be longer than the pattern,
and expressions can be made arbitrarily complicated.
.PP
The expressions in the table are made of the following pieces:
.IP -
Integer constants
.IP -
$\fIn\fP, standing for the operand of the \fIn\fP'th EM
instruction in the pattern,
undefined if that instruction has no operand.
.IP -
w, standing for the wordsize of the code optimized.
.IP -
p, for the pointersize.
.IP -
defined(expr), true if expression is defined
.IP -
samesign(expr,expr), true if expressions have the same sign.
.IP -
sfit(expr,expr), ufit(expr,expr),
true if the first expression fits signed or unsigned in the number
of bits given in the second expression.
.IP -
rotate(expr,expr),
first expression rotated left the number of bits given by the second expression.
.IP -
notreg(expr),
true if the local with the expression as number is not a candidate to put
in a register.
.IP -
rom(\fIn\fP,expr), contents of the rom descriptor at index expr that
is associated with the global label that should be the argument of
the \fIn\fP'th EM instruction.
Undefined if such a thing does not exist.
.PP
The usual arithmetic operators may be used on integer values,
if any operand is undefined the expression is undefined,
except for the defined() function above.
An undefined expression used for its truth value is false.
All arithmetic on local label operands is forbidden,
only things allowed are tests for equality.
Arithmetic on global labels makes sense,
i.e. one can add a global label and a constant,
but not two global labels.
.PP
In the table one can use five additional EM instructions in patterns.
These are:
.IP lab
Stands for a local label
.IP LLP
Load Local Pointer, translates into a
.B lol
or into a
.B ldl
depending on the relationship between wordsize and pointersize.
.IP LEP
Load External Pointer, translates into a
.B loe
or into a
.B lde .
.IP SLP
Store Local Pointer,
.B stl
or
.B sdl .
.IP SEP
Store External Pointer,
.B ste
or
.B sde .
.PP
There is only one peephole optimizer,
so the substitutions to be made for the last four instructions
are made at run time before the first optimizations are made.
.NH 1
Internal format
.PP
The translating program,
.I mktab
converts the table into an array of bytes where all
patterns follow unaligned.
Format of a pattern is:
.IP 1)
One byte for high byte of hash value,
will be explained later on.
.IP 2)
Two bytes for the index of the next pattern in a chain.
.IP 3)
An integer\u*\d,
.FS
* An integer is encoded as a byte when less than 255,
otherwise as a byte containing 255 followed by two
bytes with the real value.
.FE
pattern length.
.IP 4)
The list of pattern opcodes, one per byte.
.IP 5)
An integer expression index, 0 if not used.
.IP 6)
An integer, replacement length.
.IP 7)
A list of pairs consisting of a one byte opcode and an integer
expression index.
.PP
The expressions are kept in an array of triples,
implementing a binary tree.
The
.I mktab
program tries to minimize the number of triples by reusing
duplicates and even reverses the operands of commutative operators
when doing so would spare a triple.
.NH 1
A tour through the sources
.PP
Now we will walk through the sources and note things of interest.
.NH 2
The header files
.PP
The header files are the place where data structures and options reside.
.NH 3
alloc.h
.PP
In the header file alloc.h several defines can be used to select various
kinds of core allocation schemes.
This is important on small machines like the PDP-11 since a complete
procedure must be in core at the same space,
and the peephole optimizer should not be the limiting factor in
determining the maximum size of procedures if possible.
Options are:
.IP -
USEMALLOC, standard malloc() and free() are used instead of the own
core allocation package.
Not recommended unless the own package does not work on some bizarre
machine.
.IP -
COREDEBUG, prints large amounts of information about core management.
Better not define it unless you change the code and it stops working.
.IP -
SEPID, if you define this you will get an extra procedure that will
go through a lot of work to scrape the last bytes together if the
system won't provide more.
This is not a good idea if memory is scarce and code and data reside
in the same spaces, since the room used by the procedure might well
be more than the room saved.
.IP -
STACKROOM, number of shorts used in stack space.
This is used if memory is scarce and stack space and data space are
different.
On the PDP-11 a UNIX process starts with an 8K stack segment which
cannot be transferred to the data segment.
Under these conditions one can use a lot of the stack space for storage.
.NH 3
assert.h
.PP
Just defines the assert macro.
When compiled with -DNDEBUG all asserts will be off.
.NH 3
ext.h
.PP
Gives external definitions of variables used by more than one module.
.NH 3
line.h
.PP
Defines the structures used to keep instructions,
one structure per line of EM code,
and the structure to keep arguments of pseudos,
one structure per argument.
Both structures essentially contain a pointer to the next,
a type,
and a union containing information depending on the type.
Core is allocated only for the part of the union used.
.PP
The
.I
struct line
.R
has a very compact encoding for small integers,
they are encoded in the type field.
On the PDP-11 this gives a line structure of only 4 bytes for most
instructions.
.NH 3
lookup.h
.PP
Contains definition of the struct used for symbol table management,
global labels and procedure names are kept in one table.
.NH 3
optim.h
.PP
If one defines the DIAGOPT option in this header file,
for every optimization performed a number is written on stderr.
The number gives the number of the pattern in the table
or one of the four special numbers in this header file.
.NH 3
param.h
.PP
Contains one settable option,
LONGOFF.
If this is not defined the optimizer can only optimize programs
with wordsize 2 and pointersize 2.
Set this only if it must be run on a Z80 or something pathetic like that.
.PP
Other defines here should not be touched.
.NH 3
pattern.h
.PP
Contains defines of indices in a pattern,
definition of the expression triples,
definitions of the various expression operators
and definition of the result struct where expression results are put.
.PP
This header file is the main one that is also included by
.I mktab .
.NH 3
proinf.h
.PP
This one contains definitions
for the local label table structs
and for the struct where all information for one procedure is kept.
This is in one struct so it can be saved easily when recursive
procedures have to be resolved.
.NH 3
types.h
.PP
Collection of typedefs to be used by almost all modules.
.NH 2
The C code itself.
.PP
The C code will now be the center of our attention.
We will make a walk through the sources and we will try
to follow the sources in a logical order.
So we will start at
.NH 3
main.c
.PP
The main.c module contains the main() function.
Here nothing spectacular happens,
only thing of interest is the handling of flags:
.IP -L
This is an instruction to the peephole optimizer to perform
one of its auxiliary functions, the generation of a library module.
This makes the peephole optimizer write its output on a temporary file,
and at the end making the real output by first generating a list
of exported symbols and then copying the temporary file behind it.
.IP -n
Disables all optimization.
Only thing the optimizer does now is filling in the blank after the
.I END
pseudo and resolving recursive procedures.
.PP
The place where main() is left is the call to getlines() which brings
us to
.NH 3
getline.c
.PP
This module reads the EM code and constructs a list of
.I
struct line
.R
records,
linked together backwards,
i.e. the first instruction read is the last in the list.
Pseudos are handled here also,
for most pseudos this just means that a chain of argument records
is linked into the linked line list but some pseudos get special attention:
.IP exc
This pseudo is acted upon right away.
Lines read are shuffled around according to instruction.
.IP mes
Some messages are acted upon.
These are:
.RS
.IP ms_err 8
The input is drained, just in case it is a pipe.
After that the optimizer exits.
.IP ms_opt
The do not optimize flag is set.
Acts just like -n on the command line.
.IP ms_emx
The word- and pointersize are read,
complain if we are not able to handle this.
.IP ms_reg
We take notice of the offset of this local.
See also comments in the description of peephole.c
.RE
.IP pro
A new procedure starts, if we are already in one save the status,
else process collected input.
Collect information about this procedure and if already in a procedure
call getlines() recursively.
.IP end
Process collected input.
.PP
The phrase "process collected input" is used twice,
which brings us to
.NH 3
process.c
.PP
This module contains the entry point process() which is called at any
time the collected input must be processed.
It calls a variety of other routines to get the real work done.
Routines in this module are in chronological order:
.IP symknown 12
Marks all symbols seen until now as known,
i.e. it is now known whether their scope is local or global.
This information is used again during output.
.IP symvalue
Runs through the chain of pseudos to give values to data labels.
This needs an extra pass.
It cannot be done during the getlines pass, since an
.B exc
pseudo could destroy things.
Nor can it be done during the backward pass since it is impossible
to do good fragment numbering backward.
.IP checklocs
Checks whether all local labels referenced are defined.
It needs to be sure about this since otherwise the
semi global optimizations made cannot work.
.IP relabel
This routine finds the final destination for each label in the procedure.
Labels followed by unconditional branches or other labels are marked during
the peephole fase and this leeds to chains of identical labels.
These chains are followed here, and in the local label table each label
has associated with it its replacement label, after this procedure is run.
Care is taken in this routine to prevent a loop in the program to
cause the optimizer to loop.
.IP cleanlocals
This routine empties the local label table after everything
is processed.
.PP
But before this can all be done,
the backward linked list of instructions first has to be reversed,
so here comes
.NH 3
backward.c
.PP
The routine backward has a number of functions:
.IP -
It reverses the backward linked list, making two forward linked lists,
one for the instructions and one for the pseudos.
.IP -
It notes the last occurrence of data labels in the backward linked list
and puts it in the global symbol table.
This is of course the first occurence in the procedure.
This information is needed to decide whether the symbols are global
or local to this module.
.IP -
It decides about the fragment boundaries of data blocks.
Fragments are numbered backwards starting at 3.
This is done to be able to make the type of an expression
containing a symbol equal to its fragment.
This type can then not clash with the types integer and local label.
.IP -
It allocates a rom buffer to every data label with a rom behind
it, if that rom contains only plain integers at the start.
.PP
The first thing done after process() has called backward() and some
of its own little routines is a call to the real routine,
the one that does the work the program was written for
.NH 3
peephole.c
.PP
The first routines in peephole.c
implement a linked list for the offsets of local variables
that are candidates for a register implementation.
Several patterns use the notreg() function,
since it is forbidden to combine a load of that variable
with the load of another and
it is not allowed to take the address of that variable.
.PP
The routine peephole hashes the patterns the first time it is called
after which it doesn't do much more than calling optimize.
But first hashpatterns().
.PP
The patterns are hashed at run time of the optimizer because of
the
.B LLP ,
.B LEP ,
.B SLP
and
.B SEP
instructions added to the instruction set in this optimizer.
These are first replaced everywhere in the table by the correct
replacement after which the first three instructions of the
pattern are hashed and the pattern is linked into one of the
256 linked lists.
There is a define CHK_HASH in this module that you
can set if you do not trust the randomness of the hashing
function.
.PP
The attention now shifts to optimize().
This routine calls basicblock() for every piece of code between two labels.
It also notes which labels have another label or a branch behind them
so the relabel() routine from process.c can do something with that.
.PP
Basicblock() keeps making passes over its basic block
until no more optimizations are found.
This might be inefficient if there is a long basicblock with some
deep recursive optimization in one part of it.
The entire basic block is then scanned a lot of times just for
that one piece.
The alternative is backing up after making an optimization and running
through the same code again, but that is difficult
in a single linked list.
.PP
It hashes instructions and calls trypat() for every pattern that has
a full hash value match,
i.e. lower byte and upper byte equal.
Longest pattern is tried first.
.PP
Trypat() checks length and opcodes of the pattern.
If correct it fills the iargs[] array with argument values
and calculates the expression.
If that is also correct the work shifts to tryrepl().
.PP
Tryrepl() generates the list of replacement instructions,
links it into the list and returns true.
Why then the name tryrepl() if it always succeeds?
Well, there is a mechanism in the optimizer,
unused until today that makes it possible to do optimizations that cannot
be described by the table.
It is possible to give a number as a replacement which will cause the
optimizer to call a routine special() to do some work.
This routine might decide not to do an optimization and return false.
.PP
The last routine that is called from process() is putline()
to write the optimized code, bringing us to
.NH 3
putline.c
.PP
The major part of putline.c is the standard set of routines
that makes EM compact code.
The extra functions performed are:
.IP -
For every occurence of a global symbol it might be necessary to
output a
.B exa ,
.B exp ,
.B ina
or
.B inp
pseudo instruction.
That task is performed.
.IP -
The
.B lin
instructions are optimized here,
.B lni
instructions added for
.B lin
instructions and superfluous
.B lin
instructions deleted.

133
doc/regadd.doc
View File

@ -1,133 +0,0 @@
.\" $Header$
.TL
Addition of register variables to an existing table.
.NH 1
Introduction
.PP
This is a short description of the newest feature in the
table driven code generator for the Amsterdam Compiler Kit.
It describes how to add register variables to an existing table.
This assumes you have the distribution of October 1983 or later.
It is not clear whether you should read this when starting with
a table for a new machine,
or whether you should wait till the table is well debugged already.
.NH 1
Modifications to the table itself.
.NH 2
Register section
.PP
You can add just before the properties of the register one
of the following:
.IP - 2
regvar
.IP -
regvar ( pointer )
.IP -
regvar ( loop )
.IP -
regvar ( float )
.LP
All register variables of one type must be of the same size,
and they may have no subregisters.
.NH 2
Codesection
.PP
.IP - 2
Two pseudo functions are added to the list allowed inside expressions:
.RS
.IP 1) 3
inreg ( expr ) has as a parameter the offset of a local,
and returns 0,1 or 2:
.RS
.IP 2: 3
if the variable is in a register.
.IP 1:
if the variable could be in a register but isn't.
.IP 0:
if the variable cannot be in a register.
.RE
.IP 2)
regvar ( expr ) returns the register associated with the variable.
Undefined if it is not in a register.
So regvar ( expr ) is defined if and only if inreg (expr ) == 2.
.RE
.IP -
It is now possible to remove() a register expression,
this is of course needed for a store into a register local.
.IP -
The return out of a procedure may now involve register restores,
so the special word 'return' in the table will invoke a user defined
function.
.NH 1
Modifications to mach.c
.PP
If register variables are used in a table, the program
.I cgg
will define the word REGVARS during compilation of the sources.
So the following functions described here should be bracketed
by #ifdef REGVARS and #endif.
.IP - 2
regscore(off,size,typ,freq,totyp) long off;
.br
This function should assign a score to a register variable,
the score should preferably be the estimated number of bytes
gained when it is put in a register.
Off and size are the offset and size of the variable,
typ is the type, that is reg_any, reg_pointer, reg_loop or reg_float.
Freq is the number of times it occurs statically, and totyp
is the type of the register it is planned to go into.
.br
Keep in mind that the gain should be net, that is the cost for
register save/restore sequences and the cost of initialisation
in the case of parameters should already be included.
.IP -
i_regsave()
.br
This function is called at the start of a procedure, just before
register saves are done.
It can be used to initialise some variables if needed.
.IP -
f_regsave()
.br
This function is called at end of the register save sequence.
It can be used to do the real saving if multiple register move
instructions are available.
.IP -
regsave(regstr,off,size) char *regstr; long off;
.br
Should either do the real saving or set up a table to have
it done by f_regsave.
Note that initialisation of parameters should also be done,
or planned here.
.IP -
regreturn()
.br
Should restore saved registers and return.
The function result is already in the function return area by now.
.NH 1
Examples
.PP
Here are some examples out of the PDP 11 table
.DS
lol inreg($1)==2| | | regvar($1) | |
lil inreg($1)==2| | | {regdef2, regvar($1)} | |
stl inreg($1)==2| xsource2 |
remove(regvar($1))
move(%[1],regvar($1)) | | |
inl inreg($1)==2| | remove(regvar($1))
"inc %(regvar($1)%)"
setcc(regvar($1)) | | |
.DE
.NH 1
Afterthoughts.
.PP
At the time of this writing the tables for the PDP 11 and the M68000 and
the VAX are converted, in all cases the two byte wordsize versions.
No big problems have occurred, but experience has shown that it is
necessary to check your table carefully for all patterns with locals in them
because if you forget one code will be generated by that one coderule
to use the memoryslot the local is not in.

897
doc/toolkit.doc
View File

@ -1,897 +0,0 @@
.\" $Header$
.RP
.ND
.nr LL 78m
.tr ~
.ds as *
.TL
A Practical Tool Kit for Making Portable Compilers
.AU
Andrew S. Tanenbaum
Hans van Staveren
E. G. Keizer
Johan W. Stevenson
.AI
Mathematics Dept.
Vrije Universiteit
Amsterdam, The Netherlands
.AB
The Amsterdam Compiler Kit is an integrated collection of programs designed to
simplify the task of producing portable (cross) compilers and interpreters.
For each language to be compiled, a program (called a front end)
must be written to
translate the source program into a common intermediate code.
This intermediate code can be optimized and then either directly interpreted
or translated to the assembly language of the desired target machine.
The paper describes the various pieces of the tool kit in some detail, as well
as discussing the overall strategy.
.sp
Keywords: Compiler, Interpreter, Portability, Translator
.sp
CR Categories: 4.12, 4.13, 4.22
.sp 12
Author's present addresses:
A.S. Tanenbaum, H. van Staveren, E.G. Keizer: Mathematics
Dept., Vrije Universiteit, Postbus 7161, 1007 MC Amsterdam,
The Netherlands
J.W. Stevenson: NV Philips, S&I, T&M, Building TQ V5, Eindhoven,
The Netherlands
.AE
.NH 1
Introduction
.PP
As more and more organizations acquire many micro- and minicomputers,
the need for portable compilers is becoming more and more acute.
The present situation, in which each hardware vendor provides its own
compilers -- each with its own deficiencies and extensions, and none of them
compatible -- leaves much to be desired.
The ideal situation would be an integrated system containing a family
of (cross) compilers, each compiler accepting a standard source language and
producing code for a wide variety of target machines.
Furthermore, the compilers should be compatible, so programs written in
one language can call procedures written in another language.
Finally, the system should be designed so as to make adding new languages
and new machines easy.
Such an integrated system is being built at the Vrije Universiteit.
Its design and implementation is the subject of this article.
.PP
Our compiler building system, which is called the "Amsterdam Compiler Kit"
(ACK), can be thought of as a "tool kit."
It consists of a number of parts that can be combined to form compilers
(and interpreters) with various properties.
The tool kit is based on an idea (UNCOL) that was first suggested in 1960
[7], but which never really caught on then.
The problem which UNCOL attempts to solve is how to make a compiler for
each of
.I N
languages on
.I M
different machines without having to write
.I N
x
.I M
programs.
.PP
As shown in Fig. 1, the UNCOL approach is to write
.I N
"front ends," each
of which translates one source language to a common intermediate language,
UNCOL (UNiversal Computer Oriented Language), and
.I M
"back ends," each
of which translates programs in UNCOL to a specific machine language.
Under these conditions, only
.I N
+
.I M
programs must be written to provide all
.I N
languages on all
.I M
machines, instead of
.I N
x
.I M
programs.
.PP
Various researchers have attempted to design a suitable UNCOL
[2,8], but none of these have become popular.
It is our belief that previous attempts have failed because they have been
too ambitious, that is, they have tried to cover all languages
and all machines using a single UNCOL.
Our approach is more modest: we cater only to algebraic languages
and machines whose memory consists of 8-bit bytes, each with its own address.
Typical languages that could be handled include
Ada, ALGOL 60, ALGOL 68, BASIC, C, FORTRAN,
Modula, Pascal, PL/I, PL/M, PLAIN, and RATFOR,
whereas COBOL, LISP, and SNOBOL would be less efficient.
Examples of machines that could be included are the Intel 8080 and 8086,
Motorola 6800, 6809, and 68000, Zilog Z80 and Z8000, DEC PDP-11 and VAX,
and IBM 370 but not the Burroughs 6700, CDC Cyber, or Univac 1108 (because
they are not byte-oriented).
With these restrictions, we believe the old UNCOL idea can be used as the
basis of a practical compiler-building system.
.KF
.sp 15P
.ce 1
Fig. 1. The UNCOL model.
.sp
.KE
.NH 1
An Overview of the Amsterdam Compiler Kit
.PP
The tool kit consists of eight components:
.sp
1. The preprocessor.
2. The front ends.
3. The peephole optimizer.
4. The global optimizer.
5. The back end.
6. The target machine optimizer.
7. The universal assembler/linker.
8. The utility package.
.sp
.PP
A fully optimizing compiler,
depicted in Fig. 2, has seven cascaded phases.
Conceptually, each component reads an input file and writes a
transformed output file to be used as input to the next component.
In practice, some components may use temporary files to allow multiple
passes over the input or internal intermediate files.
.KF
.sp 12P
.ce 1
Fig. 2. Structure of the Amsterdam Compiler Kit.
.sp
.KE
.PP
In the following paragraphs we will briefly describe each component.
After this overview, we will look at all of them again in more detail.
A program to be compiled is first fed into the (language independent)
preprocessor, which provides a simple macro facility,
and similar textual facilties.
The preprocessor's output is a legal program in one of the programming
languages supported, whereas the input is a program possibly augmented
with macros, etc.
.PP
This output goes into the appropriate front end, whose job it is to
produce intermediate code.
This intermediate code (our UNCOL) is the machine language for a simple
stack machine called EM (Encoding Machine).
A typical front end might build a parse tree from the input, and then
use the parse tree to generate EM code, which is similar to reverse Polish.
In order to perform this work, the front end has to maintain tables of
declared variables, labels, etc., determine where to place the
data structures in memory, and so on.
.PP
The EM code generated by the front end is fed into the peephole optimizer,
which scans it with a window of a few instructions, replacing certain
inefficient code sequences by better ones.
Such a search is important because EM contains instructions to handle
numerous important special cases efficiently
(e.g., incrementing a variable by 1).
It is our strategy to relieve the front ends of the burden of hunting for
special cases because there are many front ends and only one peephole
optimizer.
By handling the special cases in the peephole optimizer,
the front ends become simpler, easier to write and easier to maintain.
.PP
Following the peephole optimizer is a global optimizer [5], which
unlike the peephole optimizer, examines the program as a whole.
It builds a data flow graph to make possible a variety of
global optimizations,
among them, moving invariant code out of loops, avoiding redundant
computations, live/dead analysis and eliminating tail recursion.
Note that the output of the global optimizer is still EM code.
.PP
Next comes the back end, which differs from the front ends in a
fundamental way.
Each front end is a separate program, whereas the back end is a single
program that is driven by a machine dependent driving table.
The driving table for a specific machine tells how the EM code is mapped
onto the machine's assembly language.
Although a simple driving table might just macro expand each EM instruction
into a sequence of target machine instructions, a much more sophisticated
translation strategy is normally used, as described later.
For speed, the back end does not actually read in the driving table at run time.
Instead, the tables are compiled along with the back end in advance, resulting
in one binary program per machine.
.PP
The output of the back end is a program in the assembly language of some
particular machine.
The next component in the pipeline reads this program and performs peephole
optimization on it.
The optimizations performed here involve idiosyncracies
of the target machine that cannot be performed in the machine-independent
EM-to-EM peephole optimizer.
Typically these optimizations take advantage of special instructions or special
addressing modes.
.PP
The optimized target machine assembly code then goes into the final
component in the pipeline, the universal assembler/linker.
This program assembles the input to object format, extracting routines from
libraries and including them as needed.
.PP
The final component of the tool kit is the utility package, which contains
various test programs, interpreters for EM code,
EM libraries, conversion programs, and other aids for the implementer and
user.
.NH 1
The Preprocessor
.PP
The function of the preprocessor is to extend all the programming languages
by adding certain generally useful facilities to them in a uniform way.
One of these is a simple macro system, in which the user can give names to
character strings.
The names can be used in the program, with the knowledge that they will be
macro expanded prior to being input to the front end.
Macros can be used for named constants, expanding short "procedures"
in line, etc.
.PP
Another useful facility provided by the preprocessor is the ability to
include compile-time libraries.
On large projects, it is common to have all the declarations and definitions
gathered together in a few files that are textually included in the programs
by instructing the preprocessor to read them in, thus fooling the front end
into thinking that they were part of the source program.
.PP
A third feature of the preprocessor is conditional compilation.
The input program can be split up into labeled sections.
By setting flags, some of the sections can be deleted by the preprocessor,
thus allowing a family of slightly different programs to be conveniently stored
on a single file.
.NH 1
The Front Ends
.PP
A front end is a program that converts input in some source language to a
program in EM.
At present, front ends
exist or are in preparation for Pascal, C, and Plain, and are being considered
for Ada, ALGOL 68, FORTRAN 77, and Modula 2.
Each of the present front ends is independent of all the other ones,
although a general-purpose, table-driven front end is conceivable, provided
one can devise a way to express the semantics of the source language in the
driving tables.
The Pascal front end uses a top-down parsing algorithm (recursive descent),
whereas the C and Plain front ends are bottom-up.
.PP
All front ends, independent of the language being compiled,
produce a common intermediate code called EM, which is
the assembly language for a simple stack machine.
The EM machine is based on a memory architecture
containing a stack for local variables, a (static) data area for variables
declared in the outermost block and global to the whole program, and a heap
for dynamic data structures.
In some ways EM resembles P-code [6], but is more general, since it is
intended for a wider class of languages than just Pascal.
.PP
The EM instruction set has been described elsewhere
[9,10,11]
so we will only briefly summarize it here.
Instructions exist to:
.sp
1. Load a variable or constant of some length onto the stack.
2. Store the top item on the stack in memory.
3. Add, subtract, multiply, divide, etc. the top two stack items.
4. Examine the top one or two stack items and branch conditionally.
5. Call procedures and return from them.
.sp
.PP
Loads and stores come in several variations, corresponding to the most common
programming language semantics, for example, constants, simple variables,
fields of a record, elements of an array, and so on.
Distinctions are also made between variables local to the current block
(i.e., stack frame), those in the outermost block (static storage), and those
at intermediate lexicographic levels, which are accessed by following the
static chain at run time.
.PP
All arithmetic instructions have a type (integer, unsigned, real,
pointer, or set) and an
operand length, which may either be explicit or may be popped from the stack
at run time.
Monadic branch instructions pop an item from the stack and branch if it is
less than zero, less than or equal to zero, etc.
Dyadic branch instructions pop two items, compare them, and branch accordingly.
.PP
In addition to these basic EM instructions, there is a collection of special
purpose instructions (e.g., to increment a local variable), which are typically
produced from the simple ones by the peephole optimizer.
Although the complete EM instruction set contains nearly 150 instructions,
only about 60 of them are really primitive; the rest are simply abbreviations
for commonly occurring EM instruction sequences.
.PP
Of particular interest is the way object sizes are parametrized.
The front ends allow the user to indicate how many bytes an integer, real, etc.
should occupy.
Given this information, the front ends can allocate memory, determining
the placement of variables within the stack frame.
Sizes for primitive types are restricted to 8, 16, 32, 64, etc. bits.
The front ends are also parametrized by the target machine's word length
and address size so they can tell, for example, how many "load" instructions
to generate to move a 32-bit integer.
In the examples used henceforth,
we will assume a 16-bit word size and 16-bit integers.
.PP
Since only byte-addressable target machines are permitted,
it is nearly
always possible to implement any requested sizes on any target machine.
For example, the designer of the back end tables for the Z80 should provide
code for 8-, 16-, and 32-bit arithmetic.
In our view, the Pascal, C, or Plain programmer specifies what lengths
are needed,
without reference to the target machine,
and the back end provides it.
This approach greatly enhances portability.
While it is true that doing all arithmetic using 32-bit integers on the Z80
will not be terribly fast, we feel that if that is what the programmer needs,
it should be possible to implement it.
.PP
Like all assembly languages, EM has not only machine instructions, but also
pseudoinstructions.
These are used to indicate the start and end of each procedure, allocate
and initialize storage for data, and similar functions.
One particularly important pseudoinstruction is the one that is used to
transmit information to the back end for optimization purposes.
It can be used to suggest variables that are good candidates to assign to
registers, delimit the scope of loops, indicate that certain variables
contain a useful value (next operation is a load) or not (next operation is
a store), and various other things.
.NH 1
The Peephole Optimizer
.PP
The peephole optimizer reads in unoptimized EM programs and writes out
optimized ones.
Both the input and output are expressed in a highly compact code, rather than
in ASCII, to reduce the i/o time, which would otherwise dominate the CPU
time.
The program itself is table driven, and is, by and large, ignorant of the
semantics of EM.
The knowledge of EM is contained in a
language- and machine-independent table consisting of about 400
pattern-replacement pairs.
We will briefly describe the kinds of optimizations it performs below;
a more complete discussion can be found in [9].
.PP
Each line in the driving table describes one optimization, consisting of a
pattern part and a replacement part.
The pattern part is a series of one or more EM instructions and a boolean
expression.
The replacement part is a series of EM instructions with operands.
A typical optimization might be:
.sp
LOL LOC ADI STL ($1 = $4) and ($2 = 1) and ($3 = 2) ==> INL $1
.sp
where the text prior to the ==> symbol is the pattern and the text after it is
the replacement.
LOL loads a local variable onto the stack, LOC loads a constant onto the stack,
ADI is integer addition, and STL is store local.
The pattern specifies that four consecutive EM instructions are present, with
the indicated opcodes, and that furthermore the operand of the first
instruction (denoted by $1) and the fourth instruction (denoted by $4) are the
same, the constant pushed by LOC is 1, and the size of the integers added by
ADI is 2 bytes.
(EM instructions have at most one operand, so it is not necessary to specify
the operand number.)
Under these conditions, the four instructions can be replaced by a single INL
(increment local) instruction whose operand is equal to that of LOL.
.PP
Although the optimizations cover a wide range, the main ones
can be roughly divided into the following categories.
\fIConstant folding\fR
is used to evaluate constant expressions, such as 2*3~+~7 at
compile time instead of run time.
\fIStrength reduction\fR
is used to replace one operation, such as multiply, by
another, such as shift.
\fIReordering of expressions\fR
helps in cases like -K/5, which can be better
evaluated as K/-5, because the former requires
a division and a negation, whereas the latter requires only a division.
\fINull instructions\fR
include resetting the stack pointer after a call with 0 parameters,
offsetting zero bytes to access the
first element of a record, or jumping to the next instruction.
\fISpecial instructions\fR
are those like INL, which deal with common special cases
such as adding one to a variable or comparing something to zero.
\fIGroup moves\fR
are useful because a sequence
of consecutive moves can often be replaced with EM code
that allows the back end to generate a loop instead of in line code.
\fIDead code elimination\fR
is a technique for removing unreachable statements, possibly made unreachable
by previous optimizations.
\fIBranch chain compression\fR
can be applied when a branch instruction jumps to another branch instruction.
The first branch can jump directly to the final destination instead of
indirectly.
.PP
The last two optimizations logically belong in the global optimizer but are
in the local optimizer for historical reasons (meaning that the local
optimizer has been the only optimizer for many years and the optimizations were
easy to do there).
.NH 1
The Global Optimizer
.PP
In contrast to the peephole optimizer, which examines the EM code a few lines
at a time through a small window, the global optimizer examines the
program's large scale structure.
Three distinct types of optimizations can be found here:
.sp
1. Interprocedural optimizations.
2. Intraprocedural optimizations.
3. Basic block optimizations.
.sp
We will now look at each of these in turn.
.PP
Interprocedural optimizations are those spanning procedure boundaries.
The most important one is deciding to expand procedures in line,
especially short procedures that occur in loops and pass several parameters.
If it takes more time or memory to pass the parameters than to do the work,
the program can be improved by eliminating the procedure.
The inverse optimization -- discovering long common code sequences and
turning them into a procedure -- is also possible, but much more difficult.
Like much of the global optimizer's work, the decision to make or not make
a certain program transformation is a heuristic one, based on knowledge of
how the back end works, how most target machines are organized, etc.
.PP
The heart of the global optimizer is its analysis of individual
procedures.
To perform this analysis, the optimizer must locate the basic blocks,
instruction sequences which can be entered only at the top and exited
only at the bottom.
It then constructs a data flow graph, with the basic blocks as nodes and
jumps between blocks as arcs.
.PP
From the data flow graph, many important properties of the program can be
discovered and exploited.
Chief among these is the presence of loops, indicated by cycles in the graph.
One important optimization is looking for code that can be moved outside the
loop, either prior to it or subsequent to it.
Such code motion saves execution time, although it does not save memory.
Unrolling loops is also possible and desirable in some cases.
.PP
Another area in which global analysis of loops is especially important is
in register allocation.
While it is true that EM does not have any registers to allocate,
the optimizer can easily collect information to allow the
back end to allocate registers wisely.
For example, the global optimizer can collect static frequency-of-use
and live/dead information about variables.
(A variable is dead at some point in the program if its current value is
not needed, i.e., the next reference to it overwrites it rather than
reading it; if the current value will eventually be used, the variable is
live.)
If two variables are never simultaneously live over some interval of code
(e.g., the body of a loop), they can be packed into a single variable,
which, if used often enough, may warrant being assigned to a register.
.PP
Many loops involve arrays: this leads to other optimizations.
If an array is accessed sequentially, with each iteration using the next
higher numbered element, code improvement is often possible.
Typically, a pointer to the bottom element of each array can be set up
prior to the loop.
Within the loop the element is accessed indirectly via the pointer, which is
also incremented by the element size on each iteration.
If the target machine has an autoincrement addressing mode and the pointer
is assigned to a register, an array access can often be done in a single
instruction.
.PP
Other intraprocedural optimizations include removing tail recursion
(last statement is a recursive call to the procedure itself),
topologically sorting the basic blocks to minimize the number of branch
instructions, and common subexpression recognition.
.PP
The third general class of optimizations done by the global optimizer is
improving the structure of a basic block.
For the most part these involve transforming arithmetic or boolean
expressions into forms that are likely to result in better target code.
As a simple example, A~+~B*C can be converted to B*C~+~A.
The latter can often
be handled by loading B into a register, multiplying the register by C, and
then adding in A, whereas the former may involve first putting A into a
temporary, depending on the details of the code generation table.
Another example of this kind of basic block optimization is transforming
-B~+~A~<~0 into the equivalent, but simpler, A~<~B.
.NH 1
The Back End
.PP
The back end reads a stream of EM instructions and generates assembly code
for the target machine.
Although the algorithm itself is machine independent, for each target
machine a machine dependent driving table must be supplied.
The driving table effectively defines the mapping of EM code to target code.
.PP
It will be convenient to think of the EM instructions being read as a
stream of tokens.
For didactic purposes, we will concentrate on two kinds of tokens:
those that load something onto the stack, and those that perform some operation
on the top one or two values on the stack.
The back end maintains at compile time a simulated stack whose behavior
mirrors what the stack of a hardware EM machine would do at run time.
If the current input token is a load instruction, a new entry is pushed onto
the simulated stack.
.PP
Consider, as an example, the EM code produced for the statement K~:=~I~+~7.
If K and I are
2-byte local variables, it will normally be LOL I; LOC 7; ADI~2; STL K.
Initially the simulated stack is empty.
After the first token has been read and processed, the simulated stack will
contain a stack token of type MEM with attributes telling that it is a local,
giving its address, etc.
After the second token has been read and processed, the top two tokens on the
simulated stack will be CON (constant) on top and MEM directly underneath it.
.PP
At this point the back end reads the ADI~2 token and
looks in the driving table to find a line or lines that define the
action to be taken for ADI~2.
For a typical multiregister machine, instructions will exist to add constants
to registers, but not to memory.
Consequently, the driving table will not contain an entry for ADI~2 with stack
configuration CON, MEM.
.PP
The back end is now faced with the problem of how to get from its
current stack configuration, CON, MEM, which is not listed, to one that is
listed.
The table will normally contain rules (which we call "coercions")
for converting between CON, REG, MEM, and similar tokens.
Therefore the back end attempts to "coerce" the stack into a configuration
that
.I is
present in the table.
A typical coercion rule might tell how to convert a MEM into
a REG, namely by performing the actions of allocating a
register and emitting code to move the memory word to that register.
Having transformed the compile-time stack into a configuration allowed for
ADI~2, the rule can be carried out.
A typical rule
for ADI~2 might have stack configuration REG, MEM
and would emit code to add the MEM to the REG, leaving the stack
with a single REG token instead of the REG and MEM tokens present before the
ADI~2.
.PP
In general, there will be more than one possible coercion path.
Assuming reasonable coercion rules for our example,
we might be able to convert
CON MEM into CON REG by loading the variable I into a register.
Alternatively, we could coerce CON to REG by loading the constant into a register.
The first coercion path does the add by first loading I into a register and
then adding 7 to it.
The second path first loads 7 into a register and then adds I to it.
On machines with a fast LOAD IMMEDIATE instruction for small constants
but no fast ADD IMMEDIATE, or vice
versa, one code sequence will be preferable to the other.
.PP
In fact, we actually have more choices than suggested above.
In both coercion paths a register must be allocated.
On many machines, not every register can be used in every operation, so the
choice may be important.
On some machines, for example, the operand of a multiply must be in an odd
register.
To summarize, from any state (i.e., token and stack configuration), a
variety of choices can be made, leading to a variety of different target
code sequences.
.PP
To decide which of the various code sequences to emit, the back end must have
some information about the time and memory cost of each one.
To provide this information, each rule in the driving table, including
coercions, specifies both the time and memory cost of the code emitted when
the rule is applied.
The back end can then simply try each of the legal possibilities (including all
the possible register allocations) to find the cheapest one.
.PP
This situation is similar to that found in a chess or other game-playing
program, in which from any state a finite number of moves can be made.
Just as in a chess program, the back end can look at all the "moves" that can
be made from each state reachable from the original state, and thus find the
sequence that gives the minimum cost to a depth of one.
More generally, the back end can evaluate all paths corresponding to accepting
the next
.I N
input tokens, find the cheapest one, and then make the first move along
that path, precisely the way a chess program would.
.PP
Since the back end is analogous to both a parser and a chess playing program,
some clarifying remarks may be helpful.
First, chess programs and the back end must do some look ahead, whereas the
parser for a well-designed grammar can usually suffice with one input token
because grammars are supposed to be unambiguous.
In contrast, many legal mappings
from a sequence of EM instructions to target code may exist.
Second, like a parser but unlike a chess program, the back end has perfect
information -- it does not have to contend with an unpredictable opponent's
moves.
Third, chess programs normally make a static evaluation of the board and
label the
.I nodes
of the tree with the resulting scores.
The back end, in contrast, associates costs with
.I arcs
(moves) rather than nodes (states).
However, the difference is not essential, since it could
also label each node with the cumulative cost from the root to that node.
.PP
As mentioned above, the cost field in the table contains
.I both
the time and memory costs for the code emitted.
It should be clear that the back end could use either one
or some linear combination of them as the scoring function for evaluating moves.
A user can instruct the compiler to optimize for time or for memory or
for, say, 0.3 x time + 0.7 x memory.
Thus the same compiler can provide a wide range of performance options to
the user.
The writer of the back end table can take advantage of this flexibility by
providing several code sequences with different tradeoffs for each EM
instruction (e.g., in line code vs. call to a run time routine).
.PP
In addition to the time-space tradeoffs, by specifying the depth of search
parameter,
.I N ,
the user can effectively also tradeoff compile time vs. object
code quality, for whatever code metric has been chosen.
In summary, by combining the properties of a parser and a game playing program,
it is possible to make a code generator that is table driven,
highly flexible, and has the ability to produce good code from a
stack machine intermediate code.
.NH 1
The Target Machine Optimizer
.PP
In the model of Fig 2., the peephole optimizer comes before the global
optimizer.
It may happen that the code produced by the global optimizer can also
be improved by another round of peephole optimization.
Conceivably, the system could have been designed to iterate peephole and
global optimizations until no more of either could be performed.
.PP
However, both of these optimizations are done on the machine independent
EM code.
Neither is able to take advantage of the peculiarities and idiosyncracies with
which most target machines are well endowed.
It is the function of the final
optimizer to do any (peephole) optimizations that still remain.
.PP
The algorithm used here is the same as in the EM peephole optimizer.
In fact, if it were not for the differences between EM syntax, which is
very restricted, and target assembly language syntax,
which is less so, precisely the same program could be used for both.
Nevertheless, the same ideas apply concerning patterns and replacements, so
our discussion of this optimizer will be restricted to one example.
.PP
To see what the target optimizer might do, consider the
PDP-11 instruction sequence sub #2,r0; mov (r0),x.
First 2 is subtracted from register 0, then the word pointed to by it
is moved to x.
The PDP-11 happens to have an addressing mode to perform this sequence in
one instruction: mov -(r0),x.
Although it is conceivable that this instruction could be included in the
back end driving table for the PDP-11, it is awkward to do so because it
can occur in so many contexts.
It is much easier to catch things like this in a separate program.
.NH 1
The Universal Assembler/Linker
.PP
Although assembly languages for different machines may appear very different
at first glance, they have a surprisingly large intersection.
We have been able to construct an assembler/linker that is almost entirely
independent of the assembly language being processed.
To tailor the program to a specific assembly language, it is necessary to
supply a table giving the list of instructions, the bit patterns required for
each one, and the language syntax.
The machine independent part of the assembler/linker is then compiled with the
table to produce an assembler and linker for a particular target machine.
Experience has shown that writing the necessary table for a new machine can be
done in less than a week.
.PP
To enforce a modicum of uniformity, we have chosen to use a common set of
pseudoinstructions for all target machines.
They are used to initialize memory, allocate uninitialized memory, determine the
current segment, and similar functions found in most assemblers.
.PP
The assembler is also a linker.
After assembling a program, it checks to see if there are any
unsatisfied external references.
If so, it begins reading the libraries to find the necessary routines, including
them in the object file as it finds them.
This approach requires libraries to be maintained in assembly language form,
but eliminates the need for inventing a language to express relocatable
object programs in a machine independent way.
It also simplifies the assembler, since producing absolute object code is
easier than producing relocatable object code.
Finally, although assembly language libraries may be somewhat larger than
relocatable object module libraries, the loss in speed due to having more
input may be more than compensated for by not having to pass an intermediate
file between the assembler and linker.
.NH 1
The Utility Package
.PP
The utility package is a collection of programs designed to aid the
implementers of new front ends or new back ends.
The most useful ones are the test programs.
For example, one test set, EMTEST, systematically checks out a back end by
executing an ever larger subset of the EM instructions.
It starts out by testing LOC, LOL and a few of the other essential instructions.
If these appear to work, it then tries out new instructions one at a time,
adding them to the set of instructions "known" to work as they pass the tests.
.PP
Each instruction is tested with a variety of operands chosen from values
where problems can be expected.
For example, on target machines which have 16-bit index registers but only
allow 8-bit displacements, a fundamentally different algorithm may be needed
for accessing
the first few bytes of local variables and those with offsets of thousands.
The test programs have been carefully designed to thoroughly test all relevant
cases.
.PP
In addition to EMTEST, test programs in Pascal, C, and other languages are also
available.
A typical test is:
.sp
i := 9; \fBif\fP i + 250 <> 259 \fBthen\fP error(16);
.sp
Like EMTEST, the other test programs systematically exercise all features of the
language being tested, and do so in a way that makes it possible to pinpoint
errors precisely.
While it has been said that testing can only demonstrate the presence of errors
and not their absence, our experience is that
the test programs have been invaluable in debugging new parts of the system
quickly.
.PP
Other utilities include programs to convert
the highly compact EM code produced by front ends to ASCII and vice versa,
programs to build various internal tables from human writable input formats,
a variety of libraries written in or compiled to EM to make them portable,
an EM assembler, and EM interpreters for various machines.
.PP
Interpreting the EM code instead of translating it to target machine language
is useful for several reasons.
First, the interpreters provide extensive run time diagnostics including
an option to list the original source program (in Pascal, C, etc.) with the
execution frequency or execution time for each source line printed in the
left margin.
Second, since an EM program is typically about one-third the size of a
compiled program, large programs can be executed on small machines.
Third, running the EM code directly makes it easier to pinpoint errors in
the EM output of front ends still being debugged.
.NH 1
Summary and Conclusions
.PP
The Amsterdam Compiler Kit is a tool kit for building
portable (cross) compilers and interpreters.
The main pieces of the kit are the front ends, which convert source programs
to EM code, optimizers, which improve the EM code, and back ends, which convert
the EM code to target assembly language.
The kit is highly modular, so writing one front end
(and its associated runtime routines)
is sufficient to implement
a new language on a dozen or more machines, and writing one back end table
and one universal assembler/linker table is all that is needed to bring up all
the previously implemented languages on a new machine.
In this manner, the contents, and hopefully the usefulness, of the toolkit
will increase in time.
.PP
We believe the principal lesson to be learned from our work is that the old
UNCOL idea is basically a sound way to produce compilers, provided suitable
restrictions are placed on the source languages and target machines.
We also believe that although compilers produced by this technology may not
be equal to the very best handcrafted compilers,
in terms of object code quality, they are certainly
competitive with many existing compilers.
However, when one factors in the cost of producing the compiler,
the possible slight loss in performance may be more than compensated for by the
large decrease in production cost.
As a consequence of our work and similar work by other researchers [1,3,4],
we expect integrated compiler building kits to become increasingly popular
in the near future.
.PP
The toolkit is now available for various computers running the
.UX
operating system.
For information, contact the authors.
.NH 1
References
.LP
.nr r 0 1
.in +4
.ti -4
\fB~\n+r.\fR Graham, S.L.
Table-Driven Code Generation.
.I "Computer~13" ,
8 (August 1980), 25-34.
.PP
A discussion of systematic ways to do code generation,
in particular, the idea of having a table with templates that match parts of
the parse tree and convert them into machine instructions.
.sp 2
.ti -4
\fB~\n+r.\fR Haddon, B.K., and Waite, W.M.
Experience with the Universal Intermediate Language Janus.
.I "Software Practice & Experience~8" ,
5 (Sept.-Oct. 1978), 601-616.
.PP
An intermediate language for use with ALGOL 68, Pascal, etc. is described.
The paper discusses some problems encountered and how they were dealt with.
.sp 2
.ti -4
\fB~\n+r.\fR Johnson, S.C.
A Portable Compiler: Theory and Practice.
.I "Ann. ACM Symp. Prin. Prog. Lang." ,
Jan. 1978.
.PP
A cogent discussion of the portable C compiler.
Particularly interesting are the author's thoughts on the value of
computer science theory.
.sp 2
.ti -4
\fB~\n+r.\fR Leverett, B.W., Cattell, R.G.G, Hobbs, S.O., Newcomer, J.M.,
Reiner, A.H., Schatz, B.R., and Wulf, W.A.
An Overview of the Production-Quality Compiler-Compiler Project.
.I Computer~13 ,
8 (August 1980), 38-49.
.PP
PQCC is a system for building compilers similar in concept but differing in
details from the Amsterdam Compiler Kit.
The paper describes the intermediate representation used and the code generation
strategy.
.sp 2
.ti -4
\fB~\n+r.\fR Lowry, E.S., and Medlock, C.W.
Object Code Optimization.
.I "Commun.~ACM~12",
(Jan. 1969), 13-22.
.PP
A classic paper on global object code optimization.
It covers data flow analysis, common subexpressions, code motion, register
allocation and other techniques.
.sp 2
.ti -4
\fB~\n+r.\fR Nori, K.V., Ammann, U., Jensen, K., Nageli, H.
The Pascal P Compiler Implementation Notes.
Eidgen. Tech. Hochschule, Zurich, 1975.
.PP
A description of the original P-code machine, used to transport the Pascal-P
compiler to new computers.
.sp 2
.ti -4
\fB~\n+r.\fR Steel, T.B., Jr. UNCOL: the Myth and the Fact. in
.I "Ann. Rev. Auto. Prog."
Goodman, R. (ed.), vol 2., (1960), 325-344.
.PP
An introduction to the UNCOL idea by its originator.
.sp 2
.ti -4
\fB~\n+r.\fR Steel, T.B., Jr.
A First Version of UNCOL.
.I "Proc. Western Joint Comp. Conf." ,
(1961), 371-377.
.PP
The first detailed proposal for an UNCOL. By current standards it is a
primitive language, but it is interesting for its historical perspective.
.sp 2
.ti -4
\fB~\n+r.\fR Tanenbaum, A.S., van Staveren, H., and Stevenson, J.W.
Using Peephole Optimization on Intermediate Code.
.I "ACM Trans. Prog. Lang. and Sys. 3" ,
1 (Jan. 1982) pp. 21-36.
.PP
A detailed description of a table-driven peephole optimizer.
The driving table provides a list of patterns to match as well as the
replacement text to use for each successful match.
.sp 2
.ti -4
\fB\n+r.\fR Tanenbaum, A.S., Stevenson, J.W., Keizer, E.G., and van Staveren, H.
Description of an Experimental Machine Architecture for use with Block
Structured Languages.
Informatica Rapport 81, Vrije Universiteit, Amsterdam, 1983.
.PP
The defining document for EM.
.sp 2
.ti -4
\fB\n+r.\fR Tanenbaum, A.S.
Implications of Structured Programming for Machine Architecture.
.I "Comm. ACM~21" ,
3 (March 1978), 237-246.
.PP
The background and motivation for the design of EM.
This early version emphasized the idea of interpreting the intermediate
code (then called EM-1) rather than compiling it.

303
doc/v7bugs.doc
View File

@ -1,303 +0,0 @@
.\" $Header$
.wh 0 hd
.wh 60 fo
.de hd
'sp 5
..
.de fo
'bp
..
.nr e 0 1
.de ER
.br
.ne 20
.sp 2
.in 5
.ti -5
ERROR \\n+e:
..
.de PS
.sp
.nf
.in +5
..
.de PE
.sp
.fi
.in -5
..
.sp 3
.ce
UNIX version 7 bugs
.sp 3
This document describes the UNIX version 7 errors fixed at the
Vrije Universiteit, Amsterdam.
Several of these are discovered at the VU.
Others are quoted from a list of bugs distributed by BellLabs.
.sp
For each error the differences between the original and modified
source files are given,
as well as a test program.
.ER
C optimizer bug for unsigned comparison
.sp
The following C program caused an IOT trap, while it should not
(compile with 'cc -O prog.c'):
.PS
unsigned i = 0;
main() {
register j;
j = -1;
if (i > 40000)
abort();
}
.PE
BellLabs suggests to make the following patch in c21.c:
.PS
/* modified /usr/src/cmd/c/c21.c */
189 if (r==0) {
190 /* next 2 lines replaced as indicated by
191 * Bell Labs bug distribution ( v7optbug )
192 p->back->back->forw = p->forw;
193 p->forw->back = p->back->back;
194 End of lines changed */
195 if (p->forw->op==CBR
196 || p->forw->op==SXT
197 || p->forw->op==CFCC) {
198 p->back->forw = p->forw;
199 p->forw->back = p->back;
200 } else {
201 p->back->back->forw = p->forw;
202 p->forw->back = p->back->back;
203 }
204 /* End of new lines */
205 decref(p->ref);
206 p = p->back->back;
207 nchange++;
208 } else if (r>0) {
.PE
Use the previous program to test before and after the modification.
.ER
The loader fails for large data or text portions
.sp
The loader 'ld' produces a "local symbol botch" error
for the following C program.
.PS
int big1[10000] = {
1
};
int big2[10000] = {
2
};
main() {
printf("loader is fine\\n");
}
.PE
We have made the following fix:
.PS
/* original /usr/src/cmd/ld.c */
113 struct {
114 int fmagic;
115 int tsize;
116 int dsize;
117 int bsize;
118 int ssize;
119 int entry;
120 int pad;
121 int relflg;
122 } filhdr;
/* modified /usr/src/cmd/ld.c */
113 /*
114 * The original Version 7 loader had problems loading large
115 * text or data portions.
116 * Why not include <a.out.h> ???
117 * then they would be declared unsigned
118 */
119 struct {
120 int fmagic;
121 unsigned tsize; /* not int !!! */
122 unsigned dsize; /* not int !!! */
123 unsigned bsize; /* not int !!! */
124 unsigned ssize; /* not int !!! */
125 unsigned entry; /* not int !!! */
126 unsigned pad; /* not int !!! */
127 unsigned relflg; /* not int !!! */
128 } filhdr;
.PE
.ER
Floating point registers
.sp
When a program is swapped to disk if it needs more memory,
then the floating point registers were not saved, so that
it may have different registers when it is restarted.
A small assembly program demonstrates this for the status register.
If the error is not fixed, then the program generates an IOT error.
A "memory fault" is generated if all is fine.
.PS
start: ldfps $7400
1: stfps r0
mov r0,-(sp)
cmp r0,$7400
beq 1b
4
.PE
You have to dig into the kernel to fix it.
The following patch will do:
.PS
/* original /usr/sys/sys/slp.c */
563 a2 = malloc(coremap, newsize);
564 if(a2 == NULL) {
565 xswap(p, 1, n);
566 p->p_flag |= SSWAP;
567 qswtch();
568 /* no return */
569 }
/* modified /usr/sys/sys/slp.c */
590 a2 = malloc(coremap, newsize);
591 if(a2 == NULL) {
592 #ifdef FPBUG
593 /*
594 * copy floating point register and status,
595 * but only if you must switch processes
596 */
597 if(u.u_fpsaved == 0) {
598 savfp(&u.u_fps);
599 u.u_fpsaved = 1;
600 }
601 #endif
602 xswap(p, 1, n);
603 p->p_flag |= SSWAP;
604 qswtch();
605 /* no return */
606 }
.PE
.ER
Floating point registers.
.sp
A similar problem arises when a process forks.
The child will have random floating point registers as is
demonstrated by the following assembly language program.
The child process will die by an IOT trap and the father prints
the message "child failed".
.PS
exit = 1.
fork = 2.
write = 4.
wait = 7.
start: ldfps $7400
sys fork
br child
sys wait
tst r1
bne bad
stfps r2
cmp r2,$7400
beq start
4
child: stfps r2
cmp r2,$7400
beq ex
4
bad: clr r0
sys write;mess;13.
ex: clr r0
sys exit
.data
mess: <child failed\\n>
.PE
The same file slp.c should be patched as follows:
.PS
/* original /usr/sys/sys/slp.c */
499 /*
500 * When the resume is executed for the new process,
501 * here's where it will resume.
502 */
503 if (save(u.u_ssav)) {
504 sureg();
505 return(1);
506 }
507 a2 = malloc(coremap, n);
508 /*
509 * If there is not enough core for the
510 * new process, swap out the current process to generate the
511 * copy.
512 */
/* modified /usr/sys/sys/slp.c */
519 /*
520 * When the resume is executed for the new process,
521 * here's where it will resume.
522 */
523 if (save(u.u_ssav)) {
524 sureg();
525 return(1);
526 }
527 #ifdef FPBUG
528 /* copy the floating point registers and status to child */
529 if(u.u_fpsaved == 0) {
530 savfp(&u.u_fps);
531 u.u_fpsaved = 1;
532 }
533 #endif
534 a2 = malloc(coremap, n);
535 /*
536 * If there is not enough core for the
537 * new process, swap out the current process to generate the
538 * copy.
539 */
.PE
.ER
/usr/src/libc/v6/stat.c
.sp
Some system calls are changed from version 6 to version 7.
A library of system call entries, that make a version 6 UNIX look like
a version 7 system, is provided to enable you to run some
useful version 7 utilities, like 'tar', on UNIX-6.
The entry for 'stat' contained two bugs:
the 24-bit file size was incorrectly converted to 32 bits
(sign extension of bit 15)
and the uid/gid fields suffered from sign extension.
.sp
Transferring your files from version 6 to version 7 using 'tar'
will fail for all files for which
.sp
( (size & 0100000) != 0 )
.sp
These two errors are fixed if stat.c is modified as follows:
.PS
/* original /usr/src/libc/v6/stat.c */
11 char os_size0;
12 short os_size1;
13 short os_addr[8];
49 buf->st_nlink = osbuf.os_nlinks;
50 buf->st_uid = osbuf.os_uid;
51 buf->st_gid = osbuf.os_gid;
52 buf->st_rdev = 0;
/* modified /usr/src/libc/v6/stat.c */
11 char os_size0;
12 unsigned os_size1;
13 short os_addr[8];
49 buf->st_nlink = osbuf.os_nlinks;
50 buf->st_uid = osbuf.os_uid & 0377;
51 buf->st_gid = osbuf.os_gid & 0377;
52 buf->st_rdev = 0;
.PE

753
doc/val.doc
View File

@ -1,753 +0,0 @@
.\" $Header$
.ll 72
.wh 0 hd
.wh 60 fo
.de hd
'sp 5
..
.de fo
'bp
..
.tr ~
. PARAGRAPH
.de PP
.sp
..
. CHAPTER
.de CH
.br
.ne 15
.sp 3
.in 0
\\fB\\$1\\fR
.in 5
.PP
..
. SUBCHAPTER
.de SH
.br
.ne 10
.sp
.in 5
\\fB\\$1\\fR
.in 10
.PP
..
. INDENT START
.de IS
.sp
.in +5
..
. INDENT END
.de IE
.in -5
.sp
..
. DOUBLE INDENT START
.de DS
.sp
.in +5
.ll -5
..
. DOUBLE INDENT END
.de DE
.ll +5
.in -5
.sp
..
. EQUATION START
.de EQ
.sp
.nf
..
. EQUATION END
.de EN
.fi
.sp
..
. TEST
.de TT
.ti -5
Test~\\$1:~
.br
..
. IMPLEMENTATION 1
.de I1
.br
Implementation~1:
..
. IMPLEMENTATION 2
.de I2
.br
Implementation~2:
..
.de CS
.br
~-~\\
..
.br
.fi
.sp 5
.ce
\fBPascal Validation Suite Report\fR
.CH "Pascal processor identification"
The ACK-Pascal compiler produces code for an EM machine
as defined in [1].
It is up to the implementor of the EM machine whether errors like
integer overflow, undefined operand and range bound error are recognized or not.
Therefore it depends on the EM machine implementation whether these errors
are recognized in Pascal programs or not.
The validation suite results of all known implementations are given.
.PP
There does not (yet) exist a hardware EM machine.
Therefore, EM programs must be interpreted, or translated into
instructions for a target machine.
The following implementations currently exist:
.IS
.I1
an interpreter running on a PDP-11 (using UNIX).
The normal mode of operation for this interpreter is to check
for undefined integers, overflow, range errors etc.
.sp
.I2
a translator into PDP-11 instructions (using UNIX).
Less checks are performed than in the interpreter, because the translator
is intended to speed up the execution of well-debugged programs.
.IE
.CH "Test Conditions"
Tester: E.G. Keizer
.br
Date: October 1983
.br
Validation Suite version: 3.0
.PP
The final test run is made with a slightly
modified validation suite.
.SH "Erroneous programs"
Some test did not conform to the standard proposal of February 1979.
It is this version of the standard proposal that is used
by the authors of the validation suite.
.IS
.TT 6.6.3.7-4
The semicolon between high and integer on line 17 is replaced
by a colon.
.sp
.TT 6.7.2.2-13
The div operator on line 14 replaced by mod.
.CH "Conformance tests"
Number of tests passed = 150
.br
Number of tests failed = 6
.SH "Details of failed tests"
.IS
.TT 6.1.2-1
Character sequences starting with the 8 characters 'procedur'
or 'function' are
erroneously classified as the word-symbols 'procedure' and 'function'.
.sp
.TT 6.1.3-2
Identifiers identical in the first eight characters, but
differing in ninth or higher numbered characters are treated as
identical.
.sp
.TT 6.5.1-1
ACK-Pascal requires all formal program parameters to be
declared with type \fIfile\fP.
.sp
.TT 6.6.6.5-1
Gives run-time error eof seen at call to eoln.
A have a hunch that this is a error in the suit.
.sp
.TT 6.6.4.1-1
Redefining the names of some standard procedures leads to incorrect
behaviour of the runtime system.
In this case it crashes without a sensible error message.
.sp
.TT 6.9.3.5.1-1
This test can not be translated by our compiler because two
non-identical variables are used in the same block with the same first eight
characters.
The test passed after replacement of one of those names.
.IE
.CH "Deviance tests"
Number of deviations correctly detected = 120
.br
Number of tests not detecting deviations = 20
.SH "Details of deviations"
The following tests are compiled without a proper error
indication although they do
not conform to the standard.
.IS
.TT 6.1.6-5
ACK-Pascal allows labels in the range 0..32767.
A warning is produced when testing for deviations from the
standard.
.sp
.TT 6.1.8-5
A missing space between a number and a word symbol is not
detected.
.sp
.TT 6.2.2-8
.TT 6.3-6
.TT 6.4.1-3
.TT 6.6.1-3
.TT 6.6.1-4
Undetected scope error. The scope of an identifier should start at the
beginning of the block in which it is declared.
In the ACK-Pascal compiler the scope starts just after the declaration,
however.
.sp
.TT 6.4.3.3-7
The values of fields from one variant are accessible from
another variant.
The correlation is exact.
.sp
.TT 6.6.3.3-4
The passing as a variable parameter of the selector of a
variant part is not detected.
A runtime error is produced because the variant selector is not
initialized.
.sp
.TT 6.8.2.4-2
.TT 6.8.2.4-3
.TT 6.8.2.4-4
.TT 6.8.2.4-5
.TT 6.8.2.4-6
The ACK-Pascal compiler does not restrict the places from where
you may jump to a label by means of a goto-statement.
.sp
.TT 6.8.3.9-5
.TT 6.8.3.9-6
.TT 6.8.3.9-7
.TT 6.8.3.9-16
There are no errors produced for assignments to a variable
in use as control-variable of a for-statement.
.TT 6.8.3.9-8
.TT 6.8.3.9-9
Use of a controlled variable after leaving the loop without
intervening initialization is not detected.
.IE
.CH "Error handling"
The results depend on the EM implementation.
.sp
Number of errors correctly detected =
.in +5
.I1
32
.I2
17
.in -5
Number of errors not detected =
.in +5
.I1
21
.I2
36
.in -5
Number of errors incorrectly detected =
.in +5
.I1
2
.I2
2
.in -5
.SH "Details of errors not detected"
The following test fails because the ACK-Pascal compiler only
generates a warning that does not prevent to run the tests.
.IS
.TT 6.6.2-8
A warning is produced if there is no assignment to a function-identifier.
.IE
With this test the ACK-Pascal compiler issues an error message for a legal
construct not directly related to the error to be detected.
.IS
.TT 6.5.5-2
Program does not compile.
Buffer variable of text file is not allowed as variable
parameter.
.IE
The following errors are not detected at all.
.IS
.TT 6.2.1-11
.I2
The use of an undefined integer is not caught as an error.
.sp
.TT 6.4.3.3-10
.TT 6.4.3.3-11
.TT 6.4.3.3-12
.TT 6.4.3.3-13
The notion of 'current variant' is not implemented, not even if a tagfield
is present.
.sp
.TT 6.4.5-15
.TT 6.4.6-9
.TT 6.4.6-10
.TT 6.4.6-11
.TT 6.5.3.2-2
.I2
Subrange bounds are not checked.
.sp
.TT 6.4.6-12
.TT 6.4.6-13
.TT 6.7.2.4-4
If the base-type of a set is a subrange, then the set elements are not checked
against the bounds of the subrange.
Only the host-type of this subrange-type is relevant for ACK-Pascal.
.sp
.TT 6.5.4-1
.I2
Nil pointers are not detected.
.sp
.TT 6.5.4-2
.I2
Undefined pointers are not detected.
.sp
.TT 6.5.5-3
Changing the file position while the window is in use as actual variable
parameter or as an element of the record variable list of a with-statement
is not detected.
.sp
.TT 6.6.2-9
An undefined function result is not detected,
because it is never used in an expression.
.sp
.TT 6.6.5.3-6
.TT 6.6.5.3-7
Disposing a variable while it is in use as actual variable parameter or
as an element of the record variable list of a with-statement is not detected.
.sp
.TT 6.6.5.3-8
.TT 6.6.5.3-9
.TT 6.6.5.3-10
It is not detected that a record variable, created with the variant form
of new, is used as an operand in an expression or as the variable in an
assignment or as an actual value parameter.
.sp
.TT 6.6.5.3-11
Use of a variable that is not reinitialized after a dispose is
not detected.
.sp
.TT 6.6.6.4-4
.TT 6.6.6.4-5
.TT 6.6.6.4-7
.I2
There are no range checks for pred, succ and chr.
.sp
.TT 6.6.6.5-6
ACK-Pascal considers a rewrite of a file as a defining
occurence.
.sp
.TT 6.7.2.2-8
.TT 6.7.2.2-9
.TT 6.7.2.2-10
.TT 6.7.2.2-12
.I2
Division by 0 or integer overflow is not detected.
.sp
.TT 6.8.3.9-18
The use of the some control variable in two nested for
statements in not detected.
.sp
.TT 6.8.3.9-19
Access of a control variable after leaving the loop results in
the final-value, although an error should be produced.
.sp
.TT 6.9.3.2-3
The program stops with a file not open error.
The rewrite before the write is missing in the program.
.sp
.TT 6.9.3.2-4
.TT 6.9.3.2-5
Illegal FracDigits values are not detected.
.CH "Implementation dependence"
Number of tests run = 14
.br
Number of tests incorrectly handled = 0
.SH "Details of implementation dependence"
.IS
.TT 6.1.9-5
Alternate comment delimiters are implemented
.sp
.TT 6.1.9-6
The equivalent symbols @ for ^, (. for [ and .) for ] are not
implemented.
.sp
.TT 6.4.2.2-10
Maxint = 32767
.sp
.TT 6.4.3.4-5
Only elements with non-negative ordinal value are allowed in sets.
.sp
.TT 6.6.6.1-1
Standard procedures and functions are not allowed as parameters.
.sp
.TT 6.6.6.2-11
Details of the machine characteristics regarding real numbers:
.IS
.nf
beta = 2
t = 56
rnd = 1
ngrd = 0
machep = -56
negep = -56
iexp = 8
minexp = -128
maxexp = 127
eps = 1.387779e-17
epsneg = 1.387779e-17
xmin = 2.938736e-39
xmax = 1.701412e+38
.fi
.IE
.sp
.TT 6.7.2.3-3
.TT 6.7.2.3-4
All operands of boolean expressions are evaluated.
.sp
.TT 6.8.2.2-1
.TT 6.8.2.2-2
The expression in an assignment statement is evaluated
before the variable selection if this involves pointer
dereferencing or array indexing.
.sp
.TT 6.8.2.3-2
Actual parameters are evaluated in reverse order.
.sp
.TT 6.9.3.2-6
The default width for integer, Boolean and real are 6, 5 and 13.
.sp
.TT 6.9.3.5.1-2
The number of digits written in an exponent is 2.
.sp
.TT 6.9.3.6-1
The representations of true and false are (~true) and (false).
The parenthesis serve to indicate width.
.IE
.CH "Quality measurement"
Number of tests run = 60
.br
Number of tests handled incorrectly = 1
.SH "Results of tests"
Several test perform operations on reals on indicate the error
introduced by these operations.
For each of these tests the following two quality measures are extracted:
.sp
.in +5
maxRE:~~maximum relative error
.br
rmsRE:~~root-mean-square relative error
.in -5
.sp 2
.IS
.TT 1.2-1
.I1
25 thousand Whetstone instructions per second.
.I2
169 thousand Whetstone instructions per second.
.sp
.TT 1.2-2
The value of (TRUEACC-ACC)*2^56/100000 is 1.4 .
This is well within the bounds specified in [3].
.br
The GAMM measure is:
.I1
238 microseconds
.I2
26.3 microseconds.
.sp
.TT 1.2-3
The number of procedure calls calculated in this test exceeds
the maximum integer value.
The program stops indicating overflow.
.sp
.TT 6.1.3-3
The number of significant characters for identifiers is 8.
.sp
.TT 6.1.5-8
There is no maximum to the line length.
.sp
.TT 6.1.5-9
The error message "too many digits" is given for numbers larger
than maxint.
.sp
.TT 6.1.5-10
.TT 6.1.5-11
.TT 6.1.5-12
Normal values are allowed for real constants and variables.
.sp
.TT 6.1.7-14
A reasonably large number of strings is allowed.
.sp
.TT 6.1.8-6
No warning is given for possibly unclosed comments.
.sp
.TT 6.2.1-12
.TT 6.2.1-13
.TT 6.2.1-14
.TT 6.2.1-15
.TT 6.5.1-2
Large lists of declarations are possible in each block.
.sp
.TT 6.4.3.2-6
An 'array[integer] of' is not allowed.
.sp
.TT 6.4.3.2-7
.TT 6.4.3.2-8
Large values are allowed for arrays and indices.
.sp
.TT 6.4.3.3-14
Large amounts of case-constant values are allowed in variants.
.sp
.TT 6.4.3.3-15
Large amounts of record sections can appear in the fixed part of
a record.
.sp
.TT 6.4.3.3-16
Large amounts of variants are allowed in a record.
.TT 6.4.3.4-4
Size and speed of Warshall's algorithm depend on the
implementation of EM:
.IS
.I1
.br
size: 122 bytes
.br
speed: 5.2 seconds
.sp
.I2
.br
size: 196 bytes
.br
speed: 0.7 seconds
.IE
.TT 6.5.3.2-3
Deep nesting of array indices is allowed.
.sp
.TT 6.5.3.2-4
.TT 6.5.3.2-5
Arrays can have at least 8 dimensions.
.sp
.TT 6.6.1-8
Deep static nesting of procedure is allowed.
.sp
.TT 6.6.3.1-6
Large amounts of formal parameters are allowed.
.sp
.TT 6.6.5.3-12
Dispose is fully implemented.
.sp
.TT 6.6.6.2-6
Test sqrt(x): no errors.
The error is within acceptable bounds.
.in +5
maxRE:~~2~**~-55.50
.br
rmsRE:~~2~**~-57.53
.in -5
.sp
.TT 6.6.6.2-7
Test arctan(x): may cause underflow or overflow errors.
The error is within acceptable bounds.
.in +5
.br
maxRE:~~2~**~-55.00
.br
rmsRE:~~2~**~-56.36
.in -5
.sp
.TT 6.6.6.2-8
Test exp(x): may cause underflow or overflow errors.
The error is not within acceptable bounds.
.in +5
maxRE:~~2~**~-50.03
.br
rmsRE:~~2~**~-51.03
.in -5
.sp
.TT 6.6.6.2-9
Test sin(x): may cause underflow errors.
The error is not within acceptable bounds.
.in +5
maxRE:~~2~**~-38.20
.br
rmsRE:~~2~**~-43.68
.in -5
.sp
Test cos(x): may cause underflow errors.
The error is not within acceptable bounds.
.in +5
maxRE:~~2~**~-41.33
.br
rmsRE:~~2~**~-46.62
.in -5
.sp
.TT 6.6.6.2-10
Test ln(x):
The error is not within acceptable bounds.
.in +5
maxRE:~~2~**~-54.05
.br
rmsRE:~~2~**~-55.77
.in -5
.sp
.TT 6.7.1-3
.TT 6.7.1-4
.TT 6.7.1-5
Complex nested expressions are allowed.
.sp
.TT 6.7.2.2-14
Test real division:
The error is within acceptable bounds.
.in +5
maxRE:~~0
.br
rmsRE:~~0
.in -5
.sp
.TT 6.7.2.2-15
Operations of reals in the integer range are exact.
.sp
.TT 6.7.3-1
.TT 6.8.3.2-1
.TT 6.8.3.4-2
.TT 6.8.3.5-15
.TT 6.8.3.7-4
.TT 6.8.3.8-3
.TT 6.8.3.9-20
.TT 6.8.3.10-7
Static deep nesting of function calls,
compound statements, if statements, case statements, repeat
loops, while loops, for loops and with statements is possible.
.sp
.TT 6.8.3.2-2
Large amounts of statements are allowed in a compound
statement.
.sp
.TT 6.8.3.5-12
The compiler requires case constants to be compatible with
the case selector.
.sp
.TT 6.8.3.5-13
.TT 6.8.3.5-14
Large case statements are possible.
.sp
.TT 6.9-2
Recursive IO on the same file is well-behaved.
.sp
.TT 6.9.1-6
The reading of real values from a text file is done with
sufficient accuracy.
.in +5
maxRE:~~2~**~-54.61
.br
rmsRE:~~2~**~-56.32
.in -5
.sp
.TT 6.9.1-7
.TT 6.9.2-2
.TT 6.9.3-3
.TT 6.9.4-2
Read, readln, write and writeln may have large amounts of
parameters.
.sp
.TT 6.9.1-8
The loss of precision for reals written on a text file and read
back is:
.in +5
maxRE:~~2~**~-53.95
.br
rmsRE:~~2~**~-55.90
.in -5
.sp
.TT 6.9.3-2
File IO buffers without trailing marker are correctly flushed.
.sp
.TT 6.9.3.5.2-2
Reals are written with sufficient accuracy.
.in +5
maxRE:~~0
.br
rmsRE:~~0
.in -5
.IE
.CH "Level 1 conformance tests"
Number of test passed = 4
.br
Number of tests failed = 1
.SH "Details of failed tests"
.IS
.TT 6.6.3.7-4
An expression indicated by parenthesis whose
value is a conformant array is not allowed.
.IE
.CH "Level 1 deviance tests"
Number of deviations correctly detected = 4
.br
Number of tests not detecting deviations = 0
.IE
.CH "Level 1 error handling"
The results depend on the EM implementation.
.sp
Number of errors correctly detected =
.in +5
.I1
1
.I2
0
.in -5
Number of errors not detected =
.in +5
.I1
0
.I2
1
.in -5
.SH "Details of errors not detected"
.IS
.TT 6.6.3.7-9
.I2
Subrange bounds are not checked.
.IE
.CH "Level 1 quality measurement"
Number of tests run = 1
.SH "Results of test"
.IS
.TT 6.6.3.7-10
Large conformant arrays are allowed.
.IE
.CH "Extensions"
Number of tests run = 3
.SH Details of test failed
.IS
.TT 6.1.9-7
The alternative relational operators are not allowed.
.sp
.TT 6.1.9-8
The alternative symbols for colon, semicolon and assignment are
not allowed.
.sp
.TT 6.8.3.5-16
The otherwise selector in case statements is not allowed.
.IE
.CH "References"
.ti -5
[1]~~\
A.S.Tanenbaum, E.G.Keizer, J.W.Stevenson, Hans van Staveren,
"Description of a machine architecture for use with block structured
languages",
Informatica rapport IR-81.
.ti -5
[2]~~\
ISO standard proposal ISO/TC97/SC5-N462, dated February 1979.
The same proposal, in slightly modified form, can be found in:
A.M.Addyman e.a., "A draft description of Pascal",
Software, practice and experience, May 1979.
An improved version, received March 1980,
is followed as much as possible for the
current ACK-Pascal.
.ti -5
[3]~~\
B. A. Wichman and J du Croz,
A program to calculate the GAMM measure, Computer Journal,
November 1979.

352
etc/ip_spec.t
View File

@ -1,352 +0,0 @@
aar mwPo 1 34
adf sP 1 35
adi mwPo 2 36
adp 2 38
adp mPo 2 39
adp sP 1 41
adp sN 1 42
ads mwPo 1 43
and mwPo 1 44
asp mwPo 5 45
asp swP 1 50
beq 2 51
beq sP 1 52
bge sP 1 53
bgt sP 1 54
ble sP 1 55
blm sP 1 56
blt sP 1 57
bne sP 1 58
bra 2 59
bra sN 2 60
bra sP 2 62
cal mPo 28 64
cal sP 1 92
cff - 93
cif - 94
cii - 95
cmf sP 1 96
cmi mwPo 2 97
cmp - 99
cms sP 1 100
csa mwPo 1 101
csb mwPo 1 102
dec - 103
dee sw 1 104
del swN 1 105
dup mwPo 1 106
dvf sP 1 107
dvi mwPo 1 108
fil 2 109
inc - 110
ine w2 111
ine sw 1 112
inl mwN 3 113
inl swN 1 116
inn sP 1 117
ior mwPo 1 118
ior sP 1 119
lae 2 120
lae sw 7 121
lal P2 128
lal N2 129
lal m 1 130
lal mN 1 131
lal swP 1 132
lal swN 2 133
lar mwPo 1 135
ldc mP 1 136
lde w2 137
lde sw 1 138
ldl mP 1 139
ldl swN 1 140
lfr mwPo 2 141
lfr sP 1 143
lil swN 1 144
lil swP 1 145
lil mwP 2 146
lin 2 148
lin sP 1 149
lni - 150
loc 2 151
loc mP 34 0
loc mN 1 152
loc sP 1 153
loc sN 1 154
loe w2 155
loe sw 5 156
lof 2 161
lof mwPo 4 162
lof sP 1 166
loi 2 167
loi mPo 1 168
loi mwPo 4 169
loi sP 1 173
lol wP2 174
lol wN2 175
lol mwP 4 176
lol mwN 8 180
lol swP 1 188
lol swN 1 189
lxa mPo 1 190
lxl mPo 2 191
mlf sP 1 193
mli mwPo 2 194
rck mwPo 1 196
ret mwP 2 197
ret sP 1 199
rmi mwPo 1 200
sar mwPo 1 201
sbf sP 1 202
sbi mwPo 2 203
sdl swN 1 205
set sP 1 206
sil swN 1 207
sil swP 1 208
sli mwPo 1 209
ste w2 210
ste sw 3 211
stf 2 214
stf mwPo 2 215
stf sP 1 217
sti mPo 1 218
sti mwPo 4 219
sti sP 1 223
stl wP2 224
stl wN2 225
stl mwP 2 226
stl mwN 5 228
stl swN 1 233
teq - 234
tgt - 235
tlt - 236
tne - 237
zeq 2 238
zeq sP 2 239
zer sP 1 241
zge sP 1 242
zgt sP 1 243
zle sP 1 244
zlt sP 1 245
zne sP 1 246
zne sN 1 247
zre w2 248
zre sw 1 249
zrl mwN 2 250
zrl swN 1 252
zrl wN2 253
aar e2 0
aar e- 1
adf e2 2
adf e- 3
adi e2 4
adi e- 5
ads e2 6
ads e- 7
adu e2 8
adu e- 9
and e2 10
and e- 11
asp ew2 12
ass e2 13
ass e- 14
bge e2 15
bgt e2 16
ble e2 17
blm e2 18
bls e2 19
bls e- 20
blt e2 21
bne e2 22
cai e- 23
cal e2 24
cfi e- 25
cfu e- 26
ciu e- 27
cmf e2 28
cmf e- 29
cmi e2 30
cmi e- 31
cms e2 32
cms e- 33
cmu e2 34
cmu e- 35
com e2 36
com e- 37
csa e2 38
csa e- 39
csb e2 40
csb e- 41
cuf e- 42
cui e- 43
cuu e- 44
dee ew2 45
del ewP2 46
del ewN2 47
dup e2 48
dus e2 49
dus e- 50
dvf e2 51
dvf e- 52
dvi e2 53
dvi e- 54
dvu e2 55
dvu e- 56
fef e2 57
fef e- 58
fif e2 59
fif e- 60
inl ewP2 61
inl ewN2 62
inn e2 63
inn e- 64
ior e2 65
ior e- 66
lar e2 67
lar e- 68
ldc e2 69
ldf e2 70
ldl ewP2 71
ldl ewN2 72
lfr e2 73
lil ewP2 74
lil ewN2 75
lim e- 76
los e2 77
los e- 78
lor esP 1 79
lpi e2 80
lxa e2 81
lxl e2 82
mlf e2 83
mlf e- 84
mli e2 85
mli e- 86
mlu e2 87
mlu e- 88
mon e- 89
ngf e2 90
ngf e- 91
ngi e2 92
ngi e- 93
nop e- 94
rck e2 95
rck e- 96
ret e2 97
rmi e2 98
rmi e- 99
rmu e2 100
rmu e- 101
rol e2 102
rol e- 103
ror e2 104
ror e- 105
rtt e- 106
sar e2 107
sar e- 108
sbf e2 109
sbf e- 110
sbi e2 111
sbi e- 112
sbs e2 113
sbs e- 114
sbu e2 115
sbu e- 116
sde e2 117
sdf e2 118
sdl ewP2 119
sdl ewN2 120
set e2 121
set e- 122
sig e- 123
sil ewP2 124
sil ewN2 125
sim e- 126
sli e2 127
sli e- 128
slu e2 129
slu e- 130
sri e2 131
sri e- 132
sru e2 133
sru e- 134
sti e2 135
sts e2 136
sts e- 137
str esP 1 138
tge e- 139
tle e- 140
trp e- 141
xor e2 142
xor e- 143
zer e2 144
zer e- 145
zge e2 146
zgt e2 147
zle e2 148
zlt e2 149
zne e2 150
zrf e2 151
zrf e- 152
zrl ewP2 153
dch e- 154
exg esP 1 155
exg e2 156
exg e- 157
lpb e- 158
gto e2 159
ldc 4 0
lae 4 1
lal P4 2
lal N4 3
lde w4 4
ldf 4 5
ldl wP4 6
ldl wN4 7
lil wP4 8
lil wN4 9
loc 4 10
loe w4 11
lof 4 12
lol wP4 13
lol wN4 14
lpi 4 15
adp 4 16
asp w4 17
beq 4 18
bge 4 19
bgt 4 20
ble 4 21
blm 4 22
blt 4 23
bne 4 24
bra 4 25
cal 4 26
dee w4 27
del wP4 28
del wN4 29
fil 4 30
gto 4 31
ine w4 32
inl wP4 33
inl wN4 34
lin 4 35
sde 4 36
sdf 4 37
sdl wP4 38
sdl wN4 39
sil wP4 40
sil wN4 41
ste w4 42
stf 4 43
stl wP4 44
stl wN4 45
zeq 4 46
zge 4 47
zgt 4 48
zle 4 49
zlt 4 50
zne 4 51
zre w4 52
zrl wP4 53
zrl wN4 54

7
first/em_path.h.src
View File

@ -1,7 +0,0 @@
/* Intended as a common directory for ALL temporary files */
#define TMP_DIR "/usr/tmp"
/* Access to the ACK tree and parts thereof */
#define EM_DIR "/usr/em" /* The root directory for EM stuff */
#define RTERR_PATH "etc/pc_rt_errors"
#define ACK_PATH "lib/ack"

7
first/local.h.src
View File

@ -1,7 +0,0 @@
/* collection of options, selected by including or excluding 'defines' */
/* Version number of the EM object code */
# define VERSION 3 /* 16 bits number */
/* The default machine used by ack, acc, apc */
# define ACKM "vax2"

10
h/Makefile
View File

@ -1,10 +0,0 @@
install cmp:
opr:
make pr | opr
pr:
@pr Makefile *.h
clean:
-rm -f *.old

12
h/arch.h
View File

@ -1,12 +0,0 @@
#define ARMAG 0177545
struct ar_hdr {
char ar_name[14];
long ar_date;
char ar_uid;
char ar_gid;
int ar_mode;
long ar_size;
};
#define AR_TOTAL 26
#define AR_SIZE 22

1
h/as_spec.h
View File

@ -1 +0,0 @@
#define as_magic (sp_magic|(14<<8))

156
h/cg_pattern.h
View File

@ -1,156 +0,0 @@
/* offsets of interesting fields in EM-pattern */
#define PO_HASH 0
#define PO_NEXT 1
#define PO_MATCH 3
#define ILLHASH 0177777
/* Escapes in printstrings */
#define PR_TOK '\001'
#define PR_TOKFLD '\002'
#define PR_EMINT '\003'
#define PR_EMSTR '\004'
#define PR_ALLREG '\005'
#define PR_SUBREG '\006'
/*
* In case this list gets longer remember to keep out printable nonprintables
* like \t \n \r and the like.
*/
/* Commands for codegenerator, in low order 5 bits of byte */
#define DO_NEXTEM 0
#define DO_MATCH 1
#define DO_XMATCH 2
#define DO_XXMATCH 3
#define DO_REMOVE 4
#define DO_DEALLOCATE 5
#define DO_REALLOCATE 6
#define DO_ALLOCATE 7
#define DO_LOUTPUT 8
#define DO_ROUTPUT 9
#define DO_MOVE 10
#define DO_ERASE 11
#define DO_TOKREPLACE 12
#define DO_EMREPLACE 13
#define DO_COST 14
#define DO_RETURN 15
#define DO_COERC 16
#define DO_PRETURN 17
#define DO_RREMOVE 18
typedef struct instance {
int in_which;
# define IN_COPY 1
# define IN_RIDENT 2
# define IN_ALLOC 3
# define IN_DESCR 4
# define IN_REGVAR 5
int in_info[TOKENSIZE+1];
} inst_t,*inst_p;
typedef struct {
int c_size; /* index in enode-table */
int c_time; /* dito */
} cost_t,*cost_p;
typedef struct {
int m_set1; /* number of tokenexpr in move: from */
int m_expr1; /* optional expression */
int m_set2; /* number of tokenexpr in move: to */
int m_expr2; /* optional expression */
int m_cindex; /* code index to really do it */
cost_t m_cost; /* associated cost */
} move_t, *move_p;
typedef struct {
int set_size;
short set_val[SETSIZE];
} set_t,*set_p;
struct exprnode {
short ex_operator;
short ex_lnode;
short ex_rnode;
};
typedef struct exprnode node_t;
typedef struct exprnode *node_p;
typedef struct { /* to stack coercions */
int c1_texpno; /* token expression number */
int c1_expr; /* boolean expression */
int c1_prop; /* property of register needed */
int c1_codep; /* code index */
cost_t c1_cost; /* cost involved */
} c1_t,*c1_p;
#ifdef MAXSPLIT
typedef struct { /* splitting coercions */
int c2_texpno; /* token expression number */
int c2_nsplit; /* split factor */
int c2_repl[MAXSPLIT]; /* replacement instances */
int c2_codep; /* code index */
} c2_t,*c2_p;
#endif MAXSPLIT
typedef struct { /* one to one coercions */
int c3_texpno; /* token expression number */
int c3_prop; /* property of register needed */
int c3_repl; /* replacement instance */
int c3_codep; /* code index */
} c3_t,*c3_p;
/*
* contents of .ex_operator
*/
#define EX_TOKFIELD 0
#define EX_ARG 1
#define EX_CON 2
#define EX_ALLREG 3
#define EX_SAMESIGN 4
#define EX_SFIT 5
#define EX_UFIT 6
#define EX_ROM 7
#define EX_NCPEQ 8
#define EX_SCPEQ 9
#define EX_RCPEQ 10
#define EX_NCPNE 11
#define EX_SCPNE 12
#define EX_RCPNE 13
#define EX_NCPGT 14
#define EX_NCPGE 15
#define EX_NCPLT 16
#define EX_NCPLE 17
#define EX_OR2 18
#define EX_AND2 19
#define EX_PLUS 20
#define EX_CAT 21
#define EX_MINUS 22
#define EX_TIMES 23
#define EX_DIVIDE 24
#define EX_MOD 25
#define EX_LSHIFT 26
#define EX_RSHIFT 27
#define EX_NOT 28
#define EX_COMP 29
#define EX_COST 30
#define EX_STRING 31
#define EX_DEFINED 32
#define EX_SUBREG 33
#define EX_TOSTRING 34
#define EX_UMINUS 35
#define EX_REG 36
#define EX_LOWW 37
#define EX_HIGHW 38
#define EX_INREG 39
#define EX_REGVAR 40
#define getint(a,b) \
if ((a=((*(b)++)&BMASK)) >= 128) {\
a = ((a-128)<<BSHIFT) | (*(b)++&BMASK); \
}

30
h/em_abs.h
View File

@ -1,30 +0,0 @@
#define LINO_AD 0
#define FILN_AD 4
#define LINO (*(int *)(_hol0()+LINO_AD))
#define FILN (*(char **)(_hol0()+FILN_AD))
#define EARRAY 0
#define ERANGE 1
#define ESET 2
#define EIOVFL 3
#define EFOVFL 4
#define EFUNFL 5
#define EIDIVZ 6
#define EFDIVZ 7
#define EIUND 8
#define EFUND 9
#define ECONV 10
#define ESTACK 16
#define EHEAP 17
#define EILLINS 18
#define EODDZ 19
#define ECASE 20
#define EMEMFLT 21
#define EBADPTR 22
#define EBADPC 23
#define EBADLAE 24
#define EBADMON 25
#define EBADLIN 26
#define EBADGTO 27

12
h/em_ego.h
View File

@ -1,12 +0,0 @@
/*
* The various different hints as given after a mes ms_ego
*
* Yet to be stabilized
*/
#define ego_live 0 /* ,offset,size,regno */
#define ego_dead 1 /* ,offset,size,regno */
#define ego_assoc 2 /* ,offset,size,regno */
#define ego_unass 3 /* ,offset,size,regno */
#define ego_init 4 /* ,offset,size,regno */
#define ego_update 5 /* ,offset,size,regno */

25
h/em_flag.h
View File

@ -1,25 +0,0 @@
/* flags */
#define EM_PAR 0017 /* parameter type */
#define EM_FLO 0060 /* flow information */
/* types */
#define PAR_NO 0000 /* no parameter */
#define PAR_C 0001 /* constant */
#define PAR_D 0002 /* double word constant */
#define PAR_N 0003 /* numeric (>=0) */
#define PAR_F 0004 /* address offset */
#define PAR_L 0005 /* addressing locals/parameters */
#define PAR_G 0006 /* addressing globals */
#define PAR_W 0007 /* size: word multiple, fits word, possibly indirect */
#define PAR_S 0010 /* size: word multiple */
#define PAR_Z 0011 /* size: zero or word multiple */
#define PAR_O 0012 /* size: word multiple or word fraction */
#define PAR_P 0013 /* procedure name */
#define PAR_B 0014 /* branch: instruction label */
#define PAR_R 0015 /* register number (0,1,2) */
/* flow */
#define FLO_NO 0000 /* straight on */
#define FLO_C 0020 /* conditional branch */
#define FLO_P 0040 /* procedure: call and return */
#define FLO_T 0060 /* terminate: no return */

21
h/em_mes.h
View File

@ -1,21 +0,0 @@
/*
* mnemonics for the message numbers in EM
*/
#define ms_err 0 /* Compilation error occurred, ignore rest of module */
#define ms_opt 1 /* Disable optimization please */
#define ms_emx 2 /* Wordsize and pointersize assumed */
#define ms_reg 3 /* Hint for possible register usage from frontend */
#define ms_src 4 /* Number of source lines in this module */
#define ms_flt 5 /* Floating point used */
#define ms_com 6 /* Comment to be retained in compact code */
#define ms_ret 7 /* Reserved */
#define ms_ext 8 /* List of exported symbols from this library module */
#define ms_par 9 /* Number of bytes of parameters accessed */
#define ms_ego 10 /* Hint from EM Global Optimizer */
#define ms_gto 11 /* Dangerous procedure, uses nonlocal goto */
/*
* for details about ms_reg, see em_reg.h
* for details about ms_ego, see em_ego.h
*/

8
h/em_ptyp.h
View File

@ -1,8 +0,0 @@
#define ptyp(x) (1<<(x-sp_fspec))
#define cst_ptyp 0000140
#define sym_ptyp 0000034
#define arg_ptyp 0000574
#define con_ptyp 0036000
#define val_ptyp 0037777
#define any_ptyp 0137777

10
h/em_reg.h
View File

@ -1,10 +0,0 @@
/*
* mes ms_reg,offset,size,type,priority
*
* Here are the defines for type
*/
#define reg_any 0 /* Unspecified type */
#define reg_loop 1 /* loop control variable */
#define reg_pointer 2 /* pointer variable */
#define reg_float 3 /* floating point variable */

22
h/pc_err.h
View File

@ -1,22 +0,0 @@
#define EARGC 64
#define EEXP 65
#define ELOG 66
#define ESQT 67
#define EASS 68
#define EPACK 69
#define EUNPACK 70
#define EMOD 71
#define EBADF 72
#define EFREE 73
#define EWRITEF 96
#define EREADF 97
#define EEOF 98
#define EFTRUNC 99
#define ERESET 100
#define EREWR 101
#define ECLOSE 102
#define EREAD 103
#define EWRITE 104
#define EDIGIT 105
#define EASCII 106

19
h/pc_file.h
View File

@ -1,19 +0,0 @@
#define WRBIT 0100000
#define TXTBIT 040000
#define EOFBIT 020000
#define ELNBIT 010000
#define WINDOW 04000
#define MAGIC 0252
struct file {
char *ptr;
unsigned flags;
char *fname;
int ufd;
int size;
int count;
int buflen;
char bufadr[512];
};
#define EXTFL(z) ((struct file *)(_hbase + _extfl[z]))

21
h/pc_size.h
View File

@ -1,21 +0,0 @@
/* fundamental */
#define sz_byte 1
#define sz_bool 1
#define sz_char 1
/* fixed for the time being */
#define sz_word 2
#define sz_int 2
#define sz_long 4
/* variable (see pc.c) */
#define sz_addr sizes[0]
#define sz_real sizes[1]
#define sz_head sizes[2]
#define sz_buff sizes[3]
#define sz_mset sizes[4]
#define sz_iset sizes[5]
#define sz_last 5
#define sz_proc 2*sz_addr

1
include/_tail_cc/setjmp.h
View File

@ -1 +0,0 @@
typedef char jmp_buf[256];

42
include/_tail_mon/errno.h
View File

@ -1,42 +0,0 @@
/*
* Error codes
*/
#define EPERM 1
#define ENOENT 2
#define ESRCH 3
#define EINTR 4
#define EIO 5
#define ENXIO 6
#define E2BIG 7
#define ENOEXEC 8
#define EBADF 9
#define ECHILD 10
#define EAGAIN 11
#define ENOMEM 12
#define EACCES 13
#define EFAULT 14
#define ENOTBLK 15
#define EBUSY 16
#define EEXIST 17
#define EXDEV 18
#define ENODEV 19
#define ENOTDIR 20
#define EISDIR 21
#define EINVAL 22
#define ENFILE 23
#define EMFILE 24
#define ENOTTY 25
#define ETXTBSY 26
#define EFBIG 27
#define ENOSPC 28
#define ESPIPE 29
#define EROFS 30
#define EMLINK 31
#define EPIPE 32
/* math software */
#define EDOM 33
#define ERANGE 34
#define EQUOT 35

71
lang/pc/libpc/LIST
View File

@ -1,71 +0,0 @@
tail_pc.a
abi.c
abl.c
abr.c
arg.c
ass.c
asz.c
atn.c
bcp.c
bts.e
buff.c
clock.c
diag.c
dis.c
efl.c
eln.c
encaps.e
exp.c
get.c
gto.e
hlt.c
ini.c
catch.c
log.c
mdi.c
mdl.c
new.c
nobuff.c
notext.c
opn.c
hol0.e
pac.c
pclose.c
pcreat.c
pentry.c
perrno.c
pexit.c
popen.c
cls.c
put.c
rdc.c
rdl.c
rdr.c
rdi.c
rln.c
rf.c
rnd.c
sav.e
sig.e
sin.c
sqt.c
fef.e
string.c
trap.e
unp.c
uread.c
uwrite.c
wdw.c
incpt.c
wrc.c
wrf.c
wri.c
wrl.c
wrr.c
cvt.c
fif.e
wrz.c
wrs.c
outcpt.c
wf.c
trp.e

16
lang/pc/libpc/Makefile
View File

@ -1,16 +0,0 @@
# $Header$
head:
echo This Makefile needs arguments
distr:
rm `head -1 LIST`; arch cr `head -1 LIST` `tail +2 LIST`
clean:
rm -f *.old
opr:
make pr | opr
pr:
@pr Makefile *.[ec]

11
lang/pc/libpc/READ_ME
View File

@ -1,11 +0,0 @@
problems:
- names of system call routines may clash with user routines
- some modules in Pascal?
- ttyio, stdio, pasio, unixio
- mention all external references
- list of routines and partitioning
- size of sizes in asz,bcp,dis,new,opn,pac,unp: int or long ?
NOTE:
The run files in mach/*/libpc show the actual usage of this
library.

23
lang/pc/libpc/abi.c
View File

@ -1,23 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
int _abi(i) int i; {
return(i>=0 ? i : -i);
}

23
lang/pc/libpc/abl.c
View File

@ -1,23 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
long _abl(i) long i; {
return(i>=0 ? i : -i);
}

23
lang/pc/libpc/abr.c
View File

@ -1,23 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
double _abr(r) double r; {
return(r>=0 ? r : -r);
}

56
lang/pc/libpc/arg.c
View File

@ -1,56 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
/*
/* function argc:integer; extern; */
/* function argv(i:integer):string; extern; */
/* procedure argshift; extern; */
/* function environ(i:integer):string; extern; */
extern int _pargc;
extern char **_pargv;
extern char **_penvp;
int argc() {
return(_pargc);
}
char *argv(i) {
if (i >= _pargc)
return(0);
return(_pargv[i]);
}
argshift() {
if (_pargc > 1) {
--_pargc;
_pargv++;
}
}
char *environ(i) {
char **p; char *q;
if (p = _penvp)
while (q = *p++)
if (i-- < 0)
return(q);
return(0);
}

33
lang/pc/libpc/ass.c
View File

@ -1,33 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <em_abs.h>
#include <pc_err.h>
extern char *_hol0();
extern _trp();
_ass(line,bool) int line,bool; {
if (bool==0) {
LINO = line;
_trp(EASS);
}
}

29
lang/pc/libpc/asz.c
View File

@ -1,29 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
struct descr {
int low;
int diff;
int size;
};
int _asz(dp) struct descr *dp; {
return(dp->size * (dp->diff + 1));
}

74
lang/pc/libpc/atn.c
View File

@ -1,74 +0,0 @@
/* $Header$ */
/*
floating-point arctangent
atan returns the value of the arctangent of its
argument in the range [-pi/2,pi/2].
there are no error returns.
coefficients are #5077 from Hart & Cheney. (19.56D)
*/
static double sq2p1 = 2.414213562373095048802e0;
static double sq2m1 = .414213562373095048802e0;
static double pio2 = 1.570796326794896619231e0;
static double pio4 = .785398163397448309615e0;
static double p4 = .161536412982230228262e2;
static double p3 = .26842548195503973794141e3;
static double p2 = .11530293515404850115428136e4;
static double p1 = .178040631643319697105464587e4;
static double p0 = .89678597403663861959987488e3;
static double q4 = .5895697050844462222791e2;
static double q3 = .536265374031215315104235e3;
static double q2 = .16667838148816337184521798e4;
static double q1 = .207933497444540981287275926e4;
static double q0 = .89678597403663861962481162e3;
/*
xatan evaluates a series valid in the
range [-0.414...,+0.414...].
*/
static double
xatan(arg)
double arg;
{
double argsq;
double value;
argsq = arg*arg;
value = ((((p4*argsq + p3)*argsq + p2)*argsq + p1)*argsq + p0);
value = value/(((((argsq + q4)*argsq + q3)*argsq + q2)*argsq + q1)*argsq + q0);
return(value*arg);
}
static double
satan(arg)
double arg;
{
if(arg < sq2m1)
return(xatan(arg));
else if(arg > sq2p1)
return(pio2 - xatan(1/arg));
else
return(pio4 + xatan((arg-1)/(arg+1)));
}
/*
atan makes its argument positive and
calls the inner routine satan.
*/
double
_atn(arg)
double arg;
{
if(arg>0)
return(satan(arg));
else
return(-satan(-arg));
}

30
lang/pc/libpc/bcp.c
View File

@ -1,30 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
int _bcp(sz,y,x) int sz; char *y,*x; {
while (--sz >= 0) {
if (*x < *y)
return(-1);
if (*x++ > *y++)
return(1);
}
return(0);
}

56
lang/pc/libpc/bts.e
View File

@ -1,56 +0,0 @@
#
; $Header$
;
; (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
;
; This product is part of the Amsterdam Compiler Kit.
;
; Permission to use, sell, duplicate or disclose this software must be
; obtained in writing. Requests for such permissions may be sent to
;
; Dr. Andrew S. Tanenbaum
; Wiskundig Seminarium
; Vrije Universiteit
; Postbox 7161
; 1007 MC Amsterdam
; The Netherlands
;
;
; Author: J.W. Stevenson */
mes 2,EM_WSIZE,EM_PSIZE
#define SIZE 0
#define HIGH EM_WSIZE
#define LOWB 2*EM_WSIZE
#define BASE 3*EM_WSIZE
; _bts is called with four parameters:
; - the initial set (BASE)
; - low bound of range of bits (LOWB)
; - high bound of range of bits (HIGH)
; - set size in bytes (SIZE)
exp $_bts
pro $_bts,0
lal BASE ; address of initial set
lol SIZE
los EM_WSIZE ; load initial set
1
lol LOWB ; low bound
lol HIGH ; high bound
bgt *2 ; while low <= high
lol LOWB
lol SIZE
set ? ; create [low]
lol SIZE
ior ? ; merge with initial set
inl LOWB ; increment low bound
bra *1 ; loop back
2
lal BASE
lol SIZE
sts EM_WSIZE ; store result over initial set
ret 0
end ?

35
lang/pc/libpc/buff.c
View File

@ -1,35 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_file.h>
extern _flush();
/* procedure buff(var f:file of ?); */
buff(f) struct file *f; {
int sz;
if ((f->flags & (0377|WRBIT)) != (MAGIC|WRBIT))
return;
_flush(f);
sz = f->size;
f->count = f->buflen = (sz>512 ? sz : 512-512%sz);
}

102
lang/pc/libpc/catch.c
View File

@ -1,102 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
#include <em_abs.h>
#include <em_path.h>
#include <pc_file.h>
#define MESLEN 30
#define PATHLEN 100
extern struct file *_curfil;
extern int _pargc;
extern char **_pargv;
extern char **_penvp;
extern char *_hol0();
extern _trp();
extern exit();
extern int open();
extern int read();
extern int write();
/* Modified not to use a table of indices any more. This circumvents yet
another point where byte order in words would make you lose.
*/
_catch(erno) unsigned erno; {
char *p,*q,**qq;
unsigned i;
int fd;
char *pp[8];
char mes[MESLEN];
char filename[PATHLEN];
char c;
qq = pp;
if (p = FILN)
*qq++ = p;
else
*qq++ = _pargv[0];
p = &("xxxxx: "[5]);
if (i = LINO) {
*qq++ = ", ";
do
*--p = i % 10 + '0';
while (i /= 10);
}
*qq++ = p;
if ((erno & ~037) == 0140 && (_curfil->flags&0377)==MAGIC) {
/* file error */
*qq++ = "file ";
*qq++ = _curfil->fname;
*qq++ = ": ";
}
if ( (i=strtobuf(EM_DIR,filename,PATHLEN)) >= PATHLEN-1 ||
(filename[i]='/' ,
strtobuf(RTERR_PATH,filename+i+1,PATHLEN-i-1) >= PATHLEN-i-1
) )
goto error;
if ((fd=open(filename,0))<0)
goto error;
/* skip to correct message */
for(i=0;i<erno;i++)
do if (read(fd,&c,1)!=1)
goto error;
while (c!= '\n');
if(read(fd,mes,MESLEN-1)<=0)
goto error;
mes[MESLEN-1]=0;
for(i=0;i<MESLEN-1;i++)
if(mes[i]=='\n')
mes[i+1]=0;
*qq++ = mes;
*qq = 0;
qq = pp;
while (q = *qq++) {
p = q;
while (*p)
p++;
if (write(2,q,p-q) < 0)
;
}
exit(erno);
error:
_trp(erno);
}

37
lang/pc/libpc/clock.c
View File

@ -1,37 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
/* function clock:integer; extern; */
extern int times();
struct tbuf {
long utime;
long stime;
long cutime;
long cstime;
};
int clock() {
struct tbuf t;
times(&t);
return( (t.utime + t.stime) & 077777);
}

67
lang/pc/libpc/cls.c
View File

@ -1,67 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_file.h>
#include <pc_err.h>
extern struct file *_curfil;
extern _trp();
extern _flush();
extern _outcpt();
extern int close();
_xcls(f) struct file *f; {
if ((f->flags & WRBIT) == 0)
return;
if ((f->flags & (TXTBIT|ELNBIT)) == TXTBIT) {
#ifdef CPM
*f->ptr = '\r';
_outcpt(f);
#endif
*f->ptr = '\n';
_outcpt(f);
}
_flush(f);
}
_cls(f) struct file *f; {
#ifdef MAYBE
char *p;
#endif
_curfil = f;
if ((f->flags&0377) != MAGIC)
return;
#ifdef MAYBE
p = f->bufadr;
if (f->ptr < p)
return;
if (f->buflen <= 0)
return;
p += f->buflen;
if (f->ptr >= p)
return;
#endif
_xcls(f);
if (close(f->ufd) != 0)
_trp(ECLOSE);
f->flags = 0;
}

122
lang/pc/libpc/cvt.c
View File

@ -1,122 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
extern double _fif();
/*
* _ecvt converts to decimal
* the number of digits is specified by ndigit
* decpt is set to the position of the decimal point
* sign is set to 0 for positive, 1 for negative
*/
#define NDIG 80
static char*
cvt(arg, ndigits, decpt, sign, eflag)
double arg;
int ndigits, *decpt, *sign, eflag;
{
register int r2;
double fi, fj;
register char *p, *p1;
static char buf[NDIG];
int i; /*!*/
if (ndigits<0)
ndigits = 0;
if (ndigits>=NDIG-1)
ndigits = NDIG-2;
r2 = 0;
*sign = 0;
p = &buf[0];
if (arg<0) {
*sign = 1;
arg = -arg;
}
arg = _fif(arg, 1.0, &fi);
/*
* Do integer part
*/
if (fi != 0) {
p1 = &buf[NDIG];
while (fi != 0) {
i = (_fif(fi, 0.1, &fi) + 0.03) * 10;
*--p1 = i + '0';
r2++;
}
while (p1 < &buf[NDIG])
*p++ = *p1++;
} else if (arg > 0) {
while ((fj = arg*10) < 1) {
arg = fj;
r2--;
}
}
p1 = &buf[ndigits];
if (eflag==0)
p1 += r2;
*decpt = r2;
if (p1 < &buf[0]) {
buf[0] = '\0';
return(buf);
}
while (p<=p1 && p<&buf[NDIG]) {
arg = _fif(arg, 10.0, &fj);
i = fj;
*p++ = i + '0';
}
if (p1 >= &buf[NDIG]) {
buf[NDIG-1] = '\0';
return(buf);
}
p = p1;
*p1 += 5;
while (*p1 > '9') {
*p1 = '0';
if (p1>buf) {
p1--; *p1 += 1;
} else {
*p1 = '1';
(*decpt)++;
if (eflag==0) {
if (p>buf)
*p = '0';
p++;
}
}
}
*p = '\0';
return(buf);
}
char*
_ecvt(arg, ndigits, decpt, sign)
double arg;
int ndigits, *decpt, *sign;
{
return(cvt(arg, ndigits, decpt, sign, 1));
}
char*
_fcvt(arg, ndigits, decpt, sign)
double arg;
int ndigits, *decpt, *sign;
{
return(cvt(arg, ndigits, decpt, sign, 0));
}

34
lang/pc/libpc/diag.c
View File

@ -1,34 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_file.h>
/* procedure diag(var f:text); */
diag(f) struct file *f; {
f->ptr = f->bufadr;
f->flags = WRBIT|EOFBIT|ELNBIT|TXTBIT|MAGIC;
f->fname = "DIAG";
f->ufd = 2;
f->size = 1;
f->count = 1;
f->buflen = 1;
}

87
lang/pc/libpc/dis.c
View File

@ -1,87 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_err.h>
#define assert() /* nothing */
/*
* use circular list of free blocks from low to high addresses
* _highp points to free block with highest address
*/
struct adm {
struct adm *next;
int size;
};
extern struct adm *_lastp;
extern struct adm *_highp;
extern _trp();
static int merge(p1,p2) struct adm *p1,*p2; {
struct adm *p;
p = (struct adm *)((char *)p1 + p1->size);
if (p > p2)
_trp(EFREE);
if (p != p2)
return(0);
p1->size += p2->size;
p1->next = p2->next;
return(1);
}
_dis(n,pp) int n; struct adm **pp; {
struct adm *p1,*p2;
/*
* NOTE: dispose only objects whose size is a multiple of sizeof(*pp).
* this is always true for objects allocated by _new()
*/
n = ((n+sizeof(*p1)-1) / sizeof(*p1)) * sizeof(*p1);
if (n == 0)
return;
if ((p1= *pp) == (struct adm *) 0)
_trp(EFREE);
p1->size = n;
if ((p2 = _highp) == 0) /*p1 is the only free block*/
p1->next = p1;
else {
if (p2 > p1) {
/*search for the preceding free block*/
if (_lastp < p1) /*reduce search*/
p2 = _lastp;
while (p2->next < p1)
p2 = p2->next;
}
/* if p2 preceeds p1 in the circular list,
* try to merge them */
p1->next = p2->next; p2->next = p1;
if (p2 <= p1 && merge(p2,p1))
p1 = p2;
p2 = p1->next;
/* p1 preceeds p2 in the circular list */
if (p2 > p1) merge(p1,p2);
}
if (p1 >= p1->next)
_highp = p1;
_lastp = p1;
*pp = (struct adm *) 0;
}

36
lang/pc/libpc/efl.c
View File

@ -1,36 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_file.h>
#include <pc_err.h>
extern struct file *_curfil;
extern _trp();
extern _incpt();
int _efl(f) struct file *f; {
_curfil = f;
if ((f->flags & 0377) != MAGIC)
_trp(EBADF);
if ((f->flags & (WINDOW|WRBIT|EOFBIT)) == 0)
_incpt(f);
return((f->flags & EOFBIT) != 0);
}

33
lang/pc/libpc/eln.c
View File

@ -1,33 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_file.h>
#include <pc_err.h>
extern _trp();
extern _rf();
int _eln(f) struct file *f; {
_rf(f);
if (f->flags & EOFBIT)
_trp(EEOF);
return((f->flags & ELNBIT) != 0);
}

144
lang/pc/libpc/encaps.e
View File

@ -1,144 +0,0 @@
#
; $Header$
; (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
;
; This product is part of the Amsterdam Compiler Kit.
;
; Permission to use, sell, duplicate or disclose this software must be
; obtained in writing. Requests for such permissions may be sent to
;
; Dr. Andrew S. Tanenbaum
; Wiskundig Seminarium
; Vrije Universiteit
; Postbox 7161
; 1007 MC Amsterdam
; The Netherlands
;
mes 2,EM_WSIZE,EM_PSIZE
; procedure encaps(procedure p; procedure(q(n:integer));
; {call q if a trap occurs during the execution of p}
; {if q returns, continue execution of p}
inp $handler
#define PIISZ 2*EM_PSIZE
#define PARG 0
#define QARG PIISZ
#define E_ELB -EM_PSIZE
#define E_EHA -2*EM_PSIZE
; encaps is called with two parameters:
; - procedure instance identifier of q (QARG)
; - procedure instance identifier of p (PARG)
; and two local variables:
; - the lb of the previous encaps (E_ELB)
; - the procedure identifier of the previous handler (E_EHA)
;
; One static variable:
; - the lb of the currently active encaps (enc_lb)
enc_lb
bss EM_PSIZE,0,0
exp $encaps
pro $encaps,PIISZ
; save lb of previous encaps
lae enc_lb
loi EM_PSIZE
lal E_ELB
sti EM_PSIZE
; set new lb
lxl 0
lae enc_lb
sti EM_PSIZE
; save old handler id while setting up the new handler
lpi $handler
sig
lal E_EHA
sti EM_PSIZE
; handler is ready, p can be called
; p doesn't expect parameters except possibly the static link
; always passing the link won't hurt
lal PARG
loi PIISZ
cai
asp EM_PSIZE
; reinstate old handler
lal E_ELB
loi EM_PSIZE
lae enc_lb
sti EM_PSIZE
lal E_EHA
loi EM_PSIZE
sig
asp EM_PSIZE
ret 0
end ?
#define TRAP 0
#define H_ELB -EM_PSIZE
; handler is called with one parameter:
; - trap number (TRAP)
; one local variable
; - the current LB of the enclosing encaps (H_ELB)
pro $handler,EM_PSIZE
; save LB of nearest encaps
lae enc_lb
loi EM_PSIZE
lal H_ELB
sti EM_PSIZE
; fetch setting for previous encaps via LB of nearest
lal H_ELB
loi EM_PSIZE
adp E_ELB
loi EM_PSIZE ; LB of previous encaps
lae enc_lb
sti EM_PSIZE
lal H_ELB
loi EM_PSIZE
adp E_EHA
loi EM_PSIZE ; previous handler
sig
asp EM_PSIZE
; previous handler is re-instated, time to call Q
lol TRAP ; the one and only real parameter
lal H_ELB
loi EM_PSIZE
lpb ; argument base of enclosing encaps
adp QARG
loi PIISZ
exg EM_PSIZE
dup EM_PSIZE ; The static link is now on top
zer EM_PSIZE
cmp
zeq *1
; non-zero LB
exg EM_PSIZE
cai
asp EM_WSIZE+EM_PSIZE
bra *2
1
; zero LB
asp EM_PSIZE
cai
asp EM_WSIZE
2
; now reinstate handler for continued execution of p
lal H_ELB
loi EM_PSIZE
lae enc_lb
sti EM_PSIZE
lpi $handler
sig
asp EM_PSIZE
rtt
end ?

106
lang/pc/libpc/exp.c
View File

@ -1,106 +0,0 @@
/* $Header$ */
#include <pc_err.h>
extern double _fif();
extern double _fef();
extern _trp();
/*
exp returns the exponential function of its
floating-point argument.
The coefficients are #1069 from Hart and Cheney. (22.35D)
*/
#define HUGE 1.701411733192644270e38
static double p0 = .2080384346694663001443843411e7;
static double p1 = .3028697169744036299076048876e5;
static double p2 = .6061485330061080841615584556e2;
static double q0 = .6002720360238832528230907598e7;
static double q1 = .3277251518082914423057964422e6;
static double q2 = .1749287689093076403844945335e4;
static double log2e = 1.4426950408889634073599247;
static double sqrt2 = 1.4142135623730950488016887;
static double maxf = 10000.0;
static double
floor(d)
double d;
{
if (d<0) {
d = -d;
if (_fif(d, 1.0, &d) != 0)
d += 1;
d = -d;
} else
_fif(d, 1.0, &d);
return(d);
}
static double
ldexp(fr,exp)
double fr;
int exp;
{
int neg,i;
neg = 1;
if (fr < 0) {
fr = -fr;
neg = -1;
}
fr = _fef(fr, &i);
/*
while (fr < 0.5) {
fr *= 2;
exp--;
}
*/
exp += i;
if (exp > 127) {
_trp(EEXP);
return(neg * HUGE);
}
if (exp < -127)
return(0);
while (exp > 14) {
fr *= (1<<14);
exp -= 14;
}
while (exp < -14) {
fr /= (1<<14);
exp += 14;
}
if (exp > 0)
fr *= (1<<exp);
if (exp < 0)
fr /= (1<<(-exp));
return(neg * fr);
}
double
_exp(arg)
double arg;
{
double fract;
double temp1, temp2, xsq;
int ent;
if(arg == 0)
return(1);
if(arg < -maxf)
return(0);
if(arg > maxf) {
_trp(EEXP);
return(HUGE);
}
arg *= log2e;
ent = floor(arg);
fract = (arg-ent) - 0.5;
xsq = fract*fract;
temp1 = ((p2*xsq+p1)*xsq+p0)*fract;
temp2 = ((xsq+q2)*xsq+q1)*xsq + q0;
return(ldexp(sqrt2*(temp2+temp1)/(temp2-temp1), ent));
}

39
lang/pc/libpc/fef.e
View File

@ -1,39 +0,0 @@
#
; $Header$
;
; (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
;
; This product is part of the Amsterdam Compiler Kit.
;
; Permission to use, sell, duplicate or disclose this software must be
; obtained in writing. Requests for such permissions may be sent to
;
; Dr. Andrew S. Tanenbaum
; Wiskundig Seminarium
; Vrije Universiteit
; Postbox 7161
; 1007 MC Amsterdam
; The Netherlands
;
;
mes 2,EM_WSIZE,EM_PSIZE
#define FARG 0
#define ERES EM_DSIZE
; _fef is called with two parameters:
; - address of exponent result (ERES)
; - floating point number to be split (FARG)
; and returns an EM_DSIZE-byte floating point number
exp $_fef
pro $_fef,0
lal FARG
loi EM_DSIZE
fef EM_DSIZE
lal ERES
loi EM_PSIZE
sti EM_WSIZE
ret EM_DSIZE
end ?

41
lang/pc/libpc/fif.e
View File

@ -1,41 +0,0 @@
#
; $Header$
;
; (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
;
; This product is part of the Amsterdam Compiler Kit.
;
; Permission to use, sell, duplicate or disclose this software must be
; obtained in writing. Requests for such permissions may be sent to
;
; Dr. Andrew S. Tanenbaum
; Wiskundig Seminarium
; Vrije Universiteit
; Postbox 7161
; 1007 MC Amsterdam
; The Netherlands
;
;
mes 2,EM_WSIZE,EM_PSIZE
#define ARG1 0
#define ARG2 EM_DSIZE
#define IRES 2*EM_DSIZE
; _fif is called with three parameters:
; - address of integer part result (IRES)
; - float two (ARG2)
; - float one (ARG1)
; and returns an EM_DSIZE-byte floating point number
exp $_fif
pro $_fif,0
lal 0
loi 2*EM_DSIZE
fif EM_DSIZE
lal IRES
loi EM_PSIZE
sti EM_DSIZE
ret EM_DSIZE
end ?

31
lang/pc/libpc/get.c
View File

@ -1,31 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
#include <pc_file.h>
#include <pc_err.h>
extern _rf();
extern _trp();
_get(f) struct file *f; {
_rf(f);
if (f->flags&EOFBIT)
_trp(EEOF);
f->flags &= ~WINDOW;
}

85
lang/pc/libpc/gto.e
View File

@ -1,85 +0,0 @@
#
; $Header$
; (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
;
; This product is part of the Amsterdam Compiler Kit.
;
; Permission to use, sell, duplicate or disclose this software must be
; obtained in writing. Requests for such permissions may be sent to
;
; Dr. Andrew S. Tanenbaum
; Wiskundig Seminarium
; Vrije Universiteit
; Postbox 7161
; 1007 MC Amsterdam
; The Netherlands
;
/* Author: J.W. Stevenson */
mes 2,EM_WSIZE,EM_PSIZE
#define TARLB 0
#define DESCR EM_PSIZE
#define NEWPC 0
#define SAVSP EM_PSIZE
#define D_PC 0
#define D_SP EM_PSIZE
#define D_LB EM_PSIZE+EM_PSIZE
#define LOCLB -EM_PSIZE
; _gto is called with two arguments:
; - pointer to the label descriptor (DESCR)
; - local base (LB) of target procedure (TARLB)
; the label descriptor contains two items:
; - label address i.e. new PC (NEWPC)
; - offset in target procedure frame (SAVSP)
; using this offset and the LB of the target procedure, the address of
; of local variable of the target procedure is constructed.
; the target procedure must have stored the correct target SP there.
descr
bss 3*EM_PSIZE,0,0
exp $_gto
pro $_gto,EM_PSIZE
lal DESCR
loi EM_PSIZE
adp NEWPC
loi EM_PSIZE
lae descr+D_PC
sti EM_PSIZE
lal TARLB
loi EM_PSIZE
zer EM_PSIZE
cmp
zeq *1
lal TARLB
loi EM_PSIZE
bra *2
1
lae _m_lb
loi EM_PSIZE
2
lal LOCLB
sti EM_PSIZE
lal LOCLB
loi EM_PSIZE
lal DESCR
loi EM_PSIZE
adp SAVSP
loi EM_WSIZE ; or EM_PSIZE ?
ads EM_WSIZE ; or EM_PSIZE ?
loi EM_PSIZE
lae descr+D_SP
sti EM_PSIZE
lal LOCLB
loi EM_PSIZE
lae descr+D_LB
sti EM_PSIZE
gto descr
end ?

3
lang/pc/libpc/head_pc.e
View File

@ -1,3 +0,0 @@
#
; $Header$
mes 2,EM_WSIZE,EM_PSIZE

35
lang/pc/libpc/hlt.c
View File

@ -1,35 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_file.h>
extern char *_hbase;
extern int *_extfl;
extern _cls();
extern exit();
_hlt(ecode) int ecode; {
int i;
for (i = 1; i <= _extfl[0]; i++)
if (_extfl[i] != -1)
_cls(EXTFL(i));
exit(ecode);
}

29
lang/pc/libpc/hol0.e
View File

@ -1,29 +0,0 @@
#
; $Header$
;
; (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
;
; This product is part of the Amsterdam Compiler Kit.
;
; Permission to use, sell, duplicate or disclose this software must be
; obtained in writing. Requests for such permissions may be sent to
;
; Dr. Andrew S. Tanenbaum
; Wiskundig Seminarium
; Vrije Universiteit
; Postbox 7161
; 1007 MC Amsterdam
; The Netherlands
;
;
mes 2,EM_WSIZE,EM_PSIZE
; _hol0 return the address of the ABS block (hol0)
exp $_hol0
pro $_hol0,0
lae 0
ret EM_PSIZE
end ?

75
lang/pc/libpc/incpt.c
View File

@ -1,75 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_file.h>
#include <pc_err.h>
#define EINTR 4
extern int errno;
extern _trp();
extern int read();
_incpt(f) struct file *f; {
if (f->flags & EOFBIT)
_trp(EEOF);
f->flags |= WINDOW;
f->flags &= ~ELNBIT;
#ifdef CPM
do {
#endif
f->ptr += f->size;
if (f->count == 0) {
f->ptr = f->bufadr;
for(;;) {
f->count=read(f->ufd,f->bufadr,f->buflen);
if ( f->count<0 ) {
if (errno != EINTR) _trp(EREAD) ;
continue ;
}
break ;
}
if (f->count == 0) {
f->flags |= EOFBIT;
*f->ptr = '\0';
return;
}
}
if ((f->count -= f->size) < 0)
_trp(EFTRUNC);
#ifdef CPM
} while ((f->flags&TXTBIT) && *f->ptr == '\r');
#endif
if (f->flags & TXTBIT) {
if (*f->ptr & 0200)
_trp(EASCII);
if (*f->ptr == '\n') {
f->flags |= ELNBIT;
*f->ptr = ' ';
}
#ifdef CPM
if (*f->ptr == 26) {
f->flags |= EOFBIT;
*f->ptr = 0;
}
#endif
}
}

73
lang/pc/libpc/ini.c
View File

@ -1,73 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_file.h>
#include <pc_err.h>
extern (*_sig())();
extern _catch();
#ifndef CPM
extern int ioctl();
#endif
char *_hbase;
int *_extfl;
char *_m_lb; /* LB of m_a_i_n */
struct file *_curfil; /* points to file struct in case of errors */
int _pargc;
char **_pargv;
char **_penvp;
_ini(args,hb,p,mainlb) char *args,*hb,*mainlb; int *p; {
struct file *f;
char buf[6];
_pargc= *(int *)args; args += sizeof (int);
_pargv= *(char ***)args; args += sizeof (char **);
_penvp= *(char ***)args;
_sig(_catch);
_extfl = p;
_hbase = hb;
_m_lb = mainlb;
if (_extfl[1] != -1) {
f = EXTFL(1);
f->ptr = f->bufadr;
f->flags = MAGIC|TXTBIT;
f->fname = "INPUT";
f->ufd = 0;
f->size = 1;
f->count = 0;
f->buflen = 512;
}
if (_extfl[2] != -1) {
f = EXTFL(2);
f->ptr = f->bufadr;
f->flags = MAGIC|TXTBIT|WRBIT|EOFBIT|ELNBIT;
f->fname = "OUTPUT";
f->ufd = 1;
f->size = 1;
#ifdef CPM
f->count = 1;
#else
f->count = (ioctl(1,(('t'<<8)|8),buf) == 0 ? 1 : 512);
#endif
f->buflen = f->count;
}
}

59
lang/pc/libpc/log.c
View File

@ -1,59 +0,0 @@
/* $Header$ */
#include <pc_err.h>
extern double _fef();
extern _trp();
/*
log returns the natural logarithm of its floating
point argument.
The coefficients are #2705 from Hart & Cheney. (19.38D)
It calls _fef.
*/
#define HUGE 1.701411733192644270e38
static double log2 = 0.693147180559945309e0;
static double sqrto2 = 0.707106781186547524e0;
static double p0 = -.240139179559210510e2;
static double p1 = 0.309572928215376501e2;
static double p2 = -.963769093368686593e1;
static double p3 = 0.421087371217979714e0;
static double q0 = -.120069589779605255e2;
static double q1 = 0.194809660700889731e2;
static double q2 = -.891110902798312337e1;
double
_log(arg)
double arg;
{
double x,z, zsq, temp;
int exp;
if(arg <= 0) {
_trp(ELOG);
return(-HUGE);
}
x = _fef(arg,&exp);
/*
while(x < 0.5) {
x =* 2;
exp--;
}
*/
if(x<sqrto2) {
x *= 2;
exp--;
}
z = (x-1)/(x+1);
zsq = z*z;
temp = ((p3*zsq + p2)*zsq + p1)*zsq + p0;
temp = temp/(((zsq + q2)*zsq + q1)*zsq + q0);
temp = temp*z + exp*log2;
return(temp);
}

33
lang/pc/libpc/mdi.c
View File

@ -1,33 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_err.h>
extern _trp();
int _mdi(j,i) int j,i; {
if (j <= 0)
_trp(EMOD);
i = i % j;
if (i < 0)
i += j;
return(i);
}

33
lang/pc/libpc/mdl.c
View File

@ -1,33 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_err.h>
extern _trp();
long _mdl(j,i) long j,i; {
if (j <= 0)
_trp(EMOD);
i = i % j;
if (i < 0)
i += j;
return(i);
}

67
lang/pc/libpc/new.c
View File

@ -1,67 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
extern _sav();
extern _rst();
#define assert() /* nothing */
#define UNDEF 0x8000
struct adm {
struct adm *next;
int size;
};
struct adm *_lastp = 0;
struct adm *_highp = 0;
_new(n,pp) int n; struct adm **pp; {
struct adm *p,*q;
n = ((n+sizeof(*p)-1) / sizeof(*p)) * sizeof(*p);
if ((p = _lastp) != 0)
do {
q = p->next;
if (q->size >= n) {
assert(q->size%sizeof(adm) == 0);
if ((q->size -= n) == 0) {
if (p == q)
p = 0;
else
p->next = q->next;
if (q == _highp)
_highp = p;
}
_lastp = p;
p = (struct adm *)((char *)q + q->size);
q = (struct adm *)((char *)p + n);
goto initialize;
}
p = q;
} while (p != _lastp);
/*no free block big enough*/
_sav(&p);
q = (struct adm *)((char *)p + n);
_rst(&q);
initialize:
*pp = p;
while (p < q)
*((int *)p)++ = UNDEF;
}

33
lang/pc/libpc/nobuff.c
View File

@ -1,33 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_file.h>
extern _flush();
/* procedure nobuff(var f:file of ?); */
nobuff(f) struct file *f; {
if ((f->flags & (0377|WRBIT)) != (MAGIC|WRBIT))
return;
_flush(f);
f->count = f->buflen = f->size;
}

23
lang/pc/libpc/notext.c
View File

@ -1,23 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
#include <pc_file.h>
notext(f) struct file *f; {
f->flags &= ~TXTBIT;
}

117
lang/pc/libpc/opn.c
View File

@ -1,117 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_file.h>
#include <pc_err.h>
extern char *_hbase;
extern int *_extfl;
extern struct file *_curfil;
extern int _pargc;
extern char **_pargv;
extern char **_penvp;
extern _cls();
extern _xcls();
extern _trp();
extern int getpid();
extern int creat();
extern int open();
extern int close();
extern int unlink();
extern long lseek();
static int tmpfil() {
int i; char *p,*q;
i = getpid();
p = "/usr/tmp/plf.xxxxx";
q = p + 13;
do
*q++ = (i & 07) + '0';
while (i >>= 3);
*q = '\0';
if ((i = creat(p,0644)) < 0)
if ((i = creat(p += 4,0644)) < 0)
if ((i = creat(p += 5,0644)) < 0)
goto error;
if (close(i) != 0)
goto error;
if ((i = open(p,2)) < 0)
goto error;
if (unlink(p) != 0)
error: _trp(EREWR);
return(i);
}
static int initfl(descr,sz,f) int descr; int sz; struct file *f; {
int i;
_curfil = f;
if (sz == 0) {
sz++;
descr |= TXTBIT;
}
for (i=1; i<=_extfl[0]; i++)
if (f == EXTFL(i))
break;
if (i > _extfl[0]) { /* local file */
f->fname = "LOCAL";
if ((descr & WRBIT) == 0 && (f->flags & 0377) == MAGIC) {
_xcls(f);
if (lseek(f->ufd,(long)0,0) == -1)
_trp(ERESET);
} else {
_cls(f);
f->ufd = tmpfil();
}
} else { /* external file */
if ((i -= 2) <= 0)
return(0);
if (i >= _pargc)
_trp(EARGC);
f->fname = _pargv[i];
_cls(f);
if ((descr & WRBIT) == 0) {
if ((f->ufd = open(f->fname,0)) < 0)
_trp(ERESET);
} else {
if ((f->ufd = creat(f->fname,0644)) < 0)
_trp(EREWR);
}
}
f->buflen = (sz>512 ? sz : 512-512%sz);
f->size = sz;
f->ptr = f->bufadr;
f->flags = descr;
return(1);
}
_opn(sz,f) int sz; struct file *f; {
if (initfl(MAGIC,sz,f))
f->count = 0;
}
_cre(sz,f) int sz; struct file *f; {
if (initfl(WRBIT|EOFBIT|ELNBIT|MAGIC,sz,f))
f->count = f->buflen;
}

50
lang/pc/libpc/outcpt.c
View File

@ -1,50 +0,0 @@
/* $Header$ */
/*
* (c) copyright 1983 by the Vrije Universiteit, Amsterdam, The Netherlands.
*
* This product is part of the Amsterdam Compiler Kit.
*
* Permission to use, sell, duplicate or disclose this software must be
* obtained in writing. Requests for such permissions may be sent to
*
* Dr. Andrew S. Tanenbaum
* Wiskundig Seminarium
* Vrije Universiteit
* Postbox 7161
* 1007 MC Amsterdam
* The Netherlands
*
*/
/* Author: J.W. Stevenson */
#include <pc_file.h>
#include <pc_err.h>
#define EINTR 4
extern int errno;
extern _trp();
extern int write();
_flush(f) struct file *f; {
int i,n;
f->ptr = f->bufadr;
n = f->buflen - f->count;
if (n <= 0)
return;
f->count = f->buflen;
if ((i = write(f->ufd,f->bufadr,n)) < 0 && errno == EINTR)
return;
if (i != n)
_trp(EWRITE);
}
_outcpt(f) struct file *f; {
f->flags &= ~ELNBIT;
f->ptr += f->size;
if ((f->count -= f->size) <= 0)
_flush(f);
}

Some files were not shown because too many files have changed in this diff Show More