Browse Source

adapting to phototypesetter

dick 38 years ago
parent
commit
c4936bbd48
11 changed files with 213 additions and 454 deletions
  1. 7 277
      doc/6500.doc
  2. 19 11
      doc/Makefile
  3. 107 105
      doc/ack.doc
  4. 6 0
      doc/cg.doc
  5. 0 1
      doc/cref.doc
  6. 2 0
      doc/i80.doc
  7. 27 26
      doc/install.doc
  8. 2 2
      doc/pcref.doc
  9. 1 2
      doc/toolkit.doc
  10. 1 1
      doc/val.doc
  11. 41 29
      doc/z80.doc

+ 7 - 277
doc/6500.doc

@@ -1,6 +1,6 @@
 . \" $Header$"
-.po +10
-.ND
+.RP
+.ND Dec 1984
 .TL
 .B
 A backend table for the 6500 microprocessor
@@ -12,212 +12,6 @@ The backend table is part of the Amsterdam Compiler Kit (ACK).
 It translates the intermediate language family EM to a machine
 code for the MCS6500 microprocessor family.
 .AE
-.PP
-.bp
-.NH
-Introduction.
-.PP
-As more and more organizations aquire many micro and minicomputers,
-the need for portable compilers is becoming more and more acute.
-The present situation, in which each harware 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 integerated
-system is being built at the Vrije Universiteit.
-.PP
-The 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 [5],
-but which never really caught on then. The problem which UNCOL
-attemps to solve is how to make a compiler for each of
-.B
-N
-.R
-languages on
-.B
-M
-.R
-different machines without having to write
-.B
-N
-.R
-x
-.B
-M
-.R
-programs.
-.PP
-As shown in Fig. 1, the UNCOL approach is to write
-.B
-N
-.R
-"front ends," each of which translates
-one source language to a common
-intermediate language, UNCOL (UNiversal Computer Oriented
-Language), and
-.B
-M
-.R
-"back ends," each of which translates programs
-in UNCOL to a specific machine language. Under these conditions,
-only
-.B
-N
-.R
-+
-.B
-M
-.R
-programs must be written to provide all
-.B
-N
-.R
-languages on all
-.B
-M
-.R
-machines, instead of
-.B
-N
-.R
-x
-.B
-M
-.R
-programs.
-.PP
-Various reseachers have attempted to design a suitable UNCOL [1,6],
-but none of these have become popular. It is the believe of the
-designers of the Amsterdam Compiler Kit that previous attemps 
-have failed because they have been too ambitious, that is, they have
-tried to cover all languages and all machines using a single UNCOL.
-The approach of the designers is more modest:
-they cater only to algebraic languages and machines whose memory
-consist 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, where 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, MOS Technology MCS6500 family and IBM but not the Burroughs
-6700, CDC Cyber or Univac 1108 (because they are not byte_oriented).
-With these restrictions the designers believe that the old UNCOL
-idea can be used as the basis of a practical compiler-building 
-system.
-.sp 10
-.bp
-.NH
-An overview of the Amsterdam Compiler kit
-.PP
-The tool kit consists of eight components:
-.IP 1.
-The preprocessor.
-.IP 2.
-The front ends.
-.IP 3.
-The peephole optimizer.
-.IP 4.
-The global optimizer.
-.IP 5.
-The back end.
-.IP 6.
-The target machine optimizer.
-.IP 7.
-The universal assembler/linker.
-.IP 8.
-The utility package.
-.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.
-.sp 20
-.PP
-In the following paragraphs a brief decription of each component
-is given.
-A more detailed description of the back end will be given in the 
-rest of this document. For a more detailed descripiton on the rest
-of the components see [7]. A program to be compiled is first fed
-into the (language independed) preprocessor, which provides a
-simple macro facility and similar textual facilities.
-The preprocessor's ouput is a legal program in one of the programming
-languages supported, whereas the input is a program possibly
-augmented with macro's, etc.
-.PP
-This output goes into the appropriate front end, whose job it is to 
-produce intermediate cade.
-This intermediate code (the UNCOL of ACK) is the machine language
-for a simple stack machine EM (Encoding Machine).
-A typical front end might build a parse tree from the input
-and then use the parse tree to generate EM cade,
-which is similar to reverse Polish.
-In order to perform this work, the front end has to maintain tables of declare
-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 view 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 just one peephole optimizer.
-By handeling 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 [2],
-which unlike the peephole optimizer, examines the program as a whole.
-It builts 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 EM code is
-mapped onto the machine's assembly language.
-Although a simple driving table just might macro expand each
-EM instruction into a sequence of target machine instructions,
-a much more sophisticated translation strategy is normaly used,
-as described later.
-For speech, 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 binairy 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 idiosyncrasies of the
-target machine that cannot be performed by the machine-independent
-EM-to-EM peephole optimizer.
-Typically these optimizations take advantage of the 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.
 .bp
 .DS C
 .B
