adapting to phototypesetter
This commit is contained in:
dick
parent
1cd71875ac
commit
10569743c8
284
doc/6500.doc
284
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
|
||||
|
|
|
|||
30
doc/Makefile
30
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
|
||||
|
|
|
|||
212
doc/ack.doc
212
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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
.\" $Header$
|
||||
.ll 72
|
||||
.nr ID 4
|
||||
.de hd
|
||||
'sp 2
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
. \" $Header$
|
||||
.RP
|
||||
.ND April 1985
|
||||
.TL
|
||||
Back end table for the Intel 8080 micro-processor
|
||||
.AU
|
||||
|
|
|
|||
|
|
@ -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,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,7 +1,6 @@
|
|||
.\" $Header$
|
||||
.RP
|
||||
.ND
|
||||
.nr LL 78m
|
||||
.ND July 1984
|
||||
.tr ~
|
||||
.ds as *
|
||||
.TL
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
.\" $Header$
|
||||
.ll 72
|
||||
.ll 72n
|
||||
.wh 0 hd
|
||||
.wh 60 fo
|
||||
.de hd
|
||||
|
|
|
|||
70
doc/z80.doc
70
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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue