|
996
|
1 .\" Note: This is both a current manual and an archeological exhibit.
|
|
|
2 .\" All revisions must be properly conditioned on the c string so that
|
|
|
3 .\" it's still possible to format the INTERCAL-72 manual. Only outright
|
|
|
4 .\" errors should be corrected -- each of these is marked with CORRECTION
|
|
|
5 .\" and an explanatory comment.
|
|
|
6 .\"
|
|
|
7 .\" This document is free; you can redistribute it and/or modify
|
|
|
8 .\" it under the terms of the GNU General Public License as published by
|
|
|
9 .\" the Free Software Foundation; either version 2 of the License, or
|
|
|
10 .\" (at your option) any later version.
|
|
|
11 .\"
|
|
|
12 .\" This document is distributed in the hope that it will be amusing,
|
|
|
13 .\" but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
14 .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
15 .\" GNU General Public License for more details.
|
|
|
16 .\"
|
|
|
17 .\" You should have received a copy of the GNU General Public License
|
|
|
18 .\" along with this document; if not, write to the Free Software
|
|
|
19 .\" Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
20 .ND
|
|
|
21 .ds vb V\v'-0.2'\h'-0.6'\-\v'0.2'
|
|
|
22 .if n .ds es \o"O|"
|
|
|
23 .if t .ds es \(es
|
|
|
24 .if n .ds ct \o"c/"
|
|
|
25 .if t .ds ct \(ct
|
|
|
26 .if n .ds no \o"-'"
|
|
|
27 .if t .ds no \(no
|
|
|
28 .if n .ds ov -
|
|
|
29 .if t .ds ov \(rn
|
|
|
30 .INITR intercal.refs
|
|
|
31 .TL
|
|
|
32 THE INTERCAL PROGRAMMING LANGUAGE
|
|
|
33 .br
|
|
|
34 .if '\*c'y' REVISED REFERENCE MANUAL
|
|
|
35 .if '!\*c'n' REFERENCE MANUAL
|
|
|
36
|
|
|
37 .AU "Donald R. Woods"
|
|
|
38 .AF ""
|
|
|
39 .AU "and"
|
|
|
40 .AF ""
|
|
|
41 .AU "James M. Lyon"
|
|
|
42 .AF ""
|
|
|
43 .if '\*c'y' \{\
|
|
|
44 .AU ""
|
|
|
45 .AU "C-INTERCAL revisions:"
|
|
|
46 .AU "Louis Howell"
|
|
|
47 .AF ""
|
|
|
48 .AU "and"
|
|
|
49 .AF ""
|
|
|
50 .AU "Eric S. Raymond" \}
|
|
|
51 .AF ""
|
|
|
52 .AST ""
|
|
|
53 .AS 2
|
|
|
54 .ce 2
|
|
|
55 \fICopyright (C) 1973 by Donald R. Woods
|
|
|
56 and James M. Lyon\fR
|
|
|
57 .if '\*c'y' \{\
|
|
|
58 .ce 2
|
|
|
59 \fICopyright (C) 1996, 1997 by Eric S. Raymond
|
|
|
60 Redistribution encouraged under GPL\}
|
|
|
61 .sp
|
|
|
62 .ce 1
|
|
|
63 (This version distributed with C-INTERCAL 0.18)
|
|
|
64 .AE
|
|
|
65 .MT 4
|
|
|
66 .nr % 0
|
|
|
67 .nr Hs 5
|
|
|
68 .nr Ej 1
|
|
|
69 .bp
|
|
|
70 .H 1 "INTRODUCTION"
|
|
|
71 .if '\*c'y' \{\
|
|
|
72 .DS I F
|
|
|
73 "But I don't want to go among mad people," Alice remarked.
|
|
|
74 .P
|
|
|
75 "Oh, you ca'n't help that," said the Cat: "We're all mad here. I'm
|
|
|
76 mad. You're mad."
|
|
|
77 .P
|
|
|
78 "How do you know I'm mad?" said Alice.
|
|
|
79 .P
|
|
|
80 "You must be," said the Cat, "or you wouldn't have come here."
|
|
|
81 .DE \}
|
|
|
82 .P
|
|
|
83 The names you are about to ignore are true. However, the story has been changed
|
|
|
84 significantly. Any resemblance of the programming language portrayed here
|
|
|
85 to other programming languages, living or dead, is purely coincidental.
|
|
|
86 .H 2 "Origin and Purpose"
|
|
|
87 .P
|
|
|
88 The INTERCAL programming language was designed the morning of May 26, 1972
|
|
|
89 by Donald R. Woods and James M. Lyon, at Princeton University. Exactly when
|
|
|
90 in the morning will become apparent in the course of this manual.
|
|
|
91 .ie '\*c'y' \{\
|
|
|
92 .P
|
|
|
93 Eighteen years later (give or take a few months) Eric S. Raymond perpetrated
|
|
|
94 a UNIX-hosted INTERCAL compiler as a weekend hack. The C-INTERCAL
|
|
|
95 implementation has since been maintained and extended by an international
|
|
|
96 community of technomasochists, including Louis Howell, Steve Swales,
|
|
|
97 Michael Ernst, and Brian Raiter.
|
|
|
98 .P
|
|
|
99 (There was evidently an Atari implementation sometime between these
|
|
|
100 two; notes on it got appended to the INTERCAL-72 manual. The culprits
|
|
|
101 have sensibly declined to identify themselves.)
|
|
|
102 .P
|
|
|
103 INTERCAL \}
|
|
|
104 .el It
|
|
|
105 was inspired by one ambition: to have a compiler language which has nothing at
|
|
|
106 all in common with any other major language. By 'major' was meant anything
|
|
|
107 with which the authors were at all familiar, e.g., FORTRAN, BASIC, COBOL,
|
|
|
108 ALGOL, SNOBOL, SPITBOL, FOCAL, SOLVE, TEACH, APL, LISP, and PL/I. For the
|
|
|
109 most part, INTERCAL has remained true to this goal, sharing only the basic
|
|
|
110 elements such as variables, arrays, and the ability to do I/O, and eschewing
|
|
|
111 all conventional operations other than the assignment statement (FORTRAN
|
|
|
112 "=").
|
|
|
113 .H 2 "Acronym"
|
|
|
114 .P
|
|
|
115 The full name of the compiler is "Compiler Language With No Pronounceable
|
|
|
116 Acronym", which is, for obvious reasons, abbreviated "INTERCAL".
|
|
|
117 .H 2 "Acknowledgments"
|
|
|
118 .P
|
|
|
119 The authors are deeply indebted to Eric M. Van and Daniel J. Warmenhoven,
|
|
|
120 without whose unwitting assistance this manual would still have been
|
|
|
121 possible.
|
|
|
122 .H 1 "FUNDAMENTAL CONCEPTS"
|
|
|
123 .if '\*c'y' \{\
|
|
|
124 .DS I F
|
|
|
125 "There's nothing like eating hay when you're faint," the White King
|
|
|
126 remarked to Alice, as he munched away.
|
|
|
127 .P
|
|
|
128 "I should think throwing cold water over you would be better," Alice
|
|
|
129 suggested: "-- or some sal-volatile."
|
|
|
130 .P
|
|
|
131 "I didn't say there was nothing \fIbetter\fR," the King replied. "I
|
|
|
132 said there was nothing \fIlike\fR it." Which Alice did not venture to
|
|
|
133 deny.
|
|
|
134 .DE \}
|
|
|
135 .P
|
|
|
136 In this section an attempt is made to describe how and why INTERCAL may be
|
|
|
137 used; i.e., what it is like and what it is good for.
|
|
|
138 .H 2 "Sample Program"
|
|
|
139 .SETR example1
|
|
|
140 .P
|
|
|
141 Shown below is a relatively simple INTERCAL program which will read in 32-bit
|
|
|
142 unsigned integers, treat them as signed, 2's-complement numbers, and print out
|
|
|
143 their absolute values. The program exits if the absolute value is zero. Note
|
|
|
144 in particular the inversion routine (statements 6 through 14), which could
|
|
|
145 be greatly simplified if the subroutine library (see section
|
|
|
146 .GETHN sublib
|
|
|
147 ) were used.
|
|
|
148 .P
|
|
|
149 A more detailed analysis of a program is made in section
|
|
|
150 .GETHN proghints
|
|
|
151 of this manual.
|
|
|
152 .\" Note: there was an error in line 15 in the original manual;
|
|
|
153 .\" the operands of the third \(ct were swapped.
|
|
|
154
|
|
|
155 .DS L
|
|
|
156 .cs R 24
|
|
|
157 DO (5) NEXT
|
|
|
158 (5) DO FORGET #1
|
|
|
159 PLEASE WRITE IN :1
|
|
|
160 DO .1 <- '\*(vb":1~'#32768\*(ct#0'"\*(ct#1'~#3
|
|
|
161 DO (1) NEXT
|
|
|
162 DO :1 <- "'\*(vb":1~'#65535\*(ct#0'"\*(ct#65535'
|
|
|
163 ~'#0\*(ct#65535'"\*(ct"'\*(vb":1~'#0\*(ct#65535'"
|
|
|
164 \*(ct#65535'~'#0\*(ct#65535'"
|
|
|
165 DO :2 <- #1
|
|
|
166 PLEASE DO (4) NEXT
|
|
|
167 (4) DO FORGET #1
|
|
|
168 DO .1 <- "\*(vb':1~:2'\*(ct#1"~#3
|
|
|
169 DO :1 <- "'\*(vb":1~'#65535\*(ct#0'"\*(ct":2~'#65535
|
|
|
170 \*(ct#0'"'~'#0\*(ct#65535'"\*(ct"'\*(vb":1~'#0
|
|
|
171 \*(ct#65535'"\*(ct":2~'#0\*(ct#65535'"'~'#0\*(ct#65535'"
|
|
|
172 DO (1) NEXT
|
|
|
173 DO :2 <- ":2~'#0\*(ct#65535'"
|
|
|
174 \*(ct"'":2~'#65535\*(ct#0'"\*(ct#0'~'#32767\*(ct#1'"
|
|
|
175 DO (4) NEXT
|
|
|
176 (2) DO RESUME .1
|
|
|
177 (1) PLEASE DO (2) NEXT
|
|
|
178 PLEASE FORGET #1
|
|
|
179 DO READ OUT :1
|
|
|
180 PLEASE DO .1 <- '\*(vb"':1~:1'~#1"\*(ct#1'~#3
|
|
|
181 DO (3) NEXT
|
|
|
182 PLEASE DO (5) NEXT
|
|
|
183 (3) DO (2) NEXT
|
|
|
184 PLEASE GIVE UP
|
|
|
185 .cs R
|
|
|
186 .DE
|
|
|
187 .H 2 "Uses for INTERCAL"
|
|
|
188 .P
|
|
|
189 INTERCAL's main advantage over other programming languages is its strict
|
|
|
190 simplicity. It has few capabilities, and thus there are few restrictions to
|
|
|
191 be kept in mind. Since it is an exceedingly easy language to learn, one
|
|
|
192 might expect it would be a good language for initiating novice programmers.
|
|
|
193 Perhaps surprising, then, is the fact that it would be more likely to
|
|
|
194 initiate a novice into a search for another line of work. As it turns out,
|
|
|
195 INTERCAL is more useful (which isn't saying much) as a challenge to
|
|
|
196 professional programmers. Those who doubt this need only refer back to the
|
|
|
197 sample program in section
|
|
|
198 .GETHN example1
|
|
|
199 .\" CORRECTION:
|
|
|
200 .\" The original manual counted 22 statements, incorrectly.
|
|
|
201 \&. This 23-statement program took somewhere
|
|
|
202 from 15 to 30 minutes to write, whereas the same objectives can be achieved
|
|
|
203 by single-statement programs in either SNOBOL;
|
|
|
204 .DS L
|
|
|
205 PLEASE INPUT POS(0) ('-' ! '')
|
|
|
206 + (SPAN('0123456789') $ OUTPUT)
|
|
|
207 + *NE(OUTPUT) :S(PLEASE)F(END)
|
|
|
208 .DE
|
|
|
209 or APL;
|
|
|
210 .DS L
|
|
|
211 [1] \(->0\(!=\(sq\(<-\(or\(sq
|
|
|
212 .DE
|
|
|
213 Admittedly, neither of these is likely to appear more intelligible to
|
|
|
214 anyone unfamiliar with the languages involved, but they took roughly 60
|
|
|
215 seconds and 15 seconds, respectively, to write. Such is the overwhelming
|
|
|
216 power of INTERCAL!
|
|
|
217 .P
|
|
|
218 The other major importance of INTERCAL lies in its seemingly inexhaustible
|
|
|
219 capacity for amazing one's fellow programmers, confounding programming shop
|
|
|
220 managers, winning friends, and influencing people. It is a well-known and
|
|
|
221 oft-demonstrated fact that a person whose work is incomprehensible is held
|
|
|
222 in high esteem. For example, if one were to state that the simplest way to
|
|
|
223 store a value of 65536 in a 32-bit INTERCAL variable is:
|
|
|
224 .DS L
|
|
|
225 DO :1 <- #0\*(ct#256
|
|
|
226 .DE
|
|
|
227 any sensible programmer would say that that was absurd. Since this is
|
|
|
228 indeed the simplest method, the programmer would be made to look foolish in
|
|
|
229 front of his boss, who would of course happened to turn up, as bosses are
|
|
|
230 wont to do. The effect would be no less devastating for the programmer
|
|
|
231 having been correct.
|
|
|
232 .H 1 "DESCRIPTION"
|
|
|
233 .if '\*c'y' \{\
|
|
|
234 .DS I F
|
|
|
235 "I quite agree with you," said the Duchess; "and the moral of that
|
|
|
236 is -- 'Be what you would seem to be' -- or, if you'd like it put more
|
|
|
237 simply -- 'Never imagine yourself not to be otherwise than what it might
|
|
|
238 appear to others that what you were or might have been was not
|
|
|
239 otherwise than what you had been would have appeared to them to be
|
|
|
240 otherwise."
|
|
|
241 .P
|
|
|
242 "I think I should understand that better," Alice said very politely,
|
|
|
243 "if I had it written down: but I ca'n't quite follow it as you say
|
|
|
244 it."
|
|
|
245 .P
|
|
|
246 "That's nothing to what I could say if I chose," the Duchess replied,
|
|
|
247 in a pleased tone.
|
|
|
248 .DE \}
|
|
|
249 .P
|
|
|
250 The examples of INTERCAL programming which have appeared in the preceding
|
|
|
251 sections of this manual have probably seemed highly esoteric to the reader
|
|
|
252 unfamiliar with the language. With the aim of making them more so, we
|
|
|
253 present here a description of INTERCAL.
|
|
|
254 .H 2 "Variables"
|
|
|
255 .P
|
|
|
256 INTERCAL allows only 2 different types of variables, the
|
|
|
257 .B "16-bit integer"
|
|
|
258 and the
|
|
|
259 .B "32-bit integer."
|
|
|
260 These are represented by a spot (.) or two-spot
|
|
|
261 (:), respectively, followed by any number between 1 and 65535, inclusive.
|
|
|
262 These variables may contain only non-negative numbers; thus they have the
|
|
|
263 respective ranges of values: 0 to 65535 and 0 to 4294967295. Note: .123 and
|
|
|
264 :123 are two distinct variables. On the other hand, .1 and .0001 are
|
|
|
265 identical. Furthermore, the latter may \fInot\fR be written as 1E-3.
|
|
|
266 .H 2 "Constants"
|
|
|
267 .P
|
|
|
268 .B Constants
|
|
|
269 are 16-bit values only and may range from 0 to 65535. They are
|
|
|
270 prefixed by a mesh (#). Caution! Under no circumstances confuse the mesh
|
|
|
271 with the interleave operator, except under confusing circumstances!
|
|
|
272 .H 2 "Arrays"
|
|
|
273 .P
|
|
|
274 .B Arrays
|
|
|
275 are represented by a tail (,) for 16-bit values, or a hybrid (;) for
|
|
|
276 32-bit values, followed by a number between 1 and 65535, inclusive. The
|
|
|
277 number is suffixed by the word SUB, followed by the subscripts, separated
|
|
|
278 optionally by spaces. Subscripts may be any expressions, including those
|
|
|
279 involving subscripted variables. This occasionally leads to ambiguous
|
|
|
280 constructions, which are resolved as discussed in section
|
|
|
281 .GETHN precedence
|
|
|
282 \&. Definition
|
|
|
283 of array dimensions will be discussed later in greater detail, since
|
|
|
284 discussing it in less detail would be difficult. As before, ,123 and ;123
|
|
|
285 are distinct. In summary, .123, :123, #123, ,123, and ;123 are all
|
|
|
286 distinct.
|
|
|
287 .H 2 "Operators"
|
|
|
288 .P
|
|
|
289 INTERCAL recognizes 5 operators -- 2 binary and 3 unary \*F. Please be kind to
|
|
|
290 our operators: they may not be very intelligent, but they're all we've got.
|
|
|
291 In a sense, all 5 operators are binary, as they are all bit-oriented, but
|
|
|
292 it is not our purpose here to quibble about bits of trivia.
|
|
|
293 .if '\*c'y' \{\
|
|
|
294 .FS
|
|
|
295 Other operators are also available with C-INTERCAL's non-standard
|
|
|
296 dialects; see section
|
|
|
297 .GETHN tri_intercal
|
|
|
298 \&.
|
|
|
299 .FE \}
|
|
|
300 .H 3 "Binary Operators"
|
|
|
301 .P
|
|
|
302 The binary operators are \fBinterleave\fR (also called \fBmingle\fR)
|
|
|
303 and \fBselect\fR, which
|
|
|
304 are represented by a change (\*(ct) and a sqiggle [sic] (~), respectively.
|
|
|
305 .if '\*c'y' \{\
|
|
|
306 (In C-INTERCAL's ASCII environment, EBCDIC \*(ct is replaced by a big
|
|
|
307 money ($), but \*(ct can be used if encoded in Latin-1 as \e0xA2
|
|
|
308 or UTF-8 as 0xC2A2.) \}
|
|
|
309 .P
|
|
|
310 The interleave operator takes two 16-bit values and produces a 32-bit result
|
|
|
311 by alternating the bits of the operands. Thus, #65535\*(ct#0 has the 32-bit
|
|
|
312 binary form 101010....10 or 2863311530 decimal, while #0\*(ct#65535 =
|
|
|
313 0101....01 binary = 1431655765 decimal, and #255\*(ct#255 is equivalent to
|
|
|
314 #65535.
|
|
|
315 .P
|
|
|
316 The select operator takes from the first operand whichever bits correspond
|
|
|
317 to 1's in the second operand, and packs these bits to the right in the result.
|
|
|
318 Both operands are automatically padded on the left with zeros to 32 bits
|
|
|
319 before the selection takes place, so the variable types are unrestricted.
|
|
|
320 If more than 16 bits are selected, the result is a 32-bit value, otherwise
|
|
|
321 it is a 16-bit value. For example, #179~#201 (binary value 10110011~11001001)
|
|
|
322 selects from the first argument the 8th, 7th, 4th, and 1st from last bits,
|
|
|
323 namely, 1001, which = 9. But #201~#179 selects from binary 11001001 the 8th,
|
|
|
324 6th, 5th, 2nd, and 1st from last bits, giving 10001 = 17. #179~#179 has the
|
|
|
325 value 31, while #201~#201 has the value 15.
|
|
|
326 .P
|
|
|
327 Perhaps a simpler way of understanding the operation of the select operator
|
|
|
328 .\" CORRECTION:
|
|
|
329 .\" "in Figure 1" was originally "on the following page (Figure 1)"
|
|
|
330 .\" We can't rely on the page boundaries any more.
|
|
|
331 would be to examine the logic diagram in Figure 1, which
|
|
|
332 performs the select operation upon two 8-bit values, A and B. The gates used
|
|
|
333 are Warmenhovian logic gates, which means the outputs have four possible
|
|
|
334 values: low, high, undefined (value of an uninitialized flip-flop), and
|
|
|
335 oscillating (output of a NOR gate with one input low and the other input
|
|
|
336 connected to the output). These values are represented symbolically
|
|
|
337 by '0', '1', '?', and '\*(es'.
|
|
|
338 Note in particular that, while NOT-0 is 1 and NOT-1
|
|
|
339 is 0 as in two-valued logic, NOT-? is ? and NOT-\*(es is \*(es. The functions
|
|
|
340 of the various gates are listed in Table 1.
|
|
|
341 .if n \{\
|
|
|
342 .P
|
|
|
343 [Warning: The following picture will be garbled or missing.
|
|
|
344 Get a better output device.]
|
|
|
345 .sp 1 \}
|
|
|
346 .PS
|
|
|
347 # The CIRCUITOUS DIAGRAM, Figure 1 of the INTERCAL manual.
|
|
|
348 #
|
|
|
349 # Transcribed to PIC by Eric S. Raymond from the paper original.
|
|
|
350 # The transcription is topologically correct but not geometrically perfect.
|
|
|
351 #
|
|
|
352 # I discovered late in the process that the gate spacing to gate width
|
|
|
353 # ratio should be 6/5, not 5/5. The only place the difference shows is
|
|
|
354 # in the zigzag part of the adventitious lead below gate 37, which is
|
|
|
355 # a bit narrower in this version than in the paper original.
|
|
|
356 #
|
|
|
357 # Minor liberties have been taken with the sizes of some features at the
|
|
|
358 # left and right sides to fit the diagram on a letter-sized page. The
|
|
|
359 # A/B input leads should really be a whole boxwidth wide, and the bus line
|
|
|
360 # rectangle was slightly wider and further right in the paper original.
|
|
|
361 # Also, there are only 15 "New York" terminals rather than 16, and in the
|
|
|
362 # original the bus terminal label texts were rotated 90 degrees clockwise.
|
|
|
363 #
|
|
|
364 # The whole diagram can be scaled horizontally or vertically by changing
|
|
|
365 # the boxwid and boxht variables. At default scale the values boxwid =
|
|
|
366 # 0.60 boxht = 0.525 reproduce the paper version most exactly; they get
|
|
|
367 # the gate grid and leads nearly perfect.
|
|
|
368 #
|
|
|
369 scale=6/5 # This is how we scale the whole thing to fit on 8.5x11
|
|
|
370 boxwid = 0.60
|
|
|
371 boxht = 0.525
|
|
|
372 linewid = boxwid
|
|
|
373 lineht = boxht
|
|
|
374 movewid = boxwid
|
|
|
375 moveht = boxht
|
|
|
376
|
|
|
377 # Offset of top and bottom pins from gate midline
|
|
|
378 define pinoffset {(2/3)}
|
|
|
379
|
|
|
380 define warmengate {
|
|
|
381 # Draw a Warmenhovian gate box
|
|
|
382 [
|
|
|
383 box invis;
|
|
|
384 line from last box .sw \
|
|
|
385 to last box .nw \
|
|
|
386 to 1/2 <last box .ne, last box .n> \
|
|
|
387 to 1/2 <last box .e, last box .ne> \
|
|
|
388 to 1/2 <last box .e, last box .se> \
|
|
|
389 to 1/2 <last box .se, last box .s> \
|
|
|
390 to last box .sw;
|
|
|
391 IN: last box .w;
|
|
|
392 UP: pinoffset <last box .w, last box .nw>
|
|
|
393 DN: pinoffset <last box .w, last box .sw>
|
|
|
394 OUT: last box .e;
|
|
|
395 "$1" at last box .center;
|
|
|
396 ]
|
|
|
397 }
|
|
|
398
|
|
|
399 [ # Beginning of diagram object
|
|
|
400
|
|
|
401 # Draw the gate array
|
|
|
402 copy thru % move to (($1-1) * movewid * 2, ($2-1) * moveht * 2); warmengate($3) % until "END"
|
|
|
403 0 1 6
|
|
|
404 0 2 6
|
|
|
405 0 3 1
|
|
|
406 0 4 1
|
|
|
407 0 5 1
|
|
|
408 0 6 1
|
|
|
409 0 7 1
|
|
|
410 0 8 1
|
|
|
411 0 9 1
|
|
|
412 0 10 1
|
|
|
413 END
|
|
|
414 copy thru % move to ((boxwid + movewid * 7 / 5) + ($1-2) * movewid * 2, ($2-1) * moveht * 2); warmengate($3) % until "END"
|
|
|
415 1 1 1
|
|
|
416 1 2 2
|
|
|
417 1 3 2
|
|
|
418 1 4 2
|
|
|
419 1 5 2
|
|
|
420 1 6 2
|
|
|
421 1 7 2
|
|
|
422 1 8 2
|
|
|
423 1 9 2
|
|
|
424 1 10 2
|
|
|
425 2 1 1
|
|
|
426 2 2 7
|
|
|
427 2 3 4
|
|
|
428 2 4 3
|
|
|
429 2 5 3
|
|
|
430 2 6 3
|
|
|
431 2 7 7
|
|
|
432 2 8 3
|
|
|
433 2 9 7
|
|
|
434 2 10 3
|
|
|
435 3 1 1
|
|
|
436 3 2 3
|
|
|
437 3 3 3
|
|
|
438 3 4 4
|
|
|
439 3 5 4
|
|
|
440 3 6 3
|
|
|
441 3 7 3
|
|
|
442 3 8 3
|
|
|
443 3 9 3
|
|
|
444 3 10 3
|
|
|
445 4 1 1
|
|
|
446 4 2 4
|
|
|
447 4 3 5
|
|
|
448 4 4 5
|
|
|
449 4 5 4
|
|
|
450 4 6 5
|
|
|
451 4 7 4
|
|
|
452 4 8 3
|
|
|
453 4 9 2
|
|
|
454 4 10 1
|
|
|
455 END
|
|
|
456
|
|
|
457 # Draw bus line:
|
|
|
458 BUSLINE: box with .sw at 41st [].se + (boxwid/2, 0) \
|
|
|
459 wid (boxwid / 2) \
|
|
|
460 ht (50th [].n.y - 41st [] .s.y)
|
|
|
461 copy thru % move to $1 / 40 <last box .n, last box .s>; "$2" % until "END"
|
|
|
462 9 B
|
|
|
463 11 U
|
|
|
464 13 S
|
|
|
465 17 L
|
|
|
466 19 I
|
|
|
467 21 N
|
|
|
468 23 E
|
|
|
469 30 8
|
|
|
470 END
|
|
|
471 define newyork {
|
|
|
472 line right boxwid/3
|
|
|
473 box invis "" "TO" "NEW" "YORK" ""
|
|
|
474 }
|
|
|
475 define philly {
|
|
|
476 line right boxwid/3
|
|
|
477 box invis "" "TO" "PHILA-" "DELPHIA" ""
|
|
|
478 }
|
|
|
479 for i = 0 to 14 do {
|
|
|
480 move to (i+1)/18 <BUSLINE.ne,BUSLINE.se>
|
|
|
481 newyork
|
|
|
482 }
|
|
|
483 move to (i+1)/18 <BUSLINE.ne,BUSLINE.se>
|
|
|
484 philly
|
|
|
485
|
|
|
486 define dot {circle rad 0.03 filled 1}
|
|
|
487
|
|
|
488 # Place a junction dot wherever we are
|
|
|
489 define junction % {dot at Here}; %
|
|
|
490
|
|
|
491 # Draw inputs
|
|
|
492 define inwidth {boxwid*3/4}
|
|
|
493 define drawinputs {
|
|
|
494 line left inwidth from $1.UP;
|
|
|
495 "A" at last line .end - (0.1, 0) rjust;
|
|
|
496 "$2" at last line .end - (0.05, 0.1) rjust;
|
|
|
497 move to last line .center; A$2: junction
|
|
|
498 line left inwidth from $1.DN;
|
|
|
499 "B" at last line .end - (0.1, 0) rjust;
|
|
|
500 "$2" at last line .end - (0.05, 0.1) rjust;
|
|
|
501 move to last line .center; B$2: junction
|
|
|
502 }
|
|
|
503 drawinputs(3rd [],8)
|
|
|
504 drawinputs(4th [],7)
|
|
|
505 drawinputs(5th [],6)
|
|
|
506 drawinputs(6th [],5)
|
|
|
507 drawinputs(7th [],4)
|
|
|
508 drawinputs(8th [],3)
|
|
|
509 drawinputs(9rd [],2)
|
|
|
510 # Gate 10 inputs have to be done by hand
|
|
|
511
|
|
|
512 define go {move to $1;}
|
|
|
513
|
|
|
514 # Define `gate' to *refer* to nth gate
|
|
|
515 define gate {`$1'th []}
|
|
|
516
|
|
|
517 # Go to specified pin of given gate
|
|
|
518 define pin {gate($1).$2}
|
|
|
519
|
|
|
520 # We exploit the quantization of lead placements here
|
|
|
521 # Draw from left edge of box $1 quanta of inter-box horizontal distance
|
|
|
522 define left_mv {line left boxwid * $1 / 5;}
|
|
|
523 # Draw from right edge of box $1 quanta of inter-box horizontal distance
|
|
|
524 define right_mv {line right boxwid * $1 / 5;}
|
|
|
525 # Draw from top pin of box $1 quanta of inter-box vertical distance up
|
|
|
526 define up_mv {line up (boxht * (2 - pinoffset)) * $1 / 4;}
|
|
|
527 # Draw from bottom pin of box $1 quanta of inter-box vertical distance down
|
|
|
528 define dn_mv {line down (boxht * (2 - pinoffset)) * $1 / 4;}
|
|
|
529
|
|
|
530 # Draw from here to given object, with directional constraint
|
|
|
531 define vert {line up ($1.y - Here.y);}
|
|
|
532 define horz {line right ($1.x - Here.x);}
|
|
|
533 define zig {vert($1) horz($1)}
|
|
|
534 define to_bus {line to (BUSLINE.w, Here)}
|
|
|
535
|
|
|
536 define ground {
|
|
|
537 dn_mv(1)
|
|
|
538 [
|
|
|
539 boxwid = boxwid * (3/4)
|
|
|
540 boxht = boxht / 3
|
|
|
541 box invis
|
|
|
542 line from last box .ne to last box .nw
|
|
|
543 line from 1/3 <last box.e,last box.c> to 1/3 <last box.w,last box.c>
|
|
|
544 line from 2/3 <last box.se,last box.s> to 2/3 <last box.sw,last box.s>
|
|
|
545 ]
|
|
|
546 }
|
|
|
547
|
|
|
548 # Now all those connections
|
|
|
549 # Gate 1:
|
|
|
550 go(pin(1,OUT)) right_mv(3) CORNER:Here; zig(pin(12,DN))
|
|
|
551 go(CORNER) vert(pin(1,UP)) \
|
|
|
552 {junction horz(pin(11,UP))} \
|
|
|
553 up_mv(2) junction
|
|
|
554 horz(gate(32).e) right_mv(3) junction
|
|
|
555 {zig(pin(43,IN))}
|
|
|
556 horz(gate(42).e) right_mv(1) junction
|
|
|
557 {to_bus}
|
|
|
558 vert(pin(43,UP)) up_mv(2) to_bus
|
|
|
559
|
|
|
560 # Gate 2
|
|
|
561 go(pin(2,OUT)) right_mv(2) zig(pin(12,UP))
|
|
|
562 # Gate 3
|
|
|
563 go(A8) up_mv(1) horz(gate(13).e) right_mv(3) zig(pin(23,IN))
|
|
|
564 go(B8) dn_mv(1) horz(gate(13))
|
|
|
565 right_mv(1) dn_mv(1)
|
|
|
566 horz(gate(23).e) right_mv(2) dn_mv(2) horz(pin(32,UP))
|
|
|
567 go(pin(3,OUT)) right_mv(2)
|
|
|
568 vert(gate(3).UP) up_mv(3)
|
|
|
569 horz(gate(13).e) right_mv(2)
|
|
|
570 vert(gate(15,UP)) up_mv(4) #??? don't know why 4 is necessary
|
|
|
571 horz(gate(16).w) left_mv(1)
|
|
|
572 vert(gate(6).w) up_mv(4)
|
|
|
573 left_mv(2) zig(pin(7,OUT))
|
|
|
574 # Gate 4
|
|
|
575 go(A7) up_mv(1) horz(gate(14).e) right_mv(1) zig(pin(24,UP))
|
|
|
576 go(B7) dn_mv(1) horz(gate(4))
|
|
|
577 right_mv(1) dn_mv(1)
|
|
|
578 horz(gate(14).e) right_mv(3)
|
|
|
579 vert(pin(26,UP)) up_mv(1)
|
|
|
580 horz(gate(25)) up_mv(2)
|
|
|
581 horz(gate(25).e) right_mv(4)
|
|
|
582 vert(pin(38,UP)) up_mv(1)
|
|
|
583 horz(gate(48).e) right_mv(1)
|
|
|
584 vert(pin(47,DN)) dn_mv(1)
|
|
|
585 horz(gate(47).w) left_mv(3)
|
|
|
586 vert(gate(46).DN) dn_mv(2) right_mv(2)
|
|
|
587 vert(gate(45).DN) dn_mv(2) left_mv(3)
|
|
|
588 vert(gate(44).DN) right_mv(3) dn_mv(2)
|
|
|
589 horz(gate(33).w) left_mv(1)
|
|
|
590 vert(gate(33).DN) dn_mv(3)
|
|
|
591 horz(gate(32).e) up_mv(2)
|
|
|
592 horz(gate(42).e) dn_mv(2) line down boxwid/5
|
|
|
593 to_bus
|
|
|
594 go(pin(4,OUT)) right_mv(3) junction
|
|
|
595 {zig(pin(13,UP))}
|
|
|
596 vert(pin(4,UP)) up_mv(3) junction
|
|
|
597 {right_mv(3) zig(pin(15,IN))}
|
|
|
598 left_mv(2) vert(pin(7,UP)) up_mv(3)
|
|
|
599 right_mv(3) zig(pin(19,DN))
|
|
|
600 # Gate 5
|
|
|
601 go(A6) up_mv(1) horz(gate(15).e) right_mv(1) vert(pin(15,UP)) junction
|
|
|
602 {horz(pin(25,UP))}
|
|
|
603 vert(pin(15,DN)) dn_mv(1)
|
|
|
604 horz(gate(25).e) right_mv(1)
|
|
|
605 zig(pin(34,UP))
|
|
|
606 go(B6) dn_mv(2) horz(gate(25).e) dn_mv(1) right_mv(4)
|
|
|
607 vert(pin(24,DN)) dn_mv(1)
|
|
|
608 horz(gate(34).e) right_mv(1)
|
|
|
609 vert(pin(32,DN)) dn_mv(1)
|
|
|
610 right_mv(3) zig(pin(42,IN))
|
|
|
611 go(pin(5,OUT)) right_mv(5) junction
|
|
|
612 {vert(pin(14,IN)) junction {horz(pin(14,IN))} zig(pin(13,IN)) }
|
|
|
613 vert(pin(17,DN)) junction {horz(pin(17,DN))} zig(pin(18,DN))
|
|
|
614 # Gate 6
|
|
|
615 go(A5) up_mv(1) horz(gate(16).e) right_mv(1) zig(pin(26,UP))
|
|
|
616 go(B5) dn_mv(2) horz(gate(26).e) right_mv(3) zig(pin(34,IN))
|
|
|
617 go(pin(6,OUT)) right_mv(4) junction
|
|
|
618 {horz(pin(16,IN))}
|
|
|
619 vert(pin(15,DN)) junction
|
|
|
620 {horz(pin(15,DN))}
|
|
|
621 vert(pin(14,DN)) junction
|
|
|
622 {horz(pin(14,DN))}
|
|
|
623 zig(pin(13,DN))
|
|
|
624 # Gate 7
|
|
|
625 go(A4) up_mv(1) horz(gate(27).e) right_mv(3) vert(pin(37,IN)) junction
|
|
|
626 {horz(pin(37,IN))}
|
|
|
627 vert(pin(37,DN)) dn_mv(2) right_mv(1) junction
|
|
|
628 {zig(pin(36,IN))}
|
|
|
629 horz(gate(37).e) right_mv(3)
|
|
|
630 zig(pin(45,IN))
|
|
|
631 go(B4) dn_mv(2) horz(gate(17).e) right_mv(4)
|
|
|
632 vert(pin(26,DN)) dn_mv(1)
|
|
|
633 horz(gate(26).e) dn_mv(2)
|
|
|
634 right_mv(4) vert(pin(35,DN)) dn_mv(1)
|
|
|
635 horz(gate(35).e) right_mv(2) junction
|
|
|
636 {zig(pin(45,UP))} {zig(pin(44,UP))}
|
|
|
637 # Gate 8
|
|
|
638 go(A3) up_mv(1) horz(gate(28).e) right_mv(1) zig(pin(38,UP))
|
|
|
639 go(B3) dn_mv(2) horz(gate(28).e) right_mv(2) zig(pin(37,UP))
|
|
|
640 go(pin(8,OUT)) right_mv(6) junction
|
|
|
641 {zig(pin(17,IN))}
|
|
|
642 up_mv(4) left_mv(1) vert(pin(19,UP)) junction
|
|
|
643 {horz(pin(19,UP))}
|
|
|
644 zig(pin(20,UP))
|
|
|
645 # Gate 9
|
|
|
646 go(A2) up_mv(1) horz(gate(19).e) right_mv(1) zig(pin(28,UP))
|
|
|
647 go(B2) dn_mv(2) horz(gate(39).e) right_mv(1)
|
|
|
648 vert(pin(38,DN)) dn_mv(2) right_mv(2) zig(pin(47,IN))
|
|
|
649 go(pin(9,OUT)) right_mv(3) junction
|
|
|
650 {zig(pin(20,DN))}
|
|
|
651 {horz(pin(19,IN))}
|
|
|
652 vert(pin(16,DN)) junction
|
|
|
653 {horz(pin(16,DN))}
|
|
|
654 zig(pin(15,UP))
|
|
|
655 # Gate 10
|
|
|
656 line left inwidth from 10th[].UP;
|
|
|
657 "A" at last line .end - (0.1, 0) rjust;
|
|
|
658 "1" at last line .end - (0.05, 0.1) rjust;
|
|
|
659 move to last line .center; A1: junction
|
|
|
660 line left inwidth from 10th [].DN;
|
|
|
661 "B" at last line .end - (0.1, 0) rjust;
|
|
|
662 "1" at last line .end - (0.05, 0.1) rjust;
|
|
|
663 move to 1/2 <last line .center, last line .start>; B1: junction
|
|
|
664 go(A1) vert(pin(10,DN)) dn_mv(1) horz(gate(20).e) right_mv(2) zig(pin(30,UP))
|
|
|
665 go(B1) dn_mv(2) horz(gate(30).e) right_mv(1) junction
|
|
|
666 {zig(pin(39,UP))}
|
|
|
667 right_mv(3) zig(pin(40,DN))
|
|
|
668 go(pin(10,OUT)) right_mv(2) junction
|
|
|
669 {horz(pin(20,IN))}
|
|
|
670 vert(pin(18,UP)) junction
|
|
|
671 {horz(pin(18,UP))}
|
|
|
672 vert(pin(16,UP)) junction
|
|
|
673 {horz(pin(16,UP))}
|
|
|
674 zig(pin(14,UP))
|
|
|
675 # Gate 11
|
|
|
676 go(pin(11, DN)) left_mv(3) vert(pin(11,UP)) up_mv(1) \
|
|
|
677 horz(gate(31).e) right_mv(1) zig(pin(41,DN))
|
|
|
678 go(pin(11,OUT)) right_mv(2) zig(pin(21,DN))
|
|
|
679 # Gate 12
|
|
|
680 go(pin(12,OUT)) right_mv(3) junction
|
|
|
681 {horz(pin(22,IN))}
|
|
|
682 vert(pin(12,UP)) up_mv(1)
|
|
|
683 horz(gate(12).w) left_mv(3)
|
|
|
684 zig(pin(12,IN))
|
|
|
685 # Gate 13
|
|
|
686 go(pin(13,OUT)) right_mv(1) zig(pin(23,UP))
|
|
|
687 # Gate 14
|
|
|
688 go(pin(14,OUT)) horz(pin(24,IN))
|
|
|
689 # Gate 15
|
|
|
690 go(pin(15,OUT)) horz(pin(25,IN))
|
|
|
691 # Gate 16
|
|
|
692 go(pin(16,OUT)) right_mv(2) junction
|
|
|
693 {horz(pin(26,IN))}
|
|
|
694 vert(pin(27,UP)) junction
|
|
|
695 {horz(pin(27,UP))}
|
|
|
696 zig(pin(29,DN))
|
|
|
697 # Gate 17
|
|
|
698 go(pin(17,OUT)) horz(pin(27,IN))
|
|
|
699 # Gate 18
|
|
|
700 go(pin(18,OUT)) right_mv(3) junction
|
|
|
701 {horz(pin(28,IN))}
|
|
|
702 zig(pin(27,DN))
|
|
|
703 # Gate 19
|
|
|
704 go(pin(19,OUT)) horz(pin(29,IN))
|
|
|
705 # Gate 20
|
|
|
706 go(pin(20,OUT)) right_mv(3) junction
|
|
|
707 {horz(pin(30,IN))}
|
|
|
708 zig(pin(29,UP))
|
|
|
709 # Gate 21
|
|
|
710 go(pin(21,UP)) left_mv(2) vert(pin(21,DN)) ground
|
|
|
711 go(pin(21,OUT)) right_mv(2) junction
|
|
|
712 {zig(pin(31,DN))}
|
|
|
713 up_mv(2) junction
|
|
|
714 # Gate 22
|
|
|
715 go(pin(22,UP)) left_mv(3) up_mv(2) junction
|
|
|
716 go(pin(22,DN)) left_mv(4)
|
|
|
717 vert(pin(22,UP)) up_mv(3) right_mv(3)
|
|
|
718 vert(pin(23,UP)) up_mv(3)
|
|
|
719 horz(gate(23).e) right_mv(2)
|
|
|
720 vert(pin(25,UP)) left_mv(1)
|
|
|
721 vert(pin(28,DN)) right_mv(1)
|
|
|
722 zig(pin(40,IN))
|
|
|
723 go(pin(22,OUT)) right_mv(3) junction
|
|
|
724 {horz(pin(32,IN))}
|
|
|
725 {zig(pin(33,IN))}
|
|
|
726 zig(pin(31,UP))
|
|
|
727 # Gate 23
|
|
|
728 go(pin(23,OUT)) right_mv(1)
|
|
|
729 vert(gate(23).DN) dn_mv(1)
|
|
|
730 horz(gate(33)) right_mv(1)
|
|
|
731 dn_mv(1) to_bus
|
|
|
732 # Gate 24
|
|
|
733 go(pin(24,OUT)) right_mv(1) zig(pin(33,UP))
|
|
|
734 # Gate 25
|
|
|
735 go(pin(25,OUT)) horz(pin(35,IN))
|
|
|
736 # Gate 26
|
|
|
737 go(pin(26,OUT)) right_mv(2) vert(pin(26,DN)) dn_mv(1) junction
|
|
|
738 {to_bus}
|
|
|
739 zig(pin(35,UP))
|
|
|
740 # Gate 27
|
|
|
741 go(pin(27,OUT)) right_mv(2) zig(pin(36,UP))
|
|
|
742 # Gate 28
|
|
|
743 go(pin(28,OUT)) right_mv(3) junction
|
|
|
744 {horz(pin(38,IN))}
|
|
|
745 vert(pin(38, DN)) dn_mv(1) to_bus
|
|
|
746 # Gate 29
|
|
|
747 go(pin(29,OUT)) right_mv(3) junction
|
|
|
748 {horz(pin(39,IN))}
|
|
|
749 {vert(pin(39, DN)) dn_mv(1) to_bus}
|
|
|
750 zig(pin(40,UP))
|
|
|
751 # Gate 30
|
|
|
752 go(pin(30,OUT)) right_mv(1)
|
|
|
753 vert(pin(30,DN)) dn_mv(1)
|
|
|
754 horz(gate(40).e) right_mv(2)
|
|
|
755 zig(pin(50,UP))
|
|
|
756 # Gate 31
|
|
|
757 go(pin(31,OUT)) right_mv(2) zig(pin(41,UP))
|
|
|
758 # Gate 32
|
|
|
759 go(pin(32,OUT)) right_mv(2) vert(pin(32,UP)) junction
|
|
|
760 {horz(pin(42,UP))}
|
|
|
761 up_mv(1) to_bus
|
|
|
762 # Gate 33
|
|
|
763 go(pin(33,OUT)) right_mv(2) zig(pin(43,UP))
|
|
|
764 # Gate 34
|
|
|
765 go(pin(34,OUT)) right_mv(3) junction
|
|
|
766 {horz(pin(44,IN))}
|
|
|
767 vert(pin(44, DN)) dn_mv(1) to_bus
|
|
|
768 # Gate 35
|
|
|
769 go(pin(35,OUT)) right_mv(1) dn_mv(1) right_mv(2) dn_mv(1) to_bus
|
|
|
770 # Gate 36
|
|
|
771 go(pin(36,OUT)) horz(pin(46,IN))
|
|
|
772 # Gate 37
|
|
|
773 go(pin(37,OUT)) right_mv(2) vert(pin(48,UP)) junction
|
|
|
774 {horz(pin(48,UP))}
|
|
|
775 zig(pin(49,DN))
|
|
|
776 # Gate 38
|
|
|
777 go(pin(38,OUT)) right_mv(3) junction
|
|
|
778 {horz(pin(48,IN))}
|
|
|
779 vert(pin(48,DN)) right_mv(1) dn_mv(3) left_mv(3)
|
|
|
780 vert(pin(47,UP)) junction
|
|
|
781 {horz(pin(47,UP))}
|
|
|
782 zig(pin(46,UP))
|
|
|
783 # Gate 39
|
|
|
784 go(pin(39,OUT)) right_mv(3) junction
|
|
|
785 {horz(pin(49,IN))}
|
|
|
786 {vert(pin(49, DN)) dn_mv(2) to_bus}
|
|
|
787 zig(pin(50,IN))
|
|
|
788 # Gate 40
|
|
|
789 go(pin(40,OUT)) right_mv(1)
|
|
|
790 vert(pin(40,DN))
|
|
|
791 dn_mv(2) junction
|
|
|
792 {horz(gate(40).w); dn_mv(1); horz(gate(40).e); right_mv(1)}
|
|
|
793 dn_mv(1) junction
|
|
|
794 zig(pin(49,UP))
|
|
|
795 # Gate 41
|
|
|
796 # (should be right_mv(2) but we've squeezed the bus line a bit left)
|
|
|
797 go(pin(41,OUT)) right_mv(1) vert(pin(41,DN)) ground
|
|
|
798 # Gate 42
|
|
|
799 go(pin(42,OUT)) to_bus
|
|
|
800 # Gate 43
|
|
|
801 go(pin(43,OUT)) to_bus
|
|
|
802 # Gate 44
|
|
|
803 go(pin(44,OUT)) to_bus
|
|
|
804 # Gate 45
|
|
|
805 go(pin(45,OUT)) to_bus
|
|
|
806 # Gate 46
|
|
|
807 go(pin(46,OUT)) to_bus
|
|
|
808 # Gate 47
|
|
|
809 go(pin(47,OUT)) to_bus
|
|
|
810 # Gate 48
|
|
|
811 go(pin(48,OUT)) to_bus
|
|
|
812 # Gate 49
|
|
|
813 go(pin(49,OUT)) to_bus
|
|
|
814 # Gate 50
|
|
|
815 go(pin(50,OUT)) to_bus
|
|
|
816 # The adventitious lead
|
|
|
817 go(pin(17,OUT)) right_mv(1)
|
|
|
818 {vert(pin(17,UP)) up_mv(3) horz(gate(17))}
|
|
|
819 vert(pin(17,DN)) dn_mv(1)
|
|
|
820 horz(gate(27).w) dn_mv(1) horz(gate(27).e)
|
|
|
821 dn_mv(1) horz(gate(36).w)
|
|
|
822 up_mv(2) right_mv(1) dn_mv(2)
|
|
|
823 right_mv(1) up_mv(2) right_mv(1) dn_mv(2)
|
|
|
824 right_mv(1) up_mv(2) right_mv(1)
|
|
|
825 vert(pin(37,DN)) right_mv(4) dn_mv(2)
|
|
|
826 right_mv(3) dn_mv(1) left_mv(3)
|
|
|
827 vert(pin(46,DN)) left_mv(3) dn_mv(3)
|
|
|
828 horz(gate(36).w) up_mv(1) horz(gate(36)) right_mv(1)
|
|
|
829
|
|
|
830 ] # End of diagram object
|
|
|
831 .PE
|
|
|
832 .ce 1
|
|
|
833 FIGURE 1. CIRCUITOUS DIAGRAM
|
|
|
834 .bp
|
|
|
835 .sp 10
|
|
|
836 .ps 8
|
|
|
837 .vs 10
|
|
|
838 .nf
|
|
|
839 .cs R 24
|
|
|
840 .ec %
|
|
|
841 .ds EO %(ci%v'-0.08'%h'-0.67'+%v'0.08'
|
|
|
842 .%" This is dodgy, but it's the last place es is used
|
|
|
843 .if n .ds es %o"O|"
|
|
|
844 .if t .ds es %(es
|
|
|
845 __________________________________________________________
|
|
|
846 |\ \
|
|
|
847 | \ 1. Logic gate. Inputs A, B. Output O = AB. \
|
|
|
848 | \ \
|
|
|
849 | \ \ 2. Logic gate. Inputs A, B, C. Output O = A+BC. \
|
|
|
850 | |\ \ \
|
|
|
851 | | \ \ 3. Logic gate. Inputs A, B. Output O = A+AB. \
|
|
|
852 | | \ \ \
|
|
|
853 | | |\ \ 4. Logic gate. Inputs A, B. Output O = AB %*(EO -(A+-B) \
|
|
|
854 | | | \ \ \
|
|
|
855 | | | \ \ 5. Logic gate. Inputs A, B. Output O = A%*(EOA + AA \
|
|
|
856 | | | \ \ \
|
|
|
857 | | | \ \ 6. Uninitialized flip-flop. Inputs none. Output O = ? \
|
|
|
858 | | | \ \ \
|
|
|
859 | | | \ \ 7. Flip-flop-flap. Inputs A, B, C. Output O = 1 if \
|
|
|
860 | | | \ \ A=0 or B+C=0 and A=1. O = 0 if AC=1, B=0. O = %*(es if \
|
|
|
861 | | | \ \ AB=1, C=0. O = ? if ABC=1. O as yet undetermined \
|
|
|
862 | | | \ \ for other Warmenhovian inputs. See Figure 2. \
|
|
|
863 | | | \ \ \
|
|
|
864 | | | \ \ 8. Bus line. \
|
|
|
865 | | | \ \_________________________________________________________\
|
|
|
866 | | | \ | |
|
|
|
867 | | | | | _____________________________________________________ |
|
|
|
868 | | | | | | | | | | | |
|
|
|
869 | | | | | | | | | | | |
|
|
|
870 | | | | | | | | | | | |
|
|
|
871 | | | | | | | | | | | |
|
|
|
872 | | | | | | | | | | | |
|
|
|
873 \|__| | | | \|__| | | |
|
|
|
874 | | | | | |
|
|
|
875 | | | | | |
|
|
|
876 | | | | | |
|
|
|
877 | | | | | |
|
|
|
878 | | | | | |
|
|
|
879 | | | | | |
|
|
|
880 | | | | | |
|
|
|
881 | | | | | |
|
|
|
882 | | | | | |
|
|
|
883 | | | | | |
|
|
|
884 | | | | | |
|
|
|
885 | | | | | |
|
|
|
886 | | | | | |
|
|
|
887 | | | | | |
|
|
|
888 | | | | | |
|
|
|
889 | | | | | |
|
|
|
890 | | | | | |
|
|
|
891 | | | | | |
|
|
|
892 \|__| \|__|
|
|
|
893 .ec \
|
|
|
894 .cs R
|
|
|
895 .fi
|
|
|
896 .ps 10
|
|
|
897 .vs 12
|
|
|
898 .sp
|
|
|
899 .ce 1
|
|
|
900 Table 1. Logical (and other) functions.
|
|
|
901 .bp
|
|
|
902 .if n \{\
|
|
|
903 .P
|
|
|
904 [Warning: The following picture will be garbled or missing.
|
|
|
905 Get a better output device.] \}
|
|
|
906 .sp 10
|
|
|
907 .PS
|
|
|
908 # The FLIP FLAP FLOP, Figure 2 of the INTERCAL manual
|
|
|
909 down;
|
|
|
910 A: warmengate();
|
|
|
911 move; move;
|
|
|
912 B: warmengate();
|
|
|
913 move; move;
|
|
|
914 C: warmengate();
|
|
|
915 move; move;
|
|
|
916 D: warmengate();
|
|
|
917 dot at 1st [];
|
|
|
918 dot at 2nd [];
|
|
|
919 dot at 3rd [];
|
|
|
920 circle rad 0.06 at last [];
|
|
|
921 line from last circle.w to last circle.e;
|
|
|
922 line from last circle.n to last circle.s;
|
|
|
923 line left 3 from A.UP; "A" rjust
|
|
|
924 line left 3 from B.IN; "B" rjust
|
|
|
925 line left 3 from C.UP; "C" rjust
|
|
|
926 line left 2 from C.IN then down 2 then left; "1" rjust
|
|
|
927 right; circle rad 0.06 with .w at A.OUT;
|
|
|
928 line right 0.5; junction {line right 1.5; "D" ljust}
|
|
|
929 line down 0.25; X1: Here
|
|
|
930 line left 0.5 from A.IN; line down 0.25; X2: Here
|
|
|
931 line left 0.5 from B.UP; line up 0.25; line to X1;
|
|
|
932 line right 1.0 from D.OUT; vert(B.UP) line up 0.25; line to X2;
|
|
|
933 right; circle rad 0.06 with .w at B.OUT;
|
|
|
934 line right 0.5; vert(C.DN) line down 0.25; X3: Here;
|
|
|
935 line left 0.25 from D.UP then up 0.25 then to X3;
|
|
|
936 right; circle rad 0.06 with .w at C.OUT;
|
|
|
937 line right 0.3; vert(C.DN) line down 0.25; X4: Here
|
|
|
938 line left 0.5 from D.IN; vert(D.UP) line up 0.25 then to X4;
|
|
|
939 .PE
|
|
|
940 .sp 10
|
|
|
941 .ce 1
|
|
|
942 FIGURE 2. FLIP FLAP FLOP
|
|
|
943 .bp
|
|
|
944 .if n \{\
|
|
|
945 .P
|
|
|
946 [Warning: The following picture will be garbled or missing.
|
|
|
947 Get a better output device.] \}
|
|
|
948 .PS
|
|
|
949 [
|
|
|
950 NYC: box ht 4 wid 0.5 "9";
|
|
|
951 for i = 0 to 16 do {
|
|
|
952 move to (i+1)/18 <NYC.nw,NYC.sw>
|
|
|
953 line left 0.5
|
|
|
954 }
|
|
|
955 for i = 0 to 8 do {
|
|
|
956 move to (i+1)/10 <NYC.ne,NYC.se>
|
|
|
957 line right 0.5
|
|
|
958 }
|
|
|
959 ]
|
|
|
960 move right from last [].w;
|
|
|
961 box invis wid 6 \
|
|
|
962 "GATE TYPE 9. BLACK BOX" ljust \
|
|
|
963 "INPUTS A1-8, B1-8. " ljust \
|
|
|
964 "OUTPUT O1-8 = A1-8~B1-8" ljust
|
|
|
965 .PE
|
|
|
966 .sp 10
|
|
|
967 .ce 1
|
|
|
968 FIGURE 1 (CONTINUED). NEW YORK
|
|
|
969 .bp
|
|
|
970 .if '\*c'y' \{\
|
|
|
971 .H 4 "Return type of SELECT"
|
|
|
972 .P
|
|
|
973 INTERCAL-72 defined the return type of a select operation
|
|
|
974 to depend on the number of bits selected. The C-INTERCAL compiler
|
|
|
975 takes the easier route of defining the return type to be that of
|
|
|
976 the right operand, independent of its actual value. This form has
|
|
|
977 the advantage that all types can be determined at compile time.
|
|
|
978 Putting in run-time type-checking would add significant overhead and
|
|
|
979 complication, to effect a very minor change in language semantics.
|
|
|
980 .P
|
|
|
981 The only time this distinction makes any difference is when a unary
|
|
|
982 operator is applied to the select result. This happens extremely
|
|
|
983 rarely in practice, the only known instance being the 32-bit
|
|
|
984 greater-than test in the standard library, where an XOR operator is
|
|
|
985 applied to the result of selecting a number against itself. The
|
|
|
986 INTERCAL-72 authors first select the result against #65535\*(ct#65535 to
|
|
|
987 insure that XOR sees a 32-bit value. With the current compiler this
|
|
|
988 extra step is unnecessary, but harmless.
|
|
|
989 .P
|
|
|
990 The cautious programmer should write code that does not depend on
|
|
|
991 the compiler version being used. We therefore suggest the following
|
|
|
992 guideline for determining the select return type:
|
|
|
993 .P
|
|
|
994 A select operation with a 16-bit right operand returns a 16-bit
|
|
|
995 value. The return type of a select operation with a 32-bit right
|
|
|
996 operand is undefined, but is guaranteed to be an acceptable input
|
|
|
997 to a mingle operation so long as 16 or fewer bits are actually
|
|
|
998 selected. Correct code should not depend on whether the return
|
|
|
999 type is 16 or 32 bits.\}
|
|
|
1000 .H 3 "Unary Operators"
|
|
|
1001 .P
|
|
|
1002 The unary operators are & (logical \fBAND\fR), V (logical \fBOR\fR),
|
|
|
1003 and \*(vb (logical
|
|
|
1004 \fBXOR\fR). This last character is obtained by overpunching a worm (\-) on a V
|
|
|
1005 (V).
|
|
|
1006 .if '\*c'y' \{\
|
|
|
1007 (In C-INTERCAL, \*(vb is replaced by what (?). The compiler recognizes
|
|
|
1008 V<backspace>- as a valid equivalent, in case you are concerned about
|
|
|
1009 compatibility with the Princeton compiler.
|
|
|
1010 In version 0.20 and later, the Unicode character U+2200 FOR ALL,
|
|
|
1011 which looks exactly like V<backspace>- or an upside-down `A'
|
|
|
1012 is also accepted in UTF-8 form.) \}
|
|
|
1013 The operator is inserted between the spot, two-spot, mesh, or
|
|
|
1014 what-have-you, and the integer, thus: .&123, #\*(vb123. Multiple unary
|
|
|
1015 operators may not be concatenated, thus the form #\*(vb&123 is invalid. This
|
|
|
1016 will be covered later when precedence is discussed. These operators perform
|
|
|
1017 their respective logical operations on all pairs of adjacent bits, the
|
|
|
1018 result from the first and last bits going into the first bit of the result.
|
|
|
1019 The effect is that of rotating the operand one place to the right and
|
|
|
1020 ANDing, ORing, or XORing with its initial value. Thus, #&77 (binary =
|
|
|
1021 1001101) is binary 0000000000000100 = 4, #V77 is binary 1000000001101111 =
|
|
|
1022 32879, and #\*(vb77 is binary 1000000001101011 = 32875.
|
|
|
1023 .H 3 "Precedence"
|
|
|
1024 .SETR precedence
|
|
|
1025 .P
|
|
|
1026 Precedence of operators is as follows:
|
|
|
1027 .sp 10
|
|
|
1028 (The remainder of this page intentionally left blank)\*F
|
|
|
1029 .FS
|
|
|
1030 Keep in mind that the aim in designing INTERCAL was to have no
|
|
|
1031 precedents.
|
|
|
1032 .FE
|
|
|
1033 .bp
|
|
|
1034 .P
|
|
|
1035 This precedence (or lack thereof) may be overruled by grouping expressions
|
|
|
1036 between pairs of sparks (') or rabbit-ears ("). Thus '#165\*(ct#203'~#358
|
|
|
1037 (binary value '10100101\*(ct11001011'~101100110) has the value 15, but
|
|
|
1038 #165\*(ct'#203~#358' has the value 34915, and #165\*(ct#203~#358 is invalid
|
|
|
1039 syntax and is completely valueless (except perhaps as an educational tool
|
|
|
1040 to the programmer). A unary operator is applied to a sparked or rabbit-eared
|
|
|
1041 expression by inserting the operator immediately following the opening spark
|
|
|
1042 or ears. Thus, the invalid expression #\*(vb&123,
|
|
|
1043 which was described earlier,
|
|
|
1044 could be coded as '\*(vb#&123' or '\*(vb"{"'.
|
|
|
1045 Note: In the interests of
|
|
|
1046 simplifying the sometimes overly-complex form of expressions, INTERCAL allows
|
|
|
1047 a spark-spot combination ('.) to be replaced with a wow (!). Thus '.1~.2'
|
|
|
1048 is equivalent to !1~.2', and 'V.1\*(ct.2' is equivalent to "V!1\*(ct.2'".
|
|
|
1049 .P
|
|
|
1050 Combining a rabbit-ears with a spot to form a rabbit (\o'".') is not permitted,
|
|
|
1051 although the programmer is free to use it should he find an EBCDIC reader
|
|
|
1052 which will properly translate a 12-3-7-8 punch.
|
|
|
1053 .P
|
|
|
1054 Sparks and/or rabbit-ears must also be used to distinguish among such
|
|
|
1055 otherwise ambiguous subscripted and multiply-subscripted expressions as:
|
|
|
1056 .DS L
|
|
|
1057 ,1 SUB #1 ~ #2
|
|
|
1058 ,1 SUB ,2 SUB #1 #2 #3
|
|
|
1059 ,1 SUB " ,2 SUB " ,3 SUB #1 " #2 " " #3 "
|
|
|
1060 .DE
|
|
|
1061 The third case may be isolated into either of its possible interpretations
|
|
|
1062 by simply changing some pairs of rabbit-ears to sparks, instead of adding
|
|
|
1063 more ears (which would only confuse the issue further). Ambiguous cases are
|
|
|
1064 defined as those for which the compiler being used finds a legitimate
|
|
|
1065 interpretation which is different from that which the user had in mind. See
|
|
|
1066 also section
|
|
|
1067 .GETHN princeton
|
|
|
1068 \&.
|
|
|
1069 .H 1 "STATEMENTS"
|
|
|
1070 .if '\*c'y' \{\
|
|
|
1071 .DS I F
|
|
|
1072 "There's glory for you!"
|
|
|
1073 .P
|
|
|
1074 "I don't know what you mean by 'glory,'" Alice said.
|
|
|
1075 .P
|
|
|
1076 Humpty Dumpty smiled contemptuously. "Of course you don't -- till I tell
|
|
|
1077 you. I meant 'there's a nice knock-down argument for you!'"
|
|
|
1078 .P
|
|
|
1079 "But 'glory' doesn't mean 'a nice knock-down argument.'" Alice
|
|
|
1080 objected.
|
|
|
1081 .P
|
|
|
1082 "When \fII\fR use a word," Humpty Dumpty said, in a rather scornful
|
|
|
1083 tone, "it means just what I choose it to mean -- neither more nor less."
|
|
|
1084 .DE \}
|
|
|
1085 .P
|
|
|
1086 In this section is described the format of INTERCAL statements.
|
|
|
1087 .H 2 "General Format"
|
|
|
1088 .P
|
|
|
1089 Statements may be entered in 'free format'. That is, more than one statement
|
|
|
1090 may occur on a single card, and a statement may begin on one card and end
|
|
|
1091 on a later one. Note that if this is done, all intervening cards and portions
|
|
|
1092 thereof must be part of the same statement. That this restriction is necessary
|
|
|
1093 is immediately apparent from the following example of what might occur if
|
|
|
1094 statements could be interlaced.
|
|
|
1095 .DS L
|
|
|
1096 DO .1 <- ".1\*(ct'&:51~"#\*(vb1c!12~;&75SUB"\*(vb'V.1~
|
|
|
1097 DO .2 <- '"!1\*(ct"&';\*(vb79SUB",&7SUB:173"'~!\*(vb9\*(ct
|
|
|
1098 .2'\*(ct,&1SUB:5~#33578"'"'"~'#65535\*(ct"\*(vb'V#&85'"'
|
|
|
1099 #8196'"'~.1"\*(ct.2'~'#&5\*(ct"'#1279\*(ct#4351'~#65535"'
|
|
|
1100 .DE
|
|
|
1101 The above statements are obviously meaningless. (For that matter, so are
|
|
|
1102 the statements
|
|
|
1103 .DS L
|
|
|
1104 DO .1 <- ".1\*(ct"&:51~"#\*(vb1\*(ct!12~;&75SUB"\*(vb'V.1~
|
|
|
1105 .2'\*(ct,&1SUB:5~#333578"'"'"~#65535\*(ct"\*(vb'V#&85'"'
|
|
|
1106 DO .2 <- '"!1\*(ct"&';\*(vb79SUB",&7SUB:173"'~!\*(vb9\*(ct
|
|
|
1107 #8196'"'~.1"\*(ct.2'~'#&5\*(ct"'#1279\*(ct#4351'~#65535"'
|
|
|
1108 .DE
|
|
|
1109 but this is not of interest here.)
|
|
|
1110 .P
|
|
|
1111 Spaces may be used freely to enhance program legibility (or at least reduce
|
|
|
1112 program illegibility), with the restriction that no word of a statement
|
|
|
1113 identifier (see section
|
|
|
1114 .GETHN identifiers
|
|
|
1115 ) may contain any spaces.
|
|
|
1116 .H 2 "Labels"
|
|
|
1117 .P
|
|
|
1118 A statement may begin with a
|
|
|
1119 .B "logical line label"
|
|
|
1120 enclosed in wax-wane pairs
|
|
|
1121 (()). A statement may not have more than one label, although it is possible
|
|
|
1122 to omit the label entirely. A line label is any integer from 1 to 65535,
|
|
|
1123 which must be unique within each program. The user is cautioned, however,
|
|
|
1124 that many line labels between 1000 and 1999 are used in the INTERCAL System
|
|
|
1125 Library functions.
|
|
|
1126 .H 2 "Identifiers and Qualifiers"
|
|
|
1127 .SETR identifiers
|
|
|
1128 .P
|
|
|
1129 After the line label (if any), must follow one of the following statement
|
|
|
1130 identifiers: DO, PLEASE, or PLEASE DO. These may be used interchangeably to
|
|
|
1131 improve the aesthetics of the program. The identifier is then followed by
|
|
|
1132 either, neither, or both of the following optional parameters (qualifiers):
|
|
|
1133 (1) either of the character strings NOT or N'T, which causes the statement
|
|
|
1134 to be automatically abstained from (see section
|
|
|
1135 .GETHN abstain
|
|
|
1136 ) when execution
|
|
|
1137 begins, and (2) a number between 0 and 100, preceded by a double-oh-seven
|
|
|
1138 (%), which causes the statement to have only the specified percent chance
|
|
|
1139 of being executed each time it is encountered in the course of execution.
|
|
|
1140 .H 2 "Statements"
|
|
|
1141 .P
|
|
|
1142 Following the qualifiers (or, if none are used, the identifier) must occur
|
|
|
1143 one of the
|
|
|
1144 .ie '\*c'y' \{\
|
|
|
1145 14 \}
|
|
|
1146 .el \{\
|
|
|
1147 13 \}
|
|
|
1148 valid operations. (Exception: see section
|
|
|
1149 .GETHN comments
|
|
|
1150 \&.) These are
|
|
|
1151 described individually in sections
|
|
|
1152 .GETHN calculate
|
|
|
1153 through
|
|
|
1154 .GETHN last_statement
|
|
|
1155 \&.
|
|
|
1156 .H 3 "Calculate"
|
|
|
1157 .SETR calculate
|
|
|
1158 .P
|
|
|
1159 The INTERCAL equivalent of the half-mesh (=) in FORTRAN, BASIC, PL/I, and
|
|
|
1160 others, is represented by an angle (<) followed by a worm (-). This
|
|
|
1161 combination is read 'gets'. 32-bit variables may be assigned 16-bit values,
|
|
|
1162 which are padded on the left with 16 zero bits. 16-bit variables may be
|
|
|
1163 assigned 32-bit values only if the value is less than 65535. Thus, to
|
|
|
1164 invert the least significant bit of the first element of 16-bit
|
|
|
1165 2-dimensional array number 1, one could write:
|
|
|
1166 .DS
|
|
|
1167 ,1SUB#1#1 <- '\*(vb",1SUB#1#1"\*(ct#1'~'#0\*(ct#65535'
|
|
|
1168 .DE
|
|
|
1169 Similarly to SNOBOL and SPITBOL, INTERCAL uses the angle-worm to define the
|
|
|
1170 dimensions of arrays. An example will probably best describe the format.
|
|
|
1171 To define 32-bit array number 7 as 3-dimensional, the first dimension being
|
|
|
1172 seven, the second being the current value of 16-bit variable number seven,
|
|
|
1173 and the third being the current value of the seventh element of 16-bit array
|
|
|
1174 number seven (which is one-dimensional) mingled with the last three bits of
|
|
|
1175 32-bit variable number seven, one would write (just before they came to take
|
|
|
1176 him away):
|
|
|
1177 .DS
|
|
|
1178 ;7 <- #7 BY .7 BY ",7SUB#7"\*(ct':7~#7'
|
|
|
1179 .DE
|
|
|
1180 This is, of course, different from the statement:
|
|
|
1181 .DS
|
|
|
1182 ;7 <- #7 BY .7 BY ,7SUB"#7\*(ct':7~#7'"
|
|
|
1183 .DE
|
|
|
1184 INTERCAL also permits the redefining of array dimensioning, which is done
|
|
|
1185 the same way as is the initial dimensioning. All values of items in an array
|
|
|
1186 are lost upon redimensioning, unless they have been STASHed (see section
|
|
|
1187 .GETHN stash
|
|
|
1188 ), in which case restoring them also restores the old dimensions.
|
|
|
1189 .H 3 "NEXT"
|
|
|
1190 .SETR next
|
|
|
1191 .P
|
|
|
1192 The NEXT statement is used both for subroutine calls and for unconditional
|
|
|
1193 transfers. This statement takes the form:
|
|
|
1194 .DS
|
|
|
1195 DO (label) NEXT
|
|
|
1196 .DE
|
|
|
1197 (or, of course,
|
|
|
1198 .DS
|
|
|
1199 PLEASE DO (label) NEXT
|
|
|
1200 .DE
|
|
|
1201 etc.), where (label) represents any logical line label which appears in the
|
|
|
1202 program. The effect of such a statement is to transfer control to the
|
|
|
1203 statement specified, and to store in a push down list (which is initially
|
|
|
1204 empty) the location from which the transfer takes place. Items may be
|
|
|
1205 removed from this list and may be discarded or used to return to the
|
|
|
1206 statement immediately following the NEXT statement. These operations are
|
|
|
1207 described in sections
|
|
|
1208 .GETHN forget
|
|
|
1209 and
|
|
|
1210 .GETHN resume
|
|
|
1211 respectively. The programmer is
|
|
|
1212 generally advised to discard any stack entries which he does not intend to
|
|
|
1213 utilize, since the stack has a maximum depth of 79 entries. A program's
|
|
|
1214 attempting to initiate an 80th level of NEXTing will result in the fatal
|
|
|
1215 error message, "PROGRAM HAS DISAPPEARED INTO THE BLACK LAGOON."
|
|
|
1216 .H 3 "FORGET"
|
|
|
1217 .SETR forget
|
|
|
1218 .P
|
|
|
1219 The statement PLEASE FORGET exp, where exp represents any expression
|
|
|
1220 (except colloquial and facial expressions), causes the expression to be
|
|
|
1221 evaluated, and the specified number of entries to be removed from the
|
|
|
1222 NEXTing stack and discarded. An attempt to FORGET more levels of NEXTing
|
|
|
1223 than are currently stacked will cause the stack to be emptied, and no error
|
|
|
1224 condition is indicated. This is because the condition is not considered to
|
|
|
1225 be an error. As described in section
|
|
|
1226 .GETHN next
|
|
|
1227 \&, it is good programming practice
|
|
|
1228 to execute a DO FORGET #1 after using a NEXT statement as an unconditional
|
|
|
1229 transfer, so that the stack does not get cluttered up with unused entries:
|
|
|
1230 .DS L
|
|
|
1231 .cs R 24
|
|
|
1232 DO (123) NEXT
|
|
|
1233 .
|
|
|
1234 .
|
|
|
1235 (123) DO FORGET #1
|
|
|
1236 .cs R
|
|
|
1237 .DE
|
|
|
1238 .H 3 "RESUME"
|
|
|
1239 .SETR resume
|
|
|
1240 .P
|
|
|
1241 The statement PLEASE RESUME exp has the same effect as FORGET, except that
|
|
|
1242 program control is returned to the statement immediately following the NEXT
|
|
|
1243 statement which stored in the stack the last entry to be removed. Note that
|
|
|
1244 a rough equivalent of the FORTRAN computed GO TO and BASIC ON exp GO TO is
|
|
|
1245 performed by a sequence of the form:
|
|
|
1246 .DS L
|
|
|
1247 .cs R 24
|
|
|
1248 DO (1) NEXT
|
|
|
1249 .
|
|
|
1250 .
|
|
|
1251 (1) DO (2) NEXT
|
|
|
1252 PLEASE FORGET #1
|
|
|
1253 .
|
|
|
1254 .
|
|
|
1255 (2) DO RESUME .1
|
|
|
1256 .cs R
|
|
|
1257 .DE
|
|
|
1258 Unlike the FORGET statement, an attempt to RESUME more levels of NEXTing than
|
|
|
1259 has been stacked will cause program termination. See also section
|
|
|
1260 .GETHN give_up
|
|
|
1261 \&.
|
|
|
1262 .H 3 "STASH"
|
|
|
1263 .SETR stash
|
|
|
1264 .P
|
|
|
1265 Since subroutines are not explicitly implemented in INTERCAL, the NEXT and
|
|
|
1266 RESUME statements must be used to execute common routines. However, as
|
|
|
1267 these routines might use the same variables as the main program, it is
|
|
|
1268 necessary for them to save the values of any variables whose values they
|
|
|
1269 alter, and later restore them. This process is simplified by the STASH
|
|
|
1270 statement, which has the form DO STASH list, where list represents a
|
|
|
1271 string of one or more variable or array names, separated by intersections
|
|
|
1272 (+). Thus
|
|
|
1273 .DS
|
|
|
1274 PLEASE STASH .123+:123+,123
|
|
|
1275 .DE
|
|
|
1276 stashes the values of two variables and one entire array. The values are
|
|
|
1277 left intact, and copies thereof are saved for later retrieval by (what else?)
|
|
|
1278 the RETRIEVE statement (see section
|
|
|
1279 .GETHN retrieve
|
|
|
1280 ). It is not possible to STASH
|
|
|
1281 single array items.
|
|
|
1282 .H 3 "RETRIEVE"
|
|
|
1283 .SETR retrieve
|
|
|
1284 .P
|
|
|
1285 PLEASE RETRIEVE list restores the previously STASHed values of the variables
|
|
|
1286 and arrays named in the list. If a value has been stashed more than once,
|
|
|
1287 the most recently STASHed values are RETRIEVEd, and a second RETRIEVE will
|
|
|
1288 restore the second most recent values STASHed. Attempting to RETRIEVE a
|
|
|
1289 value which has not been STASHed will result in the error message, "THROW
|
|
|
1290 STICK BEFORE RETRIEVING."
|
|
|
1291 .H 3 "IGNORE"
|
|
|
1292 .SETR ignore
|
|
|
1293 .P
|
|
|
1294 The statement DO IGNORE list causes all subsequent statements to have no
|
|
|
1295 effect upon variables and/or arrays named in the list. Thus, for example,
|
|
|
1296 after the sequence
|
|
|
1297 .DS L
|
|
|
1298 DO .1 <- #1
|
|
|
1299 PLEASE IGNORE .1
|
|
|
1300 DO .1 <- #0
|
|
|
1301 .DE
|
|
|
1302 16-bit variable number 1 would have the value 1, not 0. Inputting (see
|
|
|
1303 section
|
|
|
1304 .GETHN input
|
|
|
1305 ) into an IGNOREd variable also has no effect. The condition
|
|
|
1306 is annulled via the REMEMBER statement (see section
|
|
|
1307 .GETHN remember
|
|
|
1308 ). Note that, when
|
|
|
1309 a variable is being IGNOREd, its value, though immutable, is still
|
|
|
1310 available for use in expressions and the like.
|
|
|
1311 .if '\*c'y' \{\
|
|
|
1312 .P
|
|
|
1313 Though the INTERCAL-72 manual laid down that the value of an IGNOREd
|
|
|
1314 variable cannot change, it was unclear about whether or not a
|
|
|
1315 statement which appears to change an IGNOREd variable is executed or
|
|
|
1316 not. This may appear to be a "If a tree falls in the forest ..." type
|
|
|
1317 of question, but if the statement in question has other side effects
|
|
|
1318 it is not.
|
|
|
1319 .P
|
|
|
1320 Since another mechanism already exists for ABSTAINing from a
|
|
|
1321 statement, C-INTERCAL's IGNORE only prevents the changing of the
|
|
|
1322 specific variable in question, not the execution of the entire
|
|
|
1323 statement. In the present version of the language this only makes
|
|
|
1324 a difference for the WRITE IN (see
|
|
|
1325 .GETHN input
|
|
|
1326 ) and RETRIEVE (see
|
|
|
1327 .GETHN retrieve
|
|
|
1328 ) statements. Attempting to WRITE IN
|
|
|
1329 to an IGNOREd variable will cause a number to be read from the input,
|
|
|
1330 which will be discarded since it cannot be stored in the variable.
|
|
|
1331 Using RETRIEVE on an IGNOREd variable will pop the variable's stash
|
|
|
1332 stack without actually changing its value. \}
|
|
|
1333 .H 3 "REMEMBER"
|
|
|
1334 .SETR remember
|
|
|
1335 .P
|
|
|
1336 PLEASE REMEMBER list terminates the effect of the IGNORE statement for all
|
|
|
1337 variables and/or arrays named in the list. It does not matter if a variable
|
|
|
1338 has been IGNOREd more than once, nor is it an error if the variable has not
|
|
|
1339 been IGNOREd at all.
|
|
|
1340 .H 3 "ABSTAIN"
|
|
|
1341 .SETR abstain
|
|
|
1342 .P
|
|
|
1343 INTERCAL contains no simple equivalent to an IF statement or computed GO
|
|
|
1344 TO, making it difficult to combine similar sections of code into a single
|
|
|
1345 routine which occasionally skips around certain statements. The IGNORE
|
|
|
1346 statement (see section
|
|
|
1347 .GETHN ignore
|
|
|
1348 ) is helpful in some cases, but a more viable
|
|
|
1349 method is often required. In keeping with the goal of INTERCAL having
|
|
|
1350 nothing in common with any other language, this is made possible via the
|
|
|
1351 ABSTAIN statement.
|
|
|
1352 .P
|
|
|
1353 This statement takes on one of two forms. It may not take on both at any one
|
|
|
1354 time. DO ABSTAIN FROM (label) causes the statement whose logical line label
|
|
|
1355 is (label) to be abstained from. PLEASE ABSTAIN FROM gerund list causes all
|
|
|
1356 statements of the specified type(s) to be abstained from, as in
|
|
|
1357 .DS L
|
|
|
1358 .ta .3i .6i T .6i
|
|
|
1359 PLEASE ABSTAIN FROM STASHING
|
|
|
1360 PLEASE ABSTAIN FROM IGNORING + FORGETTING
|
|
|
1361 PLEASE ABSTAIN FROM NEXTING
|
|
|
1362 or PLEASE ABSTAIN FROM CALCULATING
|
|
|
1363 .DE
|
|
|
1364 Statements may also be automatically abstained from at the start of
|
|
|
1365 execution via the NOT or N'T parameter (see section
|
|
|
1366 .GETHN identifiers
|
|
|
1367 ).
|
|
|
1368 .P
|
|
|
1369 If, in the course of execution, a statement is encountered which is being
|
|
|
1370 abstained from, it is ignored and control passes to the next statement in
|
|
|
1371 the program (unless it, too, is being abstained from).
|
|
|
1372 .P
|
|
|
1373 The statement DO ABSTAIN FROM ABSTAINING is perfectly valid, as is DO ABSTAIN
|
|
|
1374 FROM REINSTATING (although this latter is not usually recommended). However,
|
|
|
1375 the statement DO ABSTAIN FROM GIVING UP is not accepted, even though DON'T
|
|
|
1376 GIVE UP is.
|
|
|
1377 .H 3 "REINSTATE"
|
|
|
1378 .SETR reinstate
|
|
|
1379 .P
|
|
|
1380 The REINSTATE statement, like the ABSTAIN, takes as an argument either a
|
|
|
1381 line label or a gerund list. No other form of argument is permitted. For
|
|
|
1382 example, the following is an invalid argument:
|
|
|
1383 .DS L
|
|
|
1384 Given: x\(!=0, y\(!=0, Prove: x+y=0
|
|
|
1385 Since x\(!=0, then x+1\(!=1, x+a\(!=a, x+y\(!=y.
|
|
|
1386 But what is y? y is anything but 0.
|
|
|
1387 Thus x+y \(!= anything but 0.
|
|
|
1388 Since x+y cannot equal anything but 0, x+y=0.
|
|
|
1389 Q.E.D.
|
|
|
1390 .DE
|
|
|
1391 REINSTATEment nullifies the effects of an abstention. Either form of
|
|
|
1392 REINSTATEment can be used to "free" a statement, regardless of whether the
|
|
|
1393 statement was abstained from by gerund list, line label, or NOT. Thus,
|
|
|
1394 PLEASE REINSTATE REINSTATING is not necessarily an irrelevant statement,
|
|
|
1395 since it might free a DON'T REINSTATE command or a REINSTATE the line label
|
|
|
1396 of which was abstained from. However, DO REINSTATE GIVING UP is invalid,
|
|
|
1397 and attempting to REINSTATE a GIVE UP statement by line label will have no
|
|
|
1398 effect. Note that this insures that DON'T GIVE UP will always be a
|
|
|
1399 "do-nothing" statement.
|
|
|
1400 .H 3 "GIVE UP"
|
|
|
1401 .SETR give_up
|
|
|
1402 .P
|
|
|
1403 PLEASE GIVE UP is used to exit from a program. It has the effect of a PLEASE
|
|
|
1404 RESUME #80. DON'T GIVE UP, as noted in section
|
|
|
1405 .GETHN reinstate
|
|
|
1406 \&, is effectively a null
|
|
|
1407 statement.
|
|
|
1408 .H 3 "Input"
|
|
|
1409 .SETR input
|
|
|
1410 .P
|
|
|
1411 Input is accomplished with the statement DO WRITE IN list, where list
|
|
|
1412 represents a string of variables and/or elements of arrays, separated by
|
|
|
1413 intersections. Numbers are represented on cards, each number on a separate
|
|
|
1414 card, by spelling out each digit (in English) and separating the digits
|
|
|
1415 with one or more spaces. A zero (0) may be spelled as either ZERO or OH.
|
|
|
1416 Thus the range of (32-bit) input values permissible extends from ZERO (or
|
|
|
1417 OH) through FOUR TWO NINE FOUR NINE SIX SEVEN TWO NINE FIVE.
|
|
|
1418 .if '\*c'y' \{\
|
|
|
1419 (For the convenience of aviators, C-INTERCAL accepts the spelling
|
|
|
1420 NINER for NINE. In the service of internationalization, C-INTERCAL
|
|
|
1421 also accepts input digits in Sanskrit, Basque, Tagalog, Classical
|
|
|
1422 Nahuatl, Georgian, Kwakiutl, and Volapuk.) \}
|
|
|
1423 .P
|
|
|
1424 Attempting to write in a value greater than or equal to SIX FIVE FIVE THREE
|
|
|
1425 SIX for a 16-bit variable will result in the error message, "DON'T BYTE OFF
|
|
|
1426 MORE THAN YOU CAN CHEW."
|
|
|
1427 .if '\*c'y' \{\
|
|
|
1428 .P
|
|
|
1429 (See also section
|
|
|
1430 .GETHN communication
|
|
|
1431 for a description of C-INTERCAL's character I/O.) \}
|
|
|
1432 .H 3 "Output"
|
|
|
1433 .P
|
|
|
1434 Values may be output to the printer, one value per line, via the statement
|
|
|
1435 DO READ OUT list, where the list contains variables, array elements, and/or
|
|
|
1436 constants. Output is in the form of "extended" Roman numerals (also called
|
|
|
1437 "butchered" Roman numerals), with an overline
|
|
|
1438 .if t (\(rn)
|
|
|
1439 indicating the value below
|
|
|
1440 is "times 1000", and lower-case letters indicating "times 1000000". Zero
|
|
|
1441 is indicated by an overline with no character underneath. Thus, the range
|
|
|
1442 of (32-bit) output values possible is from
|
|
|
1443 .if t \(rn
|
|
|
1444 .if n \{\
|
|
|
1445 .nf
|
|
|
1446 _
|
|
|
1447
|
|
|
1448 .fi \}
|
|
|
1449 through
|
|
|
1450 .ie t \o"i\(rn"\o"v\(rn"ccxciv\o"C\(rn"\o"M\(rn"\o"L\(rn"\o"X\(rn"\o"V\(rn"\o"I\(rn"\o"I\(rn"CCXCV.
|
|
|
1451 .el \{\
|
|
|
1452 .br
|
|
|
1453 .nf
|
|
|
1454 __ ____________
|
|
|
1455 ivccxcivCMLXVIICCXCV.
|
|
|
1456 .fi \}
|
|
|
1457 Note: For values whose residues modulo 1000000 are less than 4000, M is
|
|
|
1458 used to represent 1000; for values whose residues are 4000 or greater,
|
|
|
1459 .if t \o"I\(rn"
|
|
|
1460 .if n \{\
|
|
|
1461 .nf
|
|
|
1462 _
|
|
|
1463 I
|
|
|
1464 .fi \}
|
|
|
1465 .\" This is the one place we corrected the original manual.
|
|
|
1466 is used. Thus #3999 would read out as MMMCMXCIX \*F while #4000 would
|
|
|
1467 .FS
|
|
|
1468 The original INTERCAL-72 manual claimed
|
|
|
1469 that #3999 should render as MMMIM, but the C-INTERCAL developers have
|
|
|
1470 been unable to find an algorithm that does this and is consistent
|
|
|
1471 with the rest of the rules.
|
|
|
1472 .FE
|
|
|
1473 readout as
|
|
|
1474 .if t \o"I\(rn"\o"V\(rn".
|
|
|
1475 .if n \{\
|
|
|
1476 .nf
|
|
|
1477 __
|
|
|
1478 IV
|
|
|
1479 .fi \}
|
|
|
1480 Similar rules apply to the use of
|
|
|
1481 .if t \o"M\(rn"
|
|
|
1482 .if n \{\
|
|
|
1483 .nf
|
|
|
1484 _
|
|
|
1485 M
|
|
|
1486 .fi \}
|
|
|
1487 and i for 1000000, and to that of m and
|
|
|
1488 .if t \o"i\(rn"
|
|
|
1489 .if n \{\
|
|
|
1490 .nf
|
|
|
1491 _
|
|
|
1492 i
|
|
|
1493 .fi \}
|
|
|
1494 for 1000000000.
|
|
|
1495 .if '\*c'y' \{\
|
|
|
1496 .P
|
|
|
1497 (See also section
|
|
|
1498 .GETHN communication
|
|
|
1499 for a description of C-INTERCAL's character I/O.) \}
|
|
|
1500 .if '\*c'y' \{\
|
|
|
1501 .H 3 "COME FROM"
|
|
|
1502 .P
|
|
|
1503 In which we try to precisely define a statement that should never
|
|
|
1504 have been born, but is nevertheless one of the more useful statements
|
|
|
1505 in INTERCAL.
|
|
|
1506 .H 4 "Background"
|
|
|
1507 .P
|
|
|
1508 The earliest known description of the COME FROM statement in the computing
|
|
|
1509 literature is in [R. L. Clark, "A linguistic contribution to GOTO-less
|
|
|
1510 programming," Commun. ACM 27 (1984), pp. 349-350], part of the famous April
|
|
|
1511 Fools issue of CACM. The subsequent rush by language designers to include the
|
|
|
1512 statement in their languages was underwhelming, one might even say nonexistent.
|
|
|
1513 It was therefore decided that COME FROM would be an appropriate addition
|
|
|
1514 to C-INTERCAL.
|
|
|
1515 .H 4 "Description"
|
|
|
1516 .P
|
|
|
1517 There are two useful ways to visualize the action of the COME FROM
|
|
|
1518 statement. The simpler is to see that it acts like a GOTO when the
|
|
|
1519 program is traced backwards in time. More precisely, the statements
|
|
|
1520 .DS L
|
|
|
1521 (1) DO <any statement>
|
|
|
1522 .
|
|
|
1523 .
|
|
|
1524 .
|
|
|
1525 (2) DO COME FROM (1)
|
|
|
1526 .DE
|
|
|
1527 should be thought of as being equivalent to
|
|
|
1528 .DS L
|
|
|
1529 (1) DO <any statement>
|
|
|
1530 (2) DO GOTO (3)
|
|
|
1531 .
|
|
|
1532 .
|
|
|
1533 .
|
|
|
1534 (3) DO NOTHING
|
|
|
1535 .DE
|
|
|
1536 if INTERCAL actually had a GOTO statement at all, which of course it
|
|
|
1537 doesn't.
|
|
|
1538 .P
|
|
|
1539 What this boils down to is that the statement DO COME FROM (label),
|
|
|
1540 anywhere in the program, places a kind of invisible trap door
|
|
|
1541 immediately after statement (label). Execution or abstention of that
|
|
|
1542 statement is immediately followed by an unconditional jump to the
|
|
|
1543 COME FROM, unless the (label)ed statement is an executed NEXT, in which
|
|
|
1544 case the jump occurs if the program attempts to RESUME back to that
|
|
|
1545 NEXT statement. It is an error for more than one COME FROM to refer
|
|
|
1546 to the same (label).
|
|
|
1547 .P
|
|
|
1548 Modification of the target statement by ABSTAIN or by the % qualifier
|
|
|
1549 affects only that statement, not the subsequent jump. Such
|
|
|
1550 modifications to the COME FROM itself, however, do affect the jump.
|
|
|
1551 Encountering the COME FROM statement itself, rather than its target,
|
|
|
1552 has no effect. \}
|
|
|
1553 .SETR last_statement
|
|
|
1554 .H 2 "Comments"
|
|
|
1555 .SETR comments
|
|
|
1556 .P
|
|
|
1557 Unrecognizable statements, as noted in section
|
|
|
1558 .GETHN error_messages
|
|
|
1559 \&, are flagged with a splat
|
|
|
1560 (*) during compilation, and are not considered fatal errors unless they
|
|
|
1561 are encountered during execution, at which time the statement (as input at
|
|
|
1562 compilation time) is printed and execution is terminated. This allows for
|
|
|
1563 an interesting (and, by necessity, unique) means of including comments in
|
|
|
1564 an INTERCAL listing. For example, the statement:
|
|
|
1565 .sp 1
|
|
|
1566 * PLEASE NOTE THAT THIS LINE HAS NO EFFECT
|
|
|
1567 .P
|
|
|
1568 will be ignored during execution due to the inclusion of the NOT qualifier.
|
|
|
1569 User-supplied error messages are also easy to implement:
|
|
|
1570 .sp 1
|
|
|
1571 * DO SOMETHING ABOUT OVERFLOW IN ;3
|
|
|
1572 .P
|
|
|
1573 as are certain simple conditional errors:
|
|
|
1574 .DS L
|
|
|
1575 .cs R 24
|
|
|
1576 * (123) DON'T YOU REALIZE THIS STATEMENT SHOULD ONLY BE ENCOUNTERED
|
|
|
1577 ONCE?
|
|
|
1578 PLEASE REINSTATE (123)
|
|
|
1579 .cs R
|
|
|
1580 .DE
|
|
|
1581 This pair of statements will cause an error exit the second time they are
|
|
|
1582 encountered. Caution!! The appearance of a statement identifier in an
|
|
|
1583 intended comment will be taken as the beginning of a new
|
|
|
1584 .\" CORRECTION:
|
|
|
1585 .\" "comment example above" was originally "example on the preceding page"
|
|
|
1586 .\" We can't rely on page boundaries any more.
|
|
|
1587 statement. Thus, the first comment example above could not have been:
|
|
|
1588 .sp 1
|
|
|
1589 * PLEASE NOTE THAT THIS LINE DOES NOTHING
|
|
|
1590 .P
|
|
|
1591 The third example, however, is valid, despite the appearance of two cases
|
|
|
1592 of D-space-O, since INTERCAL does not ignore extraneous spaces in statement
|
|
|
1593 identifiers.
|
|
|
1594 .if '\*c'y' \{\
|
|
|
1595 .H 1 "OUTSIDE COMMUNICATION"
|
|
|
1596 .if '\*c'y' \{\
|
|
|
1597 .DS I F
|
|
|
1598 She puzzled over this for some time, but at last a bright thought
|
|
|
1599 struck her. "Why, it's a Looking-glass book, of course! And, if I hold
|
|
|
1600 it up to a glass, the words will all go the right way again."
|
|
|
1601 .DE \}
|
|
|
1602 .SETR communication
|
|
|
1603 .P
|
|
|
1604 In which we try to remedy the fact that, due to I/O limitations, INTERCAL
|
|
|
1605 can not even in principle perform the same tasks as other languages. It
|
|
|
1606 is hoped that this addition will permit INTERCAL users to waste vast
|
|
|
1607 quantities of computer time well into the 21st century.
|
|
|
1608 .H 2 "Motivation"
|
|
|
1609 .P
|
|
|
1610 One of the goals of INTERCAL was to provide a language which, though
|
|
|
1611 different from all other languages, is nevertheless theoretically
|
|
|
1612 capable of all the same tasks. INTERCAL-72 failed to
|
|
|
1613 accomplish this because its I/O functions could not handle arbitrary
|
|
|
1614 streams of bits, or even arbitrary sequences of characters. A
|
|
|
1615 language which can't even send its input directly to its output
|
|
|
1616 can hardly be considered as capable as other languages.
|
|
|
1617 .H 2 "Turing Text Model"
|
|
|
1618 .P
|
|
|
1619 To remedy this problem, character I/O is now provided in a form based
|
|
|
1620 on the "Turing Text" model, originally proposed by Jon Blow. The
|
|
|
1621 C-INTERCAL programmer can access this capability by placing a
|
|
|
1622 one-dimensional array in the list of items given to a WRITE IN or READ
|
|
|
1623 OUT statement. On execution of the statement, the elements of the array
|
|
|
1624 will, from first to last, be either loaded from the input or sent
|
|
|
1625 to the output, as appropriate, in the manner described below. There
|
|
|
1626 is currently no support for I/O involving higher-dimensional arrays,
|
|
|
1627 but some form of graphics might be a possible 2-D interpretation.
|
|
|
1628 .P
|
|
|
1629 The heart of the Turing Text model is the idea of a continuous loop
|
|
|
1630 of tape containing, in order, all the characters in the machine's
|
|
|
1631 character set. When a character is received by the input routine,
|
|
|
1632 the tape is advanced the appropriate number of spaces to bring
|
|
|
1633 that character under the tape head, and the number of spaces the
|
|
|
1634 tape was moved is the number that is actually seen by the INTERCAL
|
|
|
1635 program. Another way to say this is that the number placed in an
|
|
|
1636 INTERCAL array is the difference between the character just
|
|
|
1637 received and the previous character, modulo the number of characters
|
|
|
1638 in the machine character set.
|
|
|
1639 .P
|
|
|
1640 Output works in just the opposite fashion, except that the characters
|
|
|
1641 being output come from the other side of the tape. From this position
|
|
|
1642 the characters on the tape appear to be in reverse order, and are
|
|
|
1643 individually backwards as well. (We would show you what it looks
|
|
|
1644 like, but we don't have a font with backwards letters available.
|
|
|
1645 Use your imagination.) The effect is that a number is taken out
|
|
|
1646 of an INTERCAL array, subtracted from the last character output --
|
|
|
1647 i.e., the result of the last subtraction -- and then sent on down
|
|
|
1648 the output channel. The only catch is that the character as seen
|
|
|
1649 by the INTERCAL program is the mirror-image of the character as
|
|
|
1650 seen by the machine and the user. The bits of the character are
|
|
|
1651 therefore taken in reverse order as it is sent to the output.
|
|
|
1652 Note that this bit reversal affects only the character seen by
|
|
|
1653 the outside world; it does not affect the character stored internally
|
|
|
1654 by the program, from which the next output number will be subtracted.
|
|
|
1655 All subtractions are done modulo the number of characters in the
|
|
|
1656 character set.
|
|
|
1657 .P
|
|
|
1658 Two different tapes are used for input and output to allow for
|
|
|
1659 future expansion of the language to include multiple input and
|
|
|
1660 output channels. Both tapes start at character 0 when a program
|
|
|
1661 begins execution. On input, when an end-of-file marker is reached
|
|
|
1662 the number placed in the array is one greater than the
|
|
|
1663 highest-numbered character on the tape.
|
|
|
1664 .H 2 "Example Program"
|
|
|
1665 .P
|
|
|
1666 If all this seems terribly complicated, it should be made perfectly
|
|
|
1667 clear by the following example program, which simply maps its input
|
|
|
1668 to its output (like a simplified UNIX "cat"). It assumes that
|
|
|
1669 characters are 8 bits long, but that's fine since the current version
|
|
|
1670 of C-INTERCAL does too. It uses the standard library routines for addition
|
|
|
1671 and subtraction.
|
|
|
1672 .DS L
|
|
|
1673 .cs R 24
|
|
|
1674 DO ,1 <- #1
|
|
|
1675 DO .4 <- #0
|
|
|
1676 DO .5 <- #0
|
|
|
1677 DO COME FROM (30)
|
|
|
1678 DO WRITE IN ,1
|
|
|
1679 DO .1 <- ,1SUB#1
|
|
|
1680 DO (10) NEXT
|
|
|
1681 PLEASE GIVE UP
|
|
|
1682 (20) PLEASE RESUME '?.1$#256'~'#256$#256'
|
|
|
1683 (10) DO (20) NEXT
|
|
|
1684 DO FORGET #1
|
|
|
1685 DO .2 <- .4
|
|
|
1686 DO (1000) NEXT
|
|
|
1687 DO .4 <- .3~#255
|
|
|
1688 DO .3 <- !3~#15'$!3~#240'
|
|
|
1689 DO .3 <- !3~#15'$!3~#240'
|
|
|
1690 DO .2 <- !3~#15'$!3~#240'
|
|
|
1691 DO .1 <- .5
|
|
|
1692 DO (1010) NEXT
|
|
|
1693 DO .5 <- .2
|
|
|
1694 DO ,1SUB#1 <- .3
|
|
|
1695 (30) PLEASE READ OUT ,1
|
|
|
1696 .cs R
|
|
|
1697 .DE
|
|
|
1698 For each number received in the input array, the program first tests
|
|
|
1699 the #256 bit to see if the end of file has been reached. If not, the
|
|
|
1700 previous input character is subtracted off to obtain the current
|
|
|
1701 input character. Then the order of the bits is reversed to find
|
|
|
1702 out what character should be sent to the output, and the result
|
|
|
1703 is subtracted from the last character sent. Finally, the difference
|
|
|
1704 is placed in an array and given to a READ OUT statement. See?
|
|
|
1705 We told you it was simple! \}
|
|
|
1706 .if '\*c'y' \{\
|
|
|
1707 .H 1 "TriINTERCAL"
|
|
|
1708 .if '\*c'y' \{\
|
|
|
1709 .DS I F
|
|
|
1710 "-- oh dear, how puzzling it all is! I'll try if I know all the things
|
|
|
1711 I used to know. Let me see: four times five is twelve, and four times
|
|
|
1712 six is thirteen, and four times seven is -- oh dear! I shall never get
|
|
|
1713 to twenty at that rate!"
|
|
|
1714 .DE \}
|
|
|
1715 .SETR tri_intercal
|
|
|
1716 .P
|
|
|
1717 In which it is revealed that bitwise operations are too ordinary for
|
|
|
1718 hard-core INTERCAL programmers, and extensions to other bases are
|
|
|
1719 discussed. These are not, strictly speaking, extensions to INTERCAL
|
|
|
1720 itself, but rather new dialects sharing most of the features of the
|
|
|
1721 parent language.
|
|
|
1722 .H 2 "Motivation"
|
|
|
1723 .P
|
|
|
1724 INTERCAL is really a pretty sissy language. It tries hard to be
|
|
|
1725 different, but when you get right down to its roots, what do you find?
|
|
|
1726 You find bits, that's what. Plain old ones and zeroes, in groups of
|
|
|
1727 16 and 32, just like every other language you've ever heard of. And
|
|
|
1728 what operations can you perform on these bits? The INTERCAL operators
|
|
|
1729 may arrange and permute them in weird and wonderful ways, but at the
|
|
|
1730 bit level the operators are the same AND, OR and XOR you've seen
|
|
|
1731 countless times before.
|
|
|
1732 .P
|
|
|
1733 Once the prospective INTERCAL programmer masters the unusual syntax,
|
|
|
1734 she finds herself working with the familiar Boolean operators on
|
|
|
1735 perfectly ordinary unsigned integer words. Even the constants she uses
|
|
|
1736 are familiar. After all, who would not immediately recognize #65535
|
|
|
1737 and #32768? It may take a just a moment more to figure out #65280,
|
|
|
1738 and #21845 and #43690 could be puzzles until she notices that they
|
|
|
1739 sum to #65535, but basically she's still on her home turf. The 16-bit
|
|
|
1740 limit on constants actually works in the programmer's favor by insuring
|
|
|
1741 that very long anonymous constants cannot appear in INTERCAL programs.
|
|
|
1742 And this is in a language that is supposed to be different from any
|
|
|
1743 other!
|
|
|
1744 .H 2 "Abandon All Hope..."
|
|
|
1745 .P
|
|
|
1746 Standard INTERCAL is based on variables consisting of ordinary bits
|
|
|
1747 and familiar Boolean operations on those bits. In pursuit of uniqueness,
|
|
|
1748 it seems appropriate to provide a new dialect, otherwise identical to
|
|
|
1749 INTERCAL, which instead uses variables consisting of trits, i.e. ternary
|
|
|
1750 digits, and operators based on tritwise logical operations. This is
|
|
|
1751 intended to be a separate dialect, rather than an extension to INTERCAL
|
|
|
1752 itself, for a number of reasons. Doing it this way avoids word-length
|
|
|
1753 conflicts, does not spoil the elegance of the Spartan INTERCAL operator
|
|
|
1754 set, and dodges the objections of those who might feel it too great an
|
|
|
1755 alteration to the original language. Primarily, though, giving INTERCAL
|
|
|
1756 programmers the ability to switch numeric base at will amounts to
|
|
|
1757 excessive functionality. So much better that a programmer choose a base
|
|
|
1758 at the outset and then be forced to stick with it for the remainder of
|
|
|
1759 the program.
|
|
|
1760 .H 2 "Compiler Operation"
|
|
|
1761 .P
|
|
|
1762 The same compiler, ick, supports both INTERCAL and TriINTERCAL.
|
|
|
1763 This has the advantage that future bug fixes and additions to the
|
|
|
1764 language not related to arithmetic immediately apply to both versions.
|
|
|
1765 The compiler recognizes INTERCAL source files by the extension '.i',
|
|
|
1766 and TriINTERCAL source files by the extension '.3i'. It's as simple
|
|
|
1767 as that. There is no way to mix INTERCAL and TriINTERCAL source in
|
|
|
1768 the same program, and it is not always possible to determine which
|
|
|
1769 dialect a program is written in just by looking at the source code.
|
|
|
1770 .H 2 "Data Types"
|
|
|
1771 .P
|
|
|
1772 The two TriINTERCAL data types are 10-trit unsigned integers and
|
|
|
1773 20-trit unsigned integers. All INTERCAL syntax for distinguishing
|
|
|
1774 data types is ported to these new types in the obvious way. Small
|
|
|
1775 words may contain numbers from #0 to #59048; large words may contain
|
|
|
1776 numbers from #0$#0 to #59048$#59048. Errors are signaled for constants
|
|
|
1777 greater than #59048 and for attempts to WRITE IN numbers too large
|
|
|
1778 for a given variable or array element to hold.
|
|
|
1779 .P
|
|
|
1780 Note that though TriINTERCAL considers all numbers to be unsigned,
|
|
|
1781 nothing prevents the programmer from implementing arithmetic operations
|
|
|
1782 that treat their operands as signed. Three's complement is one obvious
|
|
|
1783 choice, but balanced ternary notation is also a possibility. This
|
|
|
1784 latter is a very pretty and symmetrical system in which all 2 trits
|
|
|
1785 are treated as if they had the value -1.
|
|
|
1786 .H 2 "Operators"
|
|
|
1787 .P
|
|
|
1788 The TriINTERCAL operators are designed to inherit the relevant properties
|
|
|
1789 of the standard INTERCAL operators, so that both can be considered as
|
|
|
1790 merely different aspects of the same Platonic ideal. (Not that the word
|
|
|
1791 "ideal" is ever particularly relevant when used in connection with
|
|
|
1792 INTERCAL.)
|
|
|
1793 .H 3 "Binary Operators I"
|
|
|
1794 .P
|
|
|
1795 The binary operators carry over from the original language with only
|
|
|
1796 minor changes. The mingle operator ($) creates a 20-trit word by
|
|
|
1797 alternating trits from its two 10-trit operands. The select operator (~)
|
|
|
1798 is a little more complicated, since the ternary tritmask may contain 0, 1,
|
|
|
1799 and 2 trits. If we observe that the select operation on binary operands
|
|
|
1800 amounts to a bitwise AND and some rearrangement of bits, it seems
|
|
|
1801 appropriate to base the select for ternary operands on a tritwise AND in
|
|
|
1802 the analogous fashion. We therefore postpone the definition of select
|
|
|
1803 until we know what a tritwise AND looks like.
|
|
|
1804 .H 3 "Unary Operators"
|
|
|
1805 .P
|
|
|
1806 The unary operators in INTERCAL are all derived from the familiar
|
|
|
1807 Boolean operations on single bits. To extend these operations to trits,
|
|
|
1808 we first ask ourselves what the important properties of these operations
|
|
|
1809 are that we wish to be preserved, then design the tritwise operators so
|
|
|
1810 that they behave in a similar fashion.
|
|
|
1811 .H 4 "Unary Logical Operators"
|
|
|
1812 .P
|
|
|
1813 Let's start with AND and OR. To begin with, these can be considered
|
|
|
1814 "choice" or "preference" operators, as they always return one of their
|
|
|
1815 operands. AND can be described as wanting to return 0, but returning 1
|
|
|
1816 if it is given no other choice, i.e., if both operands are 1. Similarly,
|
|
|
1817 OR wants to return 1 but returns 0 if that is its only choice. From
|
|
|
1818 this it is immediately apparent that each operator has an identity
|
|
|
1819 element that "always loses", and a dominator element that "always wins".
|
|
|
1820 .P
|
|
|
1821 AND and OR are commutative and associative, and each distributes
|
|
|
1822 over the other. They are also symmetric with each other, in the sense
|
|
|
1823 that AND looks like OR and OR looks like AND when the roles of 0 and 1
|
|
|
1824 are interchanged (De Morgan's Laws). This symmetry property seems to be
|
|
|
1825 a key element to the idea that these are logical, rather than arithmetic,
|
|
|
1826 operators. In a three-valued logic we would similarly expect a
|
|
|
1827 three-way symmetry among the three values 0, 1 and 2 and the three
|
|
|
1828 operators AND, OR and (of course) BUT.
|
|
|
1829 .P
|
|
|
1830 The following tritwise operations have all the desired properties:
|
|
|
1831 OR returns the greater of its two operands. That is, it returns 2 if
|
|
|
1832 it can get it, else it tries to return 1, and it returns 0 only if both
|
|
|
1833 operands are 0. AND wants to return 0, will return 2 if it can't get
|
|
|
1834 0, and returns 1 only if forced. BUT wants 1, will take 0, and tries
|
|
|
1835 to avoid 2. The equivalents to De Morgan's Laws apply to rotations
|
|
|
1836 of the three elements, e.g., 0 -> 1, 1 -> 2, 2 -> 0. Each operator
|
|
|
1837 distributes over exactly one other operator, so the property
|
|
|
1838 "X distributes over Y" is not transitive. The question of which way
|
|
|
1839 this distributivity ring goes around is left as an exercise for the
|
|
|
1840 student.
|
|
|
1841 .P
|
|
|
1842 In TriINTERCAL programs the whirlpool (@) denotes the unary tritwise
|
|
|
1843 BUT operation. You can think of the whirlpool as drawing values
|
|
|
1844 preferentially towards the central value 1. Alternatively, you can
|
|
|
1845 think of it as drawing your soul and your sanity inexorably down ...
|
|
|
1846 .P
|
|
|
1847 On the other hand, maybe it's best you \fInot\fR think of it that way.
|
|
|
1848 .P
|
|
|
1849 A few comments about how these operators can be used. OR acts like
|
|
|
1850 a tritwise maximum operation. AND can be used with tritmasks. 0's
|
|
|
1851 in a mask wipe out the corresponding elements in the other operand,
|
|
|
1852 while 1's let the corresponding elements pass through unchanged. 2's
|
|
|
1853 in a mask consolidate the values of nonzero elements, as both 1's and
|
|
|
1854 2's in the other operand yield 2's in the output. BUT can be used to
|
|
|
1855 create "partial tritmasks". 0's in a mask let BUT eliminate 2's from
|
|
|
1856 the other operand while leaving other values unchanged. Of course,
|
|
|
1857 the symmetry property guarantees that the operators don't really
|
|
|
1858 behave differently from each other in any fundamental way; the apparent
|
|
|
1859 differences come from the intuitive view that a 0 trit is "not set"
|
|
|
1860 while a 1 or 2 trit is "set".
|
|
|
1861 .H 4 "Binary Operators II"
|
|
|
1862 .P
|
|
|
1863 At this point we can define select, since we now know what the
|
|
|
1864 tritwise AND looks like. Select takes the binary tritwise AND of
|
|
|
1865 its two operands. It shifts all the trits of the result corresponding
|
|
|
1866 to 2's in the right operand over to the right (low) end of the result,
|
|
|
1867 then follows them with all the output trits corresponding to 1's in
|
|
|
1868 the right operand. Trits corresponding to 0's in the right operand,
|
|
|
1869 which are all 0 anyway, occupy the remaining space at the left end of
|
|
|
1870 the output word. Both 10-trit and 20-trit operands are accepted,
|
|
|
1871 and are padded with zeroes on the left if necessary. The output
|
|
|
1872 type is determined the same way as in standard C-INTERCAL.
|
|
|
1873 .H 4 "Unary Arithmetic Operators"
|
|
|
1874 .P
|
|
|
1875 Now that we've got all that settled, what about XOR? This is
|
|
|
1876 easily the most-useful of the three unary INTERCAL operators,
|
|
|
1877 because it combines in one package the operations ADD WITHOUT CARRY,
|
|
|
1878 SUBTRACT WITHOUT BORROW, BITWISE NOT-EQUAL, and BITWISE NOT. In
|
|
|
1879 TriINTERCAL we can't have all of these in the same operator, since
|
|
|
1880 addition and subtraction are no longer the same thing. The solution
|
|
|
1881 is to split the XOR concept into two operators. The ADD WITHOUT CARRY
|
|
|
1882 operation is represented by the new sharkfin (^), while the old
|
|
|
1883 what (?) represents SUBTRACT WITHOUT BORROW. The reason for this
|
|
|
1884 choice is so that what (?) will also represent the TRITWISE NOT-EQUAL
|
|
|
1885 operation.
|
|
|
1886 .P
|
|
|
1887 Note that what (?), unlike the other four unary operators, is not
|
|
|
1888 symmetrical. It should be thought of as rotating its operand one trit
|
|
|
1889 to the right (with wraparound) and then subtracting off the trits of
|
|
|
1890 the original number. These subtractions are done without borrowing,
|
|
|
1891 i.e., trit-by-trit modulo 3.
|
|
|
1892 .H 3 "Examples"
|
|
|
1893 .P
|
|
|
1894 The TriINTERCAL operators really aren't all that bad once you get
|
|
|
1895 used to them. Let's look at a few examples to show how they can
|
|
|
1896 be used in practice. In all of these examples the input value is
|
|
|
1897 contained in the 10-trit variable .3.
|
|
|
1898 .P
|
|
|
1899 In INTERCAL, single-bit values often have to be converted from
|
|
|
1900 {0,1} to {1,2} for use in RESUME statements. Examples of how to do
|
|
|
1901 this appear in the original manual. In TriINTERCAL the expression
|
|
|
1902 "^.3$#1"~#1 sends 0 -> 1 and 1 -> 2. If the 1-trit input value can
|
|
|
1903 take on any of its three possible states, however, we will also have
|
|
|
1904 to deal with the 2 case. The expression "V.3$#1"~#1 sends {0,1} -> 1
|
|
|
1905 and 2 -> 2. To test if a trit is set, we can use "V'"&.3$#2"~#1'$#1"~#1,
|
|
|
1906 sending 0 -> 1 and {1,2} -> 2. To reverse the test we use
|
|
|
1907 "?'"&.3$#2"~#1'$#1"~#1, sending 0 -> 2 and {1,2} -> 1. Note that we
|
|
|
1908 have not been taking full advantage of the new select operator. These
|
|
|
1909 last two expressions can be simplified into "V!3~#2'$#1"~#1 and
|
|
|
1910 "?!3~#2'$#1"~#1, which perform exactly the same mappings. Finally, if
|
|
|
1911 we need a 3-way test, we can use "@'"^.3$#7"~#4'$#2"~#10, which
|
|
|
1912 obviously sends 0 -> 1, 1 -> 2, and 2 -> 3.
|
|
|
1913 .P
|
|
|
1914 For an unrelated example, the expression "^.3$.3"~"#0$#29524"
|
|
|
1915 converts all of the 1-trits of .3 into 2's and all of the 2-trits
|
|
|
1916 into 1's. In balanced ternary, where 2-trits represent -1 values,
|
|
|
1917 this is the negation operation.
|
|
|
1918 .H 2 "Beyond Ternary..."
|
|
|
1919 .P
|
|
|
1920 While we're at it, we might as well extend this multiple bases
|
|
|
1921 business a little farther. The ick compiler actually recognizes
|
|
|
1922 filename suffixes of the form '.Ni', where N is any number from 2
|
|
|
1923 to 7. 2 of course gives standard INTERCAL, while 3 gives TriINTERCAL.
|
|
|
1924 We cut off before 8 because octal notation is the smallest base used
|
|
|
1925 to facilitate human-to-machine communication, and this seems quite
|
|
|
1926 contrary to the basic principles behind INTERCAL. The small data
|
|
|
1927 types hold 16 bits, 10 trits, 8 quarts, 6 quints, 6 sexts, or 5 septs,
|
|
|
1928 and the large types are always twice this size.
|
|
|
1929 .P
|
|
|
1930 As for operators, ? is always SUBTRACT WITHOUT BORROW, and ^
|
|
|
1931 is always ADD WITHOUT CARRY. V is the OR operation and always
|
|
|
1932 returns the max of its inputs. & is the AND operation, which chooses
|
|
|
1933 0 if possible but otherwise returns the max of the inputs. @ is BUT,
|
|
|
1934 which prefers 1, then 0, then the max of the remaining possibilities.
|
|
|
1935 Rather than add more special symbols forever, a numeric modifier may
|
|
|
1936 be placed directly before the @ to indicate the operation
|
|
|
1937 that prefers one of the digits not already represented. Thus in files
|
|
|
1938 ending in '.5i', the permitted unary operators are ?, ^, &, @, 2@, 3@,
|
|
|
1939 and V. Use of such barbarisms as 0@ to represent &
|
|
|
1940 are not permitted, nor is the use of @ or ^ in files with either
|
|
|
1941 of the extensions '.i' or '.2i'. Why not? You just can't, that's why.
|
|
|
1942 Don't ask so many questions.
|
|
|
1943 .P
|
|
|
1944 As a closing example, we note that in balanced quinary notation,
|
|
|
1945 where 3 means -2 and 4 means -1, the negation operation can be written
|
|
|
1946 as either
|
|
|
1947 .DS L
|
|
|
1948 DO .1 <- "^'"^.3$.3"~"#0$#3906"'$'"^.3$.3"~"#0$#3906"'"~"#0$#3906"
|
|
|
1949 .DE
|
|
|
1950 or as
|
|
|
1951 .DS L
|
|
|
1952 DO .1 <- "^.3$.3"~"#0$#3906"
|
|
|
1953 DO .1 <- "^.1$.1"~"#0$#3906"
|
|
|
1954 .DE
|
|
|
1955 These work because multiplication by -1 is the same as multiplication
|
|
|
1956 by 4, modulo 5.
|
|
|
1957 .P
|
|
|
1958 Now go beat your head against the wall for a while.\}
|
|
|
1959 .H 1 "SUBROUTINE LIBRARY"
|
|
|
1960 .if '\*c'y' \{\
|
|
|
1961 .DS I F
|
|
|
1962 "You don't know what you're talking about!" cried Humpty Dumpty. "How
|
|
|
1963 many days are there in a year?"
|
|
|
1964 .P
|
|
|
1965 "Three hundred and sixty-five," said Alice.
|
|
|
1966 .P
|
|
|
1967 "And how many birthdays have you?"
|
|
|
1968 .P
|
|
|
1969 "One."
|
|
|
1970 .P
|
|
|
1971 "And if you take one from three hundred and sixty-five, what remains?"
|
|
|
1972 .P
|
|
|
1973 "Three hundred and sixty-four, of course."
|
|
|
1974 .P
|
|
|
1975 Humpty Dumpty looked doubtful. "I'd rather see that done on paper," he
|
|
|
1976 said.
|
|
|
1977 .DE \}
|
|
|
1978 .SETR sublib
|
|
|
1979 .P
|
|
|
1980 INTERCAL provides several built-in subroutines to which control can be
|
|
|
1981 transferred to perform various operations. These operations include many
|
|
|
1982 useful functions which are not easily representable in INTERCAL, such as
|
|
|
1983 addition, subtraction, etc.
|
|
|
1984 .H 2 "Usage"
|
|
|
1985 .P
|
|
|
1986 In general, the operands are .1, .2, etc., or :1, :2, etc., and the result(s)
|
|
|
1987 are stored in what would have been the next operand(s). For instance, one
|
|
|
1988 routine adds .1 to .2 and stores the sum in .3, with .4 being used to indicate
|
|
|
1989 overflow. All variables not used for results are left unchanged.
|
|
|
1990 .H 2 "Available Functions"
|
|
|
1991 .SETR functions
|
|
|
1992 .P
|
|
|
1993 At the time of this writing, only the most fundamental operations are offered
|
|
|
1994 in the library, as a more complete selection would require prohibitive time
|
|
|
1995 and core to implement. These functions, along with their corresponding entry
|
|
|
1996 points (entered via DO (entry) NEXT) are listed below.
|
|
|
1997 .DS L
|
|
|
1998 .cs R 24
|
|
|
1999 (1000) .3 <- .1 plus .2, error exit on overflow
|
|
|
2000 (1009) .3 <- .1 plus .2
|
|
|
2001 .4 <- #1 if no overflow, else .4 <- #2
|
|
|
2002 (1010) .3 <- .1 minus .2, no action on overflow
|
|
|
2003 (1020) .1 <- .1 plus #1, no action on overflow
|
|
|
2004 (1030) .3 <- .1 times .2, error exit on overflow
|
|
|
2005 (1039) .3 <- .1 times .2
|
|
|
2006 .4 <- #1 if no overflow, else .4 <- #2
|
|
|
2007 (1040) .3 <- .1 divided by .2
|
|
|
2008 .3 <- #0 if .2 is #0
|
|
|
2009 (1050) .2 <- :1 divided by .1, error exit on overflow
|
|
|
2010 .2 <- #0 if .1 is #0
|
|
|
2011
|
|
|
2012 (1500) :3 <- :1 plus :2, error exit on overflow
|
|
|
2013 (1509) :3 <- :1 plus :2
|
|
|
2014 :4 <- #1 if no overflow, else :4 <- #2
|
|
|
2015 (1510) :3 <- :1 minus :2, no action on overflow
|
|
|
2016 (1520) :1 <- .1 concatenated with .2
|
|
|
2017 (1525) This subroutine is intended solely for internal
|
|
|
2018 use within the subroutine library and is therefore
|
|
|
2019 not described here. Its effect is to shift .3
|
|
|
2020 logically 8 bits to the left.
|
|
|
2021 (1530) :1 <- .1 times .2
|
|
|
2022 (1540) :3 <- :1 times :2, error exit on overflow
|
|
|
2023 (1549) :3 <- :1 times :2
|
|
|
2024 :4 <- #1 if no overflow, else :4 <- #2
|
|
|
2025 (1550) :3 <- :1 divided by :2
|
|
|
2026 :3 <- #0 if :2 is #0
|
|
|
2027
|
|
|
2028 (1900) .1 <- uniform random no. from #0 to #65535
|
|
|
2029 (1910) .2 <- normal random no. from #0 to .1, with
|
|
|
2030 standard deviation .1 divided by #12
|
|
|
2031 .cs R
|
|
|
2032 .DE
|
|
|
2033 .if '\*c'y' \{\
|
|
|
2034 .H 2 "Automagical Inclusion Of The Subroutine Library"
|
|
|
2035 .P
|
|
|
2036 The C-INTERCAL compiler will automatically include the system library if a DO
|
|
|
2037 (1xxx) NEXT statement is used, and if no (1xxx) labels are defined anywhere,
|
|
|
2038 where (1xxx) is a label in the 1000-1999 range, inclusive. This was not
|
|
|
2039 an INTERCAL-72 feature. \}
|
|
|
2040 .H 1 "PROGRAMMING HINTS"
|
|
|
2041 .if '\*c'y' \{\
|
|
|
2042 .DS I F
|
|
|
2043 "If any one of them can explain it," said Alice, "I'll give him
|
|
|
2044 sixpence. \fII\fR don't believe there's an atom of meaning in it."
|
|
|
2045 The jury all wrote down, on their slates, "\fIShe\fR doesn't
|
|
|
2046 believe there's an atom of meaning in it," but none of them attempted
|
|
|
2047 to explain the paper.
|
|
|
2048 .P
|
|
|
2049 "If there's no meaning in it," said the King, "that saves a world of
|
|
|
2050 trouble, you know, as we needn't try to find any. And yet, I don't
|
|
|
2051 know," he went on, spreading out the verses on one knee, and looking
|
|
|
2052 at them with one eye: "I seem to see some meaning in them, after
|
|
|
2053 all...."
|
|
|
2054 .DE \}
|
|
|
2055 .SETR proghints
|
|
|
2056 .P
|
|
|
2057 For the user looking to become more familiar with the INTERCAL language, we
|
|
|
2058 present in this section an analysis of a complex program, as well as some
|
|
|
2059 suggested projects for the ambitious programmer.
|
|
|
2060 .P
|
|
|
2061 Considering the effort involved in writing an INTERCAL program, it was
|
|
|
2062 decided in putting together this manual to use an already existing program
|
|
|
2063 for instructive analysis. Since there was only one such program available,
|
|
|
2064 we have proceeded to use it. It is known as the "INTERCAL System Library."
|
|
|
2065 .H 2 "Description"
|
|
|
2066 .P
|
|
|
2067 .\" CORRECTION:
|
|
|
2068 .\" "is in section {section}" was "on the second page following"
|
|
|
2069 .\" We can't rely on the page breaks any more.
|
|
|
2070 The program listing is in section
|
|
|
2071 .GETHN syslib
|
|
|
2072 \&. It is in the same
|
|
|
2073 format as would be produced by the Princeton INTERCAL compiler in FORMAT
|
|
|
2074 mode with WIDTH=62 (see section
|
|
|
2075 .GETHN princeton
|
|
|
2076 ). For a description of the functions
|
|
|
2077 performed by the Library, see section
|
|
|
2078 .GETHN functions
|
|
|
2079 \&.
|
|
|
2080 .H 2 "Analysis"
|
|
|
2081 .P
|
|
|
2082 We shall not attempt to discuss here the algorithms used, but rather we
|
|
|
2083 shall point out some of the general techniques applicable to a wide range
|
|
|
2084 of problems.
|
|
|
2085 .P
|
|
|
2086 Statements 10, 14, 15, and 26 make up a virtual "computed GO TO". When
|
|
|
2087 statement 10 is executed, control passes eventually to statement 16 or 11,
|
|
|
2088 depending on whether .5 contains #1 or #2, respectively. The value of .5
|
|
|
2089 is determined in statement 9, which demonstrates another handy technique.
|
|
|
2090 To turn an expression, exp, with value #0 or #1, into #1 or #2 (for use in
|
|
|
2091 a "GO TO"), use "\*(vb'exp'\*(ct#1"~#3.
|
|
|
2092 To reverse the condition (i.e., convert #0
|
|
|
2093 to #2 and leave #1 alone) use "\*(vb'exp'\*(ct#2"~#3.
|
|
|
2094 .P
|
|
|
2095 Certain conditions are easily checked. For example, to test for zero,
|
|
|
2096 select the value from itself and select the bottom bit (see statement 54).
|
|
|
2097 To test for all bits being 1's, select the value from itself and select the
|
|
|
2098 top bit.
|
|
|
2099 .\" CORRECTION:
|
|
|
2100 .\" "statements 219 and 220" were "statement 192 and 193", but there
|
|
|
2101 .\" is no such test there.
|
|
|
2102 .\" Also, last sentence had parenthetical "(see statement 261)". Not
|
|
|
2103 .\" only does 261 contain no such test, the library as a whole doesn't
|
|
|
2104 .\" seem to either.
|
|
|
2105 The test for greater than, performed in
|
|
|
2106 statements 219 and 220 on 32-bit values, employs binary logical operations,
|
|
|
2107 which are performed as follows:
|
|
|
2108 .DS
|
|
|
2109 \&'\*(vb.1\*(ct.2'~'#0\*(ct#65535'
|
|
|
2110 .DE
|
|
|
2111 for 16-bit values or, for 32-bit values:
|
|
|
2112 .DS L
|
|
|
2113 "'\*(vb":1~'#65535\*(ct30'"\*(ct":2~'#65535\*(ct#0'"'~'#0
|
|
|
2114 \*(ct#65535'"\*(ct"'\*(vb":1~'#0\*(ct#65535'"\*(ct":2~'#0
|
|
|
2115 \*(ct#65535'"'~'#0\*(ct#65535'"
|
|
|
2116 .DE
|
|
|
2117 (The proofs are left as an exercise to the reader.)
|
|
|
2118 .P
|
|
|
2119 Testing for greater-than with 16-bit values is somewhat simpler and is done
|
|
|
2120 with the pair of statements:
|
|
|
2121 .DS L
|
|
|
2122 DO .C <- '\*(vb.A\*(ct.B'~'#0\*(ct#65535'
|
|
|
2123 DO .C <- '&"'.A~.C'~'"\*(vb'\*(vb.C~.C'\*(ct#32768"
|
|
|
2124 ~"#0\*(ct#65535"'"\*(ct".C~.C"'~#1
|
|
|
2125 .DE
|
|
|
2126 This sets .C (a dummy variable) to #1 if .A > .B, and #0 otherwise. The
|
|
|
2127 expression may be expanded as described above to instead set .C to #1 or
|
|
|
2128 #2.
|
|
|
2129 .P
|
|
|
2130 Note also in statement 220 the occurrence of ~"#65535\*(ct#65535". Although
|
|
|
2131 these operations select the entire value, they are not extraneous, as they
|
|
|
2132 ensure that the forthcoming \*(vbs will be operating on 32-bit values.
|
|
|
2133 .P
|
|
|
2134 In several virtual computed GO TOs the DO FORGET #1 (statement 15 in the
|
|
|
2135 earlier example) has been omitted, since the next transfer of control would
|
|
|
2136 be a DO RESUME #1. By making this a DO RESUME #2 instead, the FORGET may
|
|
|
2137 be forgotten.
|
|
|
2138 .P
|
|
|
2139 In statement 64, note that .2 is STASHed twice by a single statement. This
|
|
|
2140 is perfectly legal.
|
|
|
2141 .P
|
|
|
2142 Lastly, note in statements 243 and 214 respectively, expressions for
|
|
|
2143 shifting 16- and 32-bit variables logically one place to the left.
|
|
|
2144 Statement 231 demonstrates right-shifting for 32-bit variables.
|
|
|
2145 .bp
|
|
|
2146 .H 2 "Program Listing"
|
|
|
2147 .SETR syslib
|
|
|
2148 .DS L
|
|
|
2149 .cs R 24
|
|
|
2150 .\" CORRECTION:
|
|
|
2151 .\" This is the corrected system library, not the rather buggy original.
|
|
|
2152 .\" Can be semi-mechanically generated from the syslib.i file with
|
|
|
2153 .\" sed syslib.i -e 1d -e '/\$/s//\\*(ct/g' -e '/?/s//\\*(vb/g' | nl | expand
|
|
|
2154 \" but you have to
|
|
|
2155 .\" (a) restore the splat on line 13 DOUBLE OR SINGLE PRECISION OVERFLOW
|
|
|
2156 .\" (b) restore the splat on line 254 PLEASE NOTE ....
|
|
|
2157 .\" (c) appropriately conditionalize lines 289-294
|
|
|
2158 .\" (d) manually break lines where they wrap
|
|
|
2159 1 (1000) PLEASE IGNORE .4
|
|
|
2160 2 PLEASE ABSTAIN FROM (1005)
|
|
|
2161 3 (1009) DO STASH .1 + .2 + .5 + .6
|
|
|
2162 4 DO .4 <- #1
|
|
|
2163 5 DO (1004) NEXT
|
|
|
2164 6 (1004) PLEASE FORGET #1
|
|
|
2165 7 DO .3 <- '\*(vb.1\*(ct.2'~'#0\*(ct#65535'
|
|
|
2166 8 DO .6 <- '&.1\*(ct.2'~'#0\*(ct#65535'
|
|
|
2167 9 PLEASE DO .5 <- "\*(vb!6~#32768'\*(ct#1"~#3
|
|
|
2168 10 DO (1002) NEXT
|
|
|
2169 11 DO .4 <- #2
|
|
|
2170 12 (1005) DO (1006) NEXT
|
|
|
2171 * 13 (1999) DOUBLE OR SINGLE PRECISION OVERFLOW
|
|
|
2172 14 (1002) DO (1001) NEXT
|
|
|
2173 15 (1006) PLEASE FORGET #1
|
|
|
2174 16 DO .5 <- '\*(vb"!6~.6'~#1"\*(ct#1'~#3
|
|
|
2175 17 DO (1003) NEXT
|
|
|
2176 18 DO .1 <- .3
|
|
|
2177 19 DO .2 <- !6\*(ct#0'~'#32767\*(ct#1'
|
|
|
2178 20 DO (1004) NEXT
|
|
|
2179 21 (1003) DO (1001) NEXT
|
|
|
2180 22 DO REINSTATE (1005)
|
|
|
2181 23 (1007) PLEASE RETRIEVE .1 + .2 + .5 + .6
|
|
|
2182 24 DO REMEMBER .4
|
|
|
2183 25 PLEASE RESUME #2
|
|
|
2184 26 (1001) DO RESUME .5
|
|
|
2185 27 (1010) DO STASH .1 + .2 + .4
|
|
|
2186 28 DO .4 <- .1
|
|
|
2187 29 DO .1 <- '\*(vb.2\*(ct#65535'~'#0\*(ct#65535'
|
|
|
2188 30 DO (1020) NEXT
|
|
|
2189 31 PLEASE DO .2 <- .4
|
|
|
2190 32 PLEASE DO (1009) NEXT
|
|
|
2191 33 DO RETRIEVE .1 + .2 + .4
|
|
|
2192 34 PLEASE RESUME #1
|
|
|
2193 35 (1020) DO STASH .2 + .3
|
|
|
2194 36 DO .2 <- #1
|
|
|
2195 37 PLEASE DO (1021) NEXT
|
|
|
2196 38 (1021) DO FORGET #1
|
|
|
2197 39 DO .3 <- "\*(vb!1~.2'\*(ct#1"~#3
|
|
|
2198 40 PLEASE DO .1 <- '\*(vb.1\*(ct.2'~'#0\*(ct#65535'
|
|
|
2199 41 DO (1022) NEXT
|
|
|
2200 42 DO .2 <- !2\*(ct#0'~'#32767\*(ct#1'
|
|
|
2201 43 DO (1021) NEXT
|
|
|
2202 44 (1023) PLEASE RESUME .3
|
|
|
2203 45 (1022) DO (1023) NEXT
|
|
|
2204 46 PLEASE RETRIEVE .2 + .3
|
|
|
2205 47 PLEASE RESUME #2
|
|
|
2206 48 (1030) DO ABSTAIN FROM (1033)
|
|
|
2207 49 PLEASE ABSTAIN FROM (1032)
|
|
|
2208 50 (1039) DO STASH :1 + .5
|
|
|
2209 51 DO (1530) NEXT
|
|
|
2210 52 DO .3 <- :1~#65535
|
|
|
2211 53 PLEASE DO .5 <- :1~'#65280\*(ct#65280'
|
|
|
2212 54 DO .5 <- '\*(vb"!5~.5'~#1"\*(ct#1'~#3
|
|
|
2213 55 DO (1031) NEXT
|
|
|
2214 56 (1032) DO (1033) NEXT
|
|
|
2215 57 DO (1999) NEXT
|
|
|
2216 58 (1031) DO (1001) NEXT
|
|
|
2217 59 (1033) DO .4 <- .5
|
|
|
2218 60 DO REINSTATE (1032)
|
|
|
2219 61 PLEASE REINSTATE (1033)
|
|
|
2220 62 DO RETRIEVE :1 + .5
|
|
|
2221 63 PLEASE RESUME #2
|
|
|
2222 64 (1040) PLEASE STASH .1 + .2 + .2 + :1 + :2 + :3
|
|
|
2223 65 DO .2 <- #0
|
|
|
2224 66 DO (1520) NEXT
|
|
|
2225 67 DO STASH :1
|
|
|
2226 68 PLEASE RETRIEVE .2
|
|
|
2227 69 DO .1 <- .2
|
|
|
2228 70 DO .2 <- #0
|
|
|
2229 71 PLEASE DO (1520) NEXT
|
|
|
2230 72 DO :2 <- :1
|
|
|
2231 73 DO RETRIEVE .1 + .2 + :1
|
|
|
2232 74 DO (1550) NEXT
|
|
|
2233 75 PLEASE DO .3 <- :3
|
|
|
2234 76 DO RETRIEVE :1 + :2 + :3
|
|
|
2235 77 DO RESUME #1
|
|
|
2236 78 (1050) PLEASE STASH :2 + :3 + .5
|
|
|
2237 79 DO :2 <- .1
|
|
|
2238 80 PLEASE DO (1550) NEXT
|
|
|
2239 81 DO .5 <- :3~'#65280\*(ct#65280'
|
|
|
2240 82 DO .5 <- '\*(vb"!5~.5'~#1"\*(ct#1'~#3
|
|
|
2241 83 DO (1051) NEXT
|
|
|
2242 84 DO (1999) NEXT
|
|
|
2243 85 (1051) DO (1001) NEXT
|
|
|
2244 86 DO .2 <- :3
|
|
|
2245 87 PLEASE RETRIEVE :2 + :3 + .5
|
|
|
2246 88 DO RESUME #2
|
|
|
2247 89 (1500) PLEASE ABSTAIN FROM (1502)
|
|
|
2248 90 PLEASE ABSTAIN FROM (1506)
|
|
|
2249 91 (1509) PLEASE STASH :1 + .1 + .2 + .3 + .4 + .5 + .6
|
|
|
2250 92 DO .1 <- :1~#65535
|
|
|
2251 93 PLEASE DO .2 <- :2~#65535
|
|
|
2252 94 DO (1009) NEXT
|
|
|
2253 95 DO .5 <- .3
|
|
|
2254 96 PLEASE DO .6 <- .4
|
|
|
2255 97 DO .1 <- :1~'#65280\*(ct#65280'
|
|
|
2256 98 DO .2 <- :2~'#65280\*(ct#65280'
|
|
|
2257 99 DO (1009) NEXT
|
|
|
2258 100 DO .1 <- .3
|
|
|
2259 101 PLEASE DO (1503) NEXT
|
|
|
2260 102 DO .6 <- .4
|
|
|
2261 103 DO .2 <- #1
|
|
|
2262 104 DO (1009) NEXT
|
|
|
2263 105 DO .1 <- .3
|
|
|
2264 106 DO (1501) NEXT
|
|
|
2265 107 (1504) PLEASE RESUME .6
|
|
|
2266 108 (1503) DO (1504) NEXT
|
|
|
2267 109 (1501) DO .2 <- .5
|
|
|
2268 110 DO .5 <- '\*(vb"'&.6\*(ct.4'~#1"\*(ct#2'~#3
|
|
|
2269 111 DO (1505) NEXT
|
|
|
2270 112 (1506) DO (1502) NEXT
|
|
|
2271 113 PLEASE DO (1999) NEXT
|
|
|
2272 114 (1505) DO (1001) NEXT
|
|
|
2273 115 (1502) DO :4 <- .5
|
|
|
2274 116 DO (1520) NEXT
|
|
|
2275 117 DO :3 <- :1
|
|
|
2276 118 PLEASE RETRIEVE :1 + .1 + .2 + .3 + .4 + .5 + .6
|
|
|
2277 119 DO REINSTATE (1502)
|
|
|
2278 120 DO REINSTATE (1506)
|
|
|
2279 121 PLEASE RESUME #3
|
|
|
2280 122 (1510) DO STASH :1 + :2 + :4
|
|
|
2281 123 DO :1 <- "'\*(vb":2~'#65535\*(ct#0'"\*(ct#65535'
|
|
|
2282 ~'#0\*(ct#65535'"\*(ct"'\*(vb":2~'#0\*(ct#65535'
|
|
|
2283 "\*(ct#65535'~'#0\*(ct#65535'"
|
|
|
2284 124 DO :2 <- #1
|
|
|
2285 125 DO (1509) NEXT
|
|
|
2286 126 PLEASE RETRIEVE :1
|
|
|
2287 127 DO :2 <- :3
|
|
|
2288 128 PLEASE DO (1509) NEXT
|
|
|
2289 129 DO RETRIEVE :2 + :4
|
|
|
2290 130 PLEASE RESUME #1
|
|
|
2291 131 (1520) PLEASE STASH .3 + .4
|
|
|
2292 132 DO .3 <- .1~#43690
|
|
|
2293 133 DO (1525) NEXT
|
|
|
2294 134 PLEASE DO .4 <- 'V.3\*(ct".2~#43690"'~'#0\*(ct#65535'
|
|
|
2295 135 DO .3 <- .1~#21845
|
|
|
2296 136 PLEASE DO (1525) NEXT
|
|
|
2297 137 DO :1 <- .4\*(ct"'V.3\*(ct".2~#21845"'~'#0\*(ct#65535'"
|
|
|
2298 138 PLEASE RETRIEVE .3 + .4
|
|
|
2299 139 DO RESUME #1
|
|
|
2300 140 (1525) DO .3 <- '"'"'"!3\*(ct#0'~'#32767\*(ct#1'"\*(ct#0'
|
|
|
2301 ~'#32767\*(ct#1'"\*(ct#0'~'#16383\*(ct#3'"\*(ct#0'
|
|
|
2302 ~'#4095\*(ct#15'
|
|
|
2303 141 PLEASE RESUME #1
|
|
|
2304 142 (1530) DO STASH :2 + :3 + .3 + .5
|
|
|
2305 143 DO :1 <- #0
|
|
|
2306 144 DO :2 <- .2
|
|
|
2307 145 DO .3 <- #1
|
|
|
2308 146 DO (1535) NEXT
|
|
|
2309 147 (1535) PLEASE FORGET #1
|
|
|
2310 148 DO .5 <- "\*(vb!1~.3'\*(ct#1"~#3
|
|
|
2311 149 DO (1531) NEXT
|
|
|
2312 150 DO (1500) NEXT
|
|
|
2313 151 DO :1 <- :3
|
|
|
2314 152 PLEASE DO (1533) NEXT
|
|
|
2315 153 (1531) PLEASE DO (1001) NEXT
|
|
|
2316 154 (1533) DO FORGET #1
|
|
|
2317 155 DO .3 <- !3\*(ct#0'~'#32767\*(ct#1'
|
|
|
2318 156 DO :2 <- ":2~'#0\*(ct#65535'"\*(ct"'":2~'#32767
|
|
|
2319 \*(ct#0'"\*(ct#0'~'#32767\*(ct#1'"
|
|
|
2320 157 PLEASE DO .5 <- "\*(vb!3~.3'\*(ct#1"~#3
|
|
|
2321 158 DO (1532) NEXT
|
|
|
2322 159 DO (1535) NEXT
|
|
|
2323 160 (1532) DO (1001) NEXT
|
|
|
2324 161 PLEASE RETRIEVE :2 + :3 + .3 + .5
|
|
|
2325 162 DO RESUME #2
|
|
|
2326 163 (1540) PLEASE ABSTAIN FROM (1541)
|
|
|
2327 164 DO ABSTAIN FROM (1542)
|
|
|
2328 165 (1549) PLEASE STASH :1 + :2 + :4 + :5 + .1 + .2 + .5
|
|
|
2329 166 DO .1 <- :1~#65535
|
|
|
2330 167 PLEASE DO .2 <- :2~'#65280\*(ct#65280'
|
|
|
2331 168 DO .5 <- :1~'#65280\*(ct#65280'
|
|
|
2332 169 DO (1530) NEXT
|
|
|
2333 170 DO :3 <- :1
|
|
|
2334 171 DO .2 <- :2~#65535
|
|
|
2335 172 PLEASE DO (1530) NEXT
|
|
|
2336 173 DO :5 <- :1
|
|
|
2337 174 DO .1 <- .5
|
|
|
2338 175 DO (1530) NEXT
|
|
|
2339 176 DO :4 <- :1
|
|
|
2340 177 PLEASE DO :1 <- ":3~'#65280\*(ct#65280'"
|
|
|
2341 \*(ct":4~'#65280\*(ct#65280'"
|
|
|
2342 178 DO .5 <- ':1~:1'~#1
|
|
|
2343 179 DO .2 <- :2~'#65280\*(ct#65280'
|
|
|
2344 180 DO (1530) NEXT
|
|
|
2345 181 PLEASE DO .5 <- '"':1~:1'~#1"\*(ct.5'~#3
|
|
|
2346 182 DO .1 <- :3~#65535
|
|
|
2347 183 DO .2 <- #0
|
|
|
2348 184 DO (1520) NEXT
|
|
|
2349 185 PLEASE DO :2 <- :1
|
|
|
2350 186 PLEASE DO .1 <- :4~#65535
|
|
|
2351 187 DO (1520) NEXT
|
|
|
2352 188 DO (1509) NEXT
|
|
|
2353 189 DO .5 <- !5\*(ct":4~#3"'~#15
|
|
|
2354 190 DO :1 <- :3
|
|
|
2355 191 DO :2 <- :5
|
|
|
2356 192 DO (1509) NEXT
|
|
|
2357 193 PLEASE DO .5 <- !5\*(ct":4~#3"'~#172
|
|
|
2358 194 DO .5 <- '\*(vb"!5~.5'~#1"\*(ct#1'~#3
|
|
|
2359 195 PLEASE RETRIEVE :4
|
|
|
2360 196 (1541) DO :4 <- .5
|
|
|
2361 197 DO (1543) NEXT
|
|
|
2362 198 (1542) DO (1544) NEXT
|
|
|
2363 199 PLEASE DO (1999) NEXT
|
|
|
2364 200 (1543) DO (1001) NEXT
|
|
|
2365 201 (1544) DO REINSTATE (1541)
|
|
|
2366 202 PLEASE REINSTATE (1542)
|
|
|
2367 203 PLEASE RETRIEVE :1 + :2 + :5 + .1 + .2 + .5
|
|
|
2368 204 DO RESUME #2
|
|
|
2369 205 (1550) DO STASH :1 + :4 + :5 + .5
|
|
|
2370 206 DO :3 <- #0
|
|
|
2371 207 DO .5 <- '\*(vb"':2~:2'~#1"\*(ct#1'~#3
|
|
|
2372 208 PLEASE DO (1551) NEXT
|
|
|
2373 209 DO :4 <- #1
|
|
|
2374 210 PLEASE DO (1553) NEXT
|
|
|
2375 211 (1553) DO FORGET #1
|
|
|
2376 212 DO .5 <- '\*(vb":2~'#32768\*(ct#0'"\*(ct#2'~#3
|
|
|
2377 213 DO (1552) NEXT
|
|
|
2378 214 DO :2 <- ":2~'#0\*(ct#65535'"\*(ct"'":2~'#32767
|
|
|
2379 \*(ct#0'"\*(ct#0'~'#32767\*(ct#1'"
|
|
|
2380 215 PLEASE DO :4 <- ":4~'#0\*(ct#65535'"\*(ct"'":4
|
|
|
2381 ~'#32767\*(ct#0'"\*(ct#0'~'#32767\*(ct#1'"
|
|
|
2382 216 DO (1553) NEXT
|
|
|
2383 217 (1552) DO (1001) NEXT
|
|
|
2384 218 (1556) PLEASE FORGET #1
|
|
|
2385 219 DO :5 <- "'\*(vb":1~'#65535\*(ct#0'"\*(ct":2
|
|
|
2386 ~'#65535\*(ct#0'"'~'#0\*(ct#65535'"\*(ct"'
|
|
|
2387 \*(vb":1~'#0\*(ct#65535'"\*(ct":2~'#0\*(ct
|
|
|
2388 #65535'"'~'#0\*(ct#65535'"
|
|
|
2389 220 DO .5 <- '\*(vb"'&"':2~:5'~'"'\*(vb"'\*(vb":5~:5
|
|
|
2390 "~"#65535\*(ct#65535"'~'#65535\*(ct#0'"\*(ct
|
|
|
2391 #32768'~'#0\*(ct#65535'"\*(ct"'\*(vb":5~:5"
|
|
|
2392 ~"#65535\*(ct#65535"'~'#0\*(ct#65535'"'"\*(ct"'
|
|
|
2393 :5~:5'~#1"'~#1"\*(ct#2'~#3
|
|
|
2394 221 DO (1554) NEXT
|
|
|
2395 222 DO :5 <- :3
|
|
|
2396 223 DO (1510) NEXT
|
|
|
2397 224 PLEASE DO :1 <- :3
|
|
|
2398 225 DO :3 <- "'V":4~'#65535\*(ct#0'"\*(ct":5~'#65535
|
|
|
2399 \*(ct#0'"'~'#0\*(ct#65535'"\*(ct"'V":4~'#0
|
|
|
2400 \*(ct#65535'"\*(ct":5~'#0\*(ct#65535'"'~'#0
|
|
|
2401 \*(ct#65535'"
|
|
|
2402 226 DO (1555) NEXT
|
|
|
2403 227 (1554) PLEASE DO (1001) NEXT
|
|
|
2404 228 (1555) DO FORGET #1
|
|
|
2405 229 DO .5 <- "\*(vb':4~#1'\*(ct#2"~#3
|
|
|
2406 230 DO (1551) NEXT
|
|
|
2407 231 DO :2 <- ":2~'#0\*(ct#65534'"\*(ct":2~'#65535\*(ct#0'"
|
|
|
2408 232 DO :4 <- ":4~'#0\*(ct#65534'"\*(ct":4~'#65535\*(ct#0'"
|
|
|
2409 233 PLEASE DO (1556) NEXT
|
|
|
2410 234 (1551) DO (1001) NEXT
|
|
|
2411 235 PLEASE RETRIEVE :1 + :4 + :5 + .5
|
|
|
2412 236 PLEASE RESUME #2
|
|
|
2413 237 (1900) DO STASH .2 + .3 + .5
|
|
|
2414 238 DO .1 <- #0
|
|
|
2415 239 DO .2 <- #1
|
|
|
2416 240 PLEASE DO (1901) NEXT
|
|
|
2417 241 (1901) DO FORGET #1
|
|
|
2418 242 DO %50 .1 <- 'V.1\*(ct.2'~'#0\*(ct#65535'
|
|
|
2419 243 DO .2 <- !2\*(ct#0'~'#32767\*(ct#1'
|
|
|
2420 244 PLEASE DO .5 <- "\*(vb!2~.2'\*(ct#1"~#3
|
|
|
2421 245 DO (1902) NEXT
|
|
|
2422 246 DO (1901) NEXT
|
|
|
2423 247 (1902) DO (1001) NEXT
|
|
|
2424 248 DO RETRIEVE .2 + .3 + .5
|
|
|
2425 249 PLEASE RESUME #2
|
|
|
2426 250 (1910) PLEASE STASH .1 + .3 + .5 + :1 + :2 + :3
|
|
|
2427 251 DO .3 <- #65524
|
|
|
2428 252 DO :1 <- #6
|
|
|
2429 253 DO (1911) NEXT
|
|
|
2430 * 254 PLEASE NOTE THAT YOU CAN'T GET THERE FROM HERE
|
|
|
2431 255 (1912) DO (1001) NEXT
|
|
|
2432 256 (1911) DO FORGET #1
|
|
|
2433 257 PLEASE DO (1900) NEXT
|
|
|
2434 258 DO :2 <- .1
|
|
|
2435 259 DO (1500) NEXT
|
|
|
2436 260 PLEASE DO :1 <- :3
|
|
|
2437 261 DO .1 <- .3
|
|
|
2438 262 DO (1020) NEXT
|
|
|
2439 263 PLEASE DO .3 <- .1
|
|
|
2440 264 DO .5 <- '\*(vb"!3~.3'~#1"\*(ct#2'~#3
|
|
|
2441 265 DO (1912) NEXT
|
|
|
2442 266 DO .1 <- #12
|
|
|
2443 267 PLEASE DO (1050) NEXT
|
|
|
2444 268 DO RETRIEVE .1
|
|
|
2445 269 DO (1530) NEXT
|
|
|
2446 270 DO :2 <- #32768
|
|
|
2447 271 DO (1500) NEXT
|
|
|
2448 272 PLEASE DO .2 <- :3~'#65280\*(ct#65280'
|
|
|
2449 273 PLEASE RETRIEVE .3 + .5 + :1 + :2 + :3
|
|
|
2450 274 DO RESUME #1
|
|
|
2451 .cs R
|
|
|
2452 .DE
|
|
|
2453 .bp
|
|
|
2454 .H 2 "Programming Suggestions"
|
|
|
2455 .P
|
|
|
2456 For the novice INTERCAL programmer, we provide here a list of suggested
|
|
|
2457 INTERCAL programming projects:
|
|
|
2458 .P
|
|
|
2459 Write an integer exponentiation subroutine. :1 <- .1 raised to the .2 power.
|
|
|
2460 .P
|
|
|
2461 Write a double-precision sorting subroutine. Given 32-bit array ;1 of size
|
|
|
2462 :1, sort the contents into numerically increasing order, leaving the results
|
|
|
2463 in ;1.
|
|
|
2464 .P
|
|
|
2465 Generate a table of prime numbers.
|
|
|
2466 .P
|
|
|
2467 Put together a floating-point library, using 32-bit variables to represent
|
|
|
2468 floating-point numbers (let the upper half be the mantissa and the lower
|
|
|
2469 half be the characteristic). The library should be capable of performing
|
|
|
2470 floating-point addition, subtraction, multiplication, and division, as well
|
|
|
2471 as the natural logarithm function.
|
|
|
2472 .P
|
|
|
2473 Program a Fast Fourier Transform (FFT). This project would probably entail
|
|
|
2474 the writing of the floating-point library as well as sine and cosine functions.
|
|
|
2475 .P
|
|
|
2476 Calculate, to :1 places, the value of pi.
|
|
|
2477 .if '\*c'y' \{\
|
|
|
2478 .P
|
|
|
2479 (Working programs for each of these projects are included in the
|
|
|
2480 C-INTERCAL distribution's pit directory of sample code.) \}
|
|
|
2481 .bp
|
|
|
2482 .H 1 "ERROR MESSAGES"
|
|
|
2483 .if '\*c'y' \{\
|
|
|
2484 .DS I F
|
|
|
2485 Alice felt dreadfully puzzled. The Hatter's remark seemed to her to
|
|
|
2486 have no sort of meaning in it, and yet it was certainly English. "I
|
|
|
2487 don't quite understand you," she said, as politely as she could.
|
|
|
2488 .DE \}
|
|
|
2489 .SETR error_messages
|
|
|
2490 .P
|
|
|
2491 Due to INTERCAL's implementation of comment lines (see section 4.5), most
|
|
|
2492 error messages are produced during execution instead of during compilation.
|
|
|
2493 All errors except those not causing immediate termination of program execution
|
|
|
2494 are treated as fatal.
|
|
|
2495 .H 2 "Format"
|
|
|
2496 .P
|
|
|
2497 All error messages appear in the following form:
|
|
|
2498 .DS L
|
|
|
2499 ICLnnnI (error message)
|
|
|
2500 ON THE WAY TO STATEMENT nnnn
|
|
|
2501 CORRECT SOURCE AND RESUBMIT
|
|
|
2502 .DE
|
|
|
2503 The message varies depending upon the error involved. For undecodable
|
|
|
2504 statements the message is the statement itself. The second line tells
|
|
|
2505 which statement would have been executed next had the error not occurred.
|
|
|
2506 Note that if the error is due to 80 attempted levels of NEXTing, the
|
|
|
2507 statement which would have been executed next need not be anywhere near the
|
|
|
2508 statement causing the error.
|
|
|
2509 .H 2 "Messages"
|
|
|
2510 .P
|
|
|
2511 Brief descriptions of the different error types are listed below according
|
|
|
2512 to message number.
|
|
|
2513 .BL
|
|
|
2514 .LI 000
|
|
|
2515 An undecodable statement has been encountered in the course of
|
|
|
2516 execution. Note that keypunching errors can be slightly disastrous,
|
|
|
2517 since if 'FORGET' were misspelled F-O-R-G-E-R, the results would
|
|
|
2518 probably not be those desired. Extreme misspellings may have even
|
|
|
2519 more surprising consequences. For example, misspelling 'FORGET'
|
|
|
2520 R-E-S-U-M-E could have drastic results.
|
|
|
2521 .LI 017
|
|
|
2522 An expression contains a syntax error.
|
|
|
2523 .LI 079
|
|
|
2524 Improper use has been made of statement identifiers.
|
|
|
2525 .LI 099
|
|
|
2526 Improper use has been made of statement identifiers.
|
|
|
2527 .LI 123
|
|
|
2528 Program has attempted 80 levels of NEXTing.
|
|
|
2529 .LI 129
|
|
|
2530 Program has attempted to transfer to a non-existent line label.
|
|
|
2531 .LI 139
|
|
|
2532 An ABSTAIN or REINSTATE statement references a non-existent line label.
|
|
|
2533 .LI 182
|
|
|
2534 A line label has been multiply defined.
|
|
|
2535 .LI 197
|
|
|
2536 An invalid line label has been encountered.
|
|
|
2537 .LI 200
|
|
|
2538 An expression involves an unidentified variable.
|
|
|
2539 .LI 240
|
|
|
2540 An attempt has been made to give an array a dimension of zero.
|
|
|
2541 .LI 241
|
|
|
2542 Invalid dimensioning information was supplied in defining or using
|
|
|
2543 an array.
|
|
|
2544 .LI 275
|
|
|
2545 A 32-bit value has been assigned to a 16-bit variable.
|
|
|
2546 .LI 436
|
|
|
2547 A retrieval has been attempted for an unSTASHed value.
|
|
|
2548 .LI 533
|
|
|
2549 A WRITE IN statement or interleave (\*(ct) operation has produced a
|
|
|
2550 value requiring over 32 bits to represent.
|
|
|
2551 .LI 562
|
|
|
2552 Insufficient data.
|
|
|
2553 .LI 579
|
|
|
2554 Input data is invalid.
|
|
|
2555 .LI 621
|
|
|
2556 The expression of a RESUME statement evaluated to #0.
|
|
|
2557 .LI 632
|
|
|
2558 Program execution was terminated via a RESUME statement instead of
|
|
|
2559 GIVE UP.
|
|
|
2560 .LI 633
|
|
|
2561 Execution has passed beyond the last statement of the program.
|
|
|
2562 .LI 774
|
|
|
2563 A compiler error has occurred (see section
|
|
|
2564 .GETHN princeton
|
|
|
2565 ).
|
|
|
2566 .LI 778
|
|
|
2567 .ie '\*c'n' \{\
|
|
|
2568 An unexplainable compiler error has occurred (see J. Lyon or D. Woods)\}.
|
|
|
2569 .el An unexplainable compiler error has occurred.
|
|
|
2570 .LE
|
|
|
2571 .if '\*c'y' \{\
|
|
|
2572 .P
|
|
|
2573 The following error codes are new in C-INTERCAL:
|
|
|
2574 .BL
|
|
|
2575 .LI 111
|
|
|
2576 You tried to use a C-INTERCAL extension with the `traditional' flag on.
|
|
|
2577 .LI 127
|
|
|
2578 Can't find syslib.i file when it's needed for magical inclusion.
|
|
|
2579 .LI 222
|
|
|
2580 Out of stash space, or attempt to stash an undeclared array.
|
|
|
2581 .LI 333
|
|
|
2582 Too many variables.
|
|
|
2583 .LI 444
|
|
|
2584 A COME FROM statement references a non-existent line label.
|
|
|
2585 .LI 555
|
|
|
2586 More than one COME FROM references the same label.
|
|
|
2587 .LI 666
|
|
|
2588 Too many source lines.
|
|
|
2589 .LI 777
|
|
|
2590 No such source file.
|
|
|
2591 .LI 888
|
|
|
2592 Can't open C output file.
|
|
|
2593 .LI 999
|
|
|
2594 Can't open C skeleton file.
|
|
|
2595 .LI 998
|
|
|
2596 Source file name with invalid extension (use .i or .[2-7]i).
|
|
|
2597 .LI 997
|
|
|
2598 Illegal possession of a controlled unary operator.
|
|
|
2599 .LE \}
|
|
|
2600 .if '\*c'y' \{\
|
|
|
2601 .H 1 "The C-INTERCAL Compiler"
|
|
|
2602 .if '\*c'y' \{\
|
|
|
2603 .DS I F
|
|
|
2604 "And yet it was a very clever pudding to invent."
|
|
|
2605 .P
|
|
|
2606 "What did you mean it to be made of?" Alice asked, hoping to cheer him
|
|
|
2607 up, for the poor Knight seemed quite low-spirited about it.
|
|
|
2608 .P
|
|
|
2609 "It began with blotting-paper," the Knight answered with a groan.
|
|
|
2610 .P
|
|
|
2611 "That wouldn't be very nice, I'm afraid --"
|
|
|
2612 .P
|
|
|
2613 "Not very nice \fIalone\fR," he interrupted, quite eagerly, "but
|
|
|
2614 you've no idea what a difference it makes, mixing it with other
|
|
|
2615 things -- such as gunpowder and sealing-wax."
|
|
|
2616 .DE \}
|
|
|
2617 .P
|
|
|
2618 This section describes the use of ick, the C-INTERCAL
|
|
|
2619 compiler. Information specific to the other known INTERCAL compilers
|
|
|
2620 appears in the following sections. These sections are less useful,
|
|
|
2621 since the other compilers are no longer available, but they are
|
|
|
2622 retained to provide a sense of history, and because any information
|
|
|
2623 regarding INTERCAL is really too scarce to discard.
|
|
|
2624 .H 2 "Character Set"
|
|
|
2625 .P
|
|
|
2626 The C-INTERCAL compiler uses ASCII rather than EBCDIC. We follow the
|
|
|
2627 Atari implementation (see section
|
|
|
2628 .GETHN atari
|
|
|
2629 ) by (a) replacing the change sign (\*(ct) with
|
|
|
2630 big money ($) as the mingle operator, and (b) replacing the
|
|
|
2631 bookworm (\*(vb) symbol with what (?) as the XOR operator.
|
|
|
2632 .P
|
|
|
2633 Version 0.18 and later versions accept the Latin-1 (ISO 8859-1)
|
|
|
2634 character set, which is a superset of ASCII. As a result,
|
|
|
2635 0xA2 (\*(ct), 0xA3 (quid), and 0xA4 (zlotnik) are accepted as mingle
|
|
|
2636 operators.
|
|
|
2637 .P
|
|
|
2638 Version 0.20 and later versions also accept UTF-8 as an alternative
|
|
|
2639 to Latin-1. The above three currency operators will be accepted in
|
|
|
2640 either Latin-1 or UTF-8 format. UTF-8 format is required if you
|
|
|
2641 wish to use any of EURO-CURRENCY SIGN, COLON SIGN (that's Costa Rican dinero,
|
|
|
2642 not the Intercal two-spot),
|
|
|
2643 CRUZEIRO SIGN, FRENCH FRANC SIGN, LIRA SIGN, MILL SIGN, NAIRA SIGN,
|
|
|
2644 PESETA SIGN, RUPEE SIGN, WON SIGN, NEW SHEQEL SIGN, DONG SIGN, EURO SIGN,
|
|
|
2645 BENGALI RUPEE MARK, BENGALI RUPEE SIGN, or THAI CURRENCY SYMBOL BAHT.
|
|
|
2646 (Isn't internationalization wonderful?)
|
|
|
2647 Furthermore, you can use the Intercal character FOR ALL to represent
|
|
|
2648 the what operator.
|
|
|
2649 .H 2 "Usage and Compilation Options"
|
|
|
2650 .P
|
|
|
2651 To compile an INTERCAL program `foo.i' to executable code, just do
|
|
|
2652
|
|
|
2653 ick foo.i
|
|
|
2654
|
|
|
2655 There's a -c option that leaves the generated C code in place for
|
|
|
2656 inspection (suppressing compilation to machine code), a -d option that
|
|
|
2657 enables verbose parse reporting from the yacc/bison parser, a -t
|
|
|
2658 option that requires strict INTERCAL-72 compliance (rejecting COME
|
|
|
2659 FROM and the extensions for bases other than two), a -b option that
|
|
|
2660 disables the INTERCAL-72 random-bug feature (error 774), and an -O option
|
|
|
2661 that enables the (hah!) optimizer. Invoking ick -? prints a usage
|
|
|
2662 message.
|
|
|
2663 .P
|
|
|
2664 Another compilation switch affects C-INTERCAL's runtime behavior. The `-C'
|
|
|
2665 option forces output in "clockface" mode, for superstitious users who
|
|
|
2666 believe writing "IV" upside-down offends IVPITER and would rather
|
|
|
2667 see IIII.
|
|
|
2668 .H 2 "Runtime Options"
|
|
|
2669 .P
|
|
|
2670 Every C-INTERCAL runtime also accepts certain options at runtime.
|
|
|
2671 These include [+/-]help, [+/-]traditional, and [+/-]wimpmode.
|
|
|
2672 The help option (with either + or -) triggers a 'usage' message. The
|
|
|
2673 +traditional option is presently a no-op.
|
|
|
2674 .P
|
|
|
2675 Steve explains: "The wimpmode option is the most interesting. I found
|
|
|
2676 myself always running my test programs with filters on both ends to
|
|
|
2677 work around the \&'nifty' INTERCAL number representations. This was so
|
|
|
2678 painful that I decided it would be \fIless\fR painful (and a lot less
|
|
|
2679 code) if I added a 'wimp' option. With the +wimpmode option, the user
|
|
|
2680 is subjected to a humiliating message about what a wimp he or she is
|
|
|
2681 to use this mode, but after that is allowed to use conventional
|
|
|
2682 numerical notation. While such a mode doubtless violates to some
|
|
|
2683 extent the INTERCAL philosophy, the fact that an 'unbutcher' command
|
|
|
2684 has been posted clearly indicates the need for it. Anyway ... if you
|
|
|
2685 don't like it, don't use it ... the default is -wimpmode
|
|
|
2686 (i.e. \fInot\fR wimp mode)."
|
|
|
2687 .H 2 "PLEASE Politesse Checking"
|
|
|
2688 .P
|
|
|
2689 A feature of INTERCAL-72 not documented in the original manual was that it
|
|
|
2690 required a certain level of politesse from the programmer. If fewer than
|
|
|
2691 1/5th of the program statements included the PLEASE qualifier, the program
|
|
|
2692 would be rejected as insufficiently polite. If more than 1/3rd of them
|
|
|
2693 included PLEASE, the program would be rejected as excessively polite.
|
|
|
2694 .P
|
|
|
2695 This check has been implemented in C-INTERCAL. To assist programmers in
|
|
|
2696 coping with it, the intercal.el mode included with the distribution randomly
|
|
|
2697 expands "do " in entered source to "PLEASE DO" 1/4th of the time.
|
|
|
2698 .H 2 "Localization: Ancient Roman"
|
|
|
2699 Version 0.18 and later versions of C-Intercal have been
|
|
|
2700 localized for Ancient Roman as well as English-speaking locales.
|
|
|
2701 This means that Latin-language keywords are accepted as equivalents
|
|
|
2702 for the English-based ones traditionally used.
|
|
|
2703 See src/lexer.l for details, as we do not propose to break
|
|
|
2704 Priscian's head (publicly expose our ignorance of Latin) here. \}
|
|
|
2705 .if '\*c'y' \{\
|
|
|
2706 .\" This is the same text as the ATARI NOTES at the end of the manual.
|
|
|
2707 .H 1 "The Atari Implementation"
|
|
|
2708 .if '\*c'y' \{\
|
|
|
2709 .DS I F
|
|
|
2710 "Perhaps it doesn't understand English," thought Alice. "I daresay
|
|
|
2711 it's a French mouse, come over with William the Conqueror." (For, with
|
|
|
2712 all her knowledge of history, Alice had no very clear notion how long
|
|
|
2713 ago anything had happened.)
|
|
|
2714 .DE \}
|
|
|
2715 .SETR atari
|
|
|
2716 .P
|
|
|
2717 The Atari implementation of INTERCAL differs from the original Princeton
|
|
|
2718 version primarily in the use of ASCII rather than EBCDIC. Since there is no
|
|
|
2719 "change" sign (\*(ct) in ASCII, we have substituted the "big money" ($) as the
|
|
|
2720 mingle operator. We feel that this correctly represents the increasing cost
|
|
|
2721 of software in relation to hardware. (Consider that in 1970 one could get
|
|
|
2722 RUNOFF for free, to run on a $20K machine, whereas today a not quite as
|
|
|
2723 powerful formatter costs $99 and runs on a $75 machine.) We also feel that
|
|
|
2724 there should be no defensible contention that INTERCAL has any sense.
|
|
|
2725 Also, since overpunches are difficult to read on the average VDT, the
|
|
|
2726 exclusive-or operator may be written ?. This correctly expresses the
|
|
|
2727 average person's reaction on first encountering exclusive-or, especially on
|
|
|
2728 a PDP-11. Note that in both of these cases, the over-punched symbol may
|
|
|
2729 also be used if one is masochistic, or concerned with portability to the
|
|
|
2730 Princeton compiler. The correct over-punch for "change" is "c<backspace>/"
|
|
|
2731 and the correct over-punch for \*(vb is "V<backspace>-". These codes will be
|
|
|
2732 properly printed if you have a proper printer, and the corresponding EBCDIC
|
|
|
2733 code will be produced by the /IBM option on the LIST command. \}
|
|
|
2734 .if '\*c'n' \{\
|
|
|
2735 .H 1 "JCL"
|
|
|
2736 .SETR princeton
|
|
|
2737 .P
|
|
|
2738 The information contained in the following section applies
|
|
|
2739 only to the Princeton compiler, run under OS/360.
|
|
|
2740 .H 2 "The Princeton Compiler" \}
|
|
|
2741 .if '\*c'y' \{\
|
|
|
2742 .H 1 "The Princeton Compiler"
|
|
|
2743 .DS I F
|
|
|
2744 "My name is Alice, so please your Majesty," said Alice very politely;
|
|
|
2745 but she added, to herself, "Why, they're only a pack of cards, after
|
|
|
2746 all. I needn't be afraid of them!"
|
|
|
2747 .DE \}
|
|
|
2748 .SETR princeton
|
|
|
2749 .P
|
|
|
2750 The Princeton compiler, written in SPITBOL (a variant of
|
|
|
2751 SNOBOL), performs the compilation in two stages. First the
|
|
|
2752 INTERCAL source is converted into SPITBOL source, then the
|
|
|
2753 latter is compiled and executed.
|
|
|
2754 .P
|
|
|
2755 It should be noted that the Princeton compiler fails to
|
|
|
2756 properly interpret certain multiply-subscripted expressions,
|
|
|
2757 such as:
|
|
|
2758 .DS
|
|
|
2759 ",1SUB",2SUB#1"#2"
|
|
|
2760 .DE
|
|
|
2761 .P
|
|
|
2762 This is not a "bug". Being documented, it is merely a
|
|
|
2763 "restriction". Such cases may be resolved by alternating
|
|
|
2764 sparks and ears in various levels of expression nesting:
|
|
|
2765 .DS
|
|
|
2766 ",1SUB',2SUB#1'#2"
|
|
|
2767 .DE
|
|
|
2768 which is advisable in any case, since INTERCAL expressions
|
|
|
2769 are unreadable enough as is.
|
|
|
2770 .P
|
|
|
2771 Since there is currently no catalogued procedure for
|
|
|
2772 invoking the compiler, the user must include the in-line
|
|
|
2773 .\" CORRECTION:
|
|
|
2774 .\" "in Figure 3" was "on the following page"
|
|
|
2775 procedure shown in Figure 3 in his job before the
|
|
|
2776 compilation step. Copies of this in-line procedure may be
|
|
|
2777 obtained at any keypunch if the proper keys are struck.
|
|
|
2778 .P
|
|
|
2779 The compiler is then executed in the usual manner:
|
|
|
2780 .DS L
|
|
|
2781
|
|
|
2782 // EXEC INTERCAL[,PARM='parameters']
|
|
|
2783 //COMPILE.SYSIN DD *
|
|
|
2784 {INTERCAL source deck}
|
|
|
2785 /*
|
|
|
2786 //EXECUTE.SYSWRITE DD *
|
|
|
2787 {input data}
|
|
|
2788 /*
|
|
|
2789
|
|
|
2790 .DE
|
|
|
2791 The various parameters are described following the in-line
|
|
|
2792 procedure. At most one parameter from each set may apply to
|
|
|
2793 a given compilation; if more than one are specified, the
|
|
|
2794 results are undefined, and may vary depending upon the
|
|
|
2795 particular set of options. The default parameters are
|
|
|
2796 .if n \{\
|
|
|
2797 underlined.\}
|
|
|
2798 .if t \{\
|
|
|
2799 italicized.\}
|
|
|
2800 .\" CORRECTION:
|
|
|
2801 .\" In the original, the footnote was on the wrong line (one above).
|
|
|
2802 .DS L
|
|
|
2803 //INTERCAL PROC
|
|
|
2804 //COMPILE EXEC PGM=INTERCAL
|
|
|
2805 //STEPLIB DD DSN=U.INTERCAL.LIBRARY,DISP=SHR
|
|
|
2806 // DD DSN=SYS1.FORTLIB,DISP=SHR
|
|
|
2807 //SYSPRINT DD SYSOUT=A,DCB=(BLKSIZE=992,LRECL=137,RECFM=VBA)
|
|
|
2808 //SYSPUNCH DD DUMMY
|
|
|
2809 //SCRATCH DD DSN=&COMPSET,UNIT=SYSDA,SPACE=(CYL,(3,1)),DISP=(,PASS)
|
|
|
2810 //EXECUTE EXEC PGM=EXECUTE,COND=(4,LT)
|
|
|
2811 //SOURCES DD DSN=U.INTERCAL.SOURCES,DISP=SHR \*F
|
|
|
2812 //STEPLIB DD DSN=U.INTERCAL.LIBRARY,DISP=SHR
|
|
|
2813 // DD DSN=SYS5.SPITLIB,DISP=SHR
|
|
|
2814 // DD DSN=SYS1.FORTLIB,DISP=SHR
|
|
|
2815 //SYSIN DD DSN=&COMPSET,DISP=(OLD,DELETE)
|
|
|
2816 //SYSOBJ DD SYSOUT=B,DCB=(BLKSIZE=80,LRECL=80,RECFM=F)
|
|
|
2817 //SYSPRINT DD SYSOUT=A,DCB=(BLKSIZE=992,LRECL=137,RECFM=VBA)
|
|
|
2818 //SYSPUNCH DD DUMMY
|
|
|
2819 // PEND
|
|
|
2820 .DE
|
|
|
2821 .FS
|
|
|
2822 Pending acquisition of SPITBOL release 3.0, the SOURCES
|
|
|
2823 DD card must be replaced by the five cards:
|
|
|
2824 .DS L
|
|
|
2825 //NOOPTPFX DD DSN=U.INTERCAL.SOURCES(NOOPTPFX),DISP=SHR
|
|
|
2826 //NOOPTSUB DD DSN=U.INTERCAL.SOURCES(NOOPTSUB),DISP=SHR
|
|
|
2827 //OPTPFX DD DSN=U.INTERCAL.SOURCES(OPTPFX),DISP=SHR
|
|
|
2828 //OPTSUB DD DSN=U.INTERCAL.SOURCES(OPTSUB),DISP=SHR
|
|
|
2829 //PRELIM DD DSN=U.INTERCAL.SOURCES(PRELIM),DISP=SHR
|
|
|
2830 .DE
|
|
|
2831 .FE
|
|
|
2832 .ce 1
|
|
|
2833 Figure 3. Inline procedure for using INTERCAL.
|
|
|
2834 .P
|
|
|
2835 .LB 5 0 " " 0 * 0 0
|
|
|
2836 .LI "\fIOPT\fR"
|
|
|
2837 .LI "NOOPT"
|
|
|
2838 .LI " "
|
|
|
2839 In the default mode, the compiler will print a
|
|
|
2840 list of all options in effect, including the
|
|
|
2841 defaults for unspecified parameter groups and the
|
|
|
2842 effective option for those sets where one was
|
|
|
2843 specified. If NOOPT is requested, it causes the
|
|
|
2844 default mode to be assumed.
|
|
|
2845
|
|
|
2846 .LI "\fIOPTSUB\fR"
|
|
|
2847 .LI "NOOPTSUB"
|
|
|
2848 .LI "NOSUB"
|
|
|
2849 .LI " "
|
|
|
2850 Unless 'NOOPTSUB' is requested, the System Library
|
|
|
2851 is optimized, resulting in much more rapid
|
|
|
2852 processing of function calls. Specifying NOOPTSUB
|
|
|
2853 causes the non-optimized INTERCAL code shown in section
|
|
|
2854 .GETHN syslib
|
|
|
2855 to be used, whereas NOSUB requests
|
|
|
2856 that the System Library be omitted altogether.
|
|
|
2857
|
|
|
2858 .LI IAMBIC
|
|
|
2859 .LI "\fIPROSE\fR"
|
|
|
2860 .LI " "
|
|
|
2861 The IAMBIC parameter permits the programmer to use
|
|
|
2862 poetic license and thus write in verse. If the
|
|
|
2863 reader does not believe it possible to write verse
|
|
|
2864 in INTERCAL, he should send the authors a stamped,
|
|
|
2865 self-addressed envelope, along with any INTERCAL
|
|
|
2866 program, and they will provide one which is verse.
|
|
|
2867
|
|
|
2868 .LI "\fIFORMAT\fR"
|
|
|
2869 .LI NOFORMAT
|
|
|
2870 .LI " "
|
|
|
2871 In FORMAT mode, each statement printed is put on a
|
|
|
2872 separate line (or lines). In NOFORMAT mode, the
|
|
|
2873 free-format source is printed exactly as input.
|
|
|
2874 In this latter case, statement numbers are
|
|
|
2875 provided only for the first statement on a card,
|
|
|
2876 and they may be only approximate. Also,
|
|
|
2877 unrecognizable statements are not flagged.
|
|
|
2878
|
|
|
2879 .LI SEQ
|
|
|
2880 .LI "\fINOSEQ\fR"
|
|
|
2881 .LI " "
|
|
|
2882 If the source deck has sequence numbers in columns
|
|
|
2883 73 through 80, specifying 'SEQ' will cause them to
|
|
|
2884 be ignored.
|
|
|
2885
|
|
|
2886 .LI "SOURCE"
|
|
|
2887 .LI "\fINOSOURCE\fR"
|
|
|
2888 .LI " "
|
|
|
2889 If NOSOURCE is selected, all source listing is
|
|
|
2890 suppressed.
|
|
|
2891
|
|
|
2892 .LI LIST
|
|
|
2893 .LI "\fINOLIST\fR"
|
|
|
2894 .LI " "
|
|
|
2895 If LIST is specified, the compiler will provide a
|
|
|
2896 list of statement numbers catalogued according to
|
|
|
2897 type of statement. The compiler uses this table
|
|
|
2898 to perform abstentions by gerund.
|
|
|
2899
|
|
|
2900 .LI "WIDTH=nn"
|
|
|
2901 .LI " "
|
|
|
2902 This sets the width (in number of characters) of
|
|
|
2903 the output line for FORMAT mode output. The
|
|
|
2904 default is
|
|
|
2905 .B 132.
|
|
|
2906
|
|
|
2907 .LI "CODE"
|
|
|
2908 .LI "\fINOCODE\fR"
|
|
|
2909 .LI " "
|
|
|
2910 Include 'CODE' in the parameter list to obtain a
|
|
|
2911 listing of the SPITBOL code produced for each
|
|
|
2912 INTERCAL statement.
|
|
|
2913
|
|
|
2914 .LI "LINES=nn"
|
|
|
2915 .LI " "
|
|
|
2916 This determines the number of lines per page,
|
|
|
2917 during both compilation and execution. The
|
|
|
2918 default is
|
|
|
2919 .B 60.
|
|
|
2920
|
|
|
2921 .LI DECK
|
|
|
2922 .LI "\fINODECK\fR"
|
|
|
2923 .LI " "
|
|
|
2924 Selecting 'DECK' will cause the compiler to punch
|
|
|
2925 out a SPITBOL object deck which may then be run
|
|
|
2926 without reinvoking the INTERCAL (or SPITBOL)
|
|
|
2927 compiler.
|
|
|
2928
|
|
|
2929 .LI "\fIKIDDING\fR"
|
|
|
2930 .LI NOKIDDING
|
|
|
2931 .LI " "
|
|
|
2932 Select NOKIDDING to eliminate the snide remarks
|
|
|
2933 which ordinarily accompany INTERCAL error
|
|
|
2934 messages.
|
|
|
2935
|
|
|
2936 .LI "\fIGO\fR"
|
|
|
2937 .LI NOGO
|
|
|
2938 .LI " "
|
|
|
2939 Specifying 'NOGO' will cause the program to be
|
|
|
2940 compiled but not executed. EXECUTE/NOEXECUTE may
|
|
|
2941 be substituted for GO/NOGO, but this will result
|
|
|
2942 in an error, and GO will be assumed.
|
|
|
2943
|
|
|
2944 .LI "\fIBUG\fR"
|
|
|
2945 .LI NOBUG
|
|
|
2946 .LI " "
|
|
|
2947 Under the default, there is a fixed probability of
|
|
|
2948 a fatal compiler bug being worked at random into
|
|
|
2949 the program being compiled. Encountering this bug
|
|
|
2950 during execution results in error message 774 (see
|
|
|
2951 section
|
|
|
2952 .GETHN error_messages
|
|
|
2953 ). This probability is reduced to zero
|
|
|
2954 under 'NOBUG'. This does not affect the
|
|
|
2955 probability (presumably negligible) of error
|
|
|
2956 message 778.
|
|
|
2957 .LE
|
|
|
2958 .H 2 "Other INTERCAL Compilers"
|
|
|
2959 .P
|
|
|
2960 There are no other INTERCAL compilers. \*F
|
|
|
2961 .FS
|
|
|
2962 This assertion in the INTERCAL-72 manual was blatantly contradicted by
|
|
|
2963 some notes on an Atari implementation included at the end of the manual.
|
|
|
2964 So, you expect compiler manuals to be consistent?
|
|
|
2965 .FE
|
|
|
2966 .ds App TONSIL
|
|
|
2967 .APP "A\*F" ""
|
|
|
2968 .if '\*c'y' \{\
|
|
|
2969 .DS I F
|
|
|
2970 "Of course they answer to their names?" the Gnat remarked carelessly.
|
|
|
2971 .P
|
|
|
2972 "I never knew them to do it."
|
|
|
2973 .P
|
|
|
2974 "What's the use of their having names," the Gnat said, "if they wo'n't
|
|
|
2975 answer to them?"
|
|
|
2976 .P
|
|
|
2977 "No use to \fIthem\fR," said Alice; "but it's useful to the people
|
|
|
2978 that name them, I suppose. If not, why do things have names at all?"
|
|
|
2979 .P
|
|
|
2980 "I ca'n't say," the Gnat replied. "Further on, in the wood down there,
|
|
|
2981 they've got no names -- however, go on with your list...."
|
|
|
2982 .DE \}
|
|
|
2983 .P
|
|
|
2984 The Official INTERCAL Character Set
|
|
|
2985 .FS
|
|
|
2986 Since all other reference manuals have Appendices, it was decided that
|
|
|
2987 the INTERCAL manual should contain some other type of removable organ.
|
|
|
2988 .FE
|
|
|
2989 .ps \n[@ps]
|
|
|
2990 .\".nr * \n*+1
|
|
|
2991 .nr PG \n%+1
|
|
|
2992 .P
|
|
|
2993 Tabulated on page \n(PG are all the characters used in INTERCAL, excepting
|
|
|
2994 letters and digits, along with their names and interpretations. Also
|
|
|
2995 included are several characters not used in INTERCAL, which are presented
|
|
|
2996 for completeness and to allow for future expansion.
|
|
|
2997 .\" All we're doing here is evaluating \*F and throwing it away
|
|
|
2998 .fi \*F
|
|
|
2999 .FS
|
|
|
3000 This footnote intentionally unreferenced.
|
|
|
3001 .FE
|
|
|
3002 .ds CH - % -
|
|
|
3003 .bp
|
|
|
3004 .\".nr * \n*-1
|
|
|
3005 .ps \n[@ps]
|
|
|
3006 .ie '\*c'n' \{\
|
|
|
3007 .TS
|
|
|
3008 box;
|
|
|
3009 c c c
|
|
|
3010 l l l.
|
|
|
3011 Character Name Use (if any)
|
|
|
3012 \&. spot identify 16-bit variable
|
|
|
3013 : two-spot identify 32-bit variable
|
|
|
3014 , tail identify 16-bit array
|
|
|
3015 ; hybrid identify 32-bit array
|
|
|
3016 # mesh identify constant
|
|
|
3017 \&= half-mesh
|
|
|
3018 \' spark grouper
|
|
|
3019 ` backspark
|
|
|
3020 ! wow equivalent to spark-spot
|
|
|
3021 ? what \fIunary exlusive OR (ASCII)\fR
|
|
|
3022 " rabbit-ears grouper
|
|
|
3023 \o'".' rabbit equivalent to ears-spot
|
|
|
3024 | spike
|
|
|
3025 % double-oh-seven percentage qualifier
|
|
|
3026 \- worm used with angles
|
|
|
3027 < angle used with worms
|
|
|
3028 > right angle
|
|
|
3029 ( wax precedes line label
|
|
|
3030 ) wane follows line label
|
|
|
3031 [ U turn
|
|
|
3032 ] U turn back
|
|
|
3033 { embrace
|
|
|
3034 } bracelet
|
|
|
3035 * splat flags invalid statements
|
|
|
3036 & ampersand \*F unary logical AND
|
|
|
3037 V V (or book) unary logical OR
|
|
|
3038 \*(vb bookworm (or universal qualifier) unary exclusive OR
|
|
|
3039 $ big money \fIbinary mingle (ASCII)\fR
|
|
|
3040 \*(ct change binary mingle
|
|
|
3041 ~ sqiggle binary select
|
|
|
3042 \&_ flat worm
|
|
|
3043 \*(ov overline indicates "times 1000"
|
|
|
3044 + intersection separates list items
|
|
|
3045 / slat
|
|
|
3046 \e backslat
|
|
|
3047 @ whirlpool
|
|
|
3048 \*(no hookworm
|
|
|
3049 ^ shark (or simply sharkfin)
|
|
|
3050 \o"#*\(sq" blotch
|
|
|
3051 .if '\*c'y' \{\
|
|
|
3052 \*(de bunghole
|
|
|
3053 \*(rg name grabber
|
|
|
3054 \*(mu andrew cross
|
|
|
3055 \*(di norwegian minus
|
|
|
3056 \*(co text grabber
|
|
|
3057 \*(sc swash
|
|
|
3058 \*(*m microscope
|
|
|
3059 \*(+- interworm
|
|
|
3060 \*(no half turn
|
|
|
3061 0xA3 quid binary mingle
|
|
|
3062 0xA4 zlotnik binary mingle
|
|
|
3063 \}
|
|
|
3064 .TE \}
|
|
|
3065 .el \{\
|
|
|
3066 .TS
|
|
|
3067 box;
|
|
|
3068 c c c
|
|
|
3069 l l l.
|
|
|
3070 Character Name Use (if any)
|
|
|
3071 \&. spot identify 16-bit variable
|
|
|
3072 : two-spot identify 32-bit variable
|
|
|
3073 , tail identify 16-bit array
|
|
|
3074 ; hybrid identify 32-bit array
|
|
|
3075 # mesh identify constant
|
|
|
3076 \&= half-mesh
|
|
|
3077 \' spark grouper
|
|
|
3078 ` backspark
|
|
|
3079 ! wow equivalent to spark-spot
|
|
|
3080 ? what unary logical XOR
|
|
|
3081 " rabbit-ears grouper
|
|
|
3082 \o'".' rabbit equivalent to ears-spot
|
|
|
3083 | spike
|
|
|
3084 % double-oh-seven percentage qualifier
|
|
|
3085 \- worm used with angles
|
|
|
3086 < angle used with worms
|
|
|
3087 > right angle
|
|
|
3088 ( wax precedes line label
|
|
|
3089 ) wane follows line label
|
|
|
3090 [ U turn
|
|
|
3091 ] U turn back
|
|
|
3092 { embrace
|
|
|
3093 } bracelet
|
|
|
3094 * splat flags invalid statements
|
|
|
3095 & ampersand \*F unary logical AND
|
|
|
3096 V V (or book) unary logical OR
|
|
|
3097 \*(vb bookworm (universal qualifier) unary logical XOR (INTERCAL-72)
|
|
|
3098 $ big money binary mingle
|
|
|
3099 \*(ct change binary mingle (INTERCAL-72)
|
|
|
3100 ~ sqiggle binary select
|
|
|
3101 \&_ flat worm
|
|
|
3102 \*(ov overline indicates "times 1000"
|
|
|
3103 + intersection separates list items
|
|
|
3104 / slat
|
|
|
3105 \e backslat
|
|
|
3106 @ whirlpool unary logical BUT (TriINTERCAL)
|
|
|
3107 \*(no hookworm
|
|
|
3108 ^ shark (or simply sharkfin) unary logical XOR (TriINTERCAL)
|
|
|
3109 \o"#*\(sq" blotch
|
|
|
3110 .if '\*c'y' \{\
|
|
|
3111 \*(de bunghole
|
|
|
3112 \*(rg name grabber
|
|
|
3113 \*(mu andrew cross
|
|
|
3114 \*(di norwegian minus
|
|
|
3115 \*(co text grabber
|
|
|
3116 \*(sc swash
|
|
|
3117 \*(*m microscope
|
|
|
3118 \*(+- interworm
|
|
|
3119 \*(no half turn
|
|
|
3120 0xA3 quid binary mingle
|
|
|
3121 0xA4 zlotnik binary mingle
|
|
|
3122 \}
|
|
|
3123 .TE \}
|
|
|
3124 .ce 1
|
|
|
3125 Table 2 (top view). INTERCAL character set.
|
|
|
3126 .FS
|
|
|
3127 Got any better ideas?
|
|
|
3128 .FE
|
|
|
3129 .ps \n[@ps]
|
|
|
3130 .if '\*c'n' \{\
|
|
|
3131 .APP "B" "NOTES ON THE ATARI IMPLEMENTATION"
|
|
|
3132 .P
|
|
|
3133 The Atari implementation of INTERCAL differs from the original Princeton
|
|
|
3134 .ds CH INTERCAL
|
|
|
3135 version primarily in the use of ASCII rather than EBCDIC. Since there is no
|
|
|
3136 "change" sign (\*(ct) in ASCII, we have substituted the "big money" ($) as the
|
|
|
3137 mingle operator. We feel that this correctly represents the increasing cost
|
|
|
3138 of software in relation to hardware. (Consider that in 1970 one could get
|
|
|
3139 RUNOFF for free, to run on a $20K machine, whereas today a not quite as
|
|
|
3140 powerful formatter costs $99 and runs on a $75 machine.) We also feel that
|
|
|
3141 there should be no defensible contention that INTERCAL has any sense.
|
|
|
3142 Also, since overpunches are difficult to read on the average VDT, the
|
|
|
3143 exclusive-or operator may be written ?. This correctly expresses the
|
|
|
3144 average person's reaction on first encountering exclusive-or, especially on
|
|
|
3145 a PDP-11. Note that in both of these cases, the over-punched symbol may
|
|
|
3146 also be used if one is masochistic, or concerned with portability to the
|
|
|
3147 Princeton compiler. The correct over-punch for "change" is "c<backspace>/"
|
|
|
3148 and the correct over-punch for \*(vb is "V<backspace>-". These codes will be
|
|
|
3149 properly printed if you have a proper printer, and the corresponding EBCDIC
|
|
|
3150 code will be produced by the /IBM option on the LIST command. \}
|