@@ -264,7 +58,7 @@ manufactured by Acorn Computer Ltd..
 The MOS Technology MCS6500
 .PP
 The MCS6500 is as a family of CPU devices developed by MOS
-Technology.
+Technology [1].
 The members of the MCS6500 family are the same chips in a 
 different housing.
 The MCS6502, the big brother in the family, can handle 64k
@@ -861,7 +655,7 @@ The above description of the machine table is
 a description of the table for the MCS6500.
 It uses only a part of the possibilities which the code generator
 generator offers.
-For a more precise and detailed description see [4].
+For a more precise and detailed description see [2].
 .DS C
 .B
 THE BACK END TABLE.
@@ -1141,7 +935,7 @@ This subroutine expects the multiplicand in zero page
 at locations ARTH, ARTH+1, while the multiplier is in zero
 page locations ARTH+2, ARTH+3.
 For a description of the algorithms used for multiplication and
-division, see [9].
+division, see [3].
 A table content is:
 .sp  1
 .br
@@ -2071,34 +1865,6 @@ if it is to be used on a MCS6500.
 REFERENCES.
 .R
 .IP 1.
-Haddon. B.K., and Waite, W.M.
-Experience with the Universal Intermediate Language Janus.
-.B
-Software Practice & Experience 8
-.R
-,
-5 (Sept.-Oct. 1978), 601-616.
-.RS
-.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.
-.RE
-.IP 2.
-Lowry, E.S., and Medlock, C.W. Object Code Optimization.
-.B
-Commun. ACM 12
-.R
-,
-(Jan. 1969), 13-22.
-.RS
-.PP
-A classical paper on global object code optimization.
-It covers data flow analysis, common subexpressions, code motion,
-register allocation and other techniques.
-.RE
-.IP 3.
 Osborn, A., Jacobson, S., and Kane, J. The Mos Technology MCS6500.
 .B
 An Introduction to Microcomputers ,
@@ -2109,7 +1875,7 @@ Volume II, Some Real Products (june 1977) chap. 9.
 A hardware description of some real existing CPU's, such as
 the Intel Z80, MCS6500, etc. is given in this book.
 .RE
-.IP 4.
+.IP 2.
 van Staveren, H.
 The table driven code generator from the Amsterdam Compiler Kit.
 Vrije Universiteit, Amsterdam, (July 11, 1983).
@@ -2117,43 +1883,7 @@ Vrije Universiteit, Amsterdam, (July 11, 1983).
 .PP
 The defining document for writing a back end table.
 .RE
-.IP 5.
-Steel, T.B., Jr. UNCOL: The Myth and the Fact. in
-.B
-Ann. Rev. Auto. Prog.
-.R
-Goodman, R. (ed.), vol 2., (1960), 325-344.
-.RS
-.PP
-An introduction to the UNCOL idea by its originator.
-.RE
-.IP 6.
-Steel. T.B., Jr. A first Version of UNCOL.
-.B
-Proc. Western Joint Comp. Conf.
-.R
-,
-(1961), 371-377.
-.IP 7.
-Tanenbaum, A.S., Stevenson, J.W., Keizer, E.G., and van Staveren,
-H.
-A Practical Tool Kit for Making Portable Compilers.
-Informatica Rapport 74, Vrije Universiteit, Amsterdam, 1983.
-.RS
-.PP
-An overview on the Amsterdam Compiler Kit.
-.RE
-.IP 8.
-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.
-.RS
-.PP
-The defining document for EM.
-.RE
-.IP 9.
+.IP 3.
 Tanenbaum, A.S. Structured Computer Organization.
 Prentice Hall. (1976).
 .RS

+ 19 - 11
doc/Makefile

@@ -2,14 +2,19 @@
 
 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)\
-basic.$(SUF) 6500.$(SUF) ncg.$(SUF) i80.$(SUF)
 NROFF=nroff
+TBL=tbl
+EQN=eqn
 MS=-ms
 
+RESFILES= \
+	toolkit.$(SUF) install.$(SUF) ack.$(SUF) v7bugs.$(SUF) \
+	peep.$(SUF) cg.$(SUF) ncg.$(SUF) regadd.$(SUF) LLgen.$(SUF) \
+	basic.$(SUF) cref.$(SUF) pcref.$(SUF) val.$(SUF) \
+	6500.$(SUF) i80.$(SUF) z80.$(SUF)
+
 cref.$(SUF):        cref.doc
-		tbl $? | $(NROFF) >$@
+		$(TBL) $? | $(NROFF) >$@
 v7bugs.$(SUF):      v7bugs.doc
 		$(NROFF) $(MS) $? >$@
 ack.$(SUF):         ack.doc
@@ -17,11 +22,11 @@ ack.$(SUF):         ack.doc
 cg.$(SUF):		cg.doc
 		$(NROFF) $(MS) $? >$@
 ncg.$(SUF):		ncg.doc
-		tbl $? | $(NROFF) $(MS) >$@
+		$(TBL) $? | $(NROFF) $(MS) >$@
 regadd.$(SUF):		regadd.doc
 		$(NROFF) $(MS) $? >$@
 install.$(SUF):     install.doc
-		$(NROFF) $(MS) $? >$@
+		$(TBL) $? | $(NROFF) $(MS) >$@
 pcref.$(SUF):       pcref.doc
 		$(NROFF) $? >$@
 basic.$(SUF):       basic.doc
@@ -33,23 +38,26 @@ val.$(SUF):         val.doc
 toolkit.$(SUF):	toolkit.doc
 		$(NROFF) $(MS) $? >$@
 LLgen.$(SUF):	LLgen.doc
-		eqn $? | tbl | $(NROFF) $(MS) >$@
+		$(EQN) $? | $(TBL) | $(NROFF) $(MS) >$@
 6500.$(SUF):	6500.doc
-		$(NROFF) $(MS) $? >$@
+		$(TBL) $? | $(NROFF) $(MS) >$@
 i80.$(SUF):	i80.doc
 		$(NROFF) $(MS) $? >$@
+z80.$(SUF):	z80.doc
+		$(NROFF) $(MS) $? >$@
 
 install cmp:
 
 distr:		install.doc
 		tbl install.doc | nroff -Tlp $(MS) >install.pr
+
 pr:
-		@make "SUF="$SUF "NROFF="$NROFF "PRINT="$PRINT $(RESFILES) \
-			>make.pr.out 2>&1
+		@make "SUF="$(SUF) "NROFF="$(NROFF) \
+			$(RESFILES) >make.pr.out 2>&1
 		@$(PRINT) $(RESFILES)
 
 opr:
 		make pr | opr
 
 clean:
-		-rm -f *.old $(RESFILES) *.t
+		-rm -f *.old $(RESFILES) *.t *.out

+ 107 - 105
doc/ack.doc

@@ -1,7 +1,6 @@
 .\" $Header$
-.nr LL 7.5i
-.tr ~
 .nr PD 1v
+.tr ~
 .TL
 Ack Description File
 .br
@@ -9,7 +8,7 @@ Reference Manual
 .AU
 Ed Keizer
 .AI
-Wiskundig Seminarium
+Vakgroep Informatica
 Vrije Universiteit
 Amsterdam
 .NH
@@ -24,16 +23,16 @@ 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
+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.
+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
@@ -60,7 +59,7 @@ convoluted.
 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
+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.
@@ -119,8 +118,8 @@ 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.
+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
@@ -134,17 +133,17 @@ 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
+.IP
 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
+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
+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.
+of an automatic \fB\-.c\fP 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
@@ -168,7 +167,7 @@ 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
+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.
@@ -193,7 +192,7 @@ 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.
+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
@@ -212,7 +211,7 @@ keyword. All other transformations do.
 .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~-
+linker \-~indicated by C option after the \fIprop\fP keyword~\-
 the output file name.
 .IP \fIprogram\fP
 .br
@@ -235,9 +234,9 @@ 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
+The flags \fB\-m\fP, \fB\-o\fP,
+\fB\-O\fP, \fB\-r\fP, \fB\-v\fP, \fB\-g\fP, \-\fB\-c\fP, \fB\-t\fP,
+\fB\-k\fP, \fB\-R\fP and \-\fB\-.\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.
@@ -249,11 +248,11 @@ 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 \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.
+\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
@@ -261,13 +260,13 @@ The example further on shows the use all this.
 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
