fixup commit for branch 'less_self_calls'

- added some data flow stuff
- many cosmetic changes

Copyright

@@ -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
- *
- */
-

Makefile

@@ -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 ) \
-	)

doc/Makefile

@@ -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

doc/ack.doc

@@ -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

doc/cref.doc

@@ -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).

doc/em/Makefile

@@ -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

doc/em/READ_ME

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

doc/em/app.nr

@@ -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

doc/em/assem.nr

@@ -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

doc/em/descr.nr

@@ -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

doc/em/dspace.nr

@@ -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.

doc/em/even.c

@@ -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") ;
-}

doc/em/exam.e

@@ -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

doc/em/exam.p

@@ -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.

doc/em/int/Makefile

@@ -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

doc/em/int/READ_ME

@@ -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 -

doc/em/int/emdmp.c

@@ -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() ;
-}

doc/em/int/mktables.c

@@ -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-- ;
-}

doc/em/intro.nr

@@ -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.

doc/em/iotrap.nr

@@ -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

doc/em/ip.awk

@@ -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" }

doc/em/ispace.nr

@@ -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.

doc/em/mach.nr

@@ -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.

doc/em/macr.nr

@@ -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

doc/em/mapping.nr

@@ -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.

doc/em/mem.nr

@@ -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.

doc/em/print

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

doc/em/show

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

doc/em/title.nr

@@ -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

doc/em/types.nr

@@ -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.

doc/install.doc

@@ -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.

doc/peep.doc

@@ -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.
-

doc/regadd.doc

@@ -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.
-

doc/toolkit.doc

@@ -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.

doc/v7bugs.doc

@@ -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

doc/val.doc

@@ -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.

etc/ip_spec.t

@@ -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

first/em_path.h.src

@@ -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"

first/local.h.src

@@ -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"

h/Makefile

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

h/arch.h

@@ -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

h/as_spec.h

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

h/cg_pattern.h

@@ -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); \
-	}

h/em_abs.h

@@ -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

h/em_ego.h

@@ -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 */

h/em_flag.h

@@ -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 */

h/em_mes.h

@@ -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
- */

h/em_ptyp.h

@@ -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

h/em_reg.h

@@ -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 */

h/pc_err.h

@@ -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

h/pc_file.h

@@ -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]))

h/pc_size.h

@@ -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

include/_tail_cc/setjmp.h

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

include/_tail_mon/errno.h

@@ -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

lang/pc/libpc/LIST

@@ -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

lang/pc/libpc/Makefile

@@ -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]

lang/pc/libpc/READ_ME

@@ -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.

lang/pc/libpc/abi.c

@@ -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);
-}

lang/pc/libpc/abl.c

@@ -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);
-}

lang/pc/libpc/abr.c

@@ -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);
-}

lang/pc/libpc/arg.c

@@ -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);
-}

lang/pc/libpc/ass.c

@@ -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);
-	}
-}

lang/pc/libpc/asz.c

@@ -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));
-}

lang/pc/libpc/atn.c

@@ -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));
-}

lang/pc/libpc/bcp.c

@@ -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);
-}

lang/pc/libpc/bts.e

@@ -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 ?

lang/pc/libpc/buff.c

@@ -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);
-}

lang/pc/libpc/catch.c

@@ -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);
-}

lang/pc/libpc/clock.c

@@ -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);
-}

lang/pc/libpc/cls.c

@@ -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;
-}

lang/pc/libpc/cvt.c

@@ -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));
-}

lang/pc/libpc/diag.c

@@ -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;
-}

lang/pc/libpc/dis.c

@@ -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;
-}

lang/pc/libpc/efl.c

@@ -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);
-}

lang/pc/libpc/eln.c

@@ -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);
-}

lang/pc/libpc/encaps.e

@@ -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 ?

lang/pc/libpc/exp.c

@@ -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));
-}

lang/pc/libpc/fef.e

@@ -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 ?

lang/pc/libpc/fif.e

@@ -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 ?

lang/pc/libpc/get.c

@@ -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;
-}

lang/pc/libpc/gto.e

@@ -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 ?

lang/pc/libpc/head_pc.e

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

lang/pc/libpc/hlt.c

@@ -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);
-}

lang/pc/libpc/hol0.e

@@ -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 ?

lang/pc/libpc/incpt.c

@@ -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
-	}
-}

lang/pc/libpc/ini.c

@@ -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;
-	}
-}

lang/pc/libpc/log.c

@@ -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);
-}

lang/pc/libpc/mdi.c

@@ -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);
-}

lang/pc/libpc/mdl.c

@@ -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);
-}

lang/pc/libpc/new.c

@@ -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;
-}

lang/pc/libpc/nobuff.c

@@ -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;
-}

lang/pc/libpc/notext.c

@@ -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;
-}

lang/pc/libpc/opn.c

@@ -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;
-}

lang/pc/libpc/outcpt.c

@@ -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);
-}