changed font 5 references to font CW references
This commit is contained in:
parent
a9ad34c8db
commit
71efb88a36
|
@ -4,5 +4,5 @@ s/^$/.ft\
|
|||
.DE\
|
||||
.bp\
|
||||
.DS\
|
||||
.ft 5\
|
||||
.ft CW\
|
||||
.ta 0.65i 1.3i 1.95i 2.6i 3.25i 3.9i 4.55i 5.2i 5.85i 6.5i/'
|
||||
|
|
|
@ -16,7 +16,7 @@ no procedures in Occam).
|
|||
In addition to the normal assignment statement, Occam has two more
|
||||
information-transfer statements, the input and the output:
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
chan1 ? x -- reads a value from chan1 into x
|
||||
chan2 ! x -- writes the value of x onto chan2
|
||||
.ft
|
||||
|
@ -36,7 +36,7 @@ for multiple input). The conditional and repetitive processes are normal
|
|||
.PP
|
||||
\fIProducer-consumer example:\fP
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
.nf
|
||||
CHAN buffer: -- declares the channel buffer
|
||||
PAR
|
||||
|
@ -60,7 +60,7 @@ with arrays of variables and/or channels.
|
|||
.PP
|
||||
\fIExample: 20 window-sorters in series:\fP
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
.nf
|
||||
CHAN s[20]: -- 20 channels
|
||||
PAR i = [ 0 FOR 19 ] -- 19 processes
|
||||
|
|
32
doc/occam/p2
32
doc/occam/p2
|
@ -8,30 +8,30 @@ the aspect of indentation.
|
|||
.NH 2
|
||||
The LLgen Parser Generator
|
||||
.PP
|
||||
LLgen accepts a Context Free syntax extended with the operators `\f5*\fP', `\f5?\fP' and `\f5+\fP'
|
||||
LLgen accepts a Context Free syntax extended with the operators `\f(CW*\fP', `\f(CW?\fP' and `\f(CW+\fP'
|
||||
that have effects similar to those in regular expressions.
|
||||
The `\f5*\fP' is the closure set operator without an upperbound; `\f5+\fP' is the positive
|
||||
closure operator without an upperbound; `\f5?\fP' is the optional operator;
|
||||
`\f5[\fP' and `\f5]\fP' can be used for grouping.
|
||||
The `\f(CW*\fP' is the closure set operator without an upperbound; `\f(CW+\fP' is the positive
|
||||
closure operator without an upperbound; `\f(CW?\fP' is the optional operator;
|
||||
`\f(CW[\fP' and `\f(CW]\fP' can be used for grouping.
|
||||
For example, a comma-separated list of expressions can be described as:
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
expression_list:
|
||||
expression [ ',' expression ]*
|
||||
;
|
||||
.ft
|
||||
.DE
|
||||
.LP
|
||||
Alternatives must be separated by `\f5|\fP'.
|
||||
Alternatives must be separated by `\f(CW|\fP'.
|
||||
C code (``actions'') can be inserted at all points between the colon and the
|
||||
semicolon.
|
||||
Variables global to the complete rule can be declared just in front of the
|
||||
colon enclosed in the brackets `\f5{\fP' and `\f5}\fP'. All other declarations are local to
|
||||
colon enclosed in the brackets `\f(CW{\fP' and `\f(CW}\fP'. All other declarations are local to
|
||||
their actions.
|
||||
Nonterminals can have parameters to pass information.
|
||||
A more mature version of the above example would be:
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
expression_list(expr *e;) { expr e1, e2; } :
|
||||
expression(&e1)
|
||||
[ ',' expression(&e2)
|
||||
|
@ -48,18 +48,18 @@ are possible, viz. the \fBalternation\fP and \fBrepetition\fP conflict.
|
|||
An alternation confict arises if two sides of an alternation can start with the
|
||||
same symbol. E.g.
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
plus: '+' | '+' ;
|
||||
.ft
|
||||
.DE
|
||||
The parser doesn't know which `\f5+\fP' to choose (neither do we).
|
||||
The parser doesn't know which `\f(CW+\fP' to choose (neither do we).
|
||||
Such a conflict can be resolved by putting an \fBif-condition\fP in front of
|
||||
the first conflicting production. It consists of a \fB``%if''\fP followed by a
|
||||
C-expression between parentheses.
|
||||
If a conflict occurs (and only if it does) the C-expression is evaluated and
|
||||
parsing continues along this path if non-zero. Example:
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
plus:
|
||||
%if (some_plusses_are_more_equal_than_others())
|
||||
'+'
|
||||
|
@ -69,7 +69,7 @@ parsing continues along this path if non-zero. Example:
|
|||
.ft
|
||||
.DE
|
||||
A repetition conflict arises when the parser cannot decide whether
|
||||
``\f5productionrule\fP'' in e.g. ``\f5[ productionrule ]*\fP'' must be chosen
|
||||
``\f(CWproductionrule\fP'' in e.g. ``\f(CW[ productionrule ]*\fP'' must be chosen
|
||||
once more, or that it should continue.
|
||||
This kind of conflicts can be resolved by putting a \fBwhile-condition\fP right
|
||||
after the opening parentheses. It consists of a \fB``%while''\fP
|
||||
|
@ -79,7 +79,7 @@ comma-expression if the total expression is not part of another comma-separated
|
|||
list:
|
||||
.DS
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
comma_expression:
|
||||
sub_expression
|
||||
[ %while (not_part_of_comma_separated_list())
|
||||
|
@ -110,7 +110,7 @@ is the \fBSEQ\fP construct, which exists in two flavors, one with a replicator
|
|||
and one process:
|
||||
.DS
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
seq i = [ 1 for str[byte 0] ]
|
||||
out ! str[byte i]
|
||||
.ft
|
||||
|
@ -119,7 +119,7 @@ and one process:
|
|||
and one without a replicator and several processes:
|
||||
.DS
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
seq
|
||||
in ? c
|
||||
out ! c
|
||||
|
@ -129,7 +129,7 @@ and one without a replicator and several processes:
|
|||
The LLgen skeleton grammar to handle these two is:
|
||||
.DS
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
SEQ { line=yylineno; oind=ind; }
|
||||
[ %if (line==yylineno)
|
||||
replicator
|
||||
|
|
22
doc/occam/p3
22
doc/occam/p3
|
@ -59,10 +59,10 @@ line left 1.0 from 7/12 <2nd box.nw, 2nd box.sw>
|
|||
.DS C
|
||||
\fIFigure 1. Interprocess and outside world communication channels\fP
|
||||
.DE
|
||||
The basic channel handling is done by \f5chan_in\fP and \f5chan_out\fP. All
|
||||
other routines are based on them. The routine \f5chan_any\fP only checks if
|
||||
The basic channel handling is done by \f(CWchan_in\fP and \f(CWchan_out\fP. All
|
||||
other routines are based on them. The routine \f(CWchan_any\fP only checks if
|
||||
there's a value available on a given channel. (It does not read this value!)
|
||||
\f5C_init\fP initializes an array of interprocess communication channels.
|
||||
\f(CWC_init\fP initializes an array of interprocess communication channels.
|
||||
.LP
|
||||
The following table shows Occam statements paired with the routines used to
|
||||
execute them.
|
||||
|
@ -224,7 +224,7 @@ for(;;) {
|
|||
T}
|
||||
.sp 0.5
|
||||
.TE
|
||||
The code of \f5c_init\fP, \f5chan_in\fP, \f5chan_out\fP and \f5chan_any\fP
|
||||
The code of \f(CWc_init\fP, \f(CWchan_in\fP, \f(CWchan_out\fP and \f(CWchan_any\fP
|
||||
can be found in Appendix A.
|
||||
.NH 3
|
||||
Synchronization on interprocess communication channels
|
||||
|
@ -252,7 +252,7 @@ NOW
|
|||
\fBNOW\fP evaluates to the current time returned by the time(2) system call.
|
||||
The code is simply:
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
.nf
|
||||
long now()
|
||||
{
|
||||
|
@ -276,14 +276,14 @@ defined:
|
|||
\fBerror\fP, that corresponds with the standard error file.
|
||||
.IP -
|
||||
\fBfile\fP, an array of channels that can be subscripted with an index
|
||||
obtained by the builtin named process ``\f5open\fP''. Note that
|
||||
obtained by the builtin named process ``\f(CWopen\fP''. Note that
|
||||
\fBinput\fP=\fBfile\fP[0], \fBoutput\fP=\fBfile\fP[1] and
|
||||
\fBerror\fP=\fBfile\fP[2].
|
||||
.LP
|
||||
Builtin named processes to open and close files are defined as
|
||||
.DS
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
proc open(var index, value name[], mode[]) = ..... :
|
||||
proc close(value index) = ..... :
|
||||
.fi
|
||||
|
@ -291,7 +291,7 @@ proc close(value index) = ..... :
|
|||
.DE
|
||||
To open a file `junk', write nonsense onto it, and close it, goes as follows:
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
.nf
|
||||
var i:
|
||||
seq
|
||||
|
@ -318,19 +318,19 @@ and lines are buffered before they are read).
|
|||
(i.e. no echoing of typed characters and no line buffering).
|
||||
.LP
|
||||
To exit an Occam program, e.g. after an error, a builtin named process
|
||||
\f5exit\fP is available that takes an exit code as its argument.
|
||||
\f(CWexit\fP is available that takes an exit code as its argument.
|
||||
.NH 2
|
||||
Replicators and slices
|
||||
.PP
|
||||
Both the base and the count of replicators like in
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
par i = [ base for count ]
|
||||
.ft
|
||||
.DE
|
||||
may be arbitrary expressions. The count in array slices like in
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
c ? A[ base for count ]
|
||||
.ft
|
||||
.DE
|
||||
|
|
|
@ -27,7 +27,7 @@ ANY
|
|||
According to the occam syntax the \fBANY\fP keyword may be the only argument of
|
||||
an input or output process. Thus,
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
c ? ANY; x
|
||||
.ft
|
||||
.DE
|
||||
|
|
|
@ -2,14 +2,14 @@
|
|||
.NH
|
||||
Appendix A: Implementation of the channel routines
|
||||
.DS L
|
||||
.ft 5
|
||||
.ft CW
|
||||
.ta 0.65i 1.3i 1.95i 2.6i 3.25i 3.9i 4.55i 5.2i 5.85i 6.5i
|
||||
.so channel.h.t
|
||||
.ft
|
||||
.DE
|
||||
.bp
|
||||
.DS L
|
||||
.ft 5
|
||||
.ft CW
|
||||
.ta 0.65i 1.3i 1.95i 2.6i 3.25i 3.9i 4.55i 5.2i 5.85i 6.5i
|
||||
.so channel.c.t
|
||||
.ft
|
||||
|
|
|
@ -5,7 +5,7 @@ routines to simulate parallelism
|
|||
.PP
|
||||
Translation of the parallel construct:
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
par
|
||||
P0
|
||||
par i = [ 1 for n ]
|
||||
|
|
|
@ -82,7 +82,7 @@ machine-dependent description table (see figure 1.).
|
|||
So the major part of the code of a target optimizer is
|
||||
shared among all target optimizers.
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
|
||||
|-------------------------|
|
||||
|
@ -164,7 +164,7 @@ ANY matches every instruction mnemonic.
|
|||
.nf
|
||||
|
||||
Examples of mnemonic descriptions:
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
add
|
||||
sub.l
|
||||
|
@ -177,7 +177,7 @@ An operand can also be described by a string constant.
|
|||
.nf
|
||||
|
||||
Examples:
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
(sp)+
|
||||
r5
|
||||
|
@ -192,7 +192,7 @@ Each such declaration defines the name of a variable and
|
|||
a \fIrestriction\fR to which its value is subjected.
|
||||
.nf
|
||||
Example of variable declarations:
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
CONST { VAL[0] == '$' };
|
||||
REG { VAL[0] == 'r' && VAL[1] >= '0' && VAL[1] <= '3' &&
|
||||
|
@ -206,7 +206,7 @@ a null-terminated string.
|
|||
An operand description given via a variable name matches an
|
||||
actual operand if the actual operand obeys the associated restriction.
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
CONST matches $1, $-5, $foo etc.
|
||||
REG matches r0, r1, r2 and r3
|
||||
|
@ -224,7 +224,7 @@ These procedures must be added to the table after the patterns.
|
|||
.nf
|
||||
|
||||
Example:
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
FERMAT_NUMBER { VAL[0] == '$' && is_fermat_number(&VAL[1]) };
|
||||
|
||||
|
@ -238,7 +238,7 @@ The most general form allowed is:
|
|||
string_constant1 variable_name string_constant2
|
||||
|
||||
Example:
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
(REG)+ matches (r0)+, (r1)+, (r2)+ and (r3)+
|
||||
|
||||
|
@ -268,19 +268,19 @@ the optional constraint C is satisfied, i.e. it evaluates to TRUE.
|
|||
.LP
|
||||
.nf
|
||||
The pattern:
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
dec REG : move.b CONST,(REG)
|
||||
|
||||
.ft R
|
||||
matches:
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
dec r0 : move.b $4,(r0)
|
||||
|
||||
.ft R
|
||||
but not:
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
dec r0 : move.b $4,(r1)
|
||||
|
||||
|
@ -292,7 +292,7 @@ extra names for a register should be declared, all sharing
|
|||
the same restriction.
|
||||
.nf
|
||||
Example:
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
REG1,REG2 { VAL[0] == 'r' && ..... };
|
||||
|
||||
|
@ -305,13 +305,13 @@ the parameter restrictions).
|
|||
The expression may refer to the variables and to ANY.
|
||||
.nf
|
||||
Example:
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
move REG1,REG2 { REG1[1] == REG2[1] + 1 }
|
||||
|
||||
.ft R
|
||||
matches
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
move r1,r0
|
||||
move r2,r1
|
||||
|
@ -338,7 +338,7 @@ Vax examples
|
|||
Suppose the table contains the following declarations:
|
||||
.nf
|
||||
|
||||
.ft 5
|
||||
.ft CW
|
||||
X, LOG { TRUE };
|
||||
LAB { VAL[0] == 'L' }; /* e.g. L0017 */
|
||||
A { no_side_effects(VAL) };
|
||||
|
@ -353,7 +353,7 @@ These procedures must be supplied by the table-writer and must be
|
|||
included in the table.
|
||||
.PP
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
\fIentry:\fP addl3 X,A,A -> addl2 X,A;
|
||||
.ft R
|
||||
|
||||
|
@ -362,7 +362,7 @@ This entry changes a 3-operand instruction into a cheaper 2-operand
|
|||
instruction.
|
||||
An optimization like:
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
addl3 r0,(r2)+,(r2)+ -> addl2 r0,(r2)+
|
||||
|
||||
|
@ -373,7 +373,7 @@ Hence the second argument is required to
|
|||
be side-effect free.
|
||||
.PP
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
\fIentry:\fP addw2 $-NUM,X -> subw2 $NUM,X;
|
||||
.ft R
|
||||
|
||||
|
@ -384,7 +384,7 @@ because constants in the range 0 to 63 are represented
|
|||
very efficiently on the Vax.
|
||||
.PP
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
\fIentry:\fP bitw $NUM,A : jneq LAB
|
||||
{ is_poweroftwo(NUM,LOG) } -> jbs $LOG,A,LAB;
|
||||
|
||||
|
@ -395,7 +395,7 @@ x and y.
|
|||
A "jbs n,x,l" branches to l if bit n of x is set.
|
||||
So, for example, the following transformation is possible:
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
|
||||
bitw $32,r0 : jneq L0017 -> jbs $5,r0,L0017
|
||||
|
||||
|
@ -413,7 +413,7 @@ PDP-11 examples
|
|||
Suppose we have the following declarations:
|
||||
.nf
|
||||
|
||||
.ft 5
|
||||
.ft CW
|
||||
X { TRUE };
|
||||
A { no_side_effects(VAL) };
|
||||
L1, L2 { VAL[0] == 'I' };
|
||||
|
@ -426,7 +426,7 @@ The implementation of "no_side_effects" may of course
|
|||
differ for the PDP-11 and the Vax.
|
||||
.PP
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
\fIentry:\fP mov REG,A : ANY A,X -> mov REG,A : ANY REG,X ;
|
||||
.ft R
|
||||
|
||||
|
@ -436,7 +436,7 @@ If A and REG hold the same value (which is true after "mov REG,A")
|
|||
and A is used as source (first) operand, it is cheaper to use REG instead.
|
||||
.PP
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
\fIentry:\fP jeq L1 : jbr L2 : labdef L1 -> jne L2 : labdef L1;
|
||||
.ft R
|
||||
|
||||
|
@ -447,7 +447,7 @@ As the target optimizer has to know how such a definition
|
|||
looks like, this must be expressed in the table (see Appendix A).
|
||||
.PP
|
||||
.nf
|
||||
.ft 5
|
||||
.ft CW
|
||||
\fIentry:\fP add $01,X { carry_dead(REST) } -> inc X;
|
||||
.ft R
|
||||
|
||||
|
@ -487,27 +487,27 @@ backwards,
|
|||
as it is possible that instructions that were rejected earlier now do match.
|
||||
For example, consider the following patterns:
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
cmp $0, X -> tst X ;
|
||||
mov REG,X : tst X -> move REG.X ; /* redundant test */
|
||||
.ft R
|
||||
.DE
|
||||
If the input is:
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
mov r0,foo : cmp $0,foo
|
||||
.ft R
|
||||
.DE
|
||||
then the first instruction is initially rejected.
|
||||
However, after the transformation
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
cmp $0,foo -> tst foo
|
||||
.ft R
|
||||
.DE
|
||||
the following optimization is possible:
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
mov r0,foo : tst foo -> mov r0,foo
|
||||
.ft R
|
||||
.DE
|
||||
|
@ -725,7 +725,7 @@ Identifiers are sequences of letters, digits and the underscore ('_'),
|
|||
beginning with a letter.
|
||||
.PP
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
table -> {parameter_line} '%%;' {variable_declaration} '%%;'
|
||||
{entry} '%%;' user_routines.
|
||||
.ft R
|
||||
|
@ -735,7 +735,7 @@ constants, variable declarations, pattern rules and
|
|||
user-supplied subroutines.
|
||||
.PP
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
parameter_line -> identifier value ';' .
|
||||
.ft R
|
||||
.DE
|
||||
|
@ -792,7 +792,7 @@ the line is not optimized.
|
|||
Optimization does, however, proceed with the rest of the input.
|
||||
.PP
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
variable_declaration -> identifier {',' identifier} restriction ';' .
|
||||
|
||||
restriction -> '{' anything '}' .
|
||||
|
@ -816,7 +816,7 @@ Inside the expression, the name VAL stands for the part of the actual
|
|||
The expression may contain calls to procedures that are defined in the
|
||||
user-routines section.
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
entry -> pattern '->' replacement ';' .
|
||||
|
||||
pattern -> instruction_descr
|
||||
|
@ -862,7 +862,7 @@ which contains the mnemonic of the first instruction of the
|
|||
rest of the input. (REST is a null-string if this mnemonic can
|
||||
not be determined).
|
||||
.DS
|
||||
.ft 5
|
||||
.ft CW
|
||||
user_routines -> anything .
|
||||
.ft R
|
||||
.DE
|
||||
|
|
Loading…
Reference in a new issue