+The variables assigned to by \fImapflags\fP 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
+.IP \fIprop\fP
 .br
-This -~optional~- keyword is followed by a sequence of options,
+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:
@@ -282,18 +281,18 @@ The possible options are:
 .DE
 .IP \fIrts\fP
 .br
-This -~optional~- keyword indicates that the rest of the line must be
+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.
+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
+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.
+by the \fB\-.suffix\fP flag.
 .br
 .nr PD 1v
 .NH
@@ -302,7 +301,7 @@ Conventions used in description files
 \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
+Other variables, set by \fIack\fP, are of use to all
 transformations.
 .PP
 \fIAck\fP sets the variable EM to the home directory of the
@@ -312,7 +311,7 @@ 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}.
+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.
@@ -330,91 +329,94 @@ 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
+.PP
+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
+.ta 4n 40n
+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} \e
+	    \-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
+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
+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
+.ta 4n 40n
 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
+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} \e
+	    ({RTS}:.c={EM}/{RT}cc) ({RTS}:.p={EM}/{RT}pc) \-o > < \e
+	    (.p:{TAIL}={EM}/{LIB}pc) \e
+	    (.c:{TAIL}={EM}/{LIB}cc.1s {EM}/{LIB}cc.2g) \e
+	    (.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
+The command \fIack \-mint \-v \-v \-I../h \-L \-ly prog.c\fP
+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
+.ta 4n
+1)	/lib/cpp \-I../h \-I/usr/em/include \-Dint22 \-DEM_WSIZE=2 \-DEM_PSIZE=2 \e
+	    \-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

+ 6 - 0
doc/cg.doc

@@ -1,5 +1,6 @@
 .\" $Header$
 .RP
+.ND Nov 1984
 .TL
 The table driven code generator from 
 .br
@@ -17,6 +18,11 @@ The Amsterdam Compiler Kit is such a collection of tools.
 This document provides a description of the internal workings
 of the table driven code generator in the Amsterdam Compiler Kit,
 and a description of syntax and semantics of the driving table.
+.PP
+>>>  NOTE  <<<
+.br
+This document pertains to the \fBold\fP code generator.  Refer to the
+"Second Revised Edition" for the new code generator.
 .AE
 .NH 1
 Introduction

+ 0 - 1
doc/cref.doc

@@ -1,5 +1,4 @@
 .\" $Header$
-.ll 72
 .nr ID 4
 .de hd
 'sp 2

+ 2 - 0
doc/i80.doc

@@ -1,4 +1,6 @@
+. \" $Header$
 .RP
+.ND April 1985
 .TL
 Back end table for the Intel 8080 micro-processor
 .AU

+ 27 - 26
doc/install.doc

@@ -1,12 +1,11 @@
 .\" $Header$
-.nr LL 7.5i
 .nr PD 1v
 .TL
-Amsterdam Compiler Kit installation guide
+Amsterdam Compiler Kit Installation Guide
 .AU
 Ed Keizer
 .AI
-Wiskundig Seminarium
+Vakgroep Informatica
 Vrije Universiteit
 Amsterdam
 .NH
@@ -33,16 +32,16 @@ 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
+.IP "  \-" 10
 Create a directory, for example /usr/em, on a device
 with at least 15 Megabytes left.
-.IP "  -"
+.IP "  \-"
 Change to that directory (cd ...); it will be the working directory.
-.IP "  -"
+.IP "  \-"
 Extract all files from the distribution medium, for instance
 magtape:
 \fBtar x\fP.
-.IP "  -"
+.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.
@@ -143,29 +142,31 @@ These directories have subdirectories named:
 .in +3n
 .TS
 l l.
-as	the assembler ( *.s + libraries => a.out )
 cg	the backend   ( *.m => *.s )
 ncg	the new backend   ( *.m => *.s )
+as	the assembler ( *.s + libraries => a.out )
+cv	Conversion programs for a.out files.
+dl	Down-load programs
+
+libem	Sources for EM runtime system, intended to depend only on CPU type
 libbc	Used to create Basic run-time system and libraries
 libcc	Used to create C run-time system and libraries
 libpc	Used to create Pascal run-time system and libraries
-libem	Sources for EM runtime system, intended to depend only on CPU type
 libsys	Sources for system-dependent EM library
 test	Various tests
-dl	Down-load programs
-cv	Conversion programs for a.out files.
+
 int	Source for an interpreter
 .TE
 .in -3n
-The directory proto contains files used by most machines
+The directory proto contains files used by most machines,
 like machine-independent sources and Makefiles.
 .in +3n
 .TS
 l l.
-mach/proto/libg	Makefile for compiling libraries.
-mach/proto/as	Assembler sources.
 mach/proto/cg	Current backend sources.
 mach/proto/ncg	New backend sources.
+mach/proto/as	Assembler sources.
+mach/proto/libg	Makefile for compiling libraries.
 .TE
 .IP "emtest"
 .br
@@ -277,14 +278,14 @@ first in a directory of the same name.
 .LP
 These actions are:
 .sp 1
-.IP -
+.IP \-
 Automatically checking whether you included the ACK bin directory in your
 shell PATH.
 See also the section on "commands".
-.IP -
+.IP \-
 Automatically setting the pathname of the parent directory in ../h/em_path.h.
 See also the section on "pathnames".
-.IP -
+.IP \-
 Asking you for the type of system you have
 and creating the shell script "ack_sys" in the Kit's bin directory.
 Several utilities make use of "ack_sys" to determine the type of
@@ -313,12 +314,12 @@ For ANY you can use any name you fancy,
 but the Kit will not be able to compile programs for your system.
 If you want to do that you have to read the section about "compilation
 on a different machine".
-.IP -
+.IP \-
 Automatically setting the default machine for which code is
 produced to your own type of system according to the table above.
 This in done in the file "h/local.h".
 See also the section 8.2.
-.IP -
+.IP \-
 Automatically editing a few description files that tell
 ACK to use your system's assembler.
 On both the PDP and the VAX the Kit uses the native assembler and linker.
@@ -326,14 +327,14 @@ The description files in lib/pdp/descr, lib/vax2/descr and
 lib/vax4/descr have to be altered to prevent
 attempts to assemble programs with unsuitable assemblers.
 The original descr files are copied to descr.orig.
-.IP -
+.IP \-
 Automatically installing the special include directory for vax2.
 This will only be done on VAX systems.
 The shell scripts needed by ACK for the vax2 backend differ slightly
 from the one issued by Berkeley.
 .br
 Note: this has only been tested under BSD4.1a.
-.IP -
+.IP \-
 Automatically editing the system.h file in mach/vax[24]/libem.
 Again, only on VAXen.
 These files reflect whether you have BSD4.1a, BSD4.1c or BSD4.2.
@@ -341,7 +342,7 @@ These files reflect whether you have BSD4.1a, BSD4.1c or BSD4.2.
 .sp 1
 Some actions still have to be done by hand.
 .sp 1
-.IP -
+.IP \-
 The VAX backends cannot be booted on systems
 with a 16-bit address space systems.
 The program lib/cgg needs more memory than available to transform
@@ -354,18 +355,18 @@ You will hardly be able to use these, because the
 code generated by these programs cannot be
 assembled and loaded without a native VAX assembler,
 but its nice to be able to look at the code produced.
-.IP -
+.IP \-
 The installation of the PUBMAC macro package is not done
 automatically because you needs super-user privileges to do
 that on most systems.
 This macro package is used with several of the documents
 provided in the Kit.
-.IP -
+.IP \-
 UNIX V7 as originally distributed contains a few bugs that
 prevent correct execution of some of the larger programs.
 See the section named "Fixes for the UNIX V7 system"
 about what to do.
-.IP -
+.IP \-
 The manual files for the Kit can be copied to their
 appropriate place in the system by giving the command "make install"
 in the man directory.
@@ -788,7 +789,7 @@ 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
+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

+ 2 - 2
doc/pcref.doc

@@ -2,7 +2,7 @@
 .ds OF \\fBtest~off:~\\fR
 .ds ON \\fBtest~on:~~\\fR
 .ds AL \\fBtest~all:~\\fR
-.ll 72
+.ll 72n
 .wh 0 hd
 .wh 60 fo
 .de hd
@@ -37,7 +37,7 @@ by
 .de VU
 .sp 3
 .ce 4
-Wiskundig Seminarium
+Vakgroep Informatica
 Vrije Universiteit
 De Boelelaan 1081
 Amsterdam

+ 1 - 2
doc/toolkit.doc

@@ -1,7 +1,6 @@
 .\" $Header$
 .RP
-.ND
-.nr LL 78m
+.ND July 1984
 .tr ~
 .ds as *
 .TL

+ 1 - 1
doc/val.doc

@@ -1,5 +1,5 @@
 .\" $Header$
-.ll 72
+.ll 72n
 .wh 0 hd
 .wh 60 fo
 .de hd

+ 41 - 29
doc/z80.doc

@@ -1,16 +1,21 @@
+. \" $Header$
+.ND April 1985
+.TL
 THE Z80 BACK END TABLE
-
+.AU
+Frans van Haarlem
+.NH 1
 INTRODUCTION
-
+.PP
 This table was written to make it run, not to make it clever!
 The effect is, that the table written for the intel 8080, 
 which was made very clever runs faster and requiers less space!!
 So, for anyone to run programs on a z80 machine:
 You could try to make the table as clever as the one for the i80,
 or you could run the i80 table, for that can run on every z80 too.
-
+.NH
 IMPLEMENTATION
-
+.PP
 It will not be possible to run the entire Amsterdam Compiler Kit on a
 Z80-based computer system.
 One has to write a program on another 
@@ -24,31 +29,37 @@ for example by downloading or
 by storing it in ROM (Read Only Memory).
 Depending on the characteristics of the particular z80 based system, some
 adaptions have to be made:
-1) In 'head_em': the base address, which is the address where the first
-   z80 instruction will be stored, and the initial value of the
-   stackpointer are set to 0x1000 and 0x7ffe respectivally.
-   The latter because it could run on a 32K machine as well.
-   Other systems require other values.
-2) In 'head_em': before calling "_m_a_i_n", the environment
-   pointer, argument vector and argument count will have to be pushed
-   onto the stack.
-   Since this back-end is tested on a system without any knowledge
-   of these things, dummies are pushed now.
-3) In 'tail_em': proper routines "putchar" and "getchar" should
-   be provided.
-   They should write resp. read a character on/from the monitor.
-   Maybe some conversions will have to be made.
-   The ones for the Nascom and Hermac z80 micro's are to be found
-   in the EM-library.
-4) In 'head_em': an application program returns control to the monitor by 
-   jumping to address 0x20.
-   If this is not the right way on your system, change it.
-   For an CPM-machine for example this should be 0x5, to provide a warm boot.
-5) In 'tail_em': the current version of the z80 back-end has very limited I/O
-   capabilities, because it was tested on a system that
-   had no knowlegde of files.
-   So the implementation of the EM-instruction 'mon' is very simple;
-   it can only do the following things:
+.IP 1)
+In \fIhead_em\fP: the base address, which is the address where the first
+z80 instruction will be stored, and the initial value of the
+stackpointer are set to 0x1000 and 0x7ffe respectivally.
+The latter because it could run on a 32K machine as well.
+Other systems require other values.
+.IP 2)
+In \fIhead_em\fP: before calling "_m_a_i_n", the environment
+pointer, argument vector and argument count will have to be pushed
+onto the stack.
+Since this back-end is tested on a system without any knowledge
+of these things, dummies are pushed now.
+.IP 3)
+In \fItail_em\fP: proper routines "putchar" and "getchar" should
+be provided.
+They should write resp. read a character on/from the monitor.
+Maybe some conversions will have to be made.
+The ones for the Nascom and Hermac z80 micro's are to be found
+in the EM-library.
+.IP 4)
+In \fIhead_em\fP: an application program returns control to the monitor by 
+jumping to address 0x20.
+If this is not the right way on your system, change it.
+For an CPM-machine for example this should be 0x5, to provide a warm boot.
+.IP 5)
+In \fItail_em\fP: the current version of the z80 back-end has very limited I/O
+capabilities, because it was tested on a system that
+had no knowlegde of files.
+So the implementation of the EM-instruction \fImon\fP is very simple;
+it can only do the following things:
+.DS
    Monitor call 1:
 		Exit
    Monitor call 3:
@@ -64,5 +75,6 @@ adaptions have to be made:
 		close file, returns error code = 0.
    Monitor call 54:
 		io-control, returns error code = 0.
+.DE
 If the system should do file-handling the routine ".mon"
 should be extended thoroughly.