|
996
|
1 Table of Contents
|
|
|
2 *****************
|
|
|
3
|
|
|
4 C-INTERCAL 0.29
|
|
|
5 About this manual
|
|
|
6 PART I: THE C-INTERCAL COMPILER
|
|
|
7 1 Installation
|
|
|
8 1.1 Obtaining
|
|
|
9 1.2 Unpacking
|
|
|
10 1.3 Simple Installation
|
|
|
11 1.4 DOS/Windows Install
|
|
|
12 1.5 Not Installing
|
|
|
13 1.6 Uninstalling
|
|
|
14 1.7 Reporting Bugs
|
|
|
15 1.8 Distributing
|
|
|
16 2 Invoking ick
|
|
|
17 2.1 Language-affecting Options
|
|
|
18 2.2 Debug Options
|
|
|
19 2.3 Output Options
|
|
|
20 2.4 Optimizer Options
|
|
|
21 2.5 Other Options
|
|
|
22 2.6 Options to Generated Programs
|
|
|
23 2.7 Environment Variables
|
|
|
24 3 Errors and Warnings
|
|
|
25 3.1 Errors
|
|
|
26 3.2 Warnings
|
|
|
27 4 The yuk debugger
|
|
|
28 PART II: THE INTERCAL LANGUAGE
|
|
|
29 5 Syntax
|
|
|
30 5.1 Princeton and Atari Syntax
|
|
|
31 5.2 Line Labels
|
|
|
32 5.3 Statement Identifiers
|
|
|
33 5.4 Execution Chance
|
|
|
34 5.5 ONCE and AGAIN
|
|
|
35 6 Expressions
|
|
|
36 6.1 Constants and Variables
|
|
|
37 6.2 Grouping Rules
|
|
|
38 6.3 Operators
|
|
|
39 6.3.1 Mingle
|
|
|
40 6.3.2 Select
|
|
|
41 6.3.3 Unary Binary Logic
|
|
|
42 6.3.4 Array Subscript
|
|
|
43 7 Statements
|
|
|
44 7.1 Syntax Error
|
|
|
45 7.2 Calculate
|
|
|
46 7.3 NEXT, FORGET and RESUME
|
|
|
47 7.4 STASH and RETRIEVE
|
|
|
48 7.5 IGNORE and REMEMBER
|
|
|
49 7.6 ABSTAIN and REINSTATE
|
|
|
50 7.7 READ OUT and WRITE IN
|
|
|
51 7.7.1 INTERCAL-72 I/O
|
|
|
52 7.7.2 C-INTERCAL I/O
|
|
|
53 7.7.3 CLC-INTERCAL I/O
|
|
|
54 7.8 GIVE UP
|
|
|
55 7.9 TRY AGAIN
|
|
|
56 7.10 COME FROM and NEXT FROM
|
|
|
57 8 System Library
|
|
|
58 PART III: INTERCAL DIALECTS AND EXTENSIONS
|
|
|
59 9 TriINTERCAL
|
|
|
60 10 Multithreading and Backtracking
|
|
|
61 10.1 Multithreading using COME FROM
|
|
|
62 10.2 Multithreading using WHILE
|
|
|
63 10.3 Backtracking
|
|
|
64 11 Operand Overloading
|
|
|
65 12 PIC-INTERCAL
|
|
|
66 13 CREATE
|
|
|
67 14 External Calls
|
|
|
68 14.1 External Calls to C
|
|
|
69 14.1.1 External C Call Infrastructure
|
|
|
70 14.1.2 ick_startup
|
|
|
71 14.1.3 ick_linelabel
|
|
|
72 14.1.4 ick_labeledblock
|
|
|
73 14.1.5 ick_comefrom and ick_nextfrom
|
|
|
74 14.1.6 ick_next
|
|
|
75 14.1.7 ick_resume
|
|
|
76 14.1.8 ick_forget
|
|
|
77 14.1.9 ick_get/setone/twospot
|
|
|
78 14.1.10 ick_create
|
|
|
79 14.1.11 External Calls and auto
|
|
|
80 14.2 External Calls to Funge-98
|
|
|
81 14.2.1 Creating the Funge-98 Library
|
|
|
82 14.2.2 The IFFI Fingerprint
|
|
|
83 14.3 Miscellaneous External Calls
|
|
|
84 14.4 Using External Calls
|
|
|
85 14.5 Expansion Libraries
|
|
|
86 15 Differences to Other Compilers
|
|
|
87 PART IV: APPENDICES AND INDICES
|
|
|
88 Appendix A Character Sets
|
|
|
89 Appendix B convickt
|
|
|
90 Appendix C Optimizer Idiom Language
|
|
|
91 C.1 OIL Basics
|
|
|
92 C.2 OIL Syntax
|
|
|
93 C.3 OIL Expressions
|
|
|
94 C.4 OIL Patterns
|
|
|
95 C.5 OIL Replacements
|
|
|
96 C.6 OIL Loops
|
|
|
97 C.7 OIL Tips
|
|
|
98 C.8 OIL Example
|
|
|
99 Appendix D Copying
|
|
|
100 D.1 GNU Free Documentation License
|
|
|
101 Index
|
|
|
102
|
|
|
103
|
|
|
104 C-INTERCAL 0.29
|
|
|
105 ***************
|
|
|
106
|
|
|
107 This manual is for C-INTERCAL version 0.29. It does not replace the
|
|
|
108 old groff manual, nor is it designed to be read in conjunction with it;
|
|
|
109 instead, it serves a different purpose, of providing information useful
|
|
|
110 to users of C-INTERCAL (unlike the other manual, it is not derived from
|
|
|
111 the original INTERCAL-72 manual).
|
|
|
112
|
|
|
113 Copyright (C) 2007 Alex Smith.
|
|
|
114
|
|
|
115 Permission is granted to copy, distribute and/or modify this
|
|
|
116 document under the terms of the GNU Free Documentation License,
|
|
|
117 Version 1.2 or any later version published by the Free Software
|
|
|
118 Foundation; with no Invariant Sections, with no Front-Cover Texts,
|
|
|
119 and with no Back-Cover Texts. A copy of the license is included
|
|
|
120 in the section entitled "GNU Free Documentation License."
|
|
|
121
|
|
|
122
|
|
|
123 About this manual
|
|
|
124 *****************
|
|
|
125
|
|
|
126 This is the Revamped Instruction Manual for C-INTERCAL (this version is
|
|
|
127 distributed with C-INTERCAL version 0.29). It is divided into four
|
|
|
128 parts.
|
|
|
129
|
|
|
130 The first part is about the C-INTERCAL compiler `ick', and how to use
|
|
|
131 it. It covers installing the compiler, using the compiler, what error
|
|
|
132 and warning messages are produced by the compiler, and some information
|
|
|
133 on how to use the debugger.
|
|
|
134
|
|
|
135 The second part is about the core INTERCAL language, invented in 1972,
|
|
|
136 and some other commands since then which don't feel like they're
|
|
|
137 extensions. (This is a pretty arbitrary distinction, but people who
|
|
|
138 write the documentation are entitled to arbitrary distinctions. The
|
|
|
139 manual's licensed under a license that lets you change it (*note
|
|
|
140 Copying::), so if you disagree you can move the commands from section
|
|
|
141 to section yourself.) Mostly only commands that are implemented in
|
|
|
142 C-INTERCAL are covered here (if you're interested in the other commands
|
|
|
143 implemented in other compilers, read CLC-INTERCAL's documentation).
|
|
|
144 However, a comprehensive guide to portability of these commands between
|
|
|
145 C-INTERCAL and other INTERCAL compilers is given.
|
|
|
146
|
|
|
147 The third part covers the INTERCAL extensions and dialects that are
|
|
|
148 implemented by C-INTERCAL, such as TriINTERCAL and Threaded INTERCAL.
|
|
|
149 Again, extensions and dialects not implemented have been mostly left
|
|
|
150 out.
|
|
|
151
|
|
|
152 The final part contains appendices (which were known as `tonsils' in
|
|
|
153 the original INTERCAL manual), such as character sets used by INTERCAL,
|
|
|
154 programs other than `ick' in the C-INTERCAL distribution, information
|
|
|
155 on how to read and update the list of optimizer idioms used by the
|
|
|
156 compiler, and the copyright.
|
|
|
157
|
|
|
158 PART I: THE C-INTERCAL COMPILER
|
|
|
159 *******************************
|
|
|
160
|
|
|
161 1 Installation
|
|
|
162 **************
|
|
|
163
|
|
|
164 The C-INTERCAL distribution is distributed in source code form; this
|
|
|
165 means that before using it, you first have to compile it. Don't worry:
|
|
|
166 if you have the right software, it's not at all difficult. Most
|
|
|
167 Linux-based and UNIX-based computers are likely to have the software
|
|
|
168 needed already; the software needed to compile source-distributed
|
|
|
169 packages is also readily available for free for other operating
|
|
|
170 systems. The following instructions will help you install the
|
|
|
171 distribution in a method appropriate for your system.
|
|
|
172
|
|
|
173 (If you happen to be using Debian or Ubuntu, you can also obtain and
|
|
|
174 install binaries with the command `sudo apt-get install intercal',
|
|
|
175 making the rest of this chapter redundant. If you do this, use
|
|
|
176 Debian's bug tracker to report bugs, rather than reporting them
|
|
|
177 directly to the maintainers.)
|
|
|
178
|
|
|
179 1.1 Obtaining
|
|
|
180 =============
|
|
|
181
|
|
|
182 C-INTERCAL distributions have been stored in many different places over
|
|
|
183 time; it can sometimes be hard to make sure that you are finding the
|
|
|
184 most recent version. In order to make sure that you have the most
|
|
|
185 recent version, the easiest way is to look at the alt.lang.intercal
|
|
|
186 newsgroup; all releases of the C-INTERCAL compiler ought to be
|
|
|
187 announced there. (If you are interested in what other INTERCAL
|
|
|
188 compilers are available, it may also be worth looking there.) If you
|
|
|
189 don't have access to a newsreader, your newsreader doesn't cover that
|
|
|
190 newsgroup, or the distance between releases has been too large for your
|
|
|
191 news server to keep the message, it's likely that you can find the
|
|
|
192 announcement in an archive on the World Wide Web; at the time of
|
|
|
193 writing (2007), the archives of the newsgroup are stored by Google
|
|
|
194 Groups (http://groups.google.com), and a search for `alt.lang.intercal'
|
|
|
195 there should tell you where to find a copy.
|
|
|
196
|
|
|
197 If you're looking for the latest version, note that the number after the
|
|
|
198 dot represents the major version number; you want to maximise this in
|
|
|
199 favour of the number before the dot, which is the bugfix level within a
|
|
|
200 major version. (Major versions are released as version 0.whatever; if a
|
|
|
201 new version comes out that fixes bugs but adds no new features, nowadays
|
|
|
202 its number will be of the form 1.whatever, with the same major number.
|
|
|
203 This has not always been the case, though.)
|
|
|
204
|
|
|
205 1.2 Unpacking
|
|
|
206 =============
|
|
|
207
|
|
|
208 The distribution is likely to be a single file with extension `.tgz';
|
|
|
209 this refers to a gzipped tar file. Most computer systems can extract
|
|
|
210 files in this format (nowadays even many computers running Windows have
|
|
|
211 the appropriate software).
|
|
|
212
|
|
|
213 It doesn't matter where you extract the distribution file to: it's best
|
|
|
214 if you don't put it anywhere special. If you aren't an administrator,
|
|
|
215 you should extract the file to somewhere in your home directory (Linux
|
|
|
216 or UNIX-like systems) or to your My Documents directory (recent versions
|
|
|
217 of Windows; if you're using an older version, then you _are_ an
|
|
|
218 administrator, or at least have the same privileges, and can extract it
|
|
|
219 anywhere). Some commands that you might use to extract it:
|
|
|
220
|
|
|
221 Generic UNIX/Linux
|
|
|
222 gunzip ick-0-29.tgz
|
|
|
223 tar xvf ick-0-29.tar
|
|
|
224
|
|
|
225 On most UNIX-based and Linux-based systems, `tar' will be
|
|
|
226 available to unpack the installation files once they've been
|
|
|
227 uncompressed with `gunzip'. `gunzip' is also likely to be
|
|
|
228 available; if it isn't, you will need to download a copy from the
|
|
|
229 Internet.
|
|
|
230
|
|
|
231 Using GNU tar
|
|
|
232 tar xzvf ick-0-29.tgz
|
|
|
233
|
|
|
234 If you are using the GNU version of `tar' (which is very likely on
|
|
|
235 Linux), you can combine the two steps into one as shown here.
|
|
|
236
|
|
|
237 Using DJGPP
|
|
|
238 djtar -x ick-0-29.tgz
|
|
|
239
|
|
|
240 On a DOS or Windows system, you will have to install DJGPP anyway
|
|
|
241 to be able to compile the distribution (*note DOS/Windows
|
|
|
242 Install::), and once you've done that you will be able to use
|
|
|
243 DJGPP's decompressing and unpacking utility to extract the files
|
|
|
244 needed to install the distribution. (You will need to type this
|
|
|
245 at the command line; on Windows 95 and later, try choosing Run...
|
|
|
246 from the start menu then typing `cmd' (or `command' if that fails)
|
|
|
247 in the dialog box that opens to get a command prompt, which you
|
|
|
248 can exit by typing `exit'. After typing any command at a command
|
|
|
249 line, press <RET> to tell the shell to execute that command.)
|
|
|
250
|
|
|
251 On Windows
|
|
|
252 If you're running a Windows system, you could always try
|
|
|
253 double-clicking on the ick-0-29.tgz file. It's quite possible that
|
|
|
254 you'll have a program installed that's capable of decompressing and
|
|
|
255 unpacking it. Unfortunately, I can't guess what program that
|
|
|
256 might be, so I can't give you any instructions for using it.
|
|
|
257
|
|
|
258
|
|
|
259 Whatever method you use, you should end up with a directory created
|
|
|
260 called `ick-0.29'; this is your main installation directory where all
|
|
|
261 the processing done by the installation will be carried out. You will
|
|
|
262 need to have that directory as the current directory during install (at
|
|
|
263 the command prompt in all the operating systems I know, you can set the
|
|
|
264 current directory by typing `cd ick-0.29').
|
|
|
265
|
|
|
266 1.3 Simple Installation
|
|
|
267 =======================
|
|
|
268
|
|
|
269 There are scripts included in the distribution to automate the process
|
|
|
270 of installing, in various ways. The simplest method of installing is to
|
|
|
271 use the following routine:
|
|
|
272
|
|
|
273 1. Configure C-INTERCAL, by typing `sh config.sh'
|
|
|
274
|
|
|
275 2. Compile the source code, with the command `make'
|
|
|
276
|
|
|
277 3. Optionally, create libraries from third-party interpreters to add
|
|
|
278 support for more languages to the C-INTERCAL external calls
|
|
|
279 system; see *note Creating the Funge-98 Library::. (This step can
|
|
|
280 be skipped; you can also do it later, but if you do so you need to
|
|
|
281 run the next step again.)
|
|
|
282
|
|
|
283 4. Install the executables, help files, include files, and libraries,
|
|
|
284 using `make install'. (This is the only step that needs
|
|
|
285 root/administrator permissions; so on a system that uses sudo to
|
|
|
286 elevate permissions, for instance, write it as `sudo make
|
|
|
287 install'.)
|
|
|
288
|
|
|
289
|
|
|
290 On all systems, it's worth just trying this to see if it works. This
|
|
|
291 requires a lot of software on your computer to work, but all of it is
|
|
|
292 standard on Linux and UNIX systems. The first command is a shell-script
|
|
|
293 which will analyse your system and set settings accordingly; it will
|
|
|
294 explain what it's doing and what settings it detected, and create
|
|
|
295 several files in the installation directory to record its results.
|
|
|
296 (This is a configure script produced by the GNU autoconf (config.sh);
|
|
|
297 its autoconf source code is available in the file `config.ac'.) The
|
|
|
298 second command actually compiles the source code to produce binaries;
|
|
|
299 this takes the longest of any of the steps. You will see all the
|
|
|
300 commands that it's running as it runs them. The third command will
|
|
|
301 copy the files it's compiled to appropriate shared locations on your
|
|
|
302 system so that anyone on the system can just use `ick'.
|
|
|
303
|
|
|
304 There may be various factors that prevent this simple installation
|
|
|
305 method working. On a system not based on UNIX or Linux, you may find
|
|
|
306 that you don't have some of the software required to run this (for
|
|
|
307 instance, you may be missing the shell `sh', and don't have the shell
|
|
|
308 `bash' which can emulate it, and so can't run `sh config.sh' that
|
|
|
309 depends on one of those shells being available) and so this method
|
|
|
310 won't work for you. In such cases, one solution may be to install all
|
|
|
311 the software required; the GNU project has a version of all the
|
|
|
312 commands required, for instance, and there may be ports available for
|
|
|
313 your operating system. However, the only software absolutely required
|
|
|
314 is a C compiler (C-INTERCAL was designed to work with `gcc' and has
|
|
|
315 only been tested in combination with that compiler, but in theory it
|
|
|
316 should be possible to adapt it to work with other compilers) and the
|
|
|
317 associated software needed to compile C files to object files and
|
|
|
318 executables, combine object files into libraries, etc.
|
|
|
319
|
|
|
320 Another possibility that might stop this process working is if your
|
|
|
321 version of the relevant software is incompatible with the GNU versions
|
|
|
322 that were used for testing. For instance, I have come across
|
|
|
323 proprietary versions of `lex' that need directives in the source file
|
|
|
324 to say in advance how much memory the lexer-generator needs to
|
|
|
325 allocate. In such cases, pay attention to the error messages you're
|
|
|
326 getting; normally they will suggest trivial modifications to the source
|
|
|
327 files that will cause the compilation to work again.
|
|
|
328
|
|
|
329 Some Linux and UNIX systems (notably Debian and Ubuntu) don't have the
|
|
|
330 required files for compilation installed by default. To install them,
|
|
|
331 just download and install the required packages: for Ubuntu at the time
|
|
|
332 of writing, they are `binutils', `bison', `cpp', `flex', `gcc',
|
|
|
333 `libc6-dev', `make' to compile C-INTERCAL, and if you want to modify
|
|
|
334 it, you may also need `autoconf'. For debugging help, you may also
|
|
|
335 want `gdb', and to recompile the documentation, you may need `groff',
|
|
|
336 `tetex-bin', `texinfo', and `tidy'. Of course, if INTERCAL ever (the
|
|
|
337 author of this sentence was going to write something like "becomes
|
|
|
338 popular, someone will probably package up a compiler for Debian or
|
|
|
339 Ubuntu anyway", but at that point on a whim did an Ubunutu package
|
|
|
340 search for 'intercal' and actually came up with two results, which look
|
|
|
341 suspiciously like C-INTERCAL and CLC-INTERCAL, later confirming this.
|
|
|
342 The author was vaguely aware that there was a CLC-INTERCAL package
|
|
|
343 floating around, but was unaware of the C-INTERCAL package, and as a
|
|
|
344 result was too surprised to finish the sentence.)
|
|
|
345
|
|
|
346 If you're trying to do something unusual, you probably want to set some
|
|
|
347 of the settings yourself rather than letting the compilation process
|
|
|
348 guess everything. In this case, use `sh config.sh --help' to view the
|
|
|
349 options that you can set on `config.sh'; there's a wide range of
|
|
|
350 settings that you can set available there, and one of them may be what
|
|
|
351 you want. For the special case of a non-administrator user who wants
|
|
|
352 to test the C-INTERCAL compiler without having admin rights, or
|
|
|
353 equivalently any user who wants to test the compiler without installing
|
|
|
354 it, see *note Not Installing::.
|
|
|
355
|
|
|
356 1.4 DOS/Windows Install
|
|
|
357 =======================
|
|
|
358
|
|
|
359 On DOS and Windows, it's possible to install C-INTERCAL by using the C
|
|
|
360 compiler and utilities provided by DJGPP. (Possibly other environments
|
|
|
361 also work, but DJGPP is the only C compilation system on which recent
|
|
|
362 versions of C-INTERCAL have been tested.) If you don't have a copy of
|
|
|
363 DJGPP, or you're not sure whether you have the most recent version,
|
|
|
364 visit `http://www.delorie.com/djgpp'. I think it's possible to compile
|
|
|
365 C-INTERCAL to binaries from only the files in the distribution and the C
|
|
|
366 compilation parts of DJGPP, but this relies on some prebuilt files
|
|
|
367 enclosed in the distribution, and I haven't actually tested this, so I
|
|
|
368 might be wrong. At the other extreme, if you download and install not
|
|
|
369 only the DJGPP C compiler but also all the DJGPP ports of the GNU
|
|
|
370 utilities required to run `config.sh' and `make', you can use the
|
|
|
371 simple installation method; see *note Simple Installation::. (This is
|
|
|
372 actually somewhat recommended; doing this will not only allow you to
|
|
|
373 change source code, recompile, and be guaranteed to have your changes
|
|
|
374 to the source code affect the executables, and allow you to install
|
|
|
375 C-INTERCAL without having to fiddle around with the `PATH' environment
|
|
|
376 variable, but also you may then be able to install other programs
|
|
|
377 distributed in source form without further hassle.)
|
|
|
378
|
|
|
379 Assuming that you decide not to download all the utilites required to
|
|
|
380 carry out a simple install, follow the following instructions to compile
|
|
|
381 and install the C-INTERCAL compiler:
|
|
|
382
|
|
|
383 1. If you haven't already installed DJGPP, do that now, following the
|
|
|
384 instructions given there.
|
|
|
385
|
|
|
386 2. Open a command prompt if you aren't at one already, unpack the
|
|
|
387 distribution if you haven't already, and change directory to the
|
|
|
388 main installation directory (*note Unpacking::).
|
|
|
389
|
|
|
390 3. Run one of two commands included in the distribution especially for
|
|
|
391 installing C-INTERCAL under DJGPP. Which one you run depends on
|
|
|
392 the shell you're using: if you're running under one of the
|
|
|
393 DOS/Windows shells (`cmd.exe' or `command.com'), type
|
|
|
394 `makeick.bat', and if you're running under a port of a UNIX or
|
|
|
395 Linux shell (such as `bash'), type `makeick.sh'.
|
|
|
396
|
|
|
397 4. The distribution should now have been compiled, but it still needs
|
|
|
398 to be installed. To do this, you will need to edit your `PATH'
|
|
|
399 environment variable. Under DOS and earlier versions of Windows,
|
|
|
400 you can do this by editing `C:\autoexec.bat'; look for the last
|
|
|
401 command that sets the `PATH' environment variable (i.e. that starts
|
|
|
402 with `set PATH='), and add another semicolon and the `bin'
|
|
|
403 subdirectory of your main installation directory to it (for
|
|
|
404 instance, if your installation directory is
|
|
|
405 `C:\stuff\intercal\ick-0.29', you want to add
|
|
|
406 `;C:\stuff\intercal\ick-0.29\bin' to the end of that line). Under
|
|
|
407 later versions of Windows, this won't work (I'm not sure exactly
|
|
|
408 where the cutoff is, but I know the other method doesn't work on
|
|
|
409 Windows XP); instead, go via the Start menu to Settings, Control
|
|
|
410 Panel, System, Advanced, Environment Variables, and edit either
|
|
|
411 your own or the system-wide PATH setting (depending on whether you
|
|
|
412 want to install for yourself or for everyone) to end with the
|
|
|
413 `bin' subdirectory of the main installation directory, the same
|
|
|
414 way as for older versions of Windows.
|
|
|
415
|
|
|
416
|
|
|
417 To test that the `PATH' setting is set correctly, try changing to an
|
|
|
418 unrelated directory (for instance, by typing `cd \' at a command
|
|
|
419 prompt), and typing `ick -@'; if you get a usage message for `ick',
|
|
|
420 then you've set the `PATH' setting correctly. Note that if things go
|
|
|
421 wrong during compilation, other than errors about inability to find
|
|
|
422 `flex' or `bison' (the compilation process can succeed despite either
|
|
|
423 of these errors), it's likely that you've messed up your DJGPP
|
|
|
424 installation (maybe by setting the `PATH' or `DJDIR' environment
|
|
|
425 variables incorrectly for it).
|
|
|
426
|
|
|
427 1.5 Not Installing
|
|
|
428 ==================
|
|
|
429
|
|
|
430 You don't have to install C-INTERCAL to be able to use it; you can
|
|
|
431 instead stop any of the other install techniques just after compiling
|
|
|
432 the source code, before the installation step. (This may be useful if
|
|
|
433 you just want to try out C-INTERCAL, or if you aren't a root/admin user
|
|
|
434 and therefore don't have the permissions to install things.) When
|
|
|
435 C-INTERCAL hasn't been installed, `ick' won't be able to find the files
|
|
|
436 it looks for in the places that they ought to have been installed, so
|
|
|
437 it will look in a variety of places they might be instead (the
|
|
|
438 installation directory, if it can figure out where it is; the same
|
|
|
439 directory as the binary; the current directory). In order for this to
|
|
|
440 work, just don't move any of the files that were compiled anywhere else.
|
|
|
441
|
|
|
442 Of course, if you haven't installed the compiler, just typing `ick' is
|
|
|
443 unlikely to work, because your computer won't know what you mean.
|
|
|
444 Instead, you should give a pathname (absolute or relative) to where
|
|
|
445 `ick' is, so that your computer can find it. With any luck, your
|
|
|
446 computer will communicate the pathname you used to `ick' itself, and if
|
|
|
447 that happens `ick' will use it to figure out where the main
|
|
|
448 installation directory is, and find the files it needs that way. If
|
|
|
449 you suspect that errors you are getting are due to inability to find
|
|
|
450 files (such as E127 (*note E127::) or E999 (*note E999::)), try giving
|
|
|
451 the `-u' (*note -u::) option to `ick' to see where it's looking.
|
|
|
452
|
|
|
453 You can make a `live' CD or USB-stick version of C-INTERCAL using
|
|
|
454 similar methods; configure (if possible) and compile it, but instead of
|
|
|
455 installing it, copy the entire `ick-0.29' directory to the CD or USB
|
|
|
456 stick. INTERCAL can then be run from there by explicitly giving a
|
|
|
457 pathname to `bin/ick' or `bin/ick.exe'.
|
|
|
458
|
|
|
459 1.6 Uninstalling
|
|
|
460 ================
|
|
|
461
|
|
|
462 It may happen that you decide to uninstall C-INTERCAL after installing
|
|
|
463 it; this may be useful if you want to test the installation system, or
|
|
|
464 change the location you install programs, or for some reason you don't
|
|
|
465 want it on your computer. It's worth uninstalling just before you
|
|
|
466 install a new version of C-INTERCAL because this will save some disk
|
|
|
467 space; you cannot install two versions of C-INTERCAL at once (but see
|
|
|
468 *note Not Installing:: for information on how you can use C-INTERCAL
|
|
|
469 without installing it).
|
|
|
470
|
|
|
471 If you installed C-INTERCAL using `make install', you can uninstall it
|
|
|
472 by using `make uninstall' from the installation directory, assuming
|
|
|
473 that it still exists. If you can't use that method for some reason,
|
|
|
474 you can uninstall it by deleting the files `ick.exe' where your
|
|
|
475 computer installs binaries, `libick.a', `libickmt.a', `libickec.a', and
|
|
|
476 `libyuk.a' where your computer installs libraries, and the
|
|
|
477 subdirectories `ick-0.29' in the places where your computer installs
|
|
|
478 data files and include files, and their contents.
|
|
|
479
|
|
|
480 If you installed C-INTERCAL by changing your `PATH' environment
|
|
|
481 variable, you can uninstall by changing it back.
|
|
|
482
|
|
|
483 You can go further than uninstalling. Running `make distr',
|
|
|
484 `districk.sh', or `districk.bat' will delete any files created by
|
|
|
485 compilation; `make distclean' will delete those files, and also any
|
|
|
486 files created by configuring. The distribution contains prebuilt
|
|
|
487 versions of the parser, lexical analyser and OIL compiler; doing `make
|
|
|
488 clean' (or `cleanick.sh' or `cleanick.bat') will do the same thing as
|
|
|
489 `make distr' and also delete those prebuilt versions.
|
|
|
490
|
|
|
491 1.7 Reporting Bugs
|
|
|
492 ==================
|
|
|
493
|
|
|
494 If you can't get C-INTERCAL to install at all, or something goes wrong
|
|
|
495 when you're using it, reporting a bug is probably a good idea. (This is
|
|
|
496 still important even if you figure out how to fix it, and the
|
|
|
497 information isn't in the manual, because the fix can be added to the
|
|
|
498 source code if possible, or at least to the manual, to benefit future
|
|
|
499 users.) For general help, you may want to post to the
|
|
|
500 alt.lang.intercal news group; to report a bug or submit a patch, email
|
|
|
501 the person who released the most recent C-INTERCAL version (which you
|
|
|
502 can determine by looking at that newsgroup).
|
|
|
503
|
|
|
504 If you do find a bug (either the compiler not behaving in the way you'd
|
|
|
505 expect, or if you find a way to cause E778 (*note E778::) without
|
|
|
506 modifying the source code), it helps a lot if you can submit a bug
|
|
|
507 report explaining what causes it. If you're not sure, say that; it
|
|
|
508 helps if you give examples of input, command line options, etc. that
|
|
|
509 cause the bug. There are several debug options (*note Debug Options::)
|
|
|
510 that you can use to help pin down a bug if you're interested in trying
|
|
|
511 to solve the problem yourself; looking at the output C code can also
|
|
|
512 help pin down a bug if the compiler gets that far.
|
|
|
513
|
|
|
514 Information that should be given in a bug report is what you expect to
|
|
|
515 happen, what actually happens, what input and command line options you
|
|
|
516 gave to the compiler, what operating system you're using, any ideas you
|
|
|
517 might have as to what the problem is, and any appropriate debug traces
|
|
|
518 (for instance, `-H' (*note -H: -H+.) output if you think the bug is in
|
|
|
519 the optimizer). Core dumps aren't portable between systems, so don't
|
|
|
520 send those; however, if you're getting an internal error and can dump
|
|
|
521 core with `-U' (*note -U: -U+.), it helps if you can load a debugger
|
|
|
522 (such as `gdb') on the core dump, use the debugger to produce a
|
|
|
523 backtrace, and send that backtrace.
|
|
|
524
|
|
|
525 If you figure out how to solve the bug yourself, and want to submit the
|
|
|
526 patches to help other users (this also carries the advantage that your
|
|
|
527 patches will then be maintained along with the rest of the distribution,
|
|
|
528 and that you won't have to reapply them every time you upgrade to a
|
|
|
529 newer version of C-INTERCAL), you must first agree to license your code
|
|
|
530 under the same license as the code that surrounds it (normally, that's
|
|
|
531 the GNU General Public License, but if you submit a patch to a file with
|
|
|
532 a different license, like this manual (yes, documentation patches are
|
|
|
533 useful too), you must agree to that license). You will be credited for
|
|
|
534 the patch in the source code unless you specifically ask not to be or
|
|
|
535 you don't give your name (in both these cases, you must license the code
|
|
|
536 to the public domain so that it can be incorporated without the
|
|
|
537 attribution requirement). Preferably, patches should be submitted in
|
|
|
538 the format created by the command `diff -u'; this command is likely to
|
|
|
539 be available on UNIX and Linux systems and versions are also available
|
|
|
540 for DOS and Windows (including a DJGPP port of the GNU version). If
|
|
|
541 you can't manage that, just submit your new code with enough lines of
|
|
|
542 old code around it to show where it's meant to go, and a description of
|
|
|
543 approximately where in the file it was. Patches should be submitted by
|
|
|
544 email to the person who most recently released a version of C-INTERCAL.
|
|
|
545
|
|
|
546 If you have a suggestion for a new feature, it makes sense to first
|
|
|
547 discuss it on the alt.lang.intercal news group; other INTERCAL compiler
|
|
|
548 maintainers may also want to implement that feature. If you have
|
|
|
549 developed code to implement that feature in C-INTERCAL, you can submit
|
|
|
550 it the same way that you would submit a patch for a bug.
|
|
|
551
|
|
|
552 1.8 Distributing
|
|
|
553 ================
|
|
|
554
|
|
|
555 Due to the licensing conditions of C-INTERCAL, you are allowed to
|
|
|
556 release your own version or distribution if you want to. In such
|
|
|
557 cases, it's recommended that you follow the following guidelines:
|
|
|
558
|
|
|
559 1. Make sure the new version is based on the most recent existing
|
|
|
560 version. Looking at the alt.lang.intercal newsgroup will normally
|
|
|
561 let you know what version is most recent.
|
|
|
562
|
|
|
563 2. Increment the version number; if you add any new features,
|
|
|
564 increment the major version number (after the decimal point) and
|
|
|
565 drop the minor version number (before the decimal point) to 0, and
|
|
|
566 otherwise increment the minor version number. You have to update
|
|
|
567 the version number in the following files: `config.in',
|
|
|
568 `config.sh', and `doc/ick.txi'. You also have to rename the
|
|
|
569 installation directory to reflect the new version number.
|
|
|
570
|
|
|
571 3. Add an entry to the `NEWS.txt' file explaining what's new in the
|
|
|
572 version that you're releasing, following the same format as the
|
|
|
573 other entries.
|
|
|
574
|
|
|
575 4. Update the `README.txt' with a description of any new files you may
|
|
|
576 have added.
|
|
|
577
|
|
|
578 5. Remove any autosave or backup files that may be littering the
|
|
|
579 installation directory or its subdirectories.
|
|
|
580
|
|
|
581 6. Run `make distclean', or `districk.sh' or `districk.bat' if you
|
|
|
582 didn't manage to configure; this will remove all files created by
|
|
|
583 the compilation process that shouldn't be in the distribution.
|
|
|
584
|
|
|
585 7. Update the `MANIFEST.txt' file that lists all files in the
|
|
|
586 distribution; on a Linux or UNIX system, you can do this by typing
|
|
|
587 `ls -R1 > MANIFEST.txt' in the main installation directory.
|
|
|
588
|
|
|
589 8. If creating the distribution under DJGPP, run `etc/ctrlmfix.bat'
|
|
|
590 or `etc/ctrlmfix.sh', even if you managed to configure; this will
|
|
|
591 sort out portability problems with newlines.
|
|
|
592
|
|
|
593 9. Create a gzipped tar file containing the installation directory.
|
|
|
594 Its filename should be `ick-', followed by the version number with
|
|
|
595 the dot replaced by a dash, followed by `.tgz'; this form of
|
|
|
596 filename is friendly to DOS.
|
|
|
597
|
|
|
598 10. Place the new version somewhere on the Internet, and announce the
|
|
|
599 location and the fact that a new version has been released on
|
|
|
600 alt.lang.intercal.
|
|
|
601
|
|
|
602
|
|
|
603 2 Invoking ick
|
|
|
604 **************
|
|
|
605
|
|
|
606 All operations on INTERCAL source code available in C-INTERCAL are
|
|
|
607 currently carried out by the compiler `ick'.
|
|
|
608
|
|
|
609 The syntax is
|
|
|
610
|
|
|
611 ick -options INPUTFILE
|
|
|
612
|
|
|
613 (Options can be given preceded by separate hyphens, or all in a row
|
|
|
614 after one hyphen, or a mixture; they're all single characters.) By
|
|
|
615 default, this compiles one INTERCAL program given as the input file
|
|
|
616 directly to an executable without doing anything fancy; usually you will
|
|
|
617 want to give options, which are described below.
|
|
|
618
|
|
|
619 2.1 Language-affecting Options
|
|
|
620 ==============================
|
|
|
621
|
|
|
622 The following command-line options to `ick' affect what dialect of the
|
|
|
623 INTERCAL language is compiled by the compiler; you may need to set one
|
|
|
624 or more of these options if your input is not the default C-INTERCAL but
|
|
|
625 instead some other language like INTERCAL-72 or CLC-INTERCAL, or just
|
|
|
626 because you like certainty or like being different with respect to your
|
|
|
627 output. Note that there is no command-line option corresponding to
|
|
|
628 TriINTERCAL (or the base 4-7 versions); instead, the numeric base to
|
|
|
629 use is determined by looking at the filename extension (`.i' for base
|
|
|
630 2, the default, or `.3i' to `.7i' for the base 3-7 versions.)
|
|
|
631
|
|
|
632 `-b'
|
|
|
633 If this option is _not_ given, there is a small chance that a
|
|
|
634 random bug appears in the compiler, which causes the programs it
|
|
|
635 creates to manifest a bug that causes error E774 (*note E774::).
|
|
|
636 Giving the option means that this bug will not happen. (You may
|
|
|
637 wonder why this bug was preserved; it is in fact a bug that was
|
|
|
638 carefully preserved since the days of INTERCAL-72, in this case,
|
|
|
639 but the option to turn it off is available as a workaround.
|
|
|
640 (There are no plans to fix this or any of the other carefully
|
|
|
641 preserved bugs any time soon, because that would kind of defeat
|
|
|
642 the point of having preserved them.) Interestingly, the
|
|
|
643 INTERCAL-72 compiler documentation mentions a similar command-line
|
|
|
644 option that is a workaround for the same bug.)
|
|
|
645
|
|
|
646 `-m'
|
|
|
647 This option needs to be given to allow any multithreading or
|
|
|
648 backtracking commands or identifiers to be used. (Unlike with
|
|
|
649 other language features, this is not autodetected because it's
|
|
|
650 legal to have a program with multiple COME FROM (*note COME
|
|
|
651 FROM::) commands aiming at the same line even when it isn't
|
|
|
652 multithreaded, in which case the commands cause error E555 (*note
|
|
|
653 E555::) when that line is encountered (with the usual caveats
|
|
|
654 about both commands having to be active at the time).) Attempts
|
|
|
655 to use non-COME FROM multithreading or backtracking commands
|
|
|
656 without this option produce error E405 (*note E405::).
|
|
|
657
|
|
|
658 `-e'
|
|
|
659 This option makes it possible to link non-INTERCAL programs with
|
|
|
660 INTERCAL programs; instead of giving INTERCAL programs only on the
|
|
|
661 command line, give one INTERCAL program, followed by any number of
|
|
|
662 programs in other languages that have been written to be able to
|
|
|
663 link to INTERCAL programs. It also allows expansion libraries to
|
|
|
664 be specified on the command line, after the INTERCAL program
|
|
|
665 (expansion libraries are given with no extension). For more
|
|
|
666 information, see *note External Calls::. Also, both the `-a' and
|
|
|
667 `-e' options must be set to use CREATEd operators (regardless of
|
|
|
668 whether external calls are used or not).
|
|
|
669
|
|
|
670 `-E'
|
|
|
671 This option causes the system library to never be linked; this
|
|
|
672 option is only useful if your program references a line number in
|
|
|
673 the range 1000 to 1999, contains no line numbers in that range,
|
|
|
674 and yet still doesn't want the system library to be linked in;
|
|
|
675 therefore, it is mostly useful with `-e' when adding in a custom
|
|
|
676 replacement system library written in a non-INTERCAL language,
|
|
|
677 especially the expansion library `syslibc' (a system library
|
|
|
678 replacement written in C).
|
|
|
679
|
|
|
680 `-t'
|
|
|
681 This option tells the compiler to treat the source code as
|
|
|
682 INTERCAL-72; as a result, any language constructs that are used
|
|
|
683 but weren't available in 1972 will trigger error E111 (*note
|
|
|
684 E111::).
|
|
|
685
|
|
|
686 `-a'
|
|
|
687 This option allows the CREATE statement (*note CREATE::) to be
|
|
|
688 used. Note that enabling it carries a run-time penalty, as it
|
|
|
689 means that operand overloading code has to be generated for every
|
|
|
690 variable in the program. (This option is not necessarily needed
|
|
|
691 for the external call version of CREATE to work, but the external
|
|
|
692 call version has fewer features without it.) Note that `-e'
|
|
|
693 (*note -e::) also needs to be set to be able to CREATE operators.
|
|
|
694
|
|
|
695 `-v'
|
|
|
696 It is possible to write INTERCAL code sufficiently tortuous that
|
|
|
697 it ends up assigning to a constant. Generally speaking, this
|
|
|
698 isn't what you wanted to do, so the compiler will kindly cause an
|
|
|
699 error (E277; *note E277::) that stops the insanity at that point,
|
|
|
700 but at the cost of a significant amount of performance you can
|
|
|
701 give this option to tell the compiler to simply change the
|
|
|
702 constant and keep on going anyway. (Note that unlike
|
|
|
703 CLC-INTERCAL, this only changes uses of the constant preceded by
|
|
|
704 `#' in your program, not things like line numbers; you want Forte
|
|
|
705 (http://esolangs.org/wiki/Forte) for that.) This option also
|
|
|
706 allows you to write arbitary expressions on the left of an
|
|
|
707 assignment statement if you wish.
|
|
|
708
|
|
|
709 `-C'
|
|
|
710 When this option is given, the generated programs will write the
|
|
|
711 number 4 as `IIII' rather than `IV', in case you're writing a clock
|
|
|
712 program.
|
|
|
713
|
|
|
714 `-P'
|
|
|
715 This tells the compiler to treat the input as PIC-INTERCAL (*note
|
|
|
716 PIC-INTERCAL::) rather than ordinary C-INTERCAL input, and generate
|
|
|
717 PIC output code accordingly. There are a lot of options that are
|
|
|
718 incompatible with this, as well as many language features, due to
|
|
|
719 the limited memory available on a PIC. If you get error E256
|
|
|
720 (*note E256::), you have this option given when it shouldn't be;
|
|
|
721 likewise, if you get error E652 (*note E652::), you should be
|
|
|
722 using this option but aren't. (A few simple programs are
|
|
|
723 C-INTERCAL/PIC-INTERCAL polyglots, but such programs are incapable
|
|
|
724 of doing input or output, meaning that they aren't particularly
|
|
|
725 useful.)
|
|
|
726
|
|
|
727 `-X'
|
|
|
728 The C-INTERCAL and CLC-INTERCAL compilers use different notation
|
|
|
729 for various things, sometimes to the extent where the same
|
|
|
730 notation is legal in both cases but has a different meaning. As
|
|
|
731 this is the C-INTERCAL compiler, it rather guessably uses its own
|
|
|
732 notation by default; however, the CLC-INTERCAL notation can be
|
|
|
733 used as the default instead using this option. (In most
|
|
|
734 situations where there isn't an ambiguity about what something
|
|
|
735 means, you can use the `wrong' syntax freely.) The option causes
|
|
|
736 ambiguous characters like `?' to be interpreted with Princeton
|
|
|
737 rather than Atari meanings.
|
|
|
738
|
|
|
739 `-x'
|
|
|
740 This option causes some constructs with different meanings in
|
|
|
741 C-INTERCAL and CLC-INTERCAL to use the CLC-INTERCAL meaning rather
|
|
|
742 than the C-INTERCAL meaning. At present, it affects the abstention
|
|
|
743 of a GIVE UP (*note GIVE UP::) command by line number, which is
|
|
|
744 possible as long as this switch isn't given; reading through the
|
|
|
745 INTERCAL-72 manual, there are a lot of things that imply that this
|
|
|
746 probably wasn't intended to be possible, but as far as I can tell
|
|
|
747 that manual doesn't actually _say_ anywhere that this particular
|
|
|
748 case is disallowed, even though it rules out all other similar
|
|
|
749 cases. It also causes I/O on array variables to be done in
|
|
|
750 CLC-INTERCAL's extended Baudot syntax, rather than using the
|
|
|
751 Turing Tape method.
|
|
|
752
|
|
|
753
|
|
|
754 2.2 Debug Options
|
|
|
755 =================
|
|
|
756
|
|
|
757 Sometimes things will go wrong with your program, or with the way `ick'
|
|
|
758 was installed. There may even be unknown bugs in `ick' itself (if you
|
|
|
759 find one of these, please report it). The following options are used
|
|
|
760 to debug the whole system on various levels.
|
|
|
761
|
|
|
762 `-d'
|
|
|
763 If you think that something has gone wrong with the parser, or you
|
|
|
764 want to see how your program is being parsed, you can give this
|
|
|
765 option on the command line. All the debug output produced by the
|
|
|
766 parser and lexical analyser will be output.
|
|
|
767
|
|
|
768 `-g'
|
|
|
769 This option allows debugging of the final executable at the C code
|
|
|
770 level. Any C code generated will be left in place, and the `-g'
|
|
|
771 option will be given to the C compiler that's used to compile the
|
|
|
772 code, so all the information needed for a C debugger to be used on
|
|
|
773 the executable will be present there.
|
|
|
774
|
|
|
775 `-h'
|
|
|
776 `-H'
|
|
|
777 `-hH'
|
|
|
778 These options allow debugging of the optimiser, or produce output
|
|
|
779 helpful for understanding how your program has been summarised.
|
|
|
780 `-h' produces a summary of what optimiser rules were used, the
|
|
|
781 initial expression and what it was optimised to; `-H' produces a
|
|
|
782 more expanded view that shows each intermediate step of
|
|
|
783 optimisation, and `-hH' shows the same output as `-H', but written
|
|
|
784 completely using C syntax (the other options output in a strange
|
|
|
785 mix of INTERCAL and C).
|
|
|
786
|
|
|
787 `-l'
|
|
|
788 This option turns on generation of warnings (*note Warnings::).
|
|
|
789 To make sure that they aren't actually useful, or are only
|
|
|
790 marginally useful, the warning generator is far too sensitive, and
|
|
|
791 there is no way to decide which warnings are given and which ones
|
|
|
792 aren't; you either get all of them or none.
|
|
|
793
|
|
|
794 `-p'
|
|
|
795 This option causes the program to run immediately after being
|
|
|
796 compiled, and profiles the resulting program to identify
|
|
|
797 performance bottlenecks, etc. The usefulness of this depends on
|
|
|
798 the resolution of the timers on the computer and operating system;
|
|
|
799 DOS, in particular, is really bad with timer resolution. The
|
|
|
800 output will be saved in a file called `yuk.out' when the program
|
|
|
801 finishes running. It's legal to turn on both the profiler and the
|
|
|
802 interactive debugger at the same time, but if you do this the
|
|
|
803 profiler will also identify bottlenecks in the person typing in
|
|
|
804 commands to step through the program! The profiler will, in fact,
|
|
|
805 identify all the timings that particular commands in the program
|
|
|
806 take; so `WRITE IN' instructions will often show up as taking a
|
|
|
807 long time due to their need to wait for input.
|
|
|
808
|
|
|
809 `-w'
|
|
|
810 This option causes the produced program to support the `printflow'
|
|
|
811 option fully; when this option is not given, `printflow' will in
|
|
|
812 most cases have partial or no support (except in multithreaded
|
|
|
813 programs, where this option is redundant), because not all the
|
|
|
814 code needed for it will be included in the program to save space.
|
|
|
815
|
|
|
816 `-u'
|
|
|
817 When you are getting problems with finding files - for instance,
|
|
|
818 the compiler can't find the skeleton file (*note E999::) or the
|
|
|
819 system library (*note E127::) - this option will let you know, on
|
|
|
820 standard error, where the compiler is looking for files. This may
|
|
|
821 hopefully help you pin down where the file-finding problems are
|
|
|
822 coming from, and also offers the option of simply placing copies
|
|
|
823 of the files where the compiler is looking as a last resort.
|
|
|
824
|
|
|
825 `-y'
|
|
|
826 This is the main debugging option: it loads yuk, an interactive
|
|
|
827 INTERCAL debugger with ability to step through the program, set
|
|
|
828 breakpoints, view and modify variables, etc. *Note yuk::.
|
|
|
829
|
|
|
830 `-Y'
|
|
|
831 This options causes the command line to be displayed for all calls
|
|
|
832 to other programs that `ick' makes (mostly to `gcc'); it is
|
|
|
833 therefore useful for debugging problems with the command lines used
|
|
|
834 when using the external calls system (*note External Calls::).
|
|
|
835
|
|
|
836 `-U'
|
|
|
837 The internal error E778 (*note E778::) should never happen.
|
|
|
838 However, there are all sorts of potential problems that may come
|
|
|
839 up, and if part of the code detects something impossible, or more
|
|
|
840 usually when the operating system detects things have got too
|
|
|
841 insane and segfaults, normally this error will just be generated
|
|
|
842 and that's that. (I most often get this when I've been writing a
|
|
|
843 new section of code and have made a mistake; hopefully, all or at
|
|
|
844 least most of these errors are fixed before release, though.) If
|
|
|
845 you want more information as to what's going on, you can give the
|
|
|
846 `-U' option, which will cause the compiler to raise an abort
|
|
|
847 signal when an internal error happens. This can generally be
|
|
|
848 caught by a debugger that's being run on `ick' itself at the time;
|
|
|
849 on many systems, it will also cause a core dump.
|
|
|
850
|
|
|
851
|
|
|
852 2.3 Output Options
|
|
|
853 ==================
|
|
|
854
|
|
|
855 These options allow you to control how far to compile (all the way to an
|
|
|
856 executable, or only to C, etc.), and where the output will be created.
|
|
|
857 Note that the output options may change depending on the other options
|
|
|
858 selected; for instance, many of the debug options will prevent the code
|
|
|
859 being compiled all the way to an executable.
|
|
|
860
|
|
|
861 `-c'
|
|
|
862 By default, the original INTERCAL code will be compiled all the
|
|
|
863 way to an executable, and the intermediate C and object files
|
|
|
864 produced will be deleted. Giving this option causes the compiler
|
|
|
865 to stop when it has finished producing the C file, leaving the C
|
|
|
866 file there as the final output of the compiler. (Its filename is
|
|
|
867 the same as the source file, but with `.c' as its extension/suffix
|
|
|
868 rather than the source file's extension.) Without this option, an
|
|
|
869 executable will be produced with the extension changed to
|
|
|
870 whatever's appropriate for the system you are on (or omitted
|
|
|
871 entirely if that's appropriate for the system).
|
|
|
872
|
|
|
873 This option also places verbose comments in the output C file.
|
|
|
874
|
|
|
875 `-o'
|
|
|
876 This option causes the compiler to progress no further than
|
|
|
877 producing the C output file, but instead of writing it to a file
|
|
|
878 writes it directly to standard output. This might occasionally be
|
|
|
879 useful when using `ick' as part of a pipe; it can also be useful
|
|
|
880 to see how far the compiler gets with compiling code before an
|
|
|
881 error happens, when you're trying to track down an error.
|
|
|
882
|
|
|
883
|
|
|
884 2.4 Optimizer Options
|
|
|
885 =====================
|
|
|
886
|
|
|
887 There are various command line options that can be used to tell `ick'
|
|
|
888 whether and in what ways to optimize code.
|
|
|
889
|
|
|
890 `-f'
|
|
|
891 This option requests the compiler to attempt to analyse the flow
|
|
|
892 of the program and optimize accordingly; for instance, it will
|
|
|
893 detect which commands can't possibly be `ABSTAINED' from and
|
|
|
894 refrain from generating code to check the abstention status of
|
|
|
895 those commands.
|
|
|
896
|
|
|
897 `-F'
|
|
|
898 This option tells the compiler to optimize the output for speed.
|
|
|
899 This is done to crazy extremes; the compiler may take several
|
|
|
900 hours/days analysing the program in some cases and still not come
|
|
|
901 up with an improvement. It turns on all the other optimizer
|
|
|
902 options. Note that not all systems accept this option, because it
|
|
|
903 sometimes outputs a shell script disguised as an executable rather
|
|
|
904 than an actual executable.
|
|
|
905
|
|
|
906 `-O'
|
|
|
907 This option tells the compiler to apply optimizer idioms to the
|
|
|
908 expressions in the code given, when appropriate. The list of
|
|
|
909 idioms is stored in the file `src/idiotism.oil'; note that it is
|
|
|
910 compiled into the compiler, though, so you will have to rebuild
|
|
|
911 and reinstall the compiler if you change it. For more information
|
|
|
912 about changing the list of idioms, see *note Optimizer Idiom
|
|
|
913 Language::.
|
|
|
914
|
|
|
915
|
|
|
916 2.5 Other Options
|
|
|
917 =================
|
|
|
918
|
|
|
919 Some options just can't be classified.
|
|
|
920
|
|
|
921 `-@'
|
|
|
922 If this option is given, the compiler doesn't run at all, but
|
|
|
923 instead prints a set of instructions for using it, explaining
|
|
|
924 which options are available on the system you're on and which
|
|
|
925 options conflict with which other options.
|
|
|
926
|
|
|
927
|
|
|
928 2.6 Options to Generated Programs
|
|
|
929 =================================
|
|
|
930
|
|
|
931 Once the compiler runs and produces an output executable, that
|
|
|
932 executable itself will accept a range of options that control the way it
|
|
|
933 runs. None of these options have to be used; a default value will be
|
|
|
934 assumed if they aren't.
|
|
|
935
|
|
|
936 `+help'
|
|
|
937 `-help'
|
|
|
938 Whether `+' or `-' is given at the start of this option, it will
|
|
|
939 cause the program to print out what options are available and what
|
|
|
940 state they are in. It will then cause the program to exit via an
|
|
|
941 internal error.
|
|
|
942
|
|
|
943 `+wimpmode'
|
|
|
944 `-wimpmode'
|
|
|
945 If the `+' version of this is given (rather than the default `-'),
|
|
|
946 then the program will print a message explaining that you are a
|
|
|
947 wimp (the mode itself is known as wimpmode), and for the rest of
|
|
|
948 execution will input in Arabic numerals (`123' rather than `ONE
|
|
|
949 TWO THREE') and likewise will output in Arabic numerals rather
|
|
|
950 than Roman numerals (such as `CXXIII'). True INTERCAL programmers
|
|
|
951 should rarely have to use this mode.
|
|
|
952
|
|
|
953 `+traditional'
|
|
|
954 `-traditional'
|
|
|
955 This option does not actually appear to do anything.
|
|
|
956
|
|
|
957 `+instapipe'
|
|
|
958 `-instapipe'
|
|
|
959 This option causes standard output to be flushed whenever any
|
|
|
960 characters are output when the `+' version is used, rather than on
|
|
|
961 each newline (the default `-' version). It is most useful for
|
|
|
962 more responsive pipes when outputting binary data, and also useful
|
|
|
963 for debugging very slow programs.
|
|
|
964
|
|
|
965 `+printflow'
|
|
|
966 `-printflow'
|
|
|
967 The usual debugging methods don't work with multithreaded or
|
|
|
968 backtracking programs. This option exists to give at least a slim
|
|
|
969 chance of working out what is going on with them. It causes the
|
|
|
970 program to print the line number of the command it thinks it may be
|
|
|
971 executing next (i.e. the line number that would be printed if that
|
|
|
972 line had an error) immediately after executing each command, and
|
|
|
973 also an internal identifier for the thread that that command was
|
|
|
974 in. It also prints a trace of what parts of the multithreader are
|
|
|
975 being activated; so for instance, it will tell you when a thread
|
|
|
976 is being forked into multiple threads or when a choicepoint has
|
|
|
977 been deleted. Note that the `-w' option (*note -w::) must be
|
|
|
978 given to gain full support for flow printing in non-multithreaded
|
|
|
979 non-backtracking programs, because otherwise the required code to
|
|
|
980 print this information will not be generated.
|
|
|
981
|
|
|
982 `+mystery'
|
|
|
983 `-mystery'
|
|
|
984 This option is occasionally capable of doing something, but is
|
|
|
985 deliberately undocumented. Normally changing it will have no
|
|
|
986 effect, but changing it is not recommended.
|
|
|
987
|
|
|
988
|
|
|
989 2.7 Environment Variables
|
|
|
990 =========================
|
|
|
991
|
|
|
992 Various environment variables can be set to affect the operation of
|
|
|
993 `ick'.
|
|
|
994
|
|
|
995 Variable Meaning
|
|
|
996 --------------------------------------------------------------------------
|
|
|
997 ICKINCLUDEDIR These three environment variables suggest
|
|
|
998 ICKLIBDIR locations in which `ick' should look to find
|
|
|
999 ICKDATADIR various files that it needs: the skeleton file,
|
|
|
1000 system library, C header files and libraries that
|
|
|
1001 it needs, constant-output optimiser, and the GNU
|
|
|
1002 General Public License (which the debugger needs
|
|
|
1003 to be able to display on demand for legal
|
|
|
1004 reasons).
|
|
|
1005 CC The name of a C compiler to use (defaults to gcc,
|
|
|
1006 which is the only compiler with which C-INTERCAL
|
|
|
1007 has been tested recently). This option has no
|
|
|
1008 effect on DJGPP, where gcc is always used.
|
|
|
1009 ICKTEMP On DJGPP, `ick' creates temporary files to pass
|
|
|
1010 TMPDIR options to gcc as a method of getting around the
|
|
|
1011 TEMP limit on the length of a command line that can
|
|
|
1012 TMP sometimes affect DOS programs. These four
|
|
|
1013 environment variables are tried (in this order)
|
|
|
1014 to determine a location for the temporary file;
|
|
|
1015 if none of them are set, the current directory is
|
|
|
1016 used.
|
|
|
1017
|
|
|
1018 3 Errors and Warnings
|
|
|
1019 *********************
|
|
|
1020
|
|
|
1021 Things may go wrong, either during the compilation or the execution of
|
|
|
1022 your program. Note that some things that would be compile-time errors
|
|
|
1023 in many other languages - such as syntax errors - are in fact run-time
|
|
|
1024 errors in INTERCAL.
|
|
|
1025
|
|
|
1026 Errors and warnings appear as an error code starting with `ICL',
|
|
|
1027 followed by a three digit number, followed by `I' for an error or `W'
|
|
|
1028 for a warning. However, they will be notated here as `E000', etc., to
|
|
|
1029 save space and because consistency was never a strong point of
|
|
|
1030 INTERCAL. This is followed by a text description of the error, and a
|
|
|
1031 hint as to the location of the error. This is not the line on which
|
|
|
1032 the error occurred, but rather the line on which the next command to be
|
|
|
1033 executed is. To add to the fun, the calculation of the next command to
|
|
|
1034 be executed is done at compile-time rather than runtime, so it may be
|
|
|
1035 completely wrong due to things like abstention on `COME FROM's or
|
|
|
1036 computed `COME FROM's. The moral of this story is that, if you really
|
|
|
1037 want to know where the error is, use a debugger. Note also that if the
|
|
|
1038 error happens at compile-time, there is no guarantee that the line
|
|
|
1039 number given makes any sense at all. Some errors don't give next line
|
|
|
1040 numbers, mostly those for which it doesn't make logical sense, such as
|
|
|
1041 E633 (*note E633::). After this is a suggestion to correct (or
|
|
|
1042 reconsider) the source code and to resubnit it. (This typo has been
|
|
|
1043 carefully preserved for over a decade.)
|
|
|
1044
|
|
|
1045 3.1 Errors
|
|
|
1046 ==========
|
|
|
1047
|
|
|
1048 This is a list of the error messages that might be produced during the
|
|
|
1049 compilation or execution of an INTERCAL program.
|
|
|
1050
|
|
|
1051 E000
|
|
|
1052 This is an unusual error; it's what's printed when a syntax error
|
|
|
1053 is encounted at runtime, in a situation in which it would be
|
|
|
1054 executed. (An `ABSTAIN'ed syntax error, for instance, would not
|
|
|
1055 be executed; this is one of the mechanisms available for writing
|
|
|
1056 comments.) The text of the error message is simply the statement
|
|
|
1057 that couldn't be decoded.
|
|
|
1058
|
|
|
1059 E017
|
|
|
1060 DO YOU EXPECT ME TO FIGURE THIS OUT?
|
|
|
1061
|
|
|
1062 This error occurs when there is an attempt to use a constant with a
|
|
|
1063 value outside the onespot range; it's a compile-time error.
|
|
|
1064
|
|
|
1065 E079
|
|
|
1066 PROGRAMMER IS INSUFFICIENTLY POLITE
|
|
|
1067
|
|
|
1068 The balance between various statement identifiers is important.
|
|
|
1069 If less than approximately one fifth of the statement identifiers
|
|
|
1070 used are the polite versions containing `PLEASE', that causes this
|
|
|
1071 error at compile time.
|
|
|
1072
|
|
|
1073 E099
|
|
|
1074 PROGRAMMER IS OVERLY POLITE
|
|
|
1075
|
|
|
1076 Of course, the same problem can happen in the other direction; this
|
|
|
1077 error is caused at compile time if over about one third of the
|
|
|
1078 statement identifiers are the polite form.
|
|
|
1079
|
|
|
1080 E111
|
|
|
1081 COMMUNIST PLOT DETECTED, COMPILER IS SUICIDING
|
|
|
1082
|
|
|
1083 This error happens when you give the `-t' option (*note -t::) but
|
|
|
1084 you use a language construct that wasn't available in INTERCAL-72.
|
|
|
1085 If this happens, then either there's a mistake in the program that
|
|
|
1086 prevents it being INTERCAL-72 or you shouldn't be compiling it as
|
|
|
1087 INTERCAL-72 in the first place.
|
|
|
1088
|
|
|
1089 E123
|
|
|
1090 PROGRAM HAS DISAPPEARED INTO THE BLACK LAGOON
|
|
|
1091
|
|
|
1092 There is a hard limit of 80 `NEXT's at a time; this is to
|
|
|
1093 discourage excessive use of `NEXTING' for things like recursion.
|
|
|
1094 (Recursive programs are entirely legal; you simply have to figure
|
|
|
1095 out how to do it with computed `COME FROM' instead. (For the
|
|
|
1096 record, it is possible. (Using lots of nested brackets when
|
|
|
1097 talking about recursion is great (yay!).))) Another problem with
|
|
|
1098 writing the source code that can cause this error is a failure to
|
|
|
1099 properly `FORGET' the entry on the `NEXT' stack created when
|
|
|
1100 trying to simulate a goto.
|
|
|
1101
|
|
|
1102 E127
|
|
|
1103 SAYING 'ABRACADABRA' WITHOUT A MAGIC WAND WON'T DO YOU ANY
|
|
|
1104 GOOD
|
|
|
1105 Your program asked to include the system library (by specifying a
|
|
|
1106 line number from 1000 to 1999 inclusive without including a line
|
|
|
1107 with that number), but due to installation problems the compiler
|
|
|
1108 couldn't find the system library to include. You could try using
|
|
|
1109 the `-u' (*note -u::) option to see where the compiler's looking;
|
|
|
1110 that may give you an idea of where you need to copy the system
|
|
|
1111 library so that the compilation will work. This error happens at
|
|
|
1112 compile time and doesn't give a next command line number.
|
|
|
1113
|
|
|
1114 E129
|
|
|
1115 PROGRAM HAS GOTTEN LOST
|
|
|
1116
|
|
|
1117 This error happens at compile time when the compiler can't figure
|
|
|
1118 out where a `NEXT' command is actually aiming (normally due to a
|
|
|
1119 typo in either the line label given or the line label on the line
|
|
|
1120 aimed for). The logic behind this error means that the next line
|
|
|
1121 to be executed is unknown (after all, that's the whole point of
|
|
|
1122 the error) and is therefore not given. The `-e' command-line
|
|
|
1123 option (*note -e::) makes this error into a run-time error,
|
|
|
1124 because it allows `NEXT' commands to dynamically change targets at
|
|
|
1125 runtime, as well as line labels to dynamically change values, and
|
|
|
1126 thus the error is impossible to detect at compile time.
|
|
|
1127
|
|
|
1128 E139
|
|
|
1129 I WASN'T PLANNING TO GO THERE ANYWAY
|
|
|
1130
|
|
|
1131 This error happens at compile time when an `ABSTAIN' or
|
|
|
1132 `REINSTATE' references a non-existent target line. This generally
|
|
|
1133 happens for much the same reasons as E129 (*note E129::).
|
|
|
1134
|
|
|
1135 E182
|
|
|
1136 YOU MUST LIKE THIS LABEL A LOT!
|
|
|
1137
|
|
|
1138 At present, it's impossible to have more than one line with the
|
|
|
1139 same line number. That would make `NEXT' act too much like `COME
|
|
|
1140 FROM' in reverse to be interesting. This error happens at compile
|
|
|
1141 time. (For inconsistency, it is possible to have multiple lines
|
|
|
1142 with the same number as long as at most one of them is in an
|
|
|
1143 INTERCAL program (the others have to be in programs in other
|
|
|
1144 languages included via the external calls system).)
|
|
|
1145
|
|
|
1146 E197
|
|
|
1147 SO! 65535 LABELS AREN'T ENOUGH FOR YOU?
|
|
|
1148
|
|
|
1149 Legal values for line labels are 1 to 65535 (with values from 1000
|
|
|
1150 to 1999 reserved if you want to use the system library, and 1600
|
|
|
1151 to 1699 reserved if you're using other expansion libraries). This
|
|
|
1152 error comes up if you use nonpositive or twospot values for a line
|
|
|
1153 label.
|
|
|
1154
|
|
|
1155 E200
|
|
|
1156 NOTHING VENTURED, NOTHING GAINED
|
|
|
1157
|
|
|
1158 You used a variable that isn't actually in your program. Failing
|
|
|
1159 that (which would be quite impressive and is probably impossible,
|
|
|
1160 at least in the present version of C-INTERCAL), you specified an
|
|
|
1161 illegal number for a variable (legal numbers are positive and
|
|
|
1162 onespot). This error happens at compile time, at least for
|
|
|
1163 illegal variable numbers.
|
|
|
1164
|
|
|
1165 E222
|
|
|
1166 BUMMER, DUDE!
|
|
|
1167
|
|
|
1168 In INTERCAL, you're allowed to `STASH' as much as you like; this
|
|
|
1169 makes the language Turing-complete and allows for unlimited
|
|
|
1170 recursion when combined with computed `COME FROM' in the right way.
|
|
|
1171 Unfortunately, real computers aren't so idealised; if you manage to
|
|
|
1172 write a program so memory-intensive that the computer runs out of
|
|
|
1173 memory to store stashes, it causes this error at runtime. To fix
|
|
|
1174 this error, you either have to simplify the program or upgrade
|
|
|
1175 your computer's memory, and even then that will only help to some
|
|
|
1176 extent.
|
|
|
1177
|
|
|
1178 E240
|
|
|
1179 ERROR HANDLER PRINTED SNIDE REMARK
|
|
|
1180
|
|
|
1181 Arrays have to be large enough to hold at least one element; you
|
|
|
1182 tried to dimension an array which isn't large enough to hold any
|
|
|
1183 data. This error happens at run time.
|
|
|
1184
|
|
|
1185 E241
|
|
|
1186 VARIABLES MAY NOT BE STORED IN WEST HYPERSPACE
|
|
|
1187
|
|
|
1188 This error happens at run time when the subscripts given to an
|
|
|
1189 array are inconsistent with the way the array was dimensioned,
|
|
|
1190 either because there were the wrong number of subscripts or
|
|
|
1191 because a subscript was too large to fit in the array. It can
|
|
|
1192 also happen when a multidimensional array is given to a command,
|
|
|
1193 such as `WRITE IN', that expects it to be monodimensional.
|
|
|
1194
|
|
|
1195 E252
|
|
|
1196 I'VE FORGOTTEN WHAT I WAS ABOUT TO SAY
|
|
|
1197
|
|
|
1198 This run-time error message is caused by the compiler running out
|
|
|
1199 of memory whilst trying to do I/O; at present, it can only happen
|
|
|
1200 during CLC-INTERCAL-style I/O.
|
|
|
1201
|
|
|
1202 E256
|
|
|
1203 THAT'S TOO HARD FOR MY TINY BRAIN
|
|
|
1204
|
|
|
1205 Some commands simply aren't available in PIC-INTERCAL. I mean,
|
|
|
1206 PICs generally have less than a kilobyte of memory; you're not
|
|
|
1207 going to be able to use some of the more confusing language
|
|
|
1208 features with that sort of resource limitation. The solution is
|
|
|
1209 to replace the affected command, or to not give the `-P' option
|
|
|
1210 (*note -P: -P+.) if you didn't mean to compile as PIC-INTERCAL in
|
|
|
1211 the first place.
|
|
|
1212
|
|
|
1213 E275
|
|
|
1214 DON'T BYTE OFF MORE THAN YOU CAN CHEW
|
|
|
1215
|
|
|
1216 This error happens when there is an attempt to store a twospot
|
|
|
1217 value in a onespot variable. The actual size of the value is what
|
|
|
1218 matters when counting its spots; so you can store the output of a
|
|
|
1219 mingle in a onespot variable if it happens to be less than or
|
|
|
1220 equal to 65535, for instance. (This is not necessarily the case
|
|
|
1221 in versions of INTERCAL other than C-INTERCAL, though, so you have
|
|
|
1222 to be careful with portability when doing this.)
|
|
|
1223
|
|
|
1224 E277
|
|
|
1225 YOU CAN ONLY DISTORT THE LAWS OF MATHEMATICS SO FAR
|
|
|
1226
|
|
|
1227 Reverse assignments are not always mathematically possible. Also,
|
|
|
1228 sometimes they require changing the value of a constant; this is
|
|
|
1229 only legal if you specifically specified that it was legal by
|
|
|
1230 using the `-v' option. In the case of an impossible reverse
|
|
|
1231 assignment (including a situation in which operand overloading
|
|
|
1232 causes a reverse assignment to happen), this error happens at
|
|
|
1233 runtime.
|
|
|
1234
|
|
|
1235 This error can also come up when a scalar variable is overloaded
|
|
|
1236 to an array (which doesn't make sense, but could happen if someone
|
|
|
1237 exploited bugs in the CREATE statement (*note CREATE::)), and an
|
|
|
1238 attempt is made to read or assign to that variable. (Subscripting
|
|
|
1239 a scalar variable is a syntax error, so there is no use for doing
|
|
|
1240 such an overload anyway.)
|
|
|
1241
|
|
|
1242 E281
|
|
|
1243 THAT MUCH QUOTATION AMOUNTS TO PLAGIARISM
|
|
|
1244
|
|
|
1245 There is a limit of 256 on the number of nested spark/ears groups
|
|
|
1246 allowed. If you somehow manage to exceed that limit, that will
|
|
|
1247 cause this error. Try breaking the expression up into smaller
|
|
|
1248 expressions. (The limit is trivial to increase by changing
|
|
|
1249 `SENESTMAX' in `ick.h'; if you ever actually come across a program
|
|
|
1250 that hits the limit but wasn't designed to, just email the
|
|
|
1251 maintainer to request a higher limit.)
|
|
|
1252
|
|
|
1253 E333
|
|
|
1254 YOU CAN'T HAVE EVERYTHING, WHERE WOULD YOU PUT IT?
|
|
|
1255
|
|
|
1256 Your program references so many variables that the compiler
|
|
|
1257 couldn't cope. This error is unlikely to ever happen; if it does,
|
|
|
1258 try reducing the number of variables you use by combining some
|
|
|
1259 into arrays. This is a compile-time error.
|
|
|
1260
|
|
|
1261 E345
|
|
|
1262 THAT'S TOO COMPLEX FOR ME TO GRASP
|
|
|
1263
|
|
|
1264 This is another compile-time error that's unlikely to ever happen;
|
|
|
1265 this one signifies the compiler itself running out of memory
|
|
|
1266 trying to compile your program. The only solutions to this are to
|
|
|
1267 simplify your program, or to make more memory available to the
|
|
|
1268 compiler.
|
|
|
1269
|
|
|
1270 E404
|
|
|
1271 I'M ALL OUT OF CHOICES!
|
|
|
1272
|
|
|
1273 Your program asked that a choicepoint be backtracked to or
|
|
|
1274 removed, but there aren't any choicepoints at the moment. This
|
|
|
1275 runtime error usually indicates a logic mistake in your program.
|
|
|
1276 In backtracking programs translated from other backtracking
|
|
|
1277 languages, this indicates that the program has failed.
|
|
|
1278
|
|
|
1279 E405
|
|
|
1280 PROGRAM REJECTED FOR MENTAL HEALTH REASONS
|
|
|
1281
|
|
|
1282 Your program used a construct that only makes sense when
|
|
|
1283 multithreading or backtracking (`WHILE', `MAYBE', `GO BACK', or `GO
|
|
|
1284 AHEAD'), but you didn't specify the `-m' option (*note -m::). If
|
|
|
1285 you meant to write a multithreaded or backtracking program, just
|
|
|
1286 give that option; if you didn't, be careful what words you use in
|
|
|
1287 comments! This error happens at compile-time.
|
|
|
1288
|
|
|
1289 E436
|
|
|
1290 THROW STICK BEFORE RETRIEVING!
|
|
|
1291
|
|
|
1292 In order to `RETRIEVE' a variable, it has to be `STASH'ed first;
|
|
|
1293 if it isn't, then this error happens at runtime.
|
|
|
1294
|
|
|
1295 E444
|
|
|
1296 IT CAME FROM BEYOND SPACE
|
|
|
1297
|
|
|
1298 A `COME FROM' aiming at a line label -- as opposed to a computed
|
|
|
1299 `COME FROM', which is allowed to be pointing at a nonexistent line
|
|
|
1300 -- must point to a valid line label. The same applies to `NEXT
|
|
|
1301 FROM'. This error happens at compile time if a nonexistent line
|
|
|
1302 label is found in one of these contexts.
|
|
|
1303
|
|
|
1304 E533
|
|
|
1305 YOU WANT MAYBE WE SHOULD IMPLEMENT 64-BIT VARIABLES?
|
|
|
1306
|
|
|
1307 This error is like E275 (*note E275::), but applies when an
|
|
|
1308 attempt is made at runtime to store a threespot value (or even a
|
|
|
1309 fourspot or morespot value) in a twospot variable, or a threespot
|
|
|
1310 or greater value is produced as an intermediate during a
|
|
|
1311 calculation (for instance by a mingle operation). No values above
|
|
|
1312 twospot are allowed at any point during an INTERCAL program; if
|
|
|
1313 you want to process higher numbers, you have to figure out a
|
|
|
1314 different way of storing them.
|
|
|
1315
|
|
|
1316 E555
|
|
|
1317 FLOW DIAGRAM IS EXCESSIVELY CONNECTED
|
|
|
1318
|
|
|
1319 Aiming two `COME FROM's at the same line only makes sense in a
|
|
|
1320 multithreaded program. In a non-multithread program, doing that
|
|
|
1321 will cause this error at compile time (if neither `COME FROM' is
|
|
|
1322 computed) or at run time (if the command that has just finished
|
|
|
1323 running is simultaneously the target of two or more `COME FROM's).
|
|
|
1324 This either indicates an error in your program or that you've
|
|
|
1325 forgotten to use the `-m' option (*note -m::) if you are actually
|
|
|
1326 trying to split the program into two threads.
|
|
|
1327
|
|
|
1328 E562
|
|
|
1329 I DO NOT COMPUTE
|
|
|
1330
|
|
|
1331 The program asked for input, but for some reason it wasn't
|
|
|
1332 available. (This is a runtime error, obviously.) The error may
|
|
|
1333 happen because the input is being piped in from a command or file
|
|
|
1334 which has reached end-of-file, or because the user typed
|
|
|
1335 `<CTRL>-<D>' (UNIX/Linux) or `<CTRL>-<Z>' (DOS/Windows) while the
|
|
|
1336 program was trying to `WRITE IN' some data.
|
|
|
1337
|
|
|
1338 E579
|
|
|
1339 WHAT BASE AND/OR LANGUAGE INCLUDES STRING?
|
|
|
1340
|
|
|
1341 When reading spelt-out-digit input, the input didn't seem to be a
|
|
|
1342 valid digit in English, Sanskrit, Basque, Tagalog, Classical
|
|
|
1343 Nahuatl, Georgian, Kwakiutl, Volapük, or Latin. This seems to
|
|
|
1344 have languages covered pretty well; what on earth were you using,
|
|
|
1345 or did you just make a spelling mistake?
|
|
|
1346
|
|
|
1347 E621
|
|
|
1348 ERROR TYPE 621 ENCOUNTERED
|
|
|
1349
|
|
|
1350 The compiler encountered error E621 (*note E621::). This happens
|
|
|
1351 at runtime when the program requests that no entries are removed
|
|
|
1352 from the `NEXT' stack (which is possible), but that the last entry
|
|
|
1353 removed should be jumped to (which given the circumstances isn't,
|
|
|
1354 because no entries were removed).
|
|
|
1355
|
|
|
1356 E632
|
|
|
1357 THE NEXT STACK RUPTURES. ALL DIE. OH, THE EMBARRASSMENT!
|
|
|
1358
|
|
|
1359 When an attempt is made to `RESUME' past the end of the `NEXT'
|
|
|
1360 stack, the program ends; however, this cause the program to end in
|
|
|
1361 a manner other than via `GIVE UP' or `DON'T TRY AGAIN', so an
|
|
|
1362 error message must be printed, and this is that error message.
|
|
|
1363
|
|
|
1364 E633
|
|
|
1365 PROGRAM FELL OFF THE EDGE
|
|
|
1366
|
|
|
1367 You can't just let execution run off the end of the program. At
|
|
|
1368 least, that is, if it doesn't end with `TRY AGAIN'. An attempt to
|
|
|
1369 do that causes this error at runtime. Note that if your program
|
|
|
1370 references the system library, then it counts as being appended to
|
|
|
1371 your program and so the program will run into the first line of
|
|
|
1372 the system library rather than cause this error. As it happens,
|
|
|
1373 the first line of the system library is a syntax error, so doing
|
|
|
1374 this will cause E000 (*note E000::) with the error text `PLEASE
|
|
|
1375 KNOCK BEFORE ENTERING'. There isn't a next statement to be
|
|
|
1376 executed with E633, so the next statement won't be given in the
|
|
|
1377 error message.
|
|
|
1378
|
|
|
1379 E652
|
|
|
1380 HOW DARE YOU INSULT ME!
|
|
|
1381
|
|
|
1382 The `PIN' command doesn't make much sense for anything bigger than
|
|
|
1383 a PIC; using it in a non-PIC program causes this error at
|
|
|
1384 compile-time. Try using the normal input and output mechanisms
|
|
|
1385 instead. This error may also be a clue that you are trying to
|
|
|
1386 compile a PIC-INTERCAL program without giving the `-P' option
|
|
|
1387 (*note -P: -P+.).
|
|
|
1388
|
|
|
1389 E666
|
|
|
1390 COMPILER HAS INDIGESTION
|
|
|
1391
|
|
|
1392 There isn't a limit on the length of an input program other than
|
|
|
1393 your computer's memory; if your computer does run out of memory
|
|
|
1394 during compilation, it causes this error. This error can also be
|
|
|
1395 caused if too many input files are specified on the command line;
|
|
|
1396 if you suspect this is the problem, split the compilation into
|
|
|
1397 separate compilations if you can, or otherwise you may be able to
|
|
|
1398 concatenate together your input files into larger but fewer files.
|
|
|
1399 Yet another potential cause of this error is if a line in an input
|
|
|
1400 program is too long; sensible line-wrapping techniques are
|
|
|
1401 encouraged.
|
|
|
1402
|
|
|
1403 E774
|
|
|
1404 RANDOM COMPILER BUG
|
|
|
1405
|
|
|
1406 No compiler is perfect; sometimes errors just happen at random.
|
|
|
1407 In this case, the random error is E774. If you don't like the
|
|
|
1408 idea that your program may be shot down by a random compiler bug,
|
|
|
1409 or you are doing something important, you can use the `-b' option
|
|
|
1410 (*note -b::) to prevent this bug happening. (You may wonder why
|
|
|
1411 this bug is in there at all if it's so easily prevented. The
|
|
|
1412 answer is that such a bug was present in the original INTERCAL-72
|
|
|
1413 compiler, which also had an option to turn the bug off. It's also
|
|
|
1414 a reward for people who actually read the manual.)
|
|
|
1415
|
|
|
1416 E777
|
|
|
1417 A SOURCE IS A SOURCE, OF COURSE, OF COURSE
|
|
|
1418
|
|
|
1419 You specified a file to compile on the command line, but the
|
|
|
1420 compiler couldn't find or couldn't open it. This is almost
|
|
|
1421 certainly because you made a typo specifying the file.
|
|
|
1422
|
|
|
1423 E778
|
|
|
1424 UNEXPLANED COMPILER BUG
|
|
|
1425
|
|
|
1426 This should never come up, either at compile time or at run time.
|
|
|
1427 It could come up at either when an internal check by the compiler
|
|
|
1428 or the runtime libraries realises that something has gone badly
|
|
|
1429 wrong; mistakes happen, and in such cases the mistake will have
|
|
|
1430 been detected. (If this happens at compile time you can use the
|
|
|
1431 `-U' option (*note -U: -U+.) to cause the compiler to send an
|
|
|
1432 abort signal - which normally causes a core dump - when the error
|
|
|
1433 happens, to help debug what's causing it.) More often, this error
|
|
|
1434 comes up when the operating system has noticed something
|
|
|
1435 impossible, like an attempt to free allocated memory twice or to
|
|
|
1436 write to a null pointer, and tells the compiler an error has
|
|
|
1437 occured, in which case the same response of putting up this error
|
|
|
1438 happens. The point is that in all cases this error indicates a
|
|
|
1439 bug in the compiler (even if it happens at run time); in such
|
|
|
1440 cases, it would be very helpful if you figure out what caused it
|
|
|
1441 and send a bug report (*note Reporting Bugs::).
|
|
|
1442
|
|
|
1443 E810
|
|
|
1444 ARE ONE-CHARACTER COMMANDS TOO SHORT FOR YOU?
|
|
|
1445
|
|
|
1446 This is a debug-time error caused when you give too much input to
|
|
|
1447 the debugger when all it wanted was to know what you wanted to do
|
|
|
1448 next.
|
|
|
1449
|
|
|
1450 E811
|
|
|
1451 PROGRAM IS TOO BADLY BROKEN TO RUN
|
|
|
1452
|
|
|
1453 There's a limit to how many breakpoints you can have in a program;
|
|
|
1454 you've broken the limit and therefore broken the debugger. This
|
|
|
1455 is a debug-time error.
|
|
|
1456
|
|
|
1457 E888
|
|
|
1458 I HAVE NO FILE AND I MUST SCREAM
|
|
|
1459
|
|
|
1460 The output file couldn't be written, maybe because the disk is
|
|
|
1461 full or because there's already a read-only file with the same
|
|
|
1462 name. This is a compile-time error.
|
|
|
1463
|
|
|
1464 E899
|
|
|
1465 HELLO? CAN ANYONE GIVE ME A HAND HERE?
|
|
|
1466
|
|
|
1467 This error occurs at compile-time if a file type was requested for
|
|
|
1468 which the required libraries are unavailable. (Support for Funge
|
|
|
1469 does not ship with the compiler; instead, you need to generate the
|
|
|
1470 library yourself from the cfunge sources. For more information,
|
|
|
1471 see *note Creating the Funge-98 Library::.)
|
|
|
1472
|
|
|
1473 E991
|
|
|
1474 YOU HAVE TOO MUCH ROPE TO HANG YOURSELF
|
|
|
1475
|
|
|
1476 There is no limit on the number of threads or choicepoints that
|
|
|
1477 you can have in a multithreaded or backtracking program (in a
|
|
|
1478 program that isn't multithreaded or backtracking, these are
|
|
|
1479 obviously limited to 1 and 0 respectively). However, your
|
|
|
1480 computer may not be able to cope; if it runs out of memory in the
|
|
|
1481 multithreader, it will cause this error at runtime.
|
|
|
1482
|
|
|
1483 E993
|
|
|
1484 I GAVE UP LONG AGO
|
|
|
1485
|
|
|
1486 `TRY AGAIN' has to be the last command in a program, if it's there
|
|
|
1487 at all; you can't even follow it by comments, not even if you know
|
|
|
1488 in advance that they won't be `REINSTATE'd. This error happens at
|
|
|
1489 compile time if a command is found after a `TRY AGAIN'.
|
|
|
1490
|
|
|
1491 E995
|
|
|
1492 DO YOU REALLY EXPECT ME TO HAVE IMPLEMENTED THAT?
|
|
|
1493
|
|
|
1494 Some parts of the code haven't been written yet. There ought to
|
|
|
1495 be no way to cause those to actually run; however, if you do
|
|
|
1496 somehow find a way to cause them to run, they will cause this
|
|
|
1497 error at compile time.
|
|
|
1498
|
|
|
1499 E997
|
|
|
1500 ILLEGAL POSSESSION OF A CONTROLLED UNARY OPERATOR
|
|
|
1501
|
|
|
1502 Some operators (such as whirlpool (`@') and sharkfin (`^')) only
|
|
|
1503 make sense in TriINTERCAL programs, and some have a minimum base
|
|
|
1504 in which they make sense. This error happens at compile-time if
|
|
|
1505 you try to use an operator that conflicts with the base you're in
|
|
|
1506 (such as using TriINTERCAL operators in an INTERCAL program in the
|
|
|
1507 default base 2).
|
|
|
1508
|
|
|
1509 E998
|
|
|
1510 EXCUSE ME, YOU MUST HAVE ME CONFUSED WITH SOME OTHER COMPILER
|
|
|
1511
|
|
|
1512 This error occurs just before compile-time if a file is
|
|
|
1513 encountered on the command line that C-INTERCAL doesn't recognise.
|
|
|
1514 (If this error occurs due to a `.a', `.b98', `.c', or `.c99', then
|
|
|
1515 you forgot to enable the external calls system using `-e' (*note
|
|
|
1516 -e::).)
|
|
|
1517
|
|
|
1518 E999
|
|
|
1519 NO SKELETON IN MY CLOSET, WOE IS ME!
|
|
|
1520
|
|
|
1521 The skeleton file `ick-wrap.c' or `pickwrap.c' is needed to be
|
|
|
1522 able to compile INTERCAL to C. If the compiler can't find it, it
|
|
|
1523 will give this error message. This indicates a problem with the
|
|
|
1524 way the compiler has been installed; try using the `-u' option
|
|
|
1525 (*note -u::) to find out where it's looking (you may be able to
|
|
|
1526 place a copy of the skeleton file in one of those places).
|
|
|
1527
|
|
|
1528
|
|
|
1529 3.2 Warnings
|
|
|
1530 ============
|
|
|
1531
|
|
|
1532 This is a list of the warnings stored in the warning database.
|
|
|
1533 Warnings only come up when the `-l' option (*note -l::) is given; even
|
|
|
1534 then, some of the warnings are not currently implemented and therefore
|
|
|
1535 will never come up.
|
|
|
1536
|
|
|
1537 W016
|
|
|
1538 DON'T TYPE THAT SO HASTILY
|
|
|
1539
|
|
|
1540 The positional precedence rules for unary operators are somewhat
|
|
|
1541 complicated, and it's easy to make a mistake. This warning is
|
|
|
1542 meant to detect such mistakes, but is not currently implemented.
|
|
|
1543
|
|
|
1544 W018
|
|
|
1545 THAT WAS MEANT TO BE A JOKE
|
|
|
1546
|
|
|
1547 If an INTERCAL expression has been translated from another
|
|
|
1548 language such as C, the optimiser is generally capable of
|
|
|
1549 translating it back into something similar to the original, at
|
|
|
1550 least in base 2. When after optimisation there are still INTERCAL
|
|
|
1551 operators left in an expression, then this warning is produced.
|
|
|
1552 (Therefore, it's likely to come up quite a lot if optimisation
|
|
|
1553 isn't used!) The system library produces some of these warnings
|
|
|
1554 (you can tell if a warning has come up in the system library
|
|
|
1555 because you'll get a line number after the end of your program).
|
|
|
1556
|
|
|
1557 W112
|
|
|
1558 THAT RELIES ON THE NEW WORLD ORDER
|
|
|
1559
|
|
|
1560 This warning comes up whenever the compiler recognises that you've
|
|
|
1561 added some code that didn't exist in INTERCAL-72. This allows you
|
|
|
1562 to check whether your code is valid INTERCAL-72 (although `-t'
|
|
|
1563 (*note -t::) is more useful for that); it also warns you that code
|
|
|
1564 might not be portable (because INTERCAL-72 is implemented by most
|
|
|
1565 INTERCAL compilers, but more recent language features may not be).
|
|
|
1566
|
|
|
1567 W128
|
|
|
1568 SYSLIB IS OPTIMIZED FOR OBUSCATION
|
|
|
1569
|
|
|
1570 There is an idiom used in the system library that does a
|
|
|
1571 right-shift by selecting alternate bits from a twospot number and
|
|
|
1572 then mingling them the other way round. A rightshift can much
|
|
|
1573 more easily be done with a single rightshift, so this is a silly
|
|
|
1574 way to do it, and this warning warns that this idiom was used.
|
|
|
1575 However, the present optimizer is incapable of recognising whether
|
|
|
1576 this problem exists or not, so the warning is not currently
|
|
|
1577 implemented.
|
|
|
1578
|
|
|
1579 W276
|
|
|
1580 YOU CAN'T EXPECT ME TO CHECK BACK THAT FAR
|
|
|
1581
|
|
|
1582 It's an error to assign a twospot value (a value over 65535) to a
|
|
|
1583 onespot variable, or to use it as an argument to a mingle. If the
|
|
|
1584 optimizer can't guarantee at compile time that there won't be an
|
|
|
1585 overflow, it issues this warning. (Note that this doesn't
|
|
|
1586 necessarily mean there's a problem -- for instance, the system
|
|
|
1587 library generates some of these warnings -- only that the
|
|
|
1588 optimiser couldn't work out for sure that there wasn't a problem.)
|
|
|
1589
|
|
|
1590 W239
|
|
|
1591 WARNING HANDLER PRINTED SNIDE REMARK
|
|
|
1592
|
|
|
1593 Your code looks like it's trying to assign 0 to an array, giving
|
|
|
1594 it no dimension; this is an error. This warning is produced at
|
|
|
1595 compile time if it looks like a line in your code will cause this
|
|
|
1596 error, but it isn't necessarily an error because that line of code
|
|
|
1597 might never be executed.
|
|
|
1598
|
|
|
1599 W278
|
|
|
1600 FROM A CONTRADICTION, ANYTHING FOLLOWS
|
|
|
1601
|
|
|
1602 It's sometimes impossible to reverse an assignment (a reverse
|
|
|
1603 assignment can happen if the `-v' option (*note -v::) is used and
|
|
|
1604 an expression is placed on the left of an assignment, or in
|
|
|
1605 operand overloading); if the compiler detects that a reversal
|
|
|
1606 failure is inevitable, it will cause this warning. Note that this
|
|
|
1607 doesn't always cause an error, because the relevant code might
|
|
|
1608 never be executed.
|
|
|
1609
|
|
|
1610 W450
|
|
|
1611 THE DOCUMENTOR IS NOT ALWAYS RIGHT
|
|
|
1612
|
|
|
1613 There is no way to get this warning to come up; it isn't even
|
|
|
1614 written anywhere in C-INTERCAL's source code, is not implemented
|
|
|
1615 by anything, and there are no circumstances in which it is even
|
|
|
1616 meant to come up. It is therefore not at all obvious why it is
|
|
|
1617 documented.
|
|
|
1618
|
|
|
1619 W534
|
|
|
1620 KEEP LOOKING AT THE TOP BIT
|
|
|
1621
|
|
|
1622 C-INTERCAL uses a slightly different typing mechanism to some
|
|
|
1623 other INTERCAL compilers; types are calculated at compile time
|
|
|
1624 rather than run time. This only makes a difference in some cases
|
|
|
1625 involving unary operators. It's impossible to detect at compile
|
|
|
1626 time for certain whether such a case has come up or not, but if
|
|
|
1627 the compiler or optimizer thinks that such a case might have come
|
|
|
1628 up, it will issue this warning.
|
|
|
1629
|
|
|
1630 W622
|
|
|
1631 WARNING TYPE 622 ENCOUNTERED
|
|
|
1632
|
|
|
1633 Your code looks like it's trying to resume by 0; this is an error.
|
|
|
1634 This warning is produced at compile time if it looks like a line
|
|
|
1635 in your code will cause this error, but it isn't necessarily an
|
|
|
1636 error because that line of code might never be executed.
|
|
|
1637
|
|
|
1638
|
|
|
1639 4 The yuk debugger
|
|
|
1640 ******************
|
|
|
1641
|
|
|
1642 The C-INTERCAL distribution contains a runtime debugger called `yuk'.
|
|
|
1643 Unlike most other debuggers, it is stored as object code rather than as
|
|
|
1644 an executable, and it is compiled into the code rather than operating on
|
|
|
1645 it. To debug code, add `-y' (*note -y::) to the command line of `ick'
|
|
|
1646 when invoking it; that tells it to compile the debugger into the code
|
|
|
1647 and then execute the resulting combination. (The resulting hybrid
|
|
|
1648 debugger/input executable is deleted afterwards; this is to prevent it
|
|
|
1649 being run by mistake, and to prevent spreading the debugger's licence
|
|
|
1650 onto the code it was compiled with.)
|
|
|
1651
|
|
|
1652 yuk can also be used as a profiler using the `-p' option (*note -p::);
|
|
|
1653 this produces a file `yuk.out' containing information on how much time
|
|
|
1654 was spent running each command in your program, and does not prompt for
|
|
|
1655 debugger commands.
|
|
|
1656
|
|
|
1657 Note that some command line arguments are incompatible with the
|
|
|
1658 debugger, such as `-m' and `-f'. In particular, this means that
|
|
|
1659 multithreaded programs and programs that use backtracking cannot be
|
|
|
1660 debugged using this method; the `+printflow' option (*note
|
|
|
1661 +printflow::) to a compiled program may or may not be useful for
|
|
|
1662 debugging multithreaded programs.
|
|
|
1663
|
|
|
1664 When the debugger starts, it will print a copyright message and a
|
|
|
1665 message on how to access online help; then you can enter commands to
|
|
|
1666 run/debug the program. The debugger will show a command prompt,
|
|
|
1667 `yuk007 ', to let you know you can input a command.
|
|
|
1668
|
|
|
1669 Here are the commands available. Commands are single characters
|
|
|
1670 followed by newlines, or followed by a line number (in decimal) and a
|
|
|
1671 newline or a variable name (a `.', `,', `:' or `;' followed by a number
|
|
|
1672 in decimal; note that some commands only allow onespot and twospot
|
|
|
1673 variables as arguments).
|
|
|
1674
|
|
|
1675 Command Description
|
|
|
1676 --------------------------------------------------------------------------
|
|
|
1677 aLINE All non-abstained commands on line LINE become abstained from
|
|
|
1678 once.
|
|
|
1679 bLINE A breakpoint is set on line LINE. The breakpoint causes
|
|
|
1680 execution with `c' to stop when it is reached.
|
|
|
1681 c The program is run until it ends (which also ends the
|
|
|
1682 debugger) or a breakpoint is reached.
|
|
|
1683 dLINE Any breakpoint that may be on line LINE is removed.
|
|
|
1684 eLINE An explanation of the main expression in each command on
|
|
|
1685 line LINE is printed to the screen. The explanation is in
|
|
|
1686 the same format as the format produced by `-h' (*note -h::)
|
|
|
1687 and shows what the optimiser optimised the expression to (or
|
|
|
1688 the original expression if the optimiser wasn't used).
|
|
|
1689 fLINE Removes the effect of the `m' command on line LINE.
|
|
|
1690 gLINE Causes the current command to be the first command on LINE
|
|
|
1691 (if not on that line already) or the next command on LINE,
|
|
|
1692 as if that line was `NEXT'ed to and then that `NEXT' stack
|
|
|
1693 item was forgotten.
|
|
|
1694 h Lists 10 lines either side of the current line; if there
|
|
|
1695 aren't 10 lines to one or the other side of the current
|
|
|
1696 line, instead more lines will be shown on the other side to
|
|
|
1697 compensate, if available.
|
|
|
1698 iVAR Causes variable VAR to become `IGNORE'd, making it read-only.
|
|
|
1699 jVAR Causes variable VAR to become `REMEMBER'ed, making it no
|
|
|
1700 longer read-only.
|
|
|
1701 k Continues executing commands until the `NEXT' stack is the
|
|
|
1702 same size or smaller than it was before. In other words, if
|
|
|
1703 the current command is not a `NEXT' and doesn't have a `NEXT
|
|
|
1704 FROM' aiming at it, one command is executed; but if a `NEXT'
|
|
|
1705 does happen, execution will continue until that `NEXT'
|
|
|
1706 returns or is forgotten. A breakpoint or the end of the
|
|
|
1707 program also end this.
|
|
|
1708 lLINE Lists 10 lines of source code either side of line LINE, the
|
|
|
1709 same way as with `h', but using a line stated in the command
|
|
|
1710 rather than the current line.
|
|
|
1711 mLINE Produces a message onscreen every time a command on line
|
|
|
1712 LINE is executed, but without interrupting the program.
|
|
|
1713 n Show the `NEXT' stack on the screen.
|
|
|
1714 o Continue executing commands until the `NEXT' stack is smaller
|
|
|
1715 than it was before. If you are using `NEXT's like
|
|
|
1716 procedures, then this effectively means that the procedure
|
|
|
1717 will run until it returns. A breakpoint or the end of the
|
|
|
1718 program also end this.
|
|
|
1719 p Displays the value of all onespot and twospot variables.
|
|
|
1720 q Aborts the current program and exits the debugger.
|
|
|
1721 rLINE Reinstates once all abstained commands on line LINE.
|
|
|
1722 s Executes one command.
|
|
|
1723 t Continues execution until the end of the program or a
|
|
|
1724 breakpoint: each command that executes is displayed while
|
|
|
1725 this command is running.
|
|
|
1726 uLINE Continues execution of the program until just before a
|
|
|
1727 command on line LINE is run (or a breakpoint or the end of
|
|
|
1728 the program).
|
|
|
1729 vVAR Adds a `view' on variable VAR (which must be onespot or
|
|
|
1730 twospot), causing its value to be displayed on the screen
|
|
|
1731 whenever a command is printed on screen (for instance,
|
|
|
1732 because the command has just been stepped past, or due to
|
|
|
1733 the `m' or `t' commands).
|
|
|
1734 w Displays the current line and current command onscreen.
|
|
|
1735 xVAR Removes any view and any action that may be associated with
|
|
|
1736 it on variable VAR (which must be onespot or twospot).
|
|
|
1737 yVAR Adds a view on variable VAR; also causes a break, as if a
|
|
|
1738 breakpoint was reached, whenever the value of that variable
|
|
|
1739 changes.
|
|
|
1740 zVAR Adds a view on variable VAR; also causes a break, as if a
|
|
|
1741 breakpoint was reached, whenever that variable's value
|
|
|
1742 becomes 0.
|
|
|
1743 VAR A onespot or twospot variable written by itself prints out
|
|
|
1744 the value of that variable.
|
|
|
1745 <VAR `WRITEs IN' a new value for variable VAR. Note that input
|
|
|
1746 must be in the normal `ONE TWO THREE' format; input in any
|
|
|
1747 other format will cause error E579 (*note E579::) and as
|
|
|
1748 that is a fatal error, the debugger and program it's
|
|
|
1749 debugging will end.
|
|
|
1750 * Displays the license conditions under which `ick' is
|
|
|
1751 distributed.
|
|
|
1752 ? Displays a summary of what each command does. (`@' does the
|
|
|
1753 same thing.)
|
|
|
1754
|
|
|
1755 While the code is executing (for instance, during a `c', `k', `o', `t'
|
|
|
1756 or `u' command), it's possible to interrupt it with `<CTRL>-<C>' (on
|
|
|
1757 UNIX/Linux) or `<CTRL>-<BREAK>' (on Windows/DOS); this will cause the
|
|
|
1758 current command to finish running and the debugger prompt to come back
|
|
|
1759 up.
|
|
|
1760
|
|
|
1761 PART II: THE INTERCAL LANGUAGE
|
|
|
1762 ******************************
|
|
|
1763
|
|
|
1764 5 Syntax
|
|
|
1765 ********
|
|
|
1766
|
|
|
1767 INTERCAL programs consist of a list of statements. Execution of a
|
|
|
1768 program starts with its first statement; generally speaking each
|
|
|
1769 statement runs after the previous statement, although many situations
|
|
|
1770 can change this.
|
|
|
1771
|
|
|
1772 Whitespace is generally insignificant in INTERCAL programs; it cannot be
|
|
|
1773 added in the middle of a keyword (unless the keyword contains whitespace
|
|
|
1774 itself) or inside a decimal number, but it can be added more or less
|
|
|
1775 anywhere else, and it can be removed from anywhere in the program as
|
|
|
1776 well.
|
|
|
1777
|
|
|
1778 An INTERCAL statement consists of an optional line label, a statement
|
|
|
1779 identifier, an optional execution chance, the statement itself (*note
|
|
|
1780 Statements::), and optionally `ONCE' or `AGAIN'.
|
|
|
1781
|
|
|
1782 5.1 Princeton and Atari Syntax
|
|
|
1783 ==============================
|
|
|
1784
|
|
|
1785 The history of INTERCAL is plagued with multiple syntaxes and character
|
|
|
1786 sets. The result has settled down with two versions of the syntax; the
|
|
|
1787 original Princeton syntax, and the Atari syntax (which is more suited
|
|
|
1788 to the operating systems of today).
|
|
|
1789
|
|
|
1790 Princeton syntax
|
|
|
1791 ----------------
|
|
|
1792
|
|
|
1793 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
1794 ------------------------------------------------------------------------
|
|
|
1795 some versions version 0.18+ all versions no
|
|
|
1796
|
|
|
1797 The original INTERCAL-72 compiler was the Princeton compiler, which
|
|
|
1798 introduced what has become known as the Princeton syntax for INTERCAL;
|
|
|
1799 this is the syntax used in the original manual, for instance, and can
|
|
|
1800 be considered to be the `original' or `official' INTERCAL syntax. It
|
|
|
1801 is notable for containing various characters not found in some
|
|
|
1802 character sets; for instance, it writes the operator for mingle as a
|
|
|
1803 cent sign (known as `change'). The other operator that often causes
|
|
|
1804 problems is the bookworm operator `V', backspace, `-', which is used
|
|
|
1805 for exclusive-or; the backspace can cause problems on some systems
|
|
|
1806 (which was probably the original intention). This syntax is also the
|
|
|
1807 default syntax in the CLC-INTERCAL compiler, which is the de facto
|
|
|
1808 standard for expanding the Princeton syntax to modern INTERCAL features
|
|
|
1809 that are not found in INTERCAL-72; however, it does not appear to have
|
|
|
1810 been used as the default syntax in any other compilers. Nowadays,
|
|
|
1811 there are other ways to write the required characters than using
|
|
|
1812 backspace; for instance, the cent sign appears in Latin-1 and UTF-8,
|
|
|
1813 and there are various characters that approximate bookworms (for
|
|
|
1814 instance, CLC-INTERCAL uses the Latin-1 yen symbol for this, which just
|
|
|
1815 to make things confusing, refers to a mingle in modern Atari syntax).
|
|
|
1816
|
|
|
1817 Atari syntax
|
|
|
1818 ------------
|
|
|
1819
|
|
|
1820 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
1821 ------------------------------------------------------------------------
|
|
|
1822 some versions yes version 0.05+ yes
|
|
|
1823
|
|
|
1824 The other main syntax is the Atari syntax, so called because it was
|
|
|
1825 originally used by the "Atari implementation" of INTERCAL-72. It is not
|
|
|
1826 clear why the implementation was given this name, because the authors
|
|
|
1827 of the implementation are not known; it is not clear whether it has any
|
|
|
1828 connection with Atari other than running on an Atari computer, for
|
|
|
1829 instance. The syntax was designed to work better on ASCII-based
|
|
|
1830 systems, by avoiding the change character (although it can still be
|
|
|
1831 written as `c', backspace, `/', which the Atari compiler documentation
|
|
|
1832 claims that the Princeton compiler supported) in favour of a `big
|
|
|
1833 money' character (`$'), and using the `what' (`?') as an alternative
|
|
|
1834 character for exclusive-or. This is the syntax that C-INTERCAL and
|
|
|
1835 J-INTERCAL have always used, and is the one most commonly used for
|
|
|
1836 communicating INTERCAL programs on Usenet and other similar fora (where
|
|
|
1837 ASCII is one of the most reliable-to-send character sets). It is also
|
|
|
1838 the syntax used for examples in this manual, for much the same reason.
|
|
|
1839 The Atari syntax for constructs more modern than INTERCAL-72 is
|
|
|
1840 normally taken to be that used by the C-INTERCAL compiler, because it is
|
|
|
1841 the only Atari-syntax-based compiler that contains non-INTERCAL-72
|
|
|
1842 constructs that actually need their own notation.
|
|
|
1843
|
|
|
1844 5.2 Line Labels
|
|
|
1845 ===============
|
|
|
1846
|
|
|
1847 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
1848 ------------------------------------------------------------------------
|
|
|
1849 yes all versions all versions all versions
|
|
|
1850
|
|
|
1851 The first part of an INTERCAL statement is a line label that specifies
|
|
|
1852 what its line number is. This is optional; it's allowed to have a
|
|
|
1853 statement without a line number, although that prevents other commands
|
|
|
1854 referring to it by number. Line numbers must be constants, and unique
|
|
|
1855 within the program. However, they do not have to be in order; unlike
|
|
|
1856 some other languages with line numbers, a line with a higher number can
|
|
|
1857 come earlier in the program than a line with a lower number, and the
|
|
|
1858 numbers don't affect the order in which commands are executed.
|
|
|
1859
|
|
|
1860 A line label is a integer expressed in decimal within a wax/wane pair
|
|
|
1861 (`(' and `)'). For instance, this is a valid line label:
|
|
|
1862
|
|
|
1863 (1000)
|
|
|
1864
|
|
|
1865 Note that line numbers from 1000 to 1999 are used by the system library,
|
|
|
1866 so using them within your own programs may produce unexpected errors if
|
|
|
1867 the system library is included. Apart from this, line numbers from 1 to
|
|
|
1868 65535 are allowed.
|
|
|
1869
|
|
|
1870 It has become reasonably customary for people writing INTERCAL libraries
|
|
|
1871 to pick a range of 1000 line numbers (for instance, 3000 to 3999) and
|
|
|
1872 stick to that range for all line numbers used in the program (apart from
|
|
|
1873 when calling the system library), so if you want to write an INTERCAL
|
|
|
1874 library, it may be a good idea to look at the existing libraries (in the
|
|
|
1875 `pit/lib' directory in the C-INTERCAL distribution) and choose a range
|
|
|
1876 of numbers that nobody else has used. If you aren't writing a library,
|
|
|
1877 it may be a good idea to avoid such number ranges (that is, use only
|
|
|
1878 line numbers below 1000 or very high numbers that are unlikely to be
|
|
|
1879 used by libraries in the future), so that you can easily add libraries
|
|
|
1880 to your program without renumbering in the future.
|
|
|
1881
|
|
|
1882 5.3 Statement Identifiers
|
|
|
1883 =========================
|
|
|
1884
|
|
|
1885 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
1886 ------------------------------------------------------------------------
|
|
|
1887 yes all versions all versions all versions
|
|
|
1888
|
|
|
1889 After the line label (if a statement has one) comes the statement
|
|
|
1890 identifier, which marks where the statement starts. Either the label or
|
|
|
1891 the statement identifier, whichever one comes first, marks where the
|
|
|
1892 preceding statement finishes.
|
|
|
1893
|
|
|
1894 The main statement identifier is `DO'. It also has two synonyms,
|
|
|
1895 `PLEASE' and `PLEASE DO'; these synonyms are the 'polite' forms of
|
|
|
1896 statement identifiers. Although the three identifiers have the same
|
|
|
1897 meaning, using either polite or non-polite identifiers too much can
|
|
|
1898 cause an error; the correct proportion is approximately 3 non-polite
|
|
|
1899 identifiers for every polite identifier used. None of these identifiers
|
|
|
1900 actually does anything else apart from marking where the statement
|
|
|
1901 starts; they leave the statements in the default `reinstated' state.
|
|
|
1902
|
|
|
1903 Adding `NOT' or `N'T' to the end of any of these identifiers, to create
|
|
|
1904 a statement identifier such as `DO NOT' or `PLEASE DON'T', also creates
|
|
|
1905 a valid statement identifier. These differ in meanings from the
|
|
|
1906 previous set of identifiers, though; they cause the statement they
|
|
|
1907 precede to not be executed by default; that is, the command will be
|
|
|
1908 skipped during execution (this is known as the `abstained' state).
|
|
|
1909 This applies even if the command in question is in fact a syntax error,
|
|
|
1910 thus causing this to be a useful method of writing comments. One
|
|
|
1911 common idiom is to write code like this:
|
|
|
1912
|
|
|
1913 PLEASE NOTE: This is a comment.
|
|
|
1914
|
|
|
1915 The statement identifier (`PLEASE NOT') is the only part of this
|
|
|
1916 statement that is valid INTERCAL; however, because the statement
|
|
|
1917 identifier is in the negated form that contains `NOT', the syntax error
|
|
|
1918 won't be executed, and therefore this is a valid statement. (In
|
|
|
1919 INTERCAL, syntax errors happen at runtime, so a program containing a
|
|
|
1920 statement like `DOUBT THIS WILL WORK' will still compile, and will not
|
|
|
1921 end due to the syntax error unless that statement is actually executed.
|
|
|
1922 *Note E000::.)
|
|
|
1923
|
|
|
1924 The `ABSTAIN' and `REINSTATE' statements can override the `NOT' or
|
|
|
1925 otherwise on a statement identifier; see *note ABSTAIN::.
|
|
|
1926
|
|
|
1927 In backtracking programs, `MAYBE' is also a valid statement identifier;
|
|
|
1928 see *note MAYBE::. It comes before the other keywords in the statement
|
|
|
1929 identifier, and an implicit `DO' is added if there wasn't one already
|
|
|
1930 in the statement identifier (so `MAYBE', `MAYBE DO', `MAYBE DON'T',
|
|
|
1931 `MAYBE PLEASE', and so on are all valid statement identifiers).
|
|
|
1932
|
|
|
1933 5.4 Execution Chance
|
|
|
1934 ====================
|
|
|
1935
|
|
|
1936 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
1937 ------------------------------------------------------------------------
|
|
|
1938 yes all versions version 0.02+ all versions
|
|
|
1939
|
|
|
1940 It's possible to specify that a command should be run only a certain
|
|
|
1941 proportion of the time, at random. This is a rarely used feature of
|
|
|
1942 INTERCAL, although it is the only way to introduce randomness into a
|
|
|
1943 program. (The C-INTERCAL compiler approximates this with
|
|
|
1944 pseudorandomness.) An execution chance specification comes immediately
|
|
|
1945 after the statement identifier, but before the rest of the statement,
|
|
|
1946 and consists of a double-oh-seven (`%') followed by an integer from 1
|
|
|
1947 to 99 inclusive, written in decimal; this gives the percentage chance
|
|
|
1948 of the statement running. The execution chance only acts to prevent a
|
|
|
1949 statement running when it otherwise would have run; it cannot cause a
|
|
|
1950 statement that would otherwise not have run to run. For instance, the
|
|
|
1951 statement `DO %40 WRITE OUT #1' has a 40% chance of writing out `I',
|
|
|
1952 but the statement `DON'T %40 WRITE OUT #1' has no chance of writing out
|
|
|
1953 `I' or anything else, because the `N'T' prevents it running and the
|
|
|
1954 double-oh-seven cannot override that.
|
|
|
1955
|
|
|
1956 5.5 ONCE and AGAIN
|
|
|
1957 ==================
|
|
|
1958
|
|
|
1959 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
1960 ------------------------------------------------------------------------
|
|
|
1961 no version 0.25+ no no
|
|
|
1962
|
|
|
1963 The last part of a statement is an optional `ONCE' or `AGAIN'. `ONCE'
|
|
|
1964 specifies that the statement is self-abstaining or self-reinstating
|
|
|
1965 (this will be explained below); `AGAIN' specifies that the statement
|
|
|
1966 should behave like it has already self-reinstated or self-abstained.
|
|
|
1967 Whether the behaviour is self-abstention or self-reinstatement depends
|
|
|
1968 on whether the statement was initially abstained or not; a `ONCE' on an
|
|
|
1969 initially reinstated statement or `AGAIN' on an initially abstained
|
|
|
1970 statement indicates a self-abstention, and a `ONCE' on an initially
|
|
|
1971 abstained statement or `AGAIN' on an initially reinstated statement
|
|
|
1972 indicates a self-reinstatement.
|
|
|
1973
|
|
|
1974 The first time a self-abstaining statement is encountered, it is
|
|
|
1975 executed as normal, but the statement is then abstained from and
|
|
|
1976 therefore will not run in future. Likewise, the first time
|
|
|
1977 self-reinstating statement is encountered, it is not executed (as is
|
|
|
1978 normal for an abstained statement), but then becomes reinstated and will
|
|
|
1979 run in future. In each of these cases, the `ONCE' effectively changes
|
|
|
1980 to an `AGAIN'; the `ONCE' only happens once, as might be expected.
|
|
|
1981
|
|
|
1982 `REINSTATING' a currently abstained self-abstaining statement or
|
|
|
1983 `ABSTAINING' (that is, with the `ABSTAIN' or `REINSTATE' commands) a
|
|
|
1984 currently reinstated self-reinstating statement causes the `AGAIN' on
|
|
|
1985 the statement to change back into a `ONCE', so the statement will again
|
|
|
1986 self-abstain or self-reinstate. Likewise, `REINSTATING' a currently
|
|
|
1987 abstained self-reinstating statement or `ABSTAINING' a currently
|
|
|
1988 reinstated self-abstaining statement causes its `ONCE' to turn into an
|
|
|
1989 `AGAIN'.
|
|
|
1990
|
|
|
1991 Historical note: `ONCE' was devised by Malcom Ryan as a method of
|
|
|
1992 allowing synchronisation between threads in a multithreaded program
|
|
|
1993 (`ONCE' is atomic with the statement it modifies, that is, there is no
|
|
|
1994 chance that threads will change between the statement and the `ONCE').
|
|
|
1995 `AGAIN' was added to Malcom Ryan's Threaded Intercal standard on the
|
|
|
1996 suggestion of Kyle Dean, as a method of adding extra flexibility (and
|
|
|
1997 to allow the `ONCE's to happen multiple times, which is needed to
|
|
|
1998 implement some multithreaded algorithms).
|
|
|
1999
|
|
|
2000 6 Expressions
|
|
|
2001 *************
|
|
|
2002
|
|
|
2003 Many INTERCAL statements take expressions as arguments. Expressions are
|
|
|
2004 made up out of operands and operators between them. Note that there is
|
|
|
2005 no operator precedence in INTERCAL; different compilers resolve
|
|
|
2006 ambiguities different ways, and some versions of some compilers
|
|
|
2007 (including the original INTERCAL-72 compiler) will cause error messages
|
|
|
2008 on compiling or executing an ambiguous expression, so it's safest to
|
|
|
2009 fully group each expression.
|
|
|
2010
|
|
|
2011 6.1 Constants and Variables
|
|
|
2012 ===========================
|
|
|
2013
|
|
|
2014 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2015 ------------------------------------------------------------------------
|
|
|
2016 yes all versions all versions all versions
|
|
|
2017
|
|
|
2018 The basic operands in INTERCAL are constants and variables. These
|
|
|
2019 together make up what in other languages are known as `lvalues', that
|
|
|
2020 is, operands to which values can be assigned. (Constants can also be
|
|
|
2021 lvalues in INTERCAL, but by default C-INTERCAL turns this off because it
|
|
|
2022 carries an efficiency penalty and can be confusing; this can be turned
|
|
|
2023 on with the `-v' option (*note -v::).)
|
|
|
2024
|
|
|
2025 Constants can have any integer value from 0 to 65535 inclusive; higher
|
|
|
2026 values (up to 4294967295) can be generated in programs, but cannot be
|
|
|
2027 specified literally as constants. (The usual way to work around this
|
|
|
2028 limitation is to interleave two constants together; see *note
|
|
|
2029 Mingle::.) A constant is written as a mesh (`#') followed by a number in
|
|
|
2030 decimal. At the start of the program, all constants have the same value
|
|
|
2031 as the number that identifies them; for instance, `#100' has 100 as its
|
|
|
2032 value, and it's strongly advised not to change the value of a constant
|
|
|
2033 during the execution of a program.
|
|
|
2034
|
|
|
2035 There are four types of variable: 16-bit and 32-bit unsigned integers,
|
|
|
2036 and arrays of 16-bit and 32-bit unsigned integers. These are
|
|
|
2037 represented with a spot, twospot, tail, and hybrid (`.', `:', `,', and
|
|
|
2038 `;') respectively. For this reason, integers within the range 0 to
|
|
|
2039 65535 inclusive are known as `onespot numbers', and integers within the
|
|
|
2040 range 0 to 4294967295 inclusive are known as `twospot numbers';
|
|
|
2041 variables with those ranges are known as onespot and twospot variables.
|
|
|
2042 (Note that arrays did not work in C-INTERCAL before version 0.7.)
|
|
|
2043
|
|
|
2044 Variables are represented with a character representing their data type,
|
|
|
2045 followed by an integer from 1 to 65535 inclusive, written in decimal.
|
|
|
2046 Non-array variables don't need to be declared before they are used; they
|
|
|
2047 automatically exist in any program that uses them. For instance, `.1'
|
|
|
2048 and `.001' are the same variable, onespot number 1. Array variables
|
|
|
2049 need to be dimensioned before they are used, by assigning dimensions to
|
|
|
2050 them; see *note Calculate::.
|
|
|
2051
|
|
|
2052 6.2 Grouping Rules
|
|
|
2053 ==================
|
|
|
2054
|
|
|
2055 Because there are no operator precedences in INTERCAL, there are various
|
|
|
2056 solutions to specifying what precedences actually are.
|
|
|
2057
|
|
|
2058 The portable solution
|
|
|
2059 All known versions of INTERCAL accept the INTERCAL-72 grouping
|
|
|
2060 rules. These state that it's possible to specify that an operator
|
|
|
2061 takes precedence by grouping it inside sparks (`'') or rabbit-ears
|
|
|
2062 (`"'), the same way as wax/wane pairs (parentheses) are used in
|
|
|
2063 other programming languages. INTERCAL-72 and earlier C-INTERCAL
|
|
|
2064 versions demanded that expressions were grouped fully like this,
|
|
|
2065 and this practice is still recommended because it leads to
|
|
|
2066 portable programs and is easier to understand. Whether sparks or
|
|
|
2067 rabbit-ears (often called just `ears' for short) are used normally
|
|
|
2068 doesn't matter, and programmers can use one or the other for
|
|
|
2069 clarity or for aesthetic appeal. (One common technique is to use
|
|
|
2070 just sparks at the outermost level of grouping, just ears at the
|
|
|
2071 next level, just sparks at the next level, and so on; but
|
|
|
2072 expressions like `''#1~#2'~"#3~#4"'~#5' are completely
|
|
|
2073 unambiguous, at least to the compiler.)
|
|
|
2074
|
|
|
2075 There are, however, some complicated situations involving array
|
|
|
2076 subscripting where it is necessary to use sparks and ears at
|
|
|
2077 alternate levels, if you want to write a portable program. This
|
|
|
2078 limitation is in C-INTERCAL to simplify the parsing process;
|
|
|
2079 INTERCAL-72 has the same limitation, probably for the same reason.
|
|
|
2080 Compare these two statements:
|
|
|
2081
|
|
|
2082 DO .1 <- ,3SUB",2SUB.1".2
|
|
|
2083 DO .1 <- ,3SUB",2SUB.1".2~.3"".4
|
|
|
2084
|
|
|
2085 The problem is that in the first statement, the ears close a
|
|
|
2086 group, and in the second statement, the ears open a group, and
|
|
|
2087 it's impossible to tell the difference without unlimited lookahead
|
|
|
2088 in the expression. Therefore, in similar situations (to be
|
|
|
2089 precise, in situations where a group is opened inside an array
|
|
|
2090 subscript), it's necessary to use the other grouping character to
|
|
|
2091 the one that opened the current group if you want a portable
|
|
|
2092 program.
|
|
|
2093
|
|
|
2094 One final comment about sparks and rabbit-ears; if the next
|
|
|
2095 character in the program is a spot, as often happens because
|
|
|
2096 onespot variables are common choices for operands, a spark and the
|
|
|
2097 following spot can be combined into a wow (`!'). Unfortunately,
|
|
|
2098 none of the character sets that C-INTERCAL accepts as input
|
|
|
2099 (UTF-8, Latin-1, and ASCII-7) contain the rabbit character,
|
|
|
2100 although the Hollerith input format that CLC-INTERCAL can use does.
|
|
|
2101
|
|
|
2102 Positional precedences: CLC-INTERCAL rules
|
|
|
2103 The precedence rules used by CLC-INTERCAL for grouping when full
|
|
|
2104 grouping isn't used are simple to explain: the largest part of the
|
|
|
2105 input that looks like an expression is taken to be that
|
|
|
2106 expression. The main practical upshot of this is that binary
|
|
|
2107 operators right-associate; that is, `.1~.2~.3' is equivalent to
|
|
|
2108 `.1~'.2~.3''. C-INTERCAL versions 0.26 and later also
|
|
|
2109 right-associate binary operators so as to produce the same results
|
|
|
2110 as CLC-INTERCAL rules in this situation, but as nobody has yet
|
|
|
2111 tried to work out what the other implications of CLC-INTERCAL
|
|
|
2112 rules are they are not emulated in C-INTERCAL, except possibly by
|
|
|
2113 chance.
|
|
|
2114
|
|
|
2115 Prefix and infix unary operators
|
|
|
2116 In INTERCAL-72 and versions of C-INTERCAL before 0.26, unary
|
|
|
2117 operators were always in the `infix' position. (If you're
|
|
|
2118 confused about how you can have an infix unary operator: they go
|
|
|
2119 one character inside a group that they apply to, or one character
|
|
|
2120 after the start of a constant or variable representation; so for
|
|
|
2121 instance, to portably apply the unary operator `&' to the variable
|
|
|
2122 `:1', write `:&1', and to portably apply it to the expression
|
|
|
2123 `'.1~.2'', write `'&.1~.2''.) CLC-INTERCAL, and versions of
|
|
|
2124 C-INTERCAL from 0.26 onwards, allow the `prefix' position of a
|
|
|
2125 unary operator, which is just before whatever it applies to (as in
|
|
|
2126 `&:1'). This leads to ambiguities as to whether an operator is
|
|
|
2127 prefix or infix. The portable solution is, of course, to use only
|
|
|
2128 infix operators and fully group everything, but when writing for
|
|
|
2129 recent versions of C-INTERCAL, it's possible to rely on its
|
|
|
2130 grouping rule, which is: unary operators are interpreted as infix
|
|
|
2131 where possible, but at most one infix operator is allowed to apply
|
|
|
2132 to each variable, constant, or group, and infix operators can't
|
|
|
2133 apply to anything else. So for instance, the C-INTERCAL
|
|
|
2134 `'&&&.1~.2'' is equivalent to the portable `'&"&.&1"~.2'' (or the
|
|
|
2135 more readable version of this, `"&'"&.&1"~.2'"', which is also
|
|
|
2136 portable). If these rules are counter-intuitive to you, remember
|
|
|
2137 that this is INTERCAL we're talking about; note also that this
|
|
|
2138 rule is unique to C-INTERCAL, at least at the time of writing, and
|
|
|
2139 in particular CLC-INTERCAL is likely to interpret this expression
|
|
|
2140 differently.
|
|
|
2141
|
|
|
2142
|
|
|
2143 6.3 Operators
|
|
|
2144 =============
|
|
|
2145
|
|
|
2146 Operators are used to operate on operands, to produce more complicated
|
|
|
2147 expressions that actually calculate something rather than just fetch
|
|
|
2148 information from memory. There are two types of operators, unary and
|
|
|
2149 binary operators, which operate on one and two arguments respectively.
|
|
|
2150 Binary operators are always written between their two operands; to
|
|
|
2151 portably write a unary operator, it should be in the `infix' position,
|
|
|
2152 one character after the start of its operand; see *note Prefix and
|
|
|
2153 infix unary operators:: for the full details of how to write unary
|
|
|
2154 operators portably, and how else you can use them if you aren't aiming
|
|
|
2155 for portability. This section only describes INTERCAL-72 operators;
|
|
|
2156 many INTERCAL extensions add their own operators.
|
|
|
2157
|
|
|
2158 6.3.1 Mingle
|
|
|
2159 ------------
|
|
|
2160
|
|
|
2161 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2162 ------------------------------------------------------------------------
|
|
|
2163 yes all versions all versions all versions
|
|
|
2164
|
|
|
2165 Mingle, or interleave, is one of the two binary operators in
|
|
|
2166 INTERCAL-72. However, different INTERCAL compilers represent it in
|
|
|
2167 different ways, so it is impossible to write a mingle in a program
|
|
|
2168 completely portably, because it differs between Princeton and Atari
|
|
|
2169 syntax, and worse, the sequence of character codes needed to represent
|
|
|
2170 it in each syntax has varied from compiler to compiler.
|
|
|
2171
|
|
|
2172 The original INTERCAL-72 compiler (the Princeton compiler) used the
|
|
|
2173 'change' (cent) character for a mingle, represented as `c', backspace,
|
|
|
2174 `/'. (By the way, this is still the most portable way to write a
|
|
|
2175 mingle; both C-INTERCAL and CLC-INTERCAL accept it, at least if a
|
|
|
2176 lowercase `c' is used, the Atari compiler accepted it, and its
|
|
|
2177 documentation claimed that the Princeton compiler also accepted it;
|
|
|
2178 CLC-INTERCAL also accepts a capital `C' before the backspace and `/',
|
|
|
2179 and allows `|' rather than `/'.) The Atari compiler, another
|
|
|
2180 INTERCAL-72 compiler, used a 'big money' character (`$') as the mingle
|
|
|
2181 character; this character is also the only one accepted for mingle by
|
|
|
2182 the J-INTERCAL compiler. C-INTERCAL originally also used the `$'
|
|
|
2183 character for mingle, and this character is the one most commonly seen
|
|
|
2184 in existing C-INTERCAL programs, and most often used when giving
|
|
|
2185 examples of INTERCAL on Usenet, because it exists in the ASCII-7
|
|
|
2186 character set, and because it doesn't contain control characters. From
|
|
|
2187 version 0.18 of C-INTERCAL onwards, various other units of currency
|
|
|
2188 (change, quid, and zlotnik if Latin-1 is used as the input, and euro if
|
|
|
2189 Latin-9 is used as the input) are accepted; from version 0.20 onwards,
|
|
|
2190 in addition to the Latin-1 characters, all the currency symbols in
|
|
|
2191 Unicode are accepted if UTF-8 is used as the input format.
|
|
|
2192 CLC-INTERCAL has always used the change character (either the Latin-1
|
|
|
2193 version or the version that contains a backspace) for mingle. In this
|
|
|
2194 manual, mingle will be represented as `$', but it's important to bear
|
|
|
2195 in mind that this character is not the most portable choice.
|
|
|
2196
|
|
|
2197 The mingle operator should be applied to two operands or expressions.
|
|
|
2198 To be portable, the operands must both be onespot expressions, that is
|
|
|
2199 expressions which have a 16-bit result; C-INTERCAL relaxes this rule
|
|
|
2200 slightly and only requires that the result be in the onespot range.
|
|
|
2201 (This is because the data type of a select operator's value is meant to
|
|
|
2202 be determined at runtime; C-INTERCAL determines all data types at
|
|
|
2203 compile time, so has to guess a 32-bit result for a select with a
|
|
|
2204 32-bit type as its right operand even when the result might actually
|
|
|
2205 turn out to be of a 16-bit type, and so this behaviour prevents an
|
|
|
2206 error when a select operation returns a value with a 16-bit data type
|
|
|
2207 and is used as an argument to a mingle.) The result is a 32-bit value
|
|
|
2208 (that is, it is of a 32-bit data type, even if its value fits into the
|
|
|
2209 onespot range), which consists of bits alternated from the two
|
|
|
2210 arguments; to be precise, its most significant bit is the most
|
|
|
2211 significant bit of its first argument, its second most significant bit
|
|
|
2212 is the most significant bit of its second argument, its third most
|
|
|
2213 significant bit is the second most significant bit of its first
|
|
|
2214 argument, and so on until its least significant bit, which is the least
|
|
|
2215 significant bit of its second argument.
|
|
|
2216
|
|
|
2217 One of the most common uses of interleaving is to create a constant with
|
|
|
2218 a value greater than 65535; for instance, 65536 is `#256$#0'. It is
|
|
|
2219 also commonly used in expressions that need to produce 32-bit results;
|
|
|
2220 except in some simple cases, this is usually coded by calculating
|
|
|
2221 separately the odd-numbered and even-numbered bits of the result, and
|
|
|
2222 mingling them together at the end. It is also used in expressions that
|
|
|
2223 need to left-shift values or perform similar value-increasing
|
|
|
2224 operations, as none of the other operators can easily do this; and
|
|
|
2225 mingle results are commonly used as the argument to unary binary logic
|
|
|
2226 operators, because this causes them to behave more like the binary
|
|
|
2227 logic operators found in some other languages.
|
|
|
2228
|
|
|
2229 6.3.2 Select
|
|
|
2230 ------------
|
|
|
2231
|
|
|
2232 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2233 ------------------------------------------------------------------------
|
|
|
2234 yes all versions all versions all versions
|
|
|
2235
|
|
|
2236 The select operator is one of the two binary operators in INTERCAL-72;
|
|
|
2237 unlike mingle, every known implementation of INTERCAL ever has used the
|
|
|
2238 sqiggle character (`~') as the representation of the select operator,
|
|
|
2239 meaning that writing it portably is easy.
|
|
|
2240
|
|
|
2241 The select operator takes two arguments, which can be of either
|
|
|
2242 datatype (that is, 16- or 32-bit). It returns a value made by
|
|
|
2243 selecting certain bits of its first operand indicated by the second
|
|
|
2244 operand, and right-justifying them. What it does is that it ignores
|
|
|
2245 all the bits of the first operand where the second operand has a 0 as
|
|
|
2246 the corresponding bit, that is, deletes them from a copy of the
|
|
|
2247 operand's value; the bits that are left are squashed together towards
|
|
|
2248 the least-significant end of the number, and the result is filled with
|
|
|
2249 0s to make it up to 16 or 32 bits. (In INTERCAL-72 the minimum multiple
|
|
|
2250 of 16 bits possible that the result fits into is chosen, although if :1
|
|
|
2251 has the value 131061 (in hex, 1FFFF) the expression `#21~:1' produces a
|
|
|
2252 32-bit result because 17 bits were selected, even though many of the
|
|
|
2253 leading bits were zeros; in C-INTERCAL the data type of the result is
|
|
|
2254 the same as of the right operand of the select, so that it can be
|
|
|
2255 determined at compile time, and so using a unary binary logic operator
|
|
|
2256 on the result of select when the right operand has a 32-bit type is
|
|
|
2257 nonportable and not recommended.) As an example, `#21~:1' produces 21
|
|
|
2258 as its result if :1 has the value 131061, 10 as its result if :1 has
|
|
|
2259 the value 30 (1E in hex; the least significant bit of 21 is removed
|
|
|
2260 because it corresponds to a 0 in :1), and 7 as its result if :1 has the
|
|
|
2261 value 21 (because three bits in 21 are set, and those three bits from
|
|
|
2262 21 are therefore selected by 21).
|
|
|
2263
|
|
|
2264 Select is used for right-shifts, to select every second bit from a
|
|
|
2265 number (either to produce what will eventually become an argument to
|
|
|
2266 mingle, or to interpret the result of a unary binary logic operator, or
|
|
|
2267 occasionally both), to test if a number is zero or not (by selecting it
|
|
|
2268 from itself and selecting 1 from the result), in some cases as a limited
|
|
|
2269 version of bitwise-and (that only works if the right operand is 1 less
|
|
|
2270 than a power of 2), and for many other purposes.
|
|
|
2271
|
|
|
2272 6.3.3 Unary Binary Logic
|
|
|
2273 ------------------------
|
|
|
2274
|
|
|
2275 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2276 ------------------------------------------------------------------------
|
|
|
2277 yes all versions all versions all versions
|
|
|
2278
|
|
|
2279 There are three unary operators in INTERCAL-72, each of which carries
|
|
|
2280 out a binary logic operation on adjacent bits of the number. The
|
|
|
2281 operators are and, or, and exclusive or; and and or are represented by
|
|
|
2282 an ampersand (`&') and book (`V') respectively, and exclusive or has
|
|
|
2283 the same notational problems as mingle, as it differs between Princeton
|
|
|
2284 and Atari syntax. It was represented by a bookworm, written `V',
|
|
|
2285 backspace, `-', in the Princeton INTERCAL-72 implementation, and this
|
|
|
2286 is still the most portable way to write it (C-INTERCAL and CLC-INTERCAL
|
|
|
2287 accept it). The Atari implementation of INTERCAL-72 wrote it with a
|
|
|
2288 what (`?'), and this is the representation originally used by
|
|
|
2289 C-INTERCAL (and still accepted), the only representation accepted by
|
|
|
2290 J-INTERCAL, the one most commonly used on Usenet, and the one used in
|
|
|
2291 this manual (although again, it's worth pointing out that this isn't
|
|
|
2292 portable). CLC-INTERCAL approximates a bookworm with the yen
|
|
|
2293 character, which being a currency character is one of the possible
|
|
|
2294 representations for mingle in C-INTERCAL; C-INTERCAL uses the rather
|
|
|
2295 confusing method of interpreting a yen character as exclusive-or if
|
|
|
2296 input in Latin-1 but as mingle if input in UTF-8. (This usually does
|
|
|
2297 the right thing, because CLC-INTERCAL doesn't support UTF-8.) In the
|
|
|
2298 same way, CLC-INTERCAL has a C-INTERCAL compatibility option to allow
|
|
|
2299 the use of `?' for exclusive-or.
|
|
|
2300
|
|
|
2301 The operators take each pair of consecutive bits in their arguments
|
|
|
2302 (that is, the least significant with the second least significant, the
|
|
|
2303 second least significant with the third least significant, the third
|
|
|
2304 least significant with the fourth least significant, and so on, with the
|
|
|
2305 pair consisting of the most significant and least significant being used
|
|
|
2306 to calculate the most significant bit of the result), and perform an
|
|
|
2307 appropriate logic operation on them; and sets a bit of the result if and
|
|
|
2308 only if both bits in the pair were set, or sets each bit corresponding
|
|
|
2309 to each pair where either bit was set, and exclusive or sets if and
|
|
|
2310 only if the bits in the pair had different values (that is, one was
|
|
|
2311 set, but not both). So for instance, `#&26' is 16 (26 is 1A in
|
|
|
2312 hexadecimal or 11010 in binary); `#V26' is 31 (11111 in binary), and
|
|
|
2313 `#?26' is 23 (10111 in binary).
|
|
|
2314
|
|
|
2315 The most commonly seen use for these operators is to carry out bitwise
|
|
|
2316 ands, ors, and exclusive ors between two different 16-bit expressions,
|
|
|
2317 by mingling them together, applying a unary binary logic operator, and
|
|
|
2318 selecting every second bit of the result; such code often results due to
|
|
|
2319 people thinking in terms of some other language when writing INTERCAL,
|
|
|
2320 but is still often useful. (Historically, the first idiom added to the
|
|
|
2321 optimizer, apart from constant folding, was the mingle/unary/select
|
|
|
2322 sequence.) There are more imaginative uses; one impressive example is
|
|
|
2323 the exclusive or in the test for greater-than from the original
|
|
|
2324 INTERCAL-72 system library:
|
|
|
2325
|
|
|
2326 DO :5 <- "'?":1~'#65535$#0'"$":2~'#65535$#0'"'
|
|
|
2327 ~'#0$#65535'"$"'?":1~'#0$#65535'"$":2~'#0$
|
|
|
2328 #65535'"'~'#0$#65535'"
|
|
|
2329 DO .5 <- '?"'&"':2~:5'~'"'?"'?":5~:5"~"#65535~
|
|
|
2330 #65535"'~'#65535$#0'"$#32768'~'#0$#65535'"
|
|
|
2331 $"'?":5~:5"~"#65535$#65535"'~'#0$#65535'"'
|
|
|
2332 "$"':5~:5'~#1"'~#1"$#2'~#3
|
|
|
2333
|
|
|
2334 The first statement works out the value of :1 bitwise exclusive or :2;
|
|
|
2335 the second statement then works out whether the most significant set bit
|
|
|
2336 in :5 (that is, the most significant bit that differs between :1 and :2)
|
|
|
2337 corresponds to a set bit in :2 or not. In case that's a bit too
|
|
|
2338 confusing to read, here's the corresponding optimizer idiom (in OIL):
|
|
|
2339
|
|
|
2340 ((_1~:2)~((?32(:2~:2))^#2147483648))->(_1>(:2^_1))
|
|
|
2341
|
|
|
2342 (Here, the ^ refers to a bitwise exclusive or, an operation found in OIL
|
|
|
2343 but not in INTERCAL, which is why the INTERCAL version is so much
|
|
|
2344 longer.) The INTERCAL version also has some extra code to check for
|
|
|
2345 equality and to produce 1 or 2 as the output rather than 0 or 1.
|
|
|
2346
|
|
|
2347 6.3.4 Array Subscript
|
|
|
2348 ---------------------
|
|
|
2349
|
|
|
2350 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2351 ------------------------------------------------------------------------
|
|
|
2352 yes version 0.7+ all versions all versions
|
|
|
2353
|
|
|
2354 In order to access the elements of an array, either to read or write
|
|
|
2355 the array, it is necessary to use the array subscript operator `SUB'.
|
|
|
2356 Note that an array element is not a variable, so it is not accepted as
|
|
|
2357 an acceptable argument to statements like `IGNORE'; however, it can be
|
|
|
2358 assigned to.
|
|
|
2359
|
|
|
2360 The syntax for an array element is the array, followed by the keyword
|
|
|
2361 `SUB', followed by an expression for the element number in the array.
|
|
|
2362 In the case of a multidimensional array, more than one expression is
|
|
|
2363 given after the keyword `SUB' to give the location of the element in
|
|
|
2364 each of the array's dimensions. The first element in an array or array
|
|
|
2365 dimension is numbered 1.
|
|
|
2366
|
|
|
2367 For instance, this is a legal (but not particularly useful) INTERCAL
|
|
|
2368 program with no syntax errors that shows some of the syntaxes possible
|
|
|
2369 with array subscripting:
|
|
|
2370
|
|
|
2371 PLEASE ,1 <- #2
|
|
|
2372 DO .1 <- #2
|
|
|
2373 DO ,1 SUB .1 <- #1
|
|
|
2374 DO ,1 SUB #1 <- ,1 SUB #2
|
|
|
2375 PLEASE ;1 <- #2 BY #2
|
|
|
2376 DO ;1 SUB #1 #2 <- ,1 SUB ,1 SUB .1
|
|
|
2377 DO READ OUT ;1SUB#1.1
|
|
|
2378 DO GIVE UP
|
|
|
2379
|
|
|
2380 Grouping can get complicated when nested array subscripting is used,
|
|
|
2381 particularly with multiple subscripts. It is the programmer's job to
|
|
|
2382 write an unambiguous statement, and also obey the extra grouping rules
|
|
|
2383 that apply to array subscripts; see *note Grouping Rules::.
|
|
|
2384
|
|
|
2385 7 Statements
|
|
|
2386 ************
|
|
|
2387
|
|
|
2388 There is a wide range of statements available to INTERCAL programs;
|
|
|
2389 some identifiably belong to a particular variant or dialect (such as
|
|
|
2390 Backtracking INTERCAL), but others can be considered to be part of the
|
|
|
2391 'core language'. The statements listed here are those that the
|
|
|
2392 C-INTERCAL compiler will accept with no compiler switches to turn on
|
|
|
2393 particular dialect options. Note that many statements have slightly
|
|
|
2394 different effects in different implementations of INTERCAL; known
|
|
|
2395 incompatibilities are listed here, but it's important to check your
|
|
|
2396 program on multiple compilers when attempting to write a portable
|
|
|
2397 program.
|
|
|
2398
|
|
|
2399 7.1 Syntax Error
|
|
|
2400 ================
|
|
|
2401
|
|
|
2402 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2403 ------------------------------------------------------------------------
|
|
|
2404 yes version 0.15+ all versions all versions
|
|
|
2405
|
|
|
2406 One of the more commonly-used commands in INTERCAL is the syntax error.
|
|
|
2407 A properly-written syntax error looks nothing like any known INTERCAL
|
|
|
2408 command; a syntax error that looks vaguely like a command but isn't may
|
|
|
2409 confuse C-INTERCAL before version 0.28, and possibly other compilers,
|
|
|
2410 into bailing out at compile time in some situations (this is known as a
|
|
|
2411 `serious syntax error'), and so is not portable. For other syntax
|
|
|
2412 errors, though, the semantics are easily explained: there is a run-time
|
|
|
2413 error whenever the syntax error is actually executed, and the line
|
|
|
2414 containing the syntax error is used as the error message.
|
|
|
2415
|
|
|
2416 One purpose of this is to allow your programs to produce their own
|
|
|
2417 custom errors at run time; however, it's very important to make sure
|
|
|
2418 that they start and end in the right place, by manipulating where
|
|
|
2419 statement identifiers appear. Here's a correct example from the system
|
|
|
2420 library:
|
|
|
2421
|
|
|
2422 DOUBLE OR SINGLE PRECISION ARITHMETIC OVERFLOW
|
|
|
2423
|
|
|
2424 This is a valid INTERCAL command, that produces an error when run (note
|
|
|
2425 the `DO' at the start). An even more common use is to produce an
|
|
|
2426 initially abstained syntax error by using an appropriate statement
|
|
|
2427 identifier, for instance
|
|
|
2428
|
|
|
2429 PLEASE NOTE THAT THIS IS A COMMENT
|
|
|
2430
|
|
|
2431 This would produce an error if reinstated somehow, but assuming that
|
|
|
2432 this isn't done, this is a line of code that does nothing, which is
|
|
|
2433 therefore equivalent to a comment in other programming languages. (The
|
|
|
2434 initial abstention is achieved with the statement identifier `PLEASE
|
|
|
2435 NOT'; the extra `E' causes the command to be a syntax error, and this
|
|
|
2436 particular construction is idiomatic.)
|
|
|
2437
|
|
|
2438 Referring to the set of all syntax errors in a program (or the set of
|
|
|
2439 all commands of any other given type) is achieved with a special
|
|
|
2440 keyword known as a `gerund'; gerund support for syntax errors is
|
|
|
2441 resonably recent, and only exists in CLC-INTERCAL (version 1.-94.-3 and
|
|
|
2442 later, with `COMMENT', `COMMENTS', or `COMMENTING'), and C-INTERCAL
|
|
|
2443 (`COMMENT' in version 0.26 and later, and also `COMMENTS' and
|
|
|
2444 `COMMENTING' in version 0.27 and later). Therefore, it is not portable
|
|
|
2445 to refer to the set of all syntax errors by gerund; using a line label
|
|
|
2446 is a more portable way to refer to an individual syntax-error command.
|
|
|
2447
|
|
|
2448 7.2 Calculate
|
|
|
2449 =============
|
|
|
2450
|
|
|
2451 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2452 ------------------------------------------------------------------------
|
|
|
2453 yes all versions all versions all versions
|
|
|
2454
|
|
|
2455 At present, the only INTERCAL command that contains no keywords (apart
|
|
|
2456 from the statement identifier and possibly `ONCE' or `AGAIN') is what
|
|
|
2457 is known as the `calculate' command. It is used to assign values to
|
|
|
2458 variables, array elements, and arrays; assigning a value to an array
|
|
|
2459 changes the number of elements that that array can hold, and causes the
|
|
|
2460 values of all elements previously in that array to be lost. The syntax
|
|
|
2461 of a calculate command is as follows:
|
|
|
2462
|
|
|
2463 DO .1 <- ':2~:3'~#55
|
|
|
2464
|
|
|
2465 That is, the command is written as a variable or array element, then
|
|
|
2466 the `<-' operator (known as an `angle-worm' and pronounced `gets'),
|
|
|
2467 then an expression to assign to it. In the special case when an array
|
|
|
2468 is being dimensioned by assigning a value to it, the expression can
|
|
|
2469 contain the keyword `BY' to cause the array to become multidimensional;
|
|
|
2470 so for a 3 by 4 by 5 array, it would be possible to write
|
|
|
2471
|
|
|
2472 DO ,1 <- #3 BY #4 BY #5
|
|
|
2473
|
|
|
2474 The calculate command always evaluates the expression, even if for some
|
|
|
2475 reason the assignment can't be done (for instance, if the variable
|
|
|
2476 being assigned to is read-only); this is important if the expression
|
|
|
2477 has side-effects (for instance, giving an overflow error). If the
|
|
|
2478 variable does happen to be read-only, there is not an error; the
|
|
|
2479 expression being assigned to it is just evaluated, with the resulting
|
|
|
2480 value being discarded.
|
|
|
2481
|
|
|
2482 The gerund to refer to calculations is `CALCULATING'; however, if you
|
|
|
2483 are planning to use this, note that a bug in older versions of
|
|
|
2484 C-INTERCAL means that assignments to arrays are not affected by this
|
|
|
2485 gerund before version 0.27.
|
|
|
2486
|
|
|
2487 CLC-INTERCAL from 1.-94.-4 onwards, and C-INTERCAL from 0.26 onwards,
|
|
|
2488 allow arbitrary expressions on the left hand side of an assignment
|
|
|
2489 (C-INTERCAL only if the `-v' option is used); for more information on
|
|
|
2490 how such `reverse assignments' work, see *note Operand Overloading::.
|
|
|
2491
|
|
|
2492 7.3 NEXT, FORGET and RESUME
|
|
|
2493 ===========================
|
|
|
2494
|
|
|
2495 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2496 ------------------------------------------------------------------------
|
|
|
2497 yes all versions see text all versions
|
|
|
2498
|
|
|
2499 The only flow-control commands in INTERCAL-72 were `NEXT', `RESUME',
|
|
|
2500 and `FORGET'; together these manipulate a stack of locations in the
|
|
|
2501 program known as the `NEXT stack'. Although all INTERCAL compilers
|
|
|
2502 have implemented these, from CLC-INTERCAL version 0.05 onwards
|
|
|
2503 CLC-INTERCAL has considered them obsolete, and therefore a special
|
|
|
2504 command-line switch needs to be used to enable them. (They are still
|
|
|
2505 the most portable flow-control commands currently available, though,
|
|
|
2506 precisely because INTERCAL-72 implements nothing else.) Note that there
|
|
|
2507 is a strict limit of 80 locations on the NEXT stack, enforced by all
|
|
|
2508 known INTERCAL compilers; this helps to enforce good programming style,
|
|
|
2509 by discouraging NEXT-stack leaks (which are otherwise quite easy to
|
|
|
2510 write).
|
|
|
2511
|
|
|
2512 Here are examples to show the syntax of these three statements:
|
|
|
2513
|
|
|
2514 DO (1000) NEXT
|
|
|
2515 DO FORGET '.1~.1'~#1
|
|
|
2516 DO RESUME .5
|
|
|
2517
|
|
|
2518 The `NEXT' command takes a line label as its argument (unlike most
|
|
|
2519 other INTERCAL commands, it comes after its argument rather than
|
|
|
2520 before); both `FORGET' and `RESUME' take expressions. (CLC-INTERCAL
|
|
|
2521 from version 0.05 onwards also allows an expression in `NEXT', rather
|
|
|
2522 than a label, to give a computed `NEXT', but this behaviour was not
|
|
|
2523 implemented in other compilers, and is deprecated in CLC-INTERCAL along
|
|
|
2524 with noncomputed `NEXT'; if computed `NEXT' is ever implemented in
|
|
|
2525 C-INTERCAL, it will likely likewise be deprecated upon introduction).
|
|
|
2526 (Update: it was implemented in C-INTERCAL version 0.28, but only as
|
|
|
2527 part of the external calls system, so it cannot be used in ordinary
|
|
|
2528 programs; a sample expansion library gives in-program access to a
|
|
|
2529 limited form of computed `NEXT', but should probably not be used.)
|
|
|
2530 Running a `NEXT' causes the program control to transfer to the command
|
|
|
2531 whose line label is referenced, and also saves the location in the
|
|
|
2532 program immediately after the `NEXT' command on the top of the NEXT
|
|
|
2533 stack.
|
|
|
2534
|
|
|
2535 In order to remove items from the `NEXT' stack, to prevent it filling
|
|
|
2536 up (which is what happens with a naive attempt to use the `NEXT'
|
|
|
2537 command as an equivalent to what some other languages call GOTO), it is
|
|
|
2538 possible to use the `FORGET' or `RESUME' commands. They each remove a
|
|
|
2539 number of items from the NEXT stack equal to their argument; `RESUME'
|
|
|
2540 also transfers control flow to the last location removed from the
|
|
|
2541 `NEXT' stack this way. Trying to remove no items, or more items than
|
|
|
2542 there are in the stack, does not cause an error when `FORGET' is used
|
|
|
2543 (no items or all the items are removed respectively); however, both of
|
|
|
2544 these cases are errors in a `RESUME' statement.
|
|
|
2545
|
|
|
2546 Traditionally, boolean values in INTERCAL programs have been stored
|
|
|
2547 using #1 and #2 as the two logic levels. This is because the easiest
|
|
|
2548 way to implement an if-like construct in INTERCAL-72 is by `NEXTING',
|
|
|
2549 then `NEXTING' again, then `RESUMING' either by 1 or 2 according to an
|
|
|
2550 expression, and then if the expression evaluated to 1 `FORGETTING' the
|
|
|
2551 remaining NEXT stack entry. By the way, the previous sentence also
|
|
|
2552 explained what the appropriate gerunds are for `NEXT', `RESUME', and
|
|
|
2553 `FORGET'.
|
|
|
2554
|
|
|
2555 7.4 STASH and RETRIEVE
|
|
|
2556 ======================
|
|
|
2557
|
|
|
2558 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2559 ------------------------------------------------------------------------
|
|
|
2560 yes all versions all versions all versions
|
|
|
2561
|
|
|
2562 The NEXT stack is not the only stack available in an INTERCAL program;
|
|
|
2563 each variable used in the program also has its own stack, which holds
|
|
|
2564 values of the same type as the variable. The `STASH' command pushes a
|
|
|
2565 variable's value onto that variable's stack; `RETRIEVE' can be used in
|
|
|
2566 the same way to pop the top element of a variable's stack to replace
|
|
|
2567 that variable's value. The syntax is the same as most other INTERCAL
|
|
|
2568 commands, with the word `STASH' or `RETRIEVE' followed by the variable
|
|
|
2569 or variables to stash or retrieve:
|
|
|
2570
|
|
|
2571 DO STASH .1 + ;2
|
|
|
2572 DO RETRIEVE ,3
|
|
|
2573
|
|
|
2574 Note that it is possible to stash or retrieve multiple variables at
|
|
|
2575 once, by listing their names separated by intersections (`+'); it's
|
|
|
2576 even possible to stash or retrieve a variable twice in the same
|
|
|
2577 statement.
|
|
|
2578
|
|
|
2579 It is not entirely clear how `RETRIEVE' interacts with `IGNORE' in
|
|
|
2580 historical INTERCAL-72 compilers; the three modern INTERCAL compilers
|
|
|
2581 all use different rules for the interaction (and the C-INTERCAL
|
|
|
2582 maintainers recommend that if anyone decides to write their own
|
|
|
2583 compiler, they choose yet another different rule so that looking at the
|
|
|
2584 interaction (the so-called `ignorret test') can be used as a method of
|
|
|
2585 determining which compiler is running):
|
|
|
2586
|
|
|
2587 * C-INTERCAL treats a retrieval just like an assignment. That is, a
|
|
|
2588 read-only variable will not be changed by a retrieval, and will
|
|
|
2589 remain read-only, but the side-effect of popping that variable's
|
|
|
2590 stash will still happen.
|
|
|
2591
|
|
|
2592 * J-INTERCAL ignores the read-only status of a variable when
|
|
|
2593 retrieving it from a stash; the value of the variable changes
|
|
|
2594 despite being read-only. The variable remains read-only; the
|
|
|
2595 `RETRIEVE' simply allows a change to its value despite the
|
|
|
2596 read-only status.
|
|
|
2597
|
|
|
2598 * CLC-INTERCAL is the most complicated; it stores read-only status or
|
|
|
2599 otherwise in the stash, along with the variable's value. This
|
|
|
2600 means that if a variable was stashed when read-only, retrieving it
|
|
|
2601 will retrieve its value and set it to read-only regardless of its
|
|
|
2602 previous read-only status; likewise, if a variable was stashed
|
|
|
2603 when read-write, retrieving it will retrieve its value and set it
|
|
|
2604 to read-write even if it was previously read-only.
|
|
|
2605
|
|
|
2606
|
|
|
2607 The appropriate gerunds for `STASH' and `RETRIEVE' are `STASHING' and
|
|
|
2608 `RETRIEVING' respectively.
|
|
|
2609
|
|
|
2610 7.5 IGNORE and REMEMBER
|
|
|
2611 =======================
|
|
|
2612
|
|
|
2613 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2614 ------------------------------------------------------------------------
|
|
|
2615 yes all versions all versions all versions
|
|
|
2616
|
|
|
2617 Variables in INTERCAL can be either read-write or read-only. At the
|
|
|
2618 start of a program, all variables are read-write, but this status can
|
|
|
2619 be changed dynamically during execution of a program using the `IGNORE'
|
|
|
2620 and `REMEMBER' statements (whose gerunds are `IGNORING' and
|
|
|
2621 `REMEMBERING' respectively). The syntax is the same as for `STASH' and
|
|
|
2622 `RETRIEVE': the command's name followed by an intersection-separated
|
|
|
2623 list of variables. For instance:
|
|
|
2624
|
|
|
2625 DO IGNORE .4
|
|
|
2626 DO REMEMBER ,4 + ;5
|
|
|
2627
|
|
|
2628 Using the `IGNORE' statement sets a variable to be read-only (or does
|
|
|
2629 nothing if it's read-only already); `REMEMBER' sets it to be
|
|
|
2630 read-write. Any attempt to assign to a read-only variable silently
|
|
|
2631 fails. One place that this is used is in the system library; instead
|
|
|
2632 of not assigning to a variable in certain control flow paths, it
|
|
|
2633 instead sets it to be read-only so that subsequent assignments don't
|
|
|
2634 change its value (and sets it to be read-write at the end, which
|
|
|
2635 succeeds even if it was never set read-only in the first place); the
|
|
|
2636 advantage of this is that it doesn't need to remember what flow path
|
|
|
2637 it's on except in the variable's ignorance status.
|
|
|
2638
|
|
|
2639 The interaction between `IGNORE' and `RETRIEVE' was never defined very
|
|
|
2640 clearly, and is in fact different in C-INTERCAL, CLC-INTERCAL and
|
|
|
2641 J-INTERCAL; for more details, see *note RETRIEVE::.
|
|
|
2642
|
|
|
2643 7.6 ABSTAIN and REINSTATE
|
|
|
2644 =========================
|
|
|
2645
|
|
|
2646 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2647 ------------------------------------------------------------------------
|
|
|
2648 yes all versions all versions all versions
|
|
|
2649
|
|
|
2650 The statement identifier of a statement determines whether it's in an
|
|
|
2651 abstained or reinstated state at the start of a program; these states
|
|
|
2652 determine whether the statement runs at all when it's encountered. It
|
|
|
2653 is, however, possible to change this state dynamically during a
|
|
|
2654 program's execution, and the statements to do this are rather
|
|
|
2655 appropriately named `ABSTAIN' and `REINSTATE'. There are two forms of
|
|
|
2656 each, one which takes a single line label (which must be constant in
|
|
|
2657 most compilers, but can instead be an expression in recent CLC-INTERCAL
|
|
|
2658 versions), and one which takes an intersection-delimited list of
|
|
|
2659 gerunds. They look like this:
|
|
|
2660
|
|
|
2661 DO ABSTAIN FROM ABSTAINING + REINSTATING
|
|
|
2662 DO ABSTAIN FROM (10)
|
|
|
2663 DO REINSTATE CALCULATING
|
|
|
2664 DO REINSTATE (22)
|
|
|
2665
|
|
|
2666 (This also illustrates the gerunds used for these commands; note that
|
|
|
2667 `ABSTAINING' from `REINSTATING' is generally a bad idea!) The line
|
|
|
2668 referenced, or every command represented by any gerund referenced, are
|
|
|
2669 reinstated or abstained as appropriate (effectively changing the DO to
|
|
|
2670 DON'T (or PLEASE to PLEASE DON'T, etc.), or vice versa). Using these
|
|
|
2671 forms of `ABSTAIN' and/or `REINSTATE' won't abstain from a command
|
|
|
2672 that's already abstained, or reinstate a command that's already
|
|
|
2673 reinstated.
|
|
|
2674
|
|
|
2675 There is a strange set of restrictions on `ABSTAIN' and `REINSTATE'
|
|
|
2676 that has existed since INTERCAL-72; historically such restrictions have
|
|
|
2677 not always been implemented, or have not been implemented properly.
|
|
|
2678 They together define an unusual interaction of `ABSTAIN' and `GIVE UP'
|
|
|
2679 (note, for instance, that there isn't a gerund for `GIVE UP'). The
|
|
|
2680 wording used in the INTERCAL-72 manual is:
|
|
|
2681
|
|
|
2682 [...] the statement DO ABSTAIN FROM GIVING UP is not accepted, even
|
|
|
2683 though DON'T GIVE UP is. [...] DO REINSTATE GIVING UP is invalid,
|
|
|
2684 and attempting to REINSTATE a GIVE UP statement by line label will
|
|
|
2685 have no effect. Note that this insures that DON'T GIVE UP will
|
|
|
2686 always be a "do-nothing" statement.
|
|
|
2687
|
|
|
2688 This restriction was not implemented at all in the only CLC-INTERCAL
|
|
|
2689 version before 0.02 (i.e. version 0.01), or in C-INTERCAL versions
|
|
|
2690 before 1.26. The restriction was implemented in C-INTERCAL version 1.26
|
|
|
2691 and CLC-INTERCAL versions 0.02 and later as "`GIVE UP' cannot be
|
|
|
2692 `REINSTATED' or `ABSTAINED FROM'"; however, this is not strictly the
|
|
|
2693 same as the definition used by INTERCAL-72 (C-INTERCAL still uses this
|
|
|
2694 definition in CLC-INTERCAL compatibility mode). The J-INTERCAL
|
|
|
2695 implementation of this restriction is to make `REINSTATING' or
|
|
|
2696 `ABSTAINING' from a line label that refers to a `GIVE UP' statement a
|
|
|
2697 compile-time error, but this does not fit the INTERCAL-72 definition
|
|
|
2698 either. The definition adopted with version 0.27 and later of
|
|
|
2699 C-INTERCAL, which is hopefully correct, is to allow abstaining from a
|
|
|
2700 `GIVE UP' statement by line number but to rule out the other three
|
|
|
2701 cases (reinstating by line number silently fails, reinstating or
|
|
|
2702 abstaining by gerund is impossible because there is no gerund).
|
|
|
2703
|
|
|
2704 As well as CLC-INTERCAL's extension to abstain/reinstate by computed
|
|
|
2705 line number, there is also (since version 0.25) a C-INTERCAL-specific
|
|
|
2706 extension to `ABSTAIN', also known as `computed abstain', but with a
|
|
|
2707 different syntax and different semantics. It's written like an
|
|
|
2708 ordinary `ABSTAIN', but with an expression between the words `ABSTAIN'
|
|
|
2709 and `FROM', for instance:
|
|
|
2710
|
|
|
2711 DO ABSTAIN #1 FROM (1000)
|
|
|
2712 DO ABSTAIN .2 FROM WRITING IN
|
|
|
2713
|
|
|
2714 Unlike non-computed `ABSTAIN', this form allows a command to be
|
|
|
2715 abstained from even if it's already been abstained from; so if the
|
|
|
2716 first example command is run and line (1000) is already abstained, it
|
|
|
2717 becomes `double-abstained'. The number of times the statement is
|
|
|
2718 abstained from is equal to the number of times it was already abstained
|
|
|
2719 from, plus the expression (whereas with non-computed abstain, it ends
|
|
|
2720 up abstained once if it wasn't abstained at all, and otherwise stays at
|
|
|
2721 the same abstention status). Reinstating a statement always
|
|
|
2722 de-abstains it exactly once; so double-abstaining from a statement, for
|
|
|
2723 instance, means it needs to be reinstated twice before it will actually
|
|
|
2724 execute.
|
|
|
2725
|
|
|
2726 There are many uses for `ABSTAIN' (both the computed and non-computed
|
|
|
2727 versions) and `REINSTATE', especially when interacting with `ONCE' and
|
|
|
2728 `AGAIN' (*note ONCE and AGAIN::); the computed version, in particular,
|
|
|
2729 is a major part of a particular concise way to write conditionals and
|
|
|
2730 certain kinds of loops. They also play an important role in
|
|
|
2731 multithreaded programs.
|
|
|
2732
|
|
|
2733 7.7 READ OUT and WRITE IN
|
|
|
2734 =========================
|
|
|
2735
|
|
|
2736 The `READ OUT' and `WRITE IN' commands are the output and input
|
|
|
2737 commands in INTERCAL; they allow communication between the program and
|
|
|
2738 its user. There was a numeric I/O mechanism implemented in
|
|
|
2739 INTERCAL-72, and it (or trivial variants) have been likewise
|
|
|
2740 implemented in all more modern variants. However, it had some obvious
|
|
|
2741 deficiences (such as not being able to read its own output) which meant
|
|
|
2742 that other methods of I/O were implemented in C-INTERCAL and
|
|
|
2743 CLC-INTERCAL.
|
|
|
2744
|
|
|
2745 The syntax of `READ OUT' and `WRITE IN' is the same in all cases: the
|
|
|
2746 name of the command followed by an intersection-separated list of
|
|
|
2747 items; the form of each item, the compiler you are using, and its
|
|
|
2748 command line arguments together determine what sort of I/O is used,
|
|
|
2749 which can be different for different elements in the list.
|
|
|
2750
|
|
|
2751 7.7.1 INTERCAL-72 I/O
|
|
|
2752 ---------------------
|
|
|
2753
|
|
|
2754 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2755 ------------------------------------------------------------------------
|
|
|
2756 yes all versions see text all versions
|
|
|
2757
|
|
|
2758 INTERCAL-72 had its own versions of I/O commands; these commands are
|
|
|
2759 available in all modern INTERCAL compilers as well (but CLC-INTERCAL
|
|
|
2760 implements output slightly differently). To distinguish INTERCAL-72
|
|
|
2761 input and output from the other more modern types of I/O, the `READ
|
|
|
2762 OUT' and `WRITE IN' commands must take one of the following values: a
|
|
|
2763 onespot or twospot variable, a single element of a tail or hybrid
|
|
|
2764 array, or (in the case of `READ OUT') a constant, meaning that these
|
|
|
2765 are some examples of the possible forms:
|
|
|
2766
|
|
|
2767 READ OUT .1
|
|
|
2768 READ OUT ;2 SUB .3:4
|
|
|
2769 READ OUT #3
|
|
|
2770 WRITE IN :4
|
|
|
2771 WRITE IN ,5 SUB #6
|
|
|
2772
|
|
|
2773 The statements do what you would expect; `READ OUT' outputs its
|
|
|
2774 argument to the user, and `WRITE IN' inputs a number from the user and
|
|
|
2775 assigns it to the variable or array element referenced. (If the
|
|
|
2776 variable, or the array that contains the array element, happens to be
|
|
|
2777 read-only, the input or output still happens but in the case of `WRITE
|
|
|
2778 IN' silently skips the assignment, instead throwing away the input.)
|
|
|
2779 The formats used for input and output are, however, different from each
|
|
|
2780 other and from the formats used by most mainstream languages.
|
|
|
2781
|
|
|
2782 Input is achieved by writing a number in decimal, one digit at a time,
|
|
|
2783 with each digit written out as a word; so to input the number 12345, a
|
|
|
2784 user would have to type `ONE TWO THREE FOUR FIVE' as input (if they
|
|
|
2785 were using English, the most portable choice of language). In
|
|
|
2786 INTERCAL-72 only English is accepted as a language, but other compilers
|
|
|
2787 accept other languages in addition. C-INTERCAL from version 0.10
|
|
|
2788 onwards accepts English, Sanskrit, Basque, Tagalog, Classical Nahuatl,
|
|
|
2789 Georgian, and Kwakiutl; also Volapük from version 0.11 onwards, and
|
|
|
2790 Latin from version 0.20 onwards. J-INTERCAL accepts the same languages,
|
|
|
2791 except with Esperanto instead of Latin; from version 0.05 of
|
|
|
2792 CLC-INTERCAL onwards, the same list of languages as C-INTERCAL is
|
|
|
2793 supported (apart from Latin, which was added in version 1.-94.-8), plus
|
|
|
2794 Scottish Gaelic.
|
|
|
2795
|
|
|
2796 The format that output can be read in is a modified form of Roman
|
|
|
2797 numerals, known as `butchered' Roman numerals. INTERCAL-72, C-INTERCAL
|
|
|
2798 and J-INTERCAL do this the same way; CLC-INTERCAL is somewhat
|
|
|
2799 different. The characters `I', `V', `X', `L', `C', `D', and `M' mean 1,
|
|
|
2800 5, 10, 50, 100, 500 and 1000 respectively, placing a lower-valued
|
|
|
2801 letter after a higher-valued letter adds them, and placing a
|
|
|
2802 lower-valued letter before a higher-valued letter subtracts it from the
|
|
|
2803 value; so `XI' is 11 and `IX' is 9, for instance. In INTERCAL-72,
|
|
|
2804 C-INTERCAL, and J-INTERCAL, a bar over a numeral multiplies its value
|
|
|
2805 by 1000, and writing a letter in lowercase multiplies its value by
|
|
|
2806 1000000; however, CLC-INTERCAL uses lowercase to represent
|
|
|
2807 multiplication by 1000 and for multiplication by 1000000 writes a
|
|
|
2808 backslash before the relevant numeral.
|
|
|
2809
|
|
|
2810 7.7.2 C-INTERCAL I/O
|
|
|
2811 --------------------
|
|
|
2812
|
|
|
2813 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2814 ------------------------------------------------------------------------
|
|
|
2815 no version 0.07+ version 0.05+ no
|
|
|
2816
|
|
|
2817 C-INTERCAL's method of character-based (rather than numeric) input and
|
|
|
2818 output is known as the Turing Tape method; it is a binary
|
|
|
2819 (character-set-agnostic) input/output mechanism. To specify that
|
|
|
2820 C-INTERCAL-style I/O is being used, an array must be used as the
|
|
|
2821 argument to `READ OUT' or `WRITE IN'; as the syntax is the same as for
|
|
|
2822 CLC-INTERCAL's I/O, command-line arguments and the capabilities of the
|
|
|
2823 version of the compiler being used serve to distinguish the two
|
|
|
2824 mechanisms.
|
|
|
2825
|
|
|
2826 The character-based input writes as many characters into a tail or
|
|
|
2827 hybrid array as will fit, one character in each element. The number
|
|
|
2828 that's written into the array is not the character code, though, but
|
|
|
2829 the difference between the character code and the previous character
|
|
|
2830 code, modulo 256. (To be precise, the code is the new character minus
|
|
|
2831 the previous character, or 256 minus (the previous character minus the
|
|
|
2832 new character) if the previous character had a higher character code;
|
|
|
2833 the 'previous character' is the previous character from the input, not
|
|
|
2834 the previous character written into the array.) End-of-file causes 256
|
|
|
2835 to be written into the array. The concept is that of a circular tape
|
|
|
2836 containing all the characters, where the program measures how many
|
|
|
2837 spaces it needs to move along the tape to reach the next character.
|
|
|
2838 The 'previous character' starts at 0, but is preserved throughout the
|
|
|
2839 entire program, even from one `WRITE IN' to the next.
|
|
|
2840
|
|
|
2841 Character-based output uses a similar model, but conceptually the
|
|
|
2842 output device moves on the inside of the tape, rather than on the
|
|
|
2843 outside. Therefore, the character is that is actually output is the
|
|
|
2844 bit-reversal of the difference between the last character output before
|
|
|
2845 it was bit-reversed and the number found in the array (subtracting in
|
|
|
2846 that order, and adding 256 if the result is negative). (Rather than
|
|
|
2847 trying to parse the previous sentence, you may find it easier to look
|
|
|
2848 either at the source code to the compiler if you have it (the relevant
|
|
|
2849 part is binout in `src/cesspool.c') or at some example C-INTERCAL
|
|
|
2850 programs that do text-based I/O.)
|
|
|
2851
|
|
|
2852 7.7.3 CLC-INTERCAL I/O
|
|
|
2853 ----------------------
|
|
|
2854
|
|
|
2855 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2856 ------------------------------------------------------------------------
|
|
|
2857 no see text all versions no
|
|
|
2858
|
|
|
2859 There are also two CLC-INTERCAL-specific I/O mechanisms. These are
|
|
|
2860 Baudot-based text I/O (which is also implemented from C-INTERCAL version
|
|
|
2861 0.27 onwards), and CLC-INTERCAL generalised binary I/O (not implemented
|
|
|
2862 in C-INTERCAL).
|
|
|
2863
|
|
|
2864 Baudot text-based I/O is specified by using a tail array as an argument
|
|
|
2865 to `WRITE IN' or `READ OUT'. (A tail array can also be used to specify
|
|
|
2866 C-INTERCAL-style Turing Tape I/O. In order to determine which is used:
|
|
|
2867 both C-INTERCAL and CLC-INTERCAL use their own sort of I/O unless a
|
|
|
2868 command-line argument instructs them to use the other.) In the case of
|
|
|
2869 `WRITE IN', one line of input is requested from the user (C-INTERCAL
|
|
|
2870 requires this to be input in Latin-1, and will then automatically
|
|
|
2871 convert it; CLC-INTERCAL gives the option of various character sets for
|
|
|
2872 this input as command-line options); the final newline is removed from
|
|
|
2873 this line, then it is converted to extended Baudot and stored in the
|
|
|
2874 tail array specified (causing an error if the array is too small).
|
|
|
2875 Because Baudot is only a 5-bit character set, each element is padded to
|
|
|
2876 16 bits; CLC-INTERCAL pads with zeros, C-INTERCAL pads with random
|
|
|
2877 bits. Trying to input at end-of-file will act as if the input were a
|
|
|
2878 blank line. `READ OUT' is the reverse; it interprets the array as
|
|
|
2879 extended Baudot and converts it to an appropriate character set
|
|
|
2880 (Latin-1 for C-INTERCAL, or whatever was specified on the command line
|
|
|
2881 for CLC-INTERCAL), which is output to the user, followed by a newline.
|
|
|
2882 Note that the Baudot is often longer than the corresponding character
|
|
|
2883 in other character sets due to the need to insert shift codes; for
|
|
|
2884 information on the extended Baudot character set, *note Character
|
|
|
2885 Sets::.
|
|
|
2886
|
|
|
2887 Generalised binary I/O is specified using a hybrid array as an argument
|
|
|
2888 to `WRITE IN' or `READ OUT'. Input works by reading in a number of
|
|
|
2889 bytes equal to the length of the array (without trying to interpret
|
|
|
2890 them or translating them to a different character set), prepending a
|
|
|
2891 byte with 172 to the start, padding each byte to 16 bits with random
|
|
|
2892 data, then replacing each pair of consecutive bytes (that is, the first
|
|
|
2893 and second, the second and third, the third and fourth, and so on) with
|
|
|
2894 (the first element selected from the second element) mingled with (the
|
|
|
2895 complement of the first element selected from the complement of the
|
|
|
2896 second element). Output is the exact opposite of this process.
|
|
|
2897 End-of-file reads a 0, which is padded with 0s rather than random data;
|
|
|
2898 if a non-end-of-file 0 comes in from the data, its padding will contain
|
|
|
2899 at least one 1. Any all-bits-0-even-the-padding being read out will be
|
|
|
2900 skipped.
|
|
|
2901
|
|
|
2902 7.8 GIVE UP
|
|
|
2903 ===========
|
|
|
2904
|
|
|
2905 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2906 ------------------------------------------------------------------------
|
|
|
2907 yes all versions all versions all versions
|
|
|
2908
|
|
|
2909 The `GIVE UP' command causes the program to end (or, in a multithreaded
|
|
|
2910 program, causes the current thread to end). It is written simply as
|
|
|
2911 `GIVE UP'. There is not much else to say about it, except to mention
|
|
|
2912 that it is the only way to end the program without an error unless the
|
|
|
2913 last line of the program is `TRY AGAIN', and that it has an unusual
|
|
|
2914 interaction with `ABSTAIN'; for details of this, see *note ABSTAIN::.
|
|
|
2915 (Going past the last command in the program is an error.)
|
|
|
2916
|
|
|
2917 There is no gerund for `GIVE UP'; in particular, `GIVING UP' is a
|
|
|
2918 syntax error.
|
|
|
2919
|
|
|
2920 7.9 TRY AGAIN
|
|
|
2921 =============
|
|
|
2922
|
|
|
2923 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2924 ------------------------------------------------------------------------
|
|
|
2925 no version 0.25+ no no
|
|
|
2926
|
|
|
2927 The `TRY AGAIN' command is a very simple command with many limitations;
|
|
|
2928 its effect is to place the entire program in a loop. If it exists, it
|
|
|
2929 must be the very last command in the program (it cannot even be
|
|
|
2930 followed by syntax errors), and it causes execution of the program to
|
|
|
2931 go back to the first command. If the `TRY AGAIN' command is abstained
|
|
|
2932 or for some other reason doesn't execute when reached, it exits the
|
|
|
2933 program without the error that would usually be caused by going past
|
|
|
2934 the last line of code.
|
|
|
2935
|
|
|
2936 The gerund for `TRY AGAIN' is `TRYING AGAIN'.
|
|
|
2937
|
|
|
2938 7.10 COME FROM and NEXT FROM
|
|
|
2939 ============================
|
|
|
2940
|
|
|
2941 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2942 ------------------------------------------------------------------------
|
|
|
2943 no see text see text see text
|
|
|
2944
|
|
|
2945 The `COME FROM' statement (incidentally also invented in 1972, but not
|
|
|
2946 in connection with INTERCAL) is the main control-flow command in
|
|
|
2947 CLC-INTERCAL (which deprecates `NEXT'), and one of two main control
|
|
|
2948 flow structures in other modern INTERCAL compilers. It takes either a
|
|
|
2949 label or an expression as its argument; these forms are noncomputed
|
|
|
2950 `COME FROM' and computed `COME FROM'.
|
|
|
2951
|
|
|
2952 Noncomputed `COME FROM' was implemented in version 0.5 of C-INTERCAL,
|
|
|
2953 but did not conform to modern-day semantics until version 0.7; it is
|
|
|
2954 available in every version of CLC-INTERCAL and J-INTERCAL. Computed
|
|
|
2955 `COME FROM' support is available in every version of CLC-INTERCAL and
|
|
|
2956 in C-INTERCAL from version 0.25 onwards, but not in J-INTERCAL; the
|
|
|
2957 variant `NEXT FROM' of `COME FROM' is available from CLC-INTERCAL
|
|
|
2958 version 1.-94.-8 and C-INTERCAL version 0.26 (both computed and
|
|
|
2959 noncomputed). C-INTERCAL and CLC-INTERCAL also have a from-gerund form
|
|
|
2960 of `COME FROM' and `NEXT FROM', which was also implemented from
|
|
|
2961 CLC-INTERCAL version 1.-94.-8 and C-INTERCAL version 0.26.
|
|
|
2962
|
|
|
2963 The basic rule of `COME FROM' is that if a `COME FROM' statement
|
|
|
2964 references another statement, whenever that statement is reached,
|
|
|
2965 control flow will be transferred to the `COME FROM' after that
|
|
|
2966 statement finishes executing. (`NEXT FROM' is identical except that in
|
|
|
2967 addition to the `COME FROM' behaviour, the location immediately after
|
|
|
2968 the statement that was nexted from is saved on the NEXT stack, in much
|
|
|
2969 the same way as if the statement being nexted from was itself a `NEXT'.)
|
|
|
2970
|
|
|
2971 Here are examples of noncomputed, computed, and from-gerund `COME FROM':
|
|
|
2972
|
|
|
2973 DO COME FROM (10)
|
|
|
2974 DO COME FROM #2$'.1~#1'
|
|
|
2975 DO COME FROM COMING FROM
|
|
|
2976
|
|
|
2977 (The last example is an infinite loop. If it said `DO NEXT FROM
|
|
|
2978 NEXTING FROM', it would not be an infinite loop because the NEXT stack
|
|
|
2979 would overflow and cause an error. This also establishes the gerunds
|
|
|
2980 used for `COME FROM' and `NEXT FROM'.)
|
|
|
2981
|
|
|
2982 There are some things to be careful with involving `COME FROM' and
|
|
|
2983 `NEXT FROM'. First, if the statement come from or nexted from happens
|
|
|
2984 to be a `NEXT', the `NEXT' doesn't count as 'finishing executing' until
|
|
|
2985 the NEXT stack entry created by the `NEXT' is `RESUME'd to. In
|
|
|
2986 particular, this means that if `FORGET' is used to remove the entry, or
|
|
|
2987 a `RESUME' with a large argument resumes a lower entry, the `COME FROM'
|
|
|
2988 doesn't steal execution at all.
|
|
|
2989
|
|
|
2990 Second, you may be wondering what happens if two `COME FROM's or `NEXT
|
|
|
2991 FROM's aim at the same line. In a non-multithreaded program (whether a
|
|
|
2992 program is multithreaded or not is determined by a compiler option for
|
|
|
2993 those compilers that support it), this is an error; but it is only an
|
|
|
2994 error if the statement that they both point to finishes running, and
|
|
|
2995 both `COME FROM's or `NEXT FROM's try to execute as a result (they
|
|
|
2996 might not if, for instance, one is abstained or has a double-oh-seven
|
|
|
2997 causing it not to run some of the time). If both `COME FROM's or `NEXT
|
|
|
2998 FROM's are noncomputed, however, a compiler can (but does not have to)
|
|
|
2999 give a compile time error if two `COME FROM's or `NEXT FROM's share a
|
|
|
3000 label, and so that situation should be avoided in portable code. (If
|
|
|
3001 it is wanted, one solution that works for C-INTERCAL and CLC-INTERCAL is
|
|
|
3002 to use computed `COME FROM's or `NEXT FROM's with a constant
|
|
|
3003 expression.)
|
|
|
3004
|
|
|
3005 8 System Library
|
|
|
3006 ****************
|
|
|
3007
|
|
|
3008 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3009 ------------------------------------------------------------------------
|
|
|
3010 yes all versions no all versions
|
|
|
3011
|
|
|
3012 INTERCAL has a system library, called `syslib'. It is included
|
|
|
3013 automatically at the end of your program by the compiler whenever your
|
|
|
3014 program refers to a line from (1000) to (1999) without defining any
|
|
|
3015 line in that range in the program. (Although it is not added
|
|
|
3016 automatically by the compiler in CLC-INTERCAL, it is trivial to
|
|
|
3017 concatenate a copy onto the end of the program; copies of the system
|
|
|
3018 library are available from many sources on the Internet, including a
|
|
|
3019 version in the example code that comes with C-INTERCAL.)
|
|
|
3020
|
|
|
3021 The intention of the system library is to provide a range of useful
|
|
|
3022 capabilities, like multiplication, that can otherwise be hard to write
|
|
|
3023 in INTERCAL. System library routines are used by `NEXTING' to their
|
|
|
3024 line number (*note NEXT::), where they will make changes to certain
|
|
|
3025 variables depending on certain other variables (depending on which
|
|
|
3026 routine is called), and `RESUME' back to the original program. As the
|
|
|
3027 system library is itself written in INTERCAL, there are some
|
|
|
3028 restrictions that need to be obeyed for calls to it to be guaranteed to
|
|
|
3029 work; none of the variables it uses (`.1' to `.6' and `:1' to `:5')
|
|
|
3030 should be read-only or overloaded (although the value of any variables
|
|
|
3031 that aren't mentioned in the routine's description will be preserved by
|
|
|
3032 the routine), and none of the lines in it should have their abstention
|
|
|
3033 status changed by lines outside it (this can happen with blatant
|
|
|
3034 infractions like `DO ABSTAIN FROM (1500)' or more subtle problems like
|
|
|
3035 gerund-abstention) or have `COME FROM's or `NEXT FROM's aiming at them.
|
|
|
3036
|
|
|
3037 The system library is currently available in all bases from 2 to 7
|
|
|
3038 (*note TriINTERCAL::), but not every command is available in every
|
|
|
3039 base, and C-INTERCAL is the only one of the three compilers listed above
|
|
|
3040 that use the system library to ship with a version in bases other than
|
|
|
3041 2. (This table was originally based on the INTERCAL-72 manual, but has
|
|
|
3042 had extra information added for bases other than 2.) Here, "overflow
|
|
|
3043 checked" means that #1 is assigned to .4 if there is not an overflow,
|
|
|
3044 and #2 is assigned to .4 if there is; "overflow captured" means that if
|
|
|
3045 there is overflow, the digit that overflowed is stored in the variable
|
|
|
3046 referenced. In all cases, division by 0 returns 0.
|
|
|
3047
|
|
|
3048 Line Description Bases
|
|
|
3049 -----------------------------------------------------------------------
|
|
|
3050 (1000) .3 <- .1 plus .2, error exit on overflow 2, 3, 4,
|
|
|
3051 5, 6, 7
|
|
|
3052 (1009) .3 <- .1 plus .2, overflow checked 2, 3, 4,
|
|
|
3053 5, 6, 7
|
|
|
3054 (1010) .3 <- .1 minus .2, no action on overflow 2, 3, 4,
|
|
|
3055 5, 6, 7
|
|
|
3056 (1020) .1 <- .1 plus #1, no action on overflow 2, 3, 4,
|
|
|
3057 5, 6, 7
|
|
|
3058 (1030) .3 <- .1 times .2, error exit on overflow 2, 3, 4,
|
|
|
3059 5, 6, 7
|
|
|
3060 (1039) .3 <- .1 times .2, overflow checked 2, 3, 4,
|
|
|
3061 5, 6, 7
|
|
|
3062 (1040) .3 <- .1 divided by .2 2, 3, 4,
|
|
|
3063 5, 6, 7
|
|
|
3064 (1050) .2 <- :1 divided by .1, error exit on overflow 2, 3, 4,
|
|
|
3065 5, 6, 7
|
|
|
3066 (1200) .2 <- .1 times #2, overflow captured in .3 4, 6
|
|
|
3067 (1210) .2 <- .1 divided by #2, one digit after the 4, 6
|
|
|
3068 quartic or sextic point stored in .3
|
|
|
3069 (1500) :3 <- :1 plus :2, error exit on overflow 2, 3, 4,
|
|
|
3070 5, 6, 7
|
|
|
3071 (1509) :3 <- :1 plus :2, overflow checked 2, 3, 4,
|
|
|
3072 5, 6, 7
|
|
|
3073 (1510) :3 <- :1 minus :2, no action on overflow 2, 3, 4,
|
|
|
3074 5, 6, 7
|
|
|
3075 (1520) :1 <- .1 concatenated with .2 2, 3, 4,
|
|
|
3076 5, 6, 7
|
|
|
3077 (1530) :1 <- .1 times .2 2, 3, 4,
|
|
|
3078 5, 6, 7
|
|
|
3079 (1540) :3 <- :1 times :2, error exit on overflow 2, 3, 4,
|
|
|
3080 5, 6, 7
|
|
|
3081 (1549) :3 <- :1 times :2, overflow checked 2, 3, 4,
|
|
|
3082 5, 6, 7
|
|
|
3083 (1550) :3 <- :1 divided by :2 2, 3, 4,
|
|
|
3084 5, 6, 7
|
|
|
3085 (1700) :2 <- :1 times #2, overflow captured in .1 4, 6
|
|
|
3086 (1710) :2 <- :1 divided by #2, one digit after the 4, 6
|
|
|
3087 quartic or sextic point stored in .1
|
|
|
3088 (1720) :2 <- :1 times the least significant digit of 5, 7
|
|
|
3089 .1, overflow captured in .2
|
|
|
3090 (1900) .1 <- uniform random number from #0 to #65535 2, 3, 4,
|
|
|
3091 5, 6, 7
|
|
|
3092 (1910) .2 <- normal random number from #0 to .1, with 2, 3, 4,
|
|
|
3093 standard deviation .1 divided by #12 5, 6, 7
|
|
|
3094
|
|
|
3095 If you happen to be using base 2, and are either using the external
|
|
|
3096 call system (*note External Calls::) or are willing to use it, it is
|
|
|
3097 possible to use a version of the system library written in C for speed,
|
|
|
3098 rather than the default version (which is written in INTERCAL). To do
|
|
|
3099 this, use the command line options `-eE' (before the INTERCAL file),
|
|
|
3100 and `syslibc' (at the end of the command line).
|
|
|
3101
|
|
|
3102 PART III: INTERCAL DIALECTS AND EXTENSIONS
|
|
|
3103 ******************************************
|
|
|
3104
|
|
|
3105 9 TriINTERCAL
|
|
|
3106 *************
|
|
|
3107
|
|
|
3108 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3109 ------------------------------------------------------------------------
|
|
|
3110 no version 0.7+ version no
|
|
|
3111 1.-94.-8+
|
|
|
3112
|
|
|
3113 One extension to INTERCAL that is implemented by both C-INTERCAL and
|
|
|
3114 CLC-INTERCAL is known as TriINTERCAL, and extends INTERCAL to bases
|
|
|
3115 other than binary. Unlike ordinary INTERCAL programs, which have the
|
|
|
3116 extension `.i', TriINTERCAL programs in bases from 3 to 7 (the only
|
|
|
3117 allowed bases) have extensions from `.3i' to `.7i' respectively.
|
|
|
3118
|
|
|
3119 The change of numeric base only affects expressions, and in particular
|
|
|
3120 the behaviour of operators, and the range of variables. (The onespot
|
|
|
3121 and twospot ranges become the highest number of trits or other digits
|
|
|
3122 in the base required that fit inside the binary ranges, so for
|
|
|
3123 instance, the maximum value of a onespot variable in ternary is 59048,
|
|
|
3124 or 3 to the power 10 minus 1.) Interleave/mingle is the simplest to
|
|
|
3125 explain; it alternates digits just as it alternated bits in binary.
|
|
|
3126 The other operators all change, as follows:
|
|
|
3127
|
|
|
3128 * Exclusive-or becomes two operators, known either as
|
|
|
3129 subtract-without-borrow and add-without-carry due to their
|
|
|
3130 mathematical interpretations, or what and sharkfin after their
|
|
|
3131 Atari syntax representations (`?' and `^'). (In Princeton syntax,
|
|
|
3132 these are the bookworm or yen sign, and a spike (`|').) The two
|
|
|
3133 operators do the same thing in binary, but differ in higher bases.
|
|
|
3134 (Nevertheless, it is an error to use a sharkfin in binary, because
|
|
|
3135 it is a so-called `controlled unary operator', as are the rest of
|
|
|
3136 the new operators defined in this section, which has a lower limit
|
|
|
3137 on which base it is allowed in.) Instead of doing the exclusive-or
|
|
|
3138 operation, the bits being combined are either subtracted or added;
|
|
|
3139 if the result is out of range for the base being used, the base is
|
|
|
3140 added or subtracted from the result until it is in range. (For the
|
|
|
3141 subtraction, the bit that was less significant is subtracted from
|
|
|
3142 the bit that was more significant in any given pair of bits,
|
|
|
3143 except for the subtraction between the most and least significant
|
|
|
3144 bits, where the most significant bit is subtracted from the least.)
|
|
|
3145
|
|
|
3146 * The AND and OR operators are generalised into an entire sequence of
|
|
|
3147 operators; the number of operators available is the same as the
|
|
|
3148 base that is being used. In base 3, the third operator is known
|
|
|
3149 as BUT; in other bases, there are no commonly accepted names for
|
|
|
3150 the extra operators, so names that reflect the notation are used
|
|
|
3151 here.
|
|
|
3152
|
|
|
3153 The way to think of it is this: in base 2, an AND gives the result
|
|
|
3154 0 if either argument is a 0, and otherwise a 1, and likewise, an OR
|
|
|
3155 gives the result 1 if either argument is a 1, and otherwise a 0;
|
|
|
3156 they could be said to favour 0 over 1 and 1 over 0 respectively.
|
|
|
3157 In base 3, AND favours 0 over 2 over 1, OR favours 2 over 1 over
|
|
|
3158 0, and BUT favours 1 over 0 over 2. (The symbol for BUT is `@' (a
|
|
|
3159 `whirlpool', which is another name for the BUT operation) in Atari
|
|
|
3160 syntax, and `?' in Princeton syntax.) The pattern continues: in
|
|
|
3161 base 4, AND favours 0 over 3 over 2 over 1, BUT favours 1 over 0
|
|
|
3162 over 3 over 2, 2BUT (written `2@' or `2?') favours 2 over 1 over 0
|
|
|
3163 over 3, and OR favours 3 over 2 over 1 over 0. (This can be
|
|
|
3164 extended to higher bases following the same pattern, introducing
|
|
|
3165 operators `3@' or `3?', etc., to favour 3, etc., when neither AND
|
|
|
3166 (which always favours 0) nor OR (which favours the highest digit
|
|
|
3167 in the base) are available.) All the whirlpool operators are
|
|
|
3168 controlled unary operators, which are only legal when both the base
|
|
|
3169 contains the favoured digit, and they aren't redundant to AND nor
|
|
|
3170 OR.
|
|
|
3171
|
|
|
3172 * Select has its semantics modified to deal with more than one
|
|
|
3173 nonzero digit in the base. It starts off by doing an AND (in
|
|
|
3174 whatever base is being used) between the two numbers being
|
|
|
3175 selected; then the bits of the result are sorted by the bits of
|
|
|
3176 the right-hand argument to the select, with bits corresponding to
|
|
|
3177 0s in the right-hand argument ending up more significant than bits
|
|
|
3178 corresponding to high digits in the right-hand argument. In base
|
|
|
3179 2, this has the same effect as a traditional-style select.
|
|
|
3180
|
|
|
3181
|
|
|
3182 Note that the base doesn't affect anything other than variable ranges
|
|
|
3183 and expressions; in particular, it doesn't affect the bit-reversal used
|
|
|
3184 by Turing Tape I/O. (The tape still has characters written on it in
|
|
|
3185 binary, even though the program uses a different base.)
|
|
|
3186
|
|
|
3187 10 Multithreading and Backtracking
|
|
|
3188 **********************************
|
|
|
3189
|
|
|
3190 The multithreading and backtracking extensions to INTERCAL were
|
|
|
3191 originally invented by Malcom Ryan, who implemented `COME FROM'-based
|
|
|
3192 multithreading as a modified version of C-INTERCAL, known as Threaded
|
|
|
3193 INTERCAL, but did not implement backtracking. (The same functionality
|
|
|
3194 is implemented in C-INTERCAL today, but with different code. Most
|
|
|
3195 likely, this means that the original code was better.) He also
|
|
|
3196 invented the original version of Backtracking INTERCAL, but did not
|
|
|
3197 implement it; the only known implementation is the C-INTERCAL one. A
|
|
|
3198 different version of multithreading, using `WHILE', was implemented as
|
|
|
3199 part of CLC-INTERCAL (like all extensions first available in
|
|
|
3200 CLC-INTERCAL, it is most likely due to Claudio Calvelli) and then added
|
|
|
3201 to C-INTERCAL, although its implications were not noticed for some time
|
|
|
3202 afterwards.
|
|
|
3203
|
|
|
3204 So nowadays, three freely-mixable threading-like extensions to INTERCAL
|
|
|
3205 exist, all of which are implemented in C-INTERCAL. (A fourth, Quantum
|
|
|
3206 INTERCAL, is implemented in CLC-INTERCAL but not C-INTERCAL, and so
|
|
|
3207 will not be discussed further here.) If you're wondering about the
|
|
|
3208 description of backtracking as a threading-like extension, it's
|
|
|
3209 implemented with much of the same code as multithreading in C-INTERCAL,
|
|
|
3210 because the INTERCAL version can be seen as roughly equivalent to
|
|
|
3211 multithreading where the threads run one after another rather than
|
|
|
3212 simultaneously. (This conceptualisation is probably more confusing
|
|
|
3213 than useful, though, and is also not strictly correct. The same could
|
|
|
3214 probably be said about INTERCAL as a whole, for that matter.)
|
|
|
3215
|
|
|
3216 10.1 Multithreading using COME FROM
|
|
|
3217 ===================================
|
|
|
3218
|
|
|
3219 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3220 ------------------------------------------------------------------------
|
|
|
3221 no version 0.25+ version 0.05+ no
|
|
|
3222
|
|
|
3223 The original multithreading implementation worked by giving a new
|
|
|
3224 meaning to what was previously an error condition. If in a
|
|
|
3225 multithreaded program (a program is marked as multithreaded using
|
|
|
3226 options to a compiler) two or more `COME FROM's or `NEXT FROM's (or a
|
|
|
3227 mixture of the these) attempt to steal control simultaneously, the
|
|
|
3228 original thread splits into multiple threads, one for each of the
|
|
|
3229 commands trying to take control, and a different command gains control
|
|
|
3230 of the program in each case.
|
|
|
3231
|
|
|
3232 From then on, all the threads run simultaneously. The only thing
|
|
|
3233 shared between threads (apart from the environment in which they run)
|
|
|
3234 is the abstained/reinstated status of each command; everything else is
|
|
|
3235 separate. This means, for instance, that it's possible to change the
|
|
|
3236 value of a variable in one thread, and it will not affect the
|
|
|
3237 corresponding variable in other threads created this way. Likewise,
|
|
|
3238 there is a separate NEXT stack in each thread; if both a `COME FROM'
|
|
|
3239 and a `NEXT FROM' aim at the same line, for instance, the `NEXT FROM'
|
|
|
3240 thread will end up with a NEXT stack entry that isn't in the `COME
|
|
|
3241 FROM' thread, created by the `NEXT FROM' itself. This is known as
|
|
|
3242 unwoven thread creation; none of the threads created this way are
|
|
|
3243 `woven' with any of the other threads created this way. (Whether
|
|
|
3244 threads are woven depends on how they were created.) If the thread
|
|
|
3245 being split was itself woven with other threads, exactly one of the
|
|
|
3246 resulting threads after the split is woven with the threads that the
|
|
|
3247 original thread was woven to, but the rest will not be woven to
|
|
|
3248 anything. (If that seems a somewhat unusual rule: well, this is
|
|
|
3249 INTERCAL.)
|
|
|
3250
|
|
|
3251 In C-INTERCAL, there are other guarantees that can be made about unwoven
|
|
|
3252 threads (that is, threads not woven to any other thread). In
|
|
|
3253 particular, they can all be guaranteed to run at approximately the same
|
|
|
3254 speed; to be more precise, the number of commands that have been given
|
|
|
3255 the chance to execute in any given thread will not differ by more than
|
|
|
3256 2 from the number of commands that have been given the chance to
|
|
|
3257 execute in any other thread that was created at the same time.
|
|
|
3258 (However, `COME FROM's and `NEXT FROM's can make this relationship less
|
|
|
3259 precise; it is unspecified (in the technical sense that means the
|
|
|
3260 compiler can choose any option it likes and change its mind on a whim
|
|
|
3261 without telling anyone) whether a `COME FROM' or `NEXT FROM' aiming at
|
|
|
3262 the current command counts towards the command total or not, thus
|
|
|
3263 causing the relationship to become weaker the more of them have the
|
|
|
3264 chance to execute. In versions of C-INTERCAL from 0.27 onwards, there
|
|
|
3265 is a third guarantee; that if a `COME FROM' comes from itself, it will
|
|
|
3266 actually give other threads at least some chance to run, at some speed,
|
|
|
3267 by counting itself as a command every now and then; previously this
|
|
|
3268 requirement didn't exist, meaning that a `COME FROM' could block all
|
|
|
3269 threads if it aimed for itself due to the speed restrictions and the
|
|
|
3270 fact that `COME FROM's need not count towards the total command count.)
|
|
|
3271 Also, all commands, including any `ONCE' or `AGAIN' attached to the
|
|
|
3272 command, are atomic; this means that it's impossible for another thread
|
|
|
3273 to conflict with what the command is doing. (In a departure from the
|
|
|
3274 usual INTERCAL status quo, these guarantees are somewhat _better_ than
|
|
|
3275 in most other languages that implement threading, amusingly continuing
|
|
|
3276 to leave INTERCAL with the status of being unlike any other mainstream
|
|
|
3277 language.)
|
|
|
3278
|
|
|
3279 The only way to communicate between unwoven threads is by changing the
|
|
|
3280 abstention status of commands; this always affects all threads in the
|
|
|
3281 program, whether woven or not. (The combination of `ABSTAIN' and
|
|
|
3282 `ONCE' is one way to communicate atomically, due to the atomic nature
|
|
|
3283 of `ONCE'.)
|
|
|
3284
|
|
|
3285 If there are at least two threads, the `GIVE UP' command ends the
|
|
|
3286 current thread, rather than the current program.
|
|
|
3287
|
|
|
3288 10.2 Multithreading using WHILE
|
|
|
3289 ===============================
|
|
|
3290
|
|
|
3291 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3292 ------------------------------------------------------------------------
|
|
|
3293 no version 0.27+ version 0.05+ no
|
|
|
3294
|
|
|
3295 The `WHILE' command (which is not strictly speaking a command, but more
|
|
|
3296 a sort of metacommand that joins commands) is a second method of
|
|
|
3297 achieving multithreading. (In CLC-INTERCAL, there are at least two
|
|
|
3298 other meanings for `WHILE', but only the one implemented in C-INTERCAL
|
|
|
3299 is discussed here.) The syntax is somewhat unusual, and consists of
|
|
|
3300 two commands separated by the `WHILE' keyword, but sharing the
|
|
|
3301 statement identifier, execution chance, and any `ONCE'/`AGAIN' keyword
|
|
|
3302 that may be present. For instance:
|
|
|
3303
|
|
|
3304 (1) DO COME FROM ".2~.2"~#1 WHILE :1 <-
|
|
|
3305 "'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$
|
|
|
3306 "'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
|
|
|
3307
|
|
|
3308 (OK, maybe that's an unnecessarily complicated example, and maybe it
|
|
|
3309 shouldn't have included the `/' operator which is part of another
|
|
|
3310 INTERCAL extension (*note Operand Overloading::). Still, I thought
|
|
|
3311 that maybe you'd want to see how addition can be implemented in
|
|
|
3312 INTERCAL.)
|
|
|
3313
|
|
|
3314 A `WHILE' command starts two threads (the original thread that ran that
|
|
|
3315 command and a new one), one of which runs the command to the left of
|
|
|
3316 the `WHILE' and one of which runs the command to the right. Any line
|
|
|
3317 number applies to the left-hand command, not the WHILE as a whole,
|
|
|
3318 which is a metalanguage construct. `NEXTING FROM', `ABSTAINING FROM'
|
|
|
3319 or similar behaviour with respect to the `WHILE' itself is impossible,
|
|
|
3320 although it's certainly possible to abstain from either of its operands
|
|
|
3321 (and abstaining from the left operand has much the same effect as
|
|
|
3322 abstaining from the `WHILE' itself; the right-hand thread deliberately
|
|
|
3323 takes a bit of time to get started just so that this behaviour
|
|
|
3324 happens). The right-command thread starts just before the left command
|
|
|
3325 is run (so `NEXTING', etc., directly to the left command will not start
|
|
|
3326 that loop in the first place); if that command finishes (which may be
|
|
|
3327 almost immediately for something like a calculate command, or take a
|
|
|
3328 long time for something like `NEXT'), that thread loops and reruns that
|
|
|
3329 command as long as the left command has not finished; `COMING FROM'
|
|
|
3330 that command, or a `NEXT'/`NEXT FROM' from/aiming at that command,
|
|
|
3331 doesn't count as finishing that command until it is `RESUME'd back to
|
|
|
3332 (if possible; if it's come from, that command can never end and the
|
|
|
3333 right-hand loop will continue forever, or until it `GIVE's `UP' or the
|
|
|
3334 loop ends due to the command ending later in another thread). A
|
|
|
3335 `WHILE' command itself exists across all threads of a multithreaded
|
|
|
3336 program in a way; for each left-hand command that ends (in any thread),
|
|
|
3337 the next time a right-hand command of the same `WHILE' ends it will
|
|
|
3338 cause the thread it's looping in to end, regardless of whether that
|
|
|
3339 thread corresponds to the thread in which the left-hand command ended.
|
|
|
3340 (As well as a right-hand command ending, there's also the possibility
|
|
|
3341 that it never got started; there is a delay before the right-hand
|
|
|
3342 command runs during which a left-hand command ending can prevent the
|
|
|
3343 right-hand thread starting in the first place; this counts as the same
|
|
|
3344 sort of event as terminating a right-hand loop, and can substitute for
|
|
|
3345 it anywhere a right-hand command ending is mentioned.) There is one
|
|
|
3346 exception, in that if two or more left-hand commands end in a space of
|
|
|
3347 time in which no right-hand commands for that `WHILE' ends, they
|
|
|
3348 together only cause one right-hand command to end. (What, did you
|
|
|
3349 expect the logical and orthogonal behaviour?)
|
|
|
3350
|
|
|
3351 The two threads produced by a `WHILE' (the original thread and a new
|
|
|
3352 copy of it) have more in common than ordinary INTERCAL threads created
|
|
|
3353 by `COME FROM'; ordinary threads share only `ABSTAIN'/`REINSTATE'
|
|
|
3354 information, whereas the `WHILE'-produced threads count as `woven'
|
|
|
3355 threads which also share variables and stashes. (They still have
|
|
|
3356 separate instruction pointers, separate instruction pointer stacks,
|
|
|
3357 such as the NEXT stack, and separate choicepoint lists. Overloading
|
|
|
3358 information is shared, though.) Being woven is a relationship between
|
|
|
3359 two or more threads, rather than an attribute of a thread, although a
|
|
|
3360 thread can be referred to as being unwoven if it is not woven to any
|
|
|
3361 other thread.
|
|
|
3362
|
|
|
3363 Ordinary multithreading cannot create woven threads. When threads are
|
|
|
3364 created by multiple `COME FROM's from an original thread, which was
|
|
|
3365 woven with at least one other thread, one of the resulting threads
|
|
|
3366 counts as the `original' thread and remains woven; the rest are `new'
|
|
|
3367 threads which initially start out with the same data as the original,
|
|
|
3368 but are not woven with anything. Backtracking in a thread (*note
|
|
|
3369 Backtracking::) causes it to unweave with any threads it may be woven
|
|
|
3370 with at the time (so the data in the thread that backtracks is set back
|
|
|
3371 to the data it, and the threads it was woven with at the time, had at
|
|
|
3372 the time of the `MAYBE', but the other threads continue with the same
|
|
|
3373 data as before). The only way to cause three or more threads to become
|
|
|
3374 woven is with a new `WHILE' inside one of the threads that is already
|
|
|
3375 woven, which causes all the new threads to be woven together (the
|
|
|
3376 weaving relationship is transitive).
|
|
|
3377
|
|
|
3378 10.3 Backtracking
|
|
|
3379 =================
|
|
|
3380
|
|
|
3381 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3382 ------------------------------------------------------------------------
|
|
|
3383 no version 0.25+ no no
|
|
|
3384
|
|
|
3385 A somewhat unusual threading construct that's available is
|
|
|
3386 backtracking. In case you haven't come across it before (the concept
|
|
|
3387 exists in other languages but is implemented differently and usually in
|
|
|
3388 a less general way), the basic idea is that instead of executing or not
|
|
|
3389 executing a command, you can `MAYBE' execute a command. This causes
|
|
|
3390 the command to be executed, but also creates a dormant thread in which
|
|
|
3391 the command wasn't executed; at any time later, the program can either
|
|
|
3392 decide that it liked the consequences of the command and `GO AHEAD' and
|
|
|
3393 get rid of the dormant thread, or decide that it didn't like the
|
|
|
3394 consquences of the command and `GO BACK' to the dormant thread,
|
|
|
3395 discarding the current one. The dormant thread is more commonly called
|
|
|
3396 a `choicepoint', that is, a point at which a choice was made but a
|
|
|
3397 different choice can still be made, and is generally not thought of as
|
|
|
3398 a thread at all by most programmers. (In case you're wondering:
|
|
|
3399 dormant threads are always unwoven.)
|
|
|
3400
|
|
|
3401 To create a choicepoint, the statement identifier `MAYBE' is used,
|
|
|
3402 rather than the more usual `DO' or `PLEASE'. (Combination statement
|
|
|
3403 identifiers are still allowed, but must be in the order `MAYBE PLEASE
|
|
|
3404 DO NOT' with optionally some parts omitted, or different versions of
|
|
|
3405 `NOT' used, or both.) Here's an example:
|
|
|
3406
|
|
|
3407 MAYBE DON'T GIVE UP
|
|
|
3408
|
|
|
3409 When a command whose statement identifer contains `MAYBE' is reached,
|
|
|
3410 it is executed or not executed as normal, but in addition a choicepoint
|
|
|
3411 is created containing the program as it is at that time. Only
|
|
|
3412 `ABSTAIN' and `REINSTATE', which always affect all threads in a program
|
|
|
3413 (even choicepoints), can alter the values stored in the choicepoint; so
|
|
|
3414 in this way, a choicepoint is also somewhat similar to the concept of a
|
|
|
3415 continuation in other languages. The choicepoint is placed on a
|
|
|
3416 choicepoint stack, which is maintained separately for each thread in
|
|
|
3417 much the same way that stashes and the `NEXT' stack are.
|
|
|
3418
|
|
|
3419 The choicepoint does not actually do anything immediately, but if the
|
|
|
3420 program doesn't like the look of where it's ended up, or it decides to
|
|
|
3421 change its mind, or just wants to try all the possibilities, it can
|
|
|
3422 call the `GO BACK' command (which has no arguments, and is just the
|
|
|
3423 statement identifier, optional execution chance, `GO BACK', and
|
|
|
3424 optional `ONCE' or `AGAIN'). This causes the current thread to unweave
|
|
|
3425 from all other threads and then replace itself with the thread created
|
|
|
3426 by the choicepoint on top of the choicepoint stack. The difference is
|
|
|
3427 that this time, the abstention or reinstatement status of the command
|
|
|
3428 that was modified with `MAYBE' is temporarily reversed for determining
|
|
|
3429 whether it runs or not (this reversal only lasts immediately after the
|
|
|
3430 `GO BACK', and does not affect uses of the command in other threads or
|
|
|
3431 later in the same thread), so unless it has been `ABSTAIN'ed or
|
|
|
3432 `REINSTATE'd in the meantime it will run if and only if it wasn't run
|
|
|
3433 the first time. The choicepoint stack's top entry is replaced by a
|
|
|
3434 `stale' choicepoint that definitely isn't a thread; attempting to `GO
|
|
|
3435 BACK' to a stale choicepoint instead causes the stale choicepoint to be
|
|
|
3436 deleted and the program to continue executing. (This is what gives
|
|
|
3437 INTERCAL's backtracking greater flexibility in some ways than some
|
|
|
3438 other languages; to get backtracking without the stale choicepoints
|
|
|
3439 having an effect, simply run `COME FROM' the `GO BACK' as the previous
|
|
|
3440 statement.)
|
|
|
3441
|
|
|
3442 Note that, though, when a thread splits into separate threads (whether
|
|
|
3443 woven or unwoven), the choicepoint stack doesn't split completely, but
|
|
|
3444 remains joined at the old top of stack. The two choicepoint stacks can
|
|
|
3445 add and remove items independently, but an attempt to `GO BACK' to
|
|
|
3446 before the current thread split off from any other threads that are
|
|
|
3447 still running instead causes the current thread to end, although it
|
|
|
3448 will `GO BACK' as normal if all other threads that split off from it or
|
|
|
3449 that it split off from since the top choicepoint of the stack was
|
|
|
3450 created have ended since. This means that it's possible to backtrack
|
|
|
3451 past a thread splitting and get the effect of the thread unsplitting,
|
|
|
3452 as long as both resulting threads backtrack; this is another way in
|
|
|
3453 which INTERCAL's backtracking is more flexible than that of some other
|
|
|
3454 languages.
|
|
|
3455
|
|
|
3456 If, on the other hand, a program decides that it likes where it is and
|
|
|
3457 doesn't need to `GO BACK', or it wants to `GO BACK' to a choicepoint
|
|
|
3458 lower down the stack while skipping some of the ones nearer the top of
|
|
|
3459 the stack, it can run the `GO AHEAD' command, which removes the top
|
|
|
3460 choicepoint on the stack, whether it's a genuine choicepoint or just a
|
|
|
3461 stale one.
|
|
|
3462
|
|
|
3463 Both `GO AHEAD' and `GO BACK' cause errors if an attempt is made to use
|
|
|
3464 them when the choicepoint stack is empty.
|
|
|
3465
|
|
|
3466 11 Operand Overloading
|
|
|
3467 **********************
|
|
|
3468
|
|
|
3469 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3470 ------------------------------------------------------------------------
|
|
|
3471 no version 0.26+ version 0.05+ no
|
|
|
3472
|
|
|
3473 (Operand overloading in C-INTERCAL is nowhere near as advanced as it is
|
|
|
3474 in CLC-INTERCAL. This chapter only explains the partial implementation
|
|
|
3475 used by C-INTERCAL; for a full implementation, see CLC-INTERCAL and its
|
|
|
3476 documentation.)
|
|
|
3477
|
|
|
3478 Operand overloading is a method of using a onespot or twospot variable
|
|
|
3479 as a substitute for an expression. When a variable is overloaded to an
|
|
|
3480 expression (which could be another variable, or something more
|
|
|
3481 complex), any uses of that variable cause the expression to be
|
|
|
3482 substituted instead.
|
|
|
3483
|
|
|
3484 At the beginning of the program, all variables stand for themselves; so
|
|
|
3485 `.1' really does mean `.1', for instance. The meaning of a variable
|
|
|
3486 can be overloaded using the slat operator (`/'), which is the same in
|
|
|
3487 both Princeton and Atari syntax: it is a binary operator whose left
|
|
|
3488 argument must be a onespot or twospot variable and whose right argument
|
|
|
3489 can be any expression. The slat operator returns the true value of its
|
|
|
3490 left argument, but as a side effect, changes the meaning of its left
|
|
|
3491 argument to be its right argument. Here is an example:
|
|
|
3492
|
|
|
3493 DO .1 <- .2/'.3~.4'
|
|
|
3494
|
|
|
3495 The example causes `.2''s true value to be assigned to `.1' (unless of
|
|
|
3496 course `.1' is read-only), but also causes `.2' from then on to
|
|
|
3497 actually mean `'.3~.4'', except when it's the left operand of a slat
|
|
|
3498 operator. So for instance, `DO .1 <- .2' would actually assign
|
|
|
3499 `'.3~.4'' to `.1'. Somewhat confusingly, this also works in the other
|
|
|
3500 direction; `DO .2 <- .1' would assign `.1' to `'.3~.4'', which would
|
|
|
3501 have the effect of changing the values of `.3' and `.4' so that
|
|
|
3502 `'.3~.4'' had the correct value, or throw an error if it couldn't
|
|
|
3503 manage this. (The general rule in this case is that any variable or
|
|
|
3504 constant in the expression that overloads the variable is at risk of
|
|
|
3505 being changed; this is known as a `reverse assignment'. Code like `DO
|
|
|
3506 .1 <- .1/#1' is entirely capable of changing the value of `#1',
|
|
|
3507 although to protect new INTERCAL users C-INTERCAL will refuse to carry
|
|
|
3508 out operations that change the value of constants unless a command-line
|
|
|
3509 switch (*note -v::) is used to give it permission. In C-INTERCAL,
|
|
|
3510 changing the value of a constant only changes meshes with that value,
|
|
|
3511 but in CLC-INTERCAL it can also change non-mesh uses of that constant,
|
|
|
3512 so doing so is not portable anyway.)
|
|
|
3513
|
|
|
3514 When multiple overloading rules are in effect, they are all applied;
|
|
|
3515 overloading `.1' to `'.2~.3'' and `.2' to `'.3$.4'' will cause `.1' to
|
|
|
3516 refer to `''.3$.4'~.3''. However, this expansion stops if this would
|
|
|
3517 cause a loop; to be precise, overloading is not expanded if the
|
|
|
3518 expansion is nested within the same expansion at a higher level (so
|
|
|
3519 `.1/.2' and `.2/.1' together cause `.1' to expand to `.2', which
|
|
|
3520 expands to `.1', which cannot expand any further). In C-INTERCAL, the
|
|
|
3521 expression on the right hand side of a slat is not evaluated and not
|
|
|
3522 expanded by operand overloading.
|
|
|
3523
|
|
|
3524 `STASHING' a variable causes its overloading information to be stashed
|
|
|
3525 too; `RETRIEVING' it causes its overload rule to also be retrieved from
|
|
|
3526 the stash (or any overload rule on the variable to be removed if there
|
|
|
3527 wasn't one when the variable was stashed).
|
|
|
3528
|
|
|
3529 Overloading a onespot variable to a twospot variable or vice versa is
|
|
|
3530 possible, but the results are unlikely to be predictable, especially if
|
|
|
3531 a onespot variable is used to handle a twospot value. Possible
|
|
|
3532 outcomes include truncating the value down to the right bitwidth,
|
|
|
3533 throwing an error if a value outside the onespot range is used, and
|
|
|
3534 even temporarily handling the entire twospot value as long as it
|
|
|
3535 doesn't end up eventually being assigned a value greater than twospot.
|
|
|
3536
|
|
|
3537 Note that reverse assignments can cause unpredictable behaviour if an
|
|
|
3538 attempt is made to reverse-assign the same variable twice in the same
|
|
|
3539 expression. In particular, sequences of commands like `DO .1 <-
|
|
|
3540 .2/'.3$.3' DO .2 <- #6' are liable to succeed assigning garbage to `.3'
|
|
|
3541 rather than failing as they ought to do, and likewise any situation
|
|
|
3542 where a variable is reverse-assigned twice in the same expression may
|
|
|
3543 assign garbage to it. This behaviour is seen as unsatisfactory,
|
|
|
3544 though, and plans exist to improve it for future versions.
|
|
|
3545
|
|
|
3546 12 PIC-INTERCAL
|
|
|
3547 ***************
|
|
|
3548
|
|
|
3549 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3550 ------------------------------------------------------------------------
|
|
|
3551 no version 0.26+ no no
|
|
|
3552
|
|
|
3553 PIC-INTERCAL is a simplified version of INTERCAL designed especially
|
|
|
3554 for embedded systems, designed to minimise code and data usage by
|
|
|
3555 INTERCAL programs so that they can fit on devices whose memory is
|
|
|
3556 measured in bytes rather than megabytes. (It is named after the first
|
|
|
3557 microcontroller for which code was successfully generated, and which
|
|
|
3558 influenced the choices of commands, the PIC16F628 manufactured by
|
|
|
3559 Microchip, and is most likely to be portable to other microcontrollers
|
|
|
3560 in the same range.) C-INTERCAL only compilers as far as C code when
|
|
|
3561 producing PIC-INTERCAL; it is up to the user to find the appropriate
|
|
|
3562 cross-compiler to translate this C into the relevant dialect of machine
|
|
|
3563 code. (Two header files in the distribution, `src/pick1.h' and
|
|
|
3564 `src/pick2.h', don't have any affect on the compiler but are referenced
|
|
|
3565 by the generated code, and the intent is for the user to change them to
|
|
|
3566 suit the behaviour of the PIC compiler used, because these are not as
|
|
|
3567 standardised as C compilers for everyday systems.)
|
|
|
3568
|
|
|
3569 There are several restrictions on PIC-INTERCAL programs:
|
|
|
3570
|
|
|
3571 * It's impossible to store more than one item in the STASH for any
|
|
|
3572 given variable.
|
|
|
3573
|
|
|
3574 * Many errors are not checked at runtime; it is the programmer's job
|
|
|
3575 to ensure that runtime errors are avoided. (The few errors that
|
|
|
3576 are detected will send the program into an infinite loop, as there
|
|
|
3577 is no sensible way to exit from a PIC program.)
|
|
|
3578
|
|
|
3579 * Double-oh-sevens are not randomised, but instead depend merely on
|
|
|
3580 whether the probability given is greater than 50% or not.
|
|
|
3581
|
|
|
3582 * The NEXT stack is limited to 16 entries rather than the usual 80.
|
|
|
3583
|
|
|
3584 * `ABSTAIN' and `REINSTATE' still work, but cannot be computed
|
|
|
3585 `ABSTAIN's, and will not necessarily work when used to affect the
|
|
|
3586 system library or calls to it.
|
|
|
3587
|
|
|
3588 * `READ OUT' and `WRITE IN' don't work. (See below for a
|
|
|
3589 replacement.)
|
|
|
3590
|
|
|
3591 * `COME FROM' and `NEXT FROM' must aim at a label, not an expression
|
|
|
3592 or gerund.
|
|
|
3593
|
|
|
3594 * Multithreading and TriINTERCAL cannot be used on PICs. (Operand
|
|
|
3595 overloading can be used, but only if your PIC cross-compiler
|
|
|
3596 supports function pointers; some don't.)
|
|
|
3597
|
|
|
3598
|
|
|
3599 In order to provide I/O capabilities, a new command `PIN' is available.
|
|
|
3600 It controls up to 16 I/O pins on the PIC or other embedded system; an
|
|
|
3601 I/O pin is capable of receiving or sending voltages to an electrical or
|
|
|
3602 electronic circuit. This explanation assumes that the device being
|
|
|
3603 controlled is a PIC16F628A, and therefore has its pins in two blocks of
|
|
|
3604 8 named `PORTA' and `PORTB'; for other microcontrollers, adapting the
|
|
|
3605 code in `src/pick1.h' is likely to be necessary to tell the compiler
|
|
|
3606 how to control the I/O pins, and the way in which this done will affect
|
|
|
3607 which I/O pins it is that the program will end up being able to
|
|
|
3608 communicate with.
|
|
|
3609
|
|
|
3610 The `PIN' command takes one twospot variable as its argument, like this:
|
|
|
3611
|
|
|
3612 DO PIN :2
|
|
|
3613
|
|
|
3614 The twospot variable is conceptually divided into 4 blocks of 8 bits.
|
|
|
3615 The highest two blocks control the directions of the pins in `PORTB'
|
|
|
3616 (most significant block) and `PORTA' (second most significant block); a
|
|
|
3617 1 on any bit means that the corresponding I/O pin should be set to send
|
|
|
3618 data, and a 0 means that it should be set to receive data. The lower
|
|
|
3619 two blocks control the values on the pins that are sending (and are
|
|
|
3620 ignored for receiving pins); the second least significant block
|
|
|
3621 controls `PORTB' and the least significant block controls `PORTA', with
|
|
|
3622 a 1 causing the program to set the output voltage to that of the
|
|
|
3623 microcontroller's negative voltage supply rail, and a 0 causing the
|
|
|
3624 program to set the output voltage to that of the microcontroller's
|
|
|
3625 positive voltage supply rail. (These voltages may vary on other
|
|
|
3626 systems; consult your system's datasheet and the changes you made to
|
|
|
3627 the header files.) After setting the pins, the `PIN' command then
|
|
|
3628 reads them as part of the same operation, this time setting the values
|
|
|
3629 of the lower blocks that are receiving, rather than setting the pins
|
|
|
3630 from the lower blocks that are sending. However, 1 and 0 bits on all
|
|
|
3631 bits of the twospot variable have the opposite meaning when doing this,
|
|
|
3632 so that 1 means receiving/positive voltage rail and 0 means
|
|
|
3633 sending/negative voltage rail. There is no way to input without
|
|
|
3634 output, or vice versa, but it's trivial to just send the same output
|
|
|
3635 again (which has no effect, because the voltage on sending pins is
|
|
|
3636 maintained at the same level until it is changed), or to ignore the
|
|
|
3637 input received.
|
|
|
3638
|
|
|
3639 13 CREATE
|
|
|
3640 *********
|
|
|
3641
|
|
|
3642 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3643 ------------------------------------------------------------------------
|
|
|
3644 no version 0.28+ see text no
|
|
|
3645
|
|
|
3646 The `CREATE' command allows the creation of new syntax at runtime.
|
|
|
3647 CLC-INTERCAL has had such a command since 1.-94.-8, but its syntax is
|
|
|
3648 completely different and incompatible with the C-INTERCAL version, and
|
|
|
3649 so is not documented here (see the CLC-INTERCAL documentation for more
|
|
|
3650 details). The C-INTERCAL version is only defined if the `-a' option is
|
|
|
3651 used on the command line (and a runtime error E000 otherwise), because
|
|
|
3652 it forces the operand overloading code to be introduced and so slows
|
|
|
3653 down every variable access in the program.
|
|
|
3654
|
|
|
3655 The syntax of the `CREATE' command is to write `CREATE', then a line
|
|
|
3656 label, then anything. OK, well not quite anything; you're restricted
|
|
|
3657 to syntax that is supported by the `just-in-case' compiler that runs on
|
|
|
3658 comments at compile time just in case they gain a meaning later (see
|
|
|
3659 below). The anything provides an example statement to `CREATE';
|
|
|
3660 statements which look the same (but may differ in details) are created.
|
|
|
3661 Typical syntax for a `CREATE' statement would therefore look something
|
|
|
3662 like this:
|
|
|
3663
|
|
|
3664 DO CREATE (5) SWITCH .1 WITH .2
|
|
|
3665
|
|
|
3666 There is also computed `CREATE', working identically to ordinary
|
|
|
3667 `CREATE' except that the line number is taken from an expression and
|
|
|
3668 the created command must start with a letter (to avoid an ambiguity if
|
|
|
3669 the expression giving the line label happens to be an array reference),
|
|
|
3670 with a syntax like this:
|
|
|
3671
|
|
|
3672 DO CREATE .5 SWITCH .1 WITH .2
|
|
|
3673
|
|
|
3674 Here, a new `SWITCH WITH' statement (there is no such statement in
|
|
|
3675 INTERCAL normally) is being created. This command makes it possible to
|
|
|
3676 do this:
|
|
|
3677
|
|
|
3678 DO SWITCH .3 WITH .4
|
|
|
3679
|
|
|
3680 Normally that line would be an error (E000) due to being unrecognised,
|
|
|
3681 but having been `CREATE'd, it's now a real statement. (The gerund to
|
|
|
3682 affect created statements is `COMMENT', just like before they were
|
|
|
3683 created; the gerund to affect `CREATE' itself is `CREATION' (`CREATING'
|
|
|
3684 is also allowed, but not as elegant).) When the created statement is
|
|
|
3685 encountered, it `NEXT's to line (5), the line number specified in the
|
|
|
3686 `CREATE' statement. In order for the code there to be able to affect
|
|
|
3687 the variables mentioned in the statement, the variables `:1601' (for
|
|
|
3688 the first variable or expression mentioned), `:1602' (for the second
|
|
|
3689 variable or expression mentioned), and so on, are `STASH'ed and then
|
|
|
3690 overloaded to the respective expressions or variables mentioned in the
|
|
|
3691 created command; so `:1601' has been overloaded to mean `.3' and
|
|
|
3692 `:1602' has been overloaded to mean `.4' at this point. Then, the code
|
|
|
3693 at (5) runs; if it returns via a `RESUME #1', `:1601' and `:1602' will
|
|
|
3694 be `RETRIEVE'd automatically and the program will continue from after
|
|
|
3695 the created statement. (If you do not resume to that point, say if
|
|
|
3696 you're creating a flow control statement, you'll have to deal with the
|
|
|
3697 stashes for the 1600-range variables yourself.)
|
|
|
3698
|
|
|
3699 So what syntax is available in created statements? All the capital
|
|
|
3700 letters except `V' (which is an operator in INTERCAL) are available and
|
|
|
3701 can be used freely and as many times as desired; they match themselves
|
|
|
3702 literally. However, they are not allowed to spell an INTERCAL keyword
|
|
|
3703 at any point (so watch out for `DO' and `FROM', for instance).
|
|
|
3704 Whitespace is allowed, but is ignored (both in the `CREATE' template
|
|
|
3705 statement, and in the code being created; so `DO SW ITCH :8 WITH :50'
|
|
|
3706 will also have been created). Then, there are three groups of
|
|
|
3707 matchable data: scalar variables (onespot or twospot variables, as used
|
|
|
3708 in the examples above) match other scalar variables, array elements
|
|
|
3709 (like `,4 SUB '.5~.6'') match other array elements, and other
|
|
|
3710 expressions match other other expressions. Two matchable data may not
|
|
|
3711 appear consecutively in a created command, but must be separated by at
|
|
|
3712 least one capital letter (to prevent array-subscript-related
|
|
|
3713 ambiguities; remember that the just-in-case compiler has to compile
|
|
|
3714 these statements at compile time without knowing what they are). The
|
|
|
3715 actual expressions used in the `CREATE' statement don't matter; they're
|
|
|
3716 just examples for the runtime to match against.
|
|
|
3717
|
|
|
3718 It is also possible (from C-INTERCAL version 0.29 onwards) to create new
|
|
|
3719 operators. Such operators are always binary operators (that is, they
|
|
|
3720 take two arguments and parse like mingle or select), and always return
|
|
|
3721 32-bit results. There are three types of legal names for such
|
|
|
3722 operators, all of which are treated equivalently: lowercase letters,
|
|
|
3723 punctuation marks otherwise unused in INTERCAL, and overstrikes
|
|
|
3724 consisting of a character, a backspace, and another character (apart
|
|
|
3725 from overstrikes already used for built-in INTERCAL operators). The
|
|
|
3726 syntax for creating an operator looks like one of these:
|
|
|
3727
|
|
|
3728 DO CREATE (5) x
|
|
|
3729 DO CREATE .5 =
|
|
|
3730
|
|
|
3731 The arguments to the operator will be overloaded onto :1601 and :1602
|
|
|
3732 (which are, like with `CREATE'd statements, stashed before the
|
|
|
3733 overloading happens), and the return value is read from :1603 (which is
|
|
|
3734 stashed, then overloaded to itself). All these three variables are
|
|
|
3735 retrieved again after the operator finishes evaluating.
|
|
|
3736
|
|
|
3737 Note that it is a very unwise idea to use a `CREATE'd operator in the
|
|
|
3738 expression for a computed `COME FROM' or `NEXT FROM', because this
|
|
|
3739 always leads to an infinite regress; whenever any line label is reached
|
|
|
3740 (including the line label that the `CREATE' statement pointed at), the
|
|
|
3741 expression needs to be evaluated in order to determine whether to `COME
|
|
|
3742 FROM' that point, which in turn involves evaluating lines which have
|
|
|
3743 labels.
|
|
|
3744
|
|
|
3745 Some other points: a newer `CREATE' statement supercedes an older
|
|
|
3746 `CREATE' statement if they give equivalent templates, multiple `CREATE'
|
|
|
3747 statements may aim at the same line (this is the recommended technique
|
|
|
3748 for creating a statement that can handle expressions even if they're
|
|
|
3749 array elements or variables; you do this by specifying multiple
|
|
|
3750 templates in multiple `CREATE' statements), and strange things happen
|
|
|
3751 if a twospot variable in the 1600-range is used as an argument to a
|
|
|
3752 created statement itself (because of the stash/retrieve, such a
|
|
|
3753 variable can usually be read, but may not always be able to be written
|
|
|
3754 without the data being lost).
|
|
|
3755
|
|
|
3756 14 External Calls
|
|
|
3757 *****************
|
|
|
3758
|
|
|
3759 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3760 ------------------------------------------------------------------------
|
|
|
3761 no version 0.28+ no no
|
|
|
3762
|
|
|
3763 C-INTERCAL has a feature allowing INTERCAL and non-INTERCAL code to be
|
|
|
3764 mixed. This is achieved by causing the non-INTERCAL programs to
|
|
|
3765 participate in the INTERCAL line-numbering model. The same feature
|
|
|
3766 allows expansion libraries to be linked into the code.
|
|
|
3767
|
|
|
3768 To create a combined program containing INTERCAL and non-INTERCAL code,
|
|
|
3769 use `ick' as the compiler as normal, but specify both the INTERCAL and
|
|
|
3770 non-INTERCAL source files on the command line, and use the `-e'
|
|
|
3771 command-line option. `ick' will invoke other compilers as necessary,
|
|
|
3772 after modifying the source files accordingly. At present, external
|
|
|
3773 calls are only supported to and from C.
|
|
|
3774
|
|
|
3775 In each case, it will be the INTERCAL program that is invoked first.
|
|
|
3776 (This means that it is impossible to link together more than one
|
|
|
3777 INTERCAL program, but you probably don't want to, because concatenating
|
|
|
3778 the programs is likely to have a similar effect.) You can get the
|
|
|
3779 INTERCAL program to `NEXT' to the non-INTERCAL program immediately, or
|
|
|
3780 the non-INTERCAL program to `COME FROM' or `NEXT FROM' the INTERCAL
|
|
|
3781 program immediately, to obtain the effect of running the non-INTERCAL
|
|
|
3782 program first.
|
|
|
3783
|
|
|
3784 Note that external calls are incompatible with PIC-INTERCAL and with
|
|
|
3785 multithreading; note also that you must use `gcc' as your compiler, and
|
|
|
3786 GNU cpp and ld, for them to work in the current version of C-INTERCAL.
|
|
|
3787
|
|
|
3788 14.1 External Calls to C
|
|
|
3789 ========================
|
|
|
3790
|
|
|
3791 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3792 ------------------------------------------------------------------------
|
|
|
3793 no version 0.28+ no no
|
|
|
3794
|
|
|
3795 Linking C and INTERCAL programs is achieved by placing various
|
|
|
3796 constructs into the C programs that are equivalent to various INTERCAL
|
|
|
3797 constructs. It is possible to simulate a line with a label and a dummy
|
|
|
3798 command (which serves as a `COME FROM' suckpoint and `NEXT' target), a
|
|
|
3799 command with a line label, `NEXT', `RESUME', and `FORGET', and `COME
|
|
|
3800 FROM' and `NEXT FROM'. Onespot and twospot variables are accessible
|
|
|
3801 from inside the C program, where they can be read and written; however,
|
|
|
3802 the INTERCAL program cannot access any variables inside the C program
|
|
|
3803 that weren't part of the INTERCAL program originally.
|
|
|
3804
|
|
|
3805 To prevent various logical impossibilities, there are restrictions on
|
|
|
3806 where these can be used and what preparation is needed before they are
|
|
|
3807 used. Also, the semantics are not always exactly what you might expect
|
|
|
3808 for technical reasons.
|
|
|
3809
|
|
|
3810 It should be observed that the INTERCAL link intrudes on the user
|
|
|
3811 namespace. To prevent possible namespace clashes, no identifiers
|
|
|
3812 starting with `ick_' or `ICK_' should be used anywhere in the linked C
|
|
|
3813 program for any reason, except where specified in this manual.
|
|
|
3814
|
|
|
3815 14.1.1 External C Call Infrastructure
|
|
|
3816 -------------------------------------
|
|
|
3817
|
|
|
3818 For a C program to be connected to an INTERCAL program, it needs to be
|
|
|
3819 marked with the correct header file, and needs to have functions marked
|
|
|
3820 for communication with the INTERCAL program.
|
|
|
3821
|
|
|
3822 `#include <ick_ec.h>'
|
|
|
3823 The header file `ick_ec.h' must be included using the preprocessor
|
|
|
3824 in any file which uses any of the INTERCAL external call
|
|
|
3825 functions, variables, or macros. (Note that this file may not
|
|
|
3826 necessarily exist, or exist in the usual place; `ick' will deal
|
|
|
3827 with making sure the correct header file is included.) This will
|
|
|
3828 include `stdint.h' (a standard C header file, which must exist on
|
|
|
3829 your system), so that you can access INTERCAL variables (the
|
|
|
3830 INTERCAL types onespot, twospot, tail, hybrid correspond to the C
|
|
|
3831 types uint16_t, uint32_t, uint16_t*, uint32_t* respectively);
|
|
|
3832 also, it will provide the prototypes for all the functions and
|
|
|
3833 definitions for all the macros needed to use the external calls
|
|
|
3834 system with C.
|
|
|
3835
|
|
|
3836 `ICK_EC_FUNC_START'
|
|
|
3837 `ICK_EC_FUNC_END'
|
|
|
3838 Many of the INTERCAL interface macros (`ick_linelabel',
|
|
|
3839 `ick_comefrom', and `ick_nextfrom') make it possible to jump from
|
|
|
3840 an INTERCAL program to a C program. Because C doesn't allow
|
|
|
3841 jumping into the middle of a function, there has to be some way to
|
|
|
3842 create a block of code which _can_ be jumped into. This is what
|
|
|
3843 these two macros achieve.
|
|
|
3844
|
|
|
3845 This declaration and definition:
|
|
|
3846
|
|
|
3847 ICK_EC_FUNC_START(identifier)
|
|
|
3848 {
|
|
|
3849 /* code goes here */
|
|
|
3850 }
|
|
|
3851 ICK_EC_FUNC_END
|
|
|
3852
|
|
|
3853 is equivalent to this:
|
|
|
3854
|
|
|
3855 void identifier(void)
|
|
|
3856 {
|
|
|
3857 /* code goes here */
|
|
|
3858 }
|
|
|
3859
|
|
|
3860 except that it is possible to jump from an INTERCAL program into
|
|
|
3861 the declared and defined program. (If you need to write a
|
|
|
3862 prototype for the function early, `void identifier(void);' is
|
|
|
3863 perfectly acceptable, but an early prototype is not required
|
|
|
3864 unless you call the function from earlier within the C code.) Of
|
|
|
3865 course, you can substitute any identifier that's legal as a
|
|
|
3866 function name for `identifier' (as long as it doesn't start with
|
|
|
3867 `ick_' or `ICK_'). The resulting function is a function (for
|
|
|
3868 instance, you can take its address or call it in the usual ways);
|
|
|
3869 the only differences are that it can be jumped into from INTERCAL
|
|
|
3870 code and that it is constrained to take no arguments and return no
|
|
|
3871 data. (It can still access global and INTERCAL variables.) If
|
|
|
3872 the function is jumped into from INTERCAL code, but then control
|
|
|
3873 flow reaches the end of the function, or the function `return;'s
|
|
|
3874 but was not called from C, the resulting behaviour is undefined;
|
|
|
3875 C-INTERCAL will attempt to continue by some means at that point,
|
|
|
3876 but may fail. If a function is unsure whether it gained control
|
|
|
3877 from C or from INTERCAL code, it may use `ick_return_or_resume'
|
|
|
3878 (described below).
|
|
|
3879
|
|
|
3880 Because you are not allowed to declare two C functions with the
|
|
|
3881 same name (even in different modules), all functions declared with
|
|
|
3882 `ICK_EC_FUNC_START' must have unique names across the entire
|
|
|
3883 compilation.
|
|
|
3884
|
|
|
3885
|
|
|
3886 14.1.2 ick_startup
|
|
|
3887 ------------------
|
|
|
3888
|
|
|
3889 It is sometimes necessary for a C program to do its own initialisation
|
|
|
3890 before the INTERCAL program starts running. To do so, it can use the
|
|
|
3891 `ick_startup' macro inside a function declared with
|
|
|
3892 `ICK_EC_FUNC_START'; the syntax is `ick_startup(block)', where the
|
|
|
3893 argument is an expression, statement, or compound statement to run.
|
|
|
3894 The argument itself must not contain any ick_-prefixed macros or
|
|
|
3895 functions except possibly ick_create, may have side effects, and must
|
|
|
3896 fit the C preprocessor's idea of what a macro argument should look like
|
|
|
3897 (it's more used to parsing expressions than blocks; the general rule is
|
|
|
3898 to avoid commas except when they're directly or indirectly inside
|
|
|
3899 parentheses or strings).
|
|
|
3900
|
|
|
3901 14.1.3 ick_linelabel
|
|
|
3902 --------------------
|
|
|
3903
|
|
|
3904 A line label is something that can be `NEXT'ed to and `COME FROM'.
|
|
|
3905 Unlike an INTERCAL line label, it does not label a statement, and
|
|
|
3906 therefore attempts to `ABSTAIN' or `REINSTATE' it may be errors, or may
|
|
|
3907 be ignored (it's unspecified which, which means that either may happen
|
|
|
3908 for any or no reason, but exactly one will happen in any given case,
|
|
|
3909 although the choice might not be consistent).
|
|
|
3910
|
|
|
3911 The macro `ick_linelabel(expression);' may appear anywhere a compound
|
|
|
3912 statement would normally be able to appear. (That is, it looks like a
|
|
|
3913 function call being used as a standalone expression, but in fact the
|
|
|
3914 places where it can appear are more limited.) In contrast to ordinary
|
|
|
3915 line labels, an expression can be used rather than just a constant;
|
|
|
3916 however, the behaviour is undefined if the expression has side-effects.
|
|
|
3917 Upon encountering the line label, any `COME FROM's or `NEXT FROM's
|
|
|
3918 aiming at the line label (including `ick_comefrom's and
|
|
|
3919 `ick_nextfrom's) will steal control from the program; `RESUMING' after
|
|
|
3920 a `NEXT FROM' will work, but suffers from the same caveats as
|
|
|
3921 setjmp/longjmp do (any auto variables that change their value between
|
|
|
3922 the `NEXT FROM' and `RESUME' will have their value clobbered (i.e.
|
|
|
3923 their value is no longer reliable and should not be accessed)). Note
|
|
|
3924 that the INTERCAL variables are immune to this problem. You can also
|
|
|
3925 avoid the problem by marking variables as `volatile' in the C program.
|
|
|
3926
|
|
|
3927 It is possible to `NEXT' or `ick_next' to a `ick_linelabel', which has
|
|
|
3928 the same effect as saving the `NEXT' stack, calling the function
|
|
|
3929 containing the `ick_linelabel' and then immediately doing a C `goto' to
|
|
|
3930 an imaginary label preceding it. Due to this possibility, an
|
|
|
3931 `ick_linelabel' is only allowed within a function defined with
|
|
|
3932 `ICK_EC_FUNC_START'.
|
|
|
3933
|
|
|
3934 14.1.4 ick_labeledblock
|
|
|
3935 -----------------------
|
|
|
3936
|
|
|
3937 In INTERCAL programs, labels don't stand on their own, but instead
|
|
|
3938 label a statement. The difference between a standalone line label and
|
|
|
3939 a line label that labels a statement is that `COME FROM's will come
|
|
|
3940 from the _label itself_ (which is before the next statement) when
|
|
|
3941 aiming at a standalone line label, but the _end of the statement_ when
|
|
|
3942 aiming at a labeled statement. To achieve the same effect in C, the
|
|
|
3943 macro `ick_labeledblock' is available; it can be used as
|
|
|
3944 `ick_labeledblock(expression,expression)' or
|
|
|
3945 `ick_labeledblock(expression,statement)'; the first argument is the
|
|
|
3946 label, and the second argument is an expression or statement to label
|
|
|
3947 (if an expression is labeled, it will be converted to a statement that
|
|
|
3948 evaluates it for its side effects and discards the result). It is even
|
|
|
3949 permitted to label a block statement in this way. Note, however, that
|
|
|
3950 you have to contend with the C preprocessor's ideas of where macro
|
|
|
3951 arguments begin and end when doing this. Other than the position of
|
|
|
3952 the `COME FROM' target created by the label, this behaves the same way
|
|
|
3953 as `ick_linelabel' (so for instance, computed line labels are allowed,
|
|
|
3954 but the expression that computes them must not have side effects, and
|
|
|
3955 it is only allowed within a function defined with `ICK_EC_FUNC_START').
|
|
|
3956
|
|
|
3957 14.1.5 ick_comefrom and ick_nextfrom
|
|
|
3958 ------------------------------------
|
|
|
3959
|
|
|
3960 The `ick_comefrom' and `ick_nextfrom' macros are, like the other
|
|
|
3961 INTERCAL flow control macros (as opposed to functions), only allowed
|
|
|
3962 within a function defined with `ICK_EC_FUNC_START'. They act almost
|
|
|
3963 exactly like the INTERCAL statements of the same name (although note
|
|
|
3964 that C statements cannot be `ABSTAIN'ed `FROM' even if they act the
|
|
|
3965 same way as INTERCAL statements); they are written as
|
|
|
3966 `ick_comefrom(expression);' and `ick_nextfrom(expression);'
|
|
|
3967 respectively (note that they must be called as statements, and cannot
|
|
|
3968 be used as part of an expression). Whenever a standalone line label is
|
|
|
3969 encountered whose expression evaluates to the same number as the
|
|
|
3970 expression inside the `ick_comefrom' or `ick_nextfrom', and that number
|
|
|
3971 is at most 65535, then control will be transferred to the
|
|
|
3972 `ick_comefrom' or `ick_nextfrom', leaving a `NEXT' stack entry behind
|
|
|
3973 in the case of `ick_nextfrom'; likewise, if the end of a labeled
|
|
|
3974 statement, expression or block is reached and the label has the right
|
|
|
3975 number. Some caveats: the expression need not be constant, but must
|
|
|
3976 not have side effects, must not be negative, and must fit into the
|
|
|
3977 range of an `unsigned long' in the C program (and the statement will do
|
|
|
3978 nothing if the expression evaluates to a value larger than 65535). In
|
|
|
3979 keeping with the best C traditions, these caveats are not checked, but
|
|
|
3980 instead result in undefined behaviour if breached.
|
|
|
3981
|
|
|
3982 There are also versions `ick_comefromif' and `ick_nextfromif', which
|
|
|
3983 take a second parameter, which is a condition that specifies whether
|
|
|
3984 control is actually stolen from the target. The condition may have
|
|
|
3985 side effects, and is only run when the line numbers match; it should
|
|
|
3986 return 0 or NULL to leave control flow alone, or nonzero to steal
|
|
|
3987 control, and should be either an integral type or a pointer type.
|
|
|
3988 Although side effects are allowed, the condition must not look at or
|
|
|
3989 alter `auto' or `register' variables in the enclosing function, not
|
|
|
3990 even if they are also marked `volatile'. (Global and `static'
|
|
|
3991 variables are fine, though.)
|
|
|
3992
|
|
|
3993 14.1.6 ick_next
|
|
|
3994 ---------------
|
|
|
3995
|
|
|
3996 `ick_next' is a macro that acts like the INTERCAL statement `NEXT'.
|
|
|
3997 Contrary to the other INTERCAL-like macros, it can be used in any
|
|
|
3998 function regardless of whether it was defined with `ICK_EC_FUNC_START';
|
|
|
3999 however, it must still be used as a statement by itself, and a call to
|
|
|
4000 it looks like `ick_next(expression);'. The expression is the label to
|
|
|
4001 `NEXT' to, and works under the same rules as the expressions for
|
|
|
4002 `ick_comefrom'; it need not be constant (unlike in C-INTERCAL!), but
|
|
|
4003 must not have side effects, must not be negative, must fit into the
|
|
|
4004 range of an unsigned long, and is ignored if it is over 65535. If
|
|
|
4005 there happen to be multiple labels with the correct value at the time,
|
|
|
4006 the compiler will `NEXT' to one of them. Bear in mind that there is a
|
|
|
4007 limit of 80 entries to the `NEXT' stack, and that this limit is
|
|
|
4008 enforced.
|
|
|
4009
|
|
|
4010 If the resulting `NEXT' stack entry is `RESUME'd to, the program will
|
|
|
4011 continue after the `ick_next' as if via `setjmp', with all the usual
|
|
|
4012 restrictions that that entails; if the resulting `NEXT' stack entry is
|
|
|
4013 forgotten, then the `ick_next' call will never return. (Notice the 'as
|
|
|
4014 if via setjmp' condition allows you to preserve the vales of `auto' and
|
|
|
4015 `alloca'-allocated storage as long as its value has not changed since
|
|
|
4016 the `ick_next' was called, which is a significantly more lenient
|
|
|
4017 condition than that normally imposed on such variables (*note External
|
|
|
4018 Calls and auto::).
|
|
|
4019
|
|
|
4020 14.1.7 ick_resume
|
|
|
4021 -----------------
|
|
|
4022
|
|
|
4023 `ick_resume' is a macro, but there are few restrictions on its use; it
|
|
|
4024 is permitted to use it inside an expression (but it returns void,
|
|
|
4025 making this not particularly useful), and acts like a function which
|
|
|
4026 takes an unsigned short argument, returns void, and has a prototype (but
|
|
|
4027 you cannot take its address; if you need to be able to do that, write a
|
|
|
4028 wrapper function for it). It can be used within any function regardless
|
|
|
4029 of how it was declared, and never returns; instead, it pops the
|
|
|
4030 specified number of `NEXT' stack entries and resumes execution at the
|
|
|
4031 last one popped, just as the INTERCAL statement does. This causes the
|
|
|
4032 same errors as the INTERCAL statement if the number of entries popped
|
|
|
4033 is zero or larger than the `NEXT' stack.
|
|
|
4034
|
|
|
4035 There is also a macro `ick_return_or_resume();'; it can only be used
|
|
|
4036 inside a function defined with `ICK_EC_FUNC_START', and is equivalent
|
|
|
4037 to `return;' if the function was called from C, or `ick_resume(1);' if
|
|
|
4038 the function was called from INTERCAL. It's therefore a safe way to
|
|
|
4039 return from such a C function if you don't know how control reached it
|
|
|
4040 in the first place.
|
|
|
4041
|
|
|
4042 14.1.8 ick_forget
|
|
|
4043 -----------------
|
|
|
4044
|
|
|
4045 The `ick_forget' macro removes `NEXT' stack entries, and the
|
|
|
4046 corresponding C stack entries. It must be called as a statement by
|
|
|
4047 itself, and its invocation looks like this: `ick_forget(expr);', where
|
|
|
4048 the expression is the number of `NEXT' stack entries to forget (all of
|
|
|
4049 them will be forgotten if the number is higher than the number of
|
|
|
4050 entries). The expression will be casted to an `unsigned short'.
|
|
|
4051
|
|
|
4052 `ick_forget' can only be used inside a function declared with
|
|
|
4053 `ICK_EC_FUNC_START'. As it is removing stack entries both in INTERCAL
|
|
|
4054 and in C, it will clobber the value of all `auto' variables created
|
|
|
4055 since the highest remaining `NEXT' stack entry came into being (or
|
|
|
4056 since the start of the program, if the `NEXT' stack is emptied by the
|
|
|
4057 command) and also deallocate all `alloca' storage allocated since then.
|
|
|
4058 It also causes the return address of the current function to become
|
|
|
4059 undefined, so that function must not return; control may leave it via
|
|
|
4060 `RESUME', or via `COME FROM', or via `NEXT' or `NEXT FROM' followed by
|
|
|
4061 the relevant `NEXT' stack entry being forgotten (the function is still
|
|
|
4062 'running' but suspended while the `NEXT' stack entry still exists).
|
|
|
4063 (Note that these restrictions are stronger than those on `RESUME'; this
|
|
|
4064 is because `RESUME' preserves most of the stack, but `FORGET' destroys
|
|
|
4065 parts of the stack and therefore cannot avoid destroying the data
|
|
|
4066 stored there. It could be much worse; a previous (never released)
|
|
|
4067 version of the code didn't remove those parts of the stack in many
|
|
|
4068 circumstances, leading to a stack leak that caused programs to segfault
|
|
|
4069 after a while.)
|
|
|
4070
|
|
|
4071 14.1.9 ick_get/setone/twospot
|
|
|
4072 -----------------------------
|
|
|
4073
|
|
|
4074 This class of four functions make it possible to get and set INTERCAL
|
|
|
4075 scalar variables from C code. Their prototypes are as follows:
|
|
|
4076
|
|
|
4077 uint16_t ick_getonespot(unsigned short varnumber);
|
|
|
4078 void ick_setonespot(unsigned short varnumber, uint16_t newvalue);
|
|
|
4079 uint32_t ick_gettwospot(unsigned short varnumber);
|
|
|
4080 void ick_settwospot(unsigned short varnumber, uint32_t newvalue);
|
|
|
4081
|
|
|
4082 The program will error out with a fatal error (*note E200::) if the
|
|
|
4083 variable you request is mentioned nowhere in the INTERCAL program; if
|
|
|
4084 you attempt to set an `IGNORE'd variable, the attempt will silently
|
|
|
4085 fail (just as if you assigned to it in an INTERCAL program). The get
|
|
|
4086 functions are safe to use in a computed line label, so you can use them
|
|
|
4087 to produce computed line labels that depend on INTERCAL variables.
|
|
|
4088 (`uint16_t' and `uint32_t' are standard C data types; if your system
|
|
|
4089 doesn't provide them, get better system header files.)
|
|
|
4090
|
|
|
4091 If you care about speed, note that .1 is the fastest variable of all to
|
|
|
4092 access, and otherwise variables first mentioned near the top of the
|
|
|
4093 INTERCAL program will be faster to access than variables mentioned
|
|
|
4094 lower down.
|
|
|
4095
|
|
|
4096 14.1.10 ick_create
|
|
|
4097 ------------------
|
|
|
4098
|
|
|
4099 The `ick_create' function (prototype: `void ick_create(char*, unsigned
|
|
|
4100 long)') allows the external calls system to be used to create new
|
|
|
4101 INTERCAL syntax; to do this, you give a `signature' representing the
|
|
|
4102 syntax you want to define and a line number to the function (which are
|
|
|
4103 its two arguments, respectively). The signature defines the syntax
|
|
|
4104 that you are defining; whenever that syntax is encountered within the
|
|
|
4105 INTERCAL program, it will `NEXT' to the line number you specify, which
|
|
|
4106 can do various clever things and then `RESUME' back to the INTERCAL
|
|
|
4107 program (or if you're defining a flow-control operation, you might want
|
|
|
4108 to leave the `NEXT' stack entry there and do other things). However,
|
|
|
4109 note that the overloading of `:1601', etc., will still take place as in
|
|
|
4110 the INTERCAL version of `CREATE' if the `-a' option is used (*note
|
|
|
4111 -a::), so care is needed when writing flow control statements that they
|
|
|
4112 work both with and without the option and don't cause `STASH' leaks
|
|
|
4113 (which means no `FORGET'ting the relevant `NEXT' stack entry, and no
|
|
|
4114 looking at 1600-range variables). This allows the external calls
|
|
|
4115 system to define whole new INTERCAL commands, with the same power as
|
|
|
4116 any other programming language.
|
|
|
4117
|
|
|
4118 There are various restrictions on what syntax you can `CREATE' with
|
|
|
4119 this method, which are best explained by an explanation of the relevant
|
|
|
4120 C-INTERCAL compiler internals. When an INTERCAL program is compiled by
|
|
|
4121 C-INTERCAL, any unrecognised statements it comes across are compiled by
|
|
|
4122 a `just-in-case' compiler that attempts to compile them anyway with no
|
|
|
4123 knowledge of their syntax, just in case the syntax becomes defined
|
|
|
4124 later. (E000 (*note E000::) will be thrown when such statements are
|
|
|
4125 encountered at runtime, unless the syntax has been `CREATE'd since to
|
|
|
4126 give a statement a meaning.) For the just-in-case compiler to run, the
|
|
|
4127 resulting statement must be completely unrecognised; this means that it
|
|
|
4128 may contain no keywords (not even a sequence of letters that forms a
|
|
|
4129 keyword, such as `FROM' or `DO'), it must consist only of variable
|
|
|
4130 names, expressions, and capital letters other than `V' (because `V' is
|
|
|
4131 a unary operator, so otherwise there would be ambiguity), and in which
|
|
|
4132 any two variable names or expressions are separated by at least one
|
|
|
4133 capital letter. The compiler will produce a `signature' for the
|
|
|
4134 unknown command that can be defined.
|
|
|
4135
|
|
|
4136 A signature consists of a sequence of characters (and is represented as
|
|
|
4137 a null-terminated string; the runtime makes a shallow copy of the
|
|
|
4138 string and keeps it until the end of the program, so arrangements must
|
|
|
4139 be made to ensure that the storage in which the string is allocated
|
|
|
4140 stays around that long, but this opens up interesting possibilities in
|
|
|
4141 which the signature that was actually `CREATE'd can be modified
|
|
|
4142 retroactively); whitespace is not allowed in a signature. Capital
|
|
|
4143 letters can be used (apart from `V'), and match the same capital
|
|
|
4144 letters literally in the INTERCAL syntax being created; also available
|
|
|
4145 are the special characters `.,;~', which match respectively a scalar
|
|
|
4146 variable (a onespot or twospot variable such as `:1'), an array
|
|
|
4147 variable (such as `;2'), an array element (such as `,3 SUB #4 #5'), and
|
|
|
4148 an expression that isn't a variable name and isn't an array element
|
|
|
4149 (such as `.4$.5'). If you want to be able to match other things (say,
|
|
|
4150 to be able to match all expressions), you will need to submit multiple
|
|
|
4151 signatures using multiple calls to `ick_create'; maybe you could write
|
|
|
4152 a library to do that automatically.
|
|
|
4153
|
|
|
4154 `CREATE'd operators also have signatures, but of quite a different
|
|
|
4155 form. The signature for a single-character operator is a lowercase u,
|
|
|
4156 followed by its character code in hexadecimal (no leading zeros, and in
|
|
|
4157 lowercase); the signature for an overstrike is a lowercase o, followed
|
|
|
4158 by the lower relevant character code in hexadecimal, followed by a
|
|
|
4159 lowercase x, followed by the higher relevant character code in
|
|
|
4160 hexadecimal.
|
|
|
4161
|
|
|
4162 The routine that is `NEXT'ed to will presumably want to be able to see
|
|
|
4163 what in the INTERCAL program was matched by the signature, so a range
|
|
|
4164 of function-like macros is provided to access that. They must be run
|
|
|
4165 from within the invocation of the function which was `NEXT'ed into by
|
|
|
4166 the created syntax (*note External Calls and auto:: for when a function
|
|
|
4167 invocation ends, which could be sooner than you think when the
|
|
|
4168 C-INTERCAL external calls system is used), and are undefined behaviour
|
|
|
4169 when that invocation did not gain control from a `CREATE'd statement.
|
|
|
4170 Here are their effective prototypes:
|
|
|
4171
|
|
|
4172 int ick_c_width(int);
|
|
|
4173 int ick_c_isarray(int);
|
|
|
4174 unsigned short ick_c_varnumber(int);
|
|
|
4175 uint32_t ick_c_value(int);
|
|
|
4176 /* These require -a to work */
|
|
|
4177 uint32_t ick_c_getvalue(int);
|
|
|
4178 void ick_c_setvalue(int, uint32_t);
|
|
|
4179
|
|
|
4180 The first argument to all these macros is the position of the match in
|
|
|
4181 the signature (0 for the first non-capital-letter match in the
|
|
|
4182 signature, 1 for the second, and so on until no more items are left in
|
|
|
4183 the signature to match); specifying a position that isn't in the
|
|
|
4184 signature is undefined behaviour.
|
|
|
4185
|
|
|
4186 `ick_c_width' returns the data type, as a width in bits, of the
|
|
|
4187 expression (or the width in bits of an element of the passed in array),
|
|
|
4188 and `ick_c_isarray' returns 1 if the argument was an array variable or
|
|
|
4189 0 if it was an expression (array elements and scalar variables are
|
|
|
4190 expressions). `ick_c_varnumber' returns the variable's number (for
|
|
|
4191 instance 123 for `.123'), or 0 if the corresponding argument was not a
|
|
|
4192 variable; in the cases where the argument was a variable, these three
|
|
|
4193 functions together provide enough information to figure out which
|
|
|
4194 variable (which is useful if you're writing an extension which takes a
|
|
|
4195 variable name as an argument).
|
|
|
4196
|
|
|
4197 `ick_c_value' returns the value of the corresponding expression at the
|
|
|
4198 time the `CREATE'd command was called; `ick_c_getvalue' is almost
|
|
|
4199 equivalent, but only works if the `-a' option (*note -a::) was used
|
|
|
4200 during compilation, and returns the value of the corresponding
|
|
|
4201 expression now. (The uint32_t return type is large enough to hold
|
|
|
4202 either a onespot or twospot value, and will be zero-extended if the
|
|
|
4203 corresponding expression had onespot type.) `ick_c_setvalue' also
|
|
|
4204 depends on `-a', and will assign to the corresponding expression (be
|
|
|
4205 careful not to provide a value that is too large for it!). In the case
|
|
|
4206 that the corresponding expression is not a variable, this will attempt
|
|
|
4207 to perform a reverse assignment to the expression, and can produce
|
|
|
4208 ordinary INTERCAL errors if it fails. It is not possible to
|
|
|
4209 redimension an array this way, as this is assignment, not a calculate
|
|
|
4210 operation.
|
|
|
4211
|
|
|
4212 14.1.11 External Calls and auto
|
|
|
4213 -------------------------------
|
|
|
4214
|
|
|
4215 Because the external calls system merges the INTERCAL `NEXT' stack with
|
|
|
4216 the C return value and data storage stack (note for pedants: the C
|
|
|
4217 standards nowhere mandate the existence of such a stack, or even mention
|
|
|
4218 one, but the restrictions stated in them imply that implementations have
|
|
|
4219 to act as if such a stack existed, because of the way the scoping rules
|
|
|
4220 and recursion work), the external calls system therefore has severe
|
|
|
4221 effects on data that happens to be stored there. (In INTERCAL terms,
|
|
|
4222 imagine what would happen if data could be stored on the `NEXT' stack;
|
|
|
4223 if C used the more sensible system of having a `STASH' for each
|
|
|
4224 variable, these problems would never occur in the first place, instead
|
|
|
4225 causing an entirely different set of problems.) Similar considerations
|
|
|
4226 apply to the common nonstandard C extension `alloca', which dynamically
|
|
|
4227 alters the size of the stack; also, in what goes below, `register'
|
|
|
4228 variables should be considered to be `auto', because the compiler may
|
|
|
4229 choose to allocate them on the stack. Theoretical considerations would
|
|
|
4230 lead one to conclude that variable-length arrays should obey most of
|
|
|
4231 the same restrictions; in practice, though, it's unwise to attempt to
|
|
|
4232 mix those with INTERCAL code at all, except by separating them into
|
|
|
4233 separate functions which aren't flagged with `ICK_EC_FUNC_START' and
|
|
|
4234 use no `ick_'-prefixed identifiers, even indirectly. (They may cause a
|
|
|
4235 compile to fail completely because they don't mix well with `goto'.)
|
|
|
4236
|
|
|
4237 In the description below, INTERCAL commands should be taken to include
|
|
|
4238 the equivalent C macros.
|
|
|
4239
|
|
|
4240 `NEXT'/`NEXT FROM' paired with `RESUME' have the least effect, and the
|
|
|
4241 most obvious effect, on `auto' variables in the function that was
|
|
|
4242 `NEXT'ed from, which is the same effect that the standard C function
|
|
|
4243 `longjmp' has. That is, `alloca' storage stays intact, and `auto'
|
|
|
4244 variables have their values `clobbered' (that is, their value is no
|
|
|
4245 longer reliable and should not be used) if they changed since the
|
|
|
4246 corresponding `NEXT' and are not marked as `volatile'. (This is a very
|
|
|
4247 easy restriction to get around, because changing the values of such
|
|
|
4248 variables is quite difficult without using statically-allocated
|
|
|
4249 pointers to point to them (a dubious practice in any case), and
|
|
|
4250 `volatile' is trivial to add to the declaration.)
|
|
|
4251
|
|
|
4252 `COME FROM' has more restrictions; it deallocates all `alloca' storage
|
|
|
4253 in the function that was `COME FROM', and functions that called it or
|
|
|
4254 that called functions that called it, etc., using C calls (as opposed
|
|
|
4255 to `NEXT'), and those invocations of the functions will cease to exist
|
|
|
4256 (thus destroying any `auto' variables in them), even in the case of
|
|
|
4257 `COMING FROM' a function into the same function. `auto' variables in
|
|
|
4258 the function that is come into will start uninitialised, even if
|
|
|
4259 initialisers are given in their declaration, and it will be a `new'
|
|
|
4260 invocation of that function. (It is quite possible that the
|
|
|
4261 uninitialised values in the `auto' variables will happen by chance to
|
|
|
4262 have the values they had in some previous invocation of the function,
|
|
|
4263 though, because they are likely to be stored in much the same region of
|
|
|
4264 memory; but it is highly unwise to rely on this.) Note that `volatile'
|
|
|
4265 will not help here. Observant or source-code-reading readers may note
|
|
|
4266 that there is a mention of an `ick_goto' in the source code to
|
|
|
4267 C-INTERCAL; this is undocumented and this manual does not officially
|
|
|
4268 claim that such a macro exists (after all, if it did, what in INTERCAL
|
|
|
4269 could it possibly correspond to?), but if such a macro does exist it
|
|
|
4270 obeys the same restrictions as `COME FROM'.
|
|
|
4271
|
|
|
4272 `FORGET' is the worst of all in terms of preserving data on the stack;
|
|
|
4273 it deallocates `alloca' data and clobbers or deletes `auto' variables
|
|
|
4274 in all function invocations that have come into existence since the
|
|
|
4275 `NEXT' that created the topmost remaining `NEXT' stack entry was
|
|
|
4276 called, or since the start of the program if the `NEXT' stack is
|
|
|
4277 emptied, and the current function will continue in a new invocation.
|
|
|
4278 `volatile' is useless in preventing this, because the relevant parts of
|
|
|
4279 the stack where the data were stored are deleted by the command (that's
|
|
|
4280 what `FORGET' does, remove stack). If any of these data are required,
|
|
|
4281 they have to be backed up into static storage (variables declared with
|
|
|
4282 `static' or global variables), or into heap storage (as in with
|
|
|
4283 `malloc'), or other types of storage (such as temporary files) which
|
|
|
4284 are not on the stack. (Incidentally, suddenly deleting parts of the
|
|
|
4285 stack is excellent at confusing C debuggers; but even `RESUME' and
|
|
|
4286 `COME FROM' tend to be sufficient to confuse such debuggers. More
|
|
|
4287 worrying is probably the fact that the C standard provides a portable
|
|
|
4288 method for deleting the stack like that, and in fact the external calls
|
|
|
4289 runtime library is written in standard freestanding-legal C89 (with the
|
|
|
4290 exception of `+printflow' debug output which requires a hosted
|
|
|
4291 implementation), meaning that in theory it would be possible to split
|
|
|
4292 it out to create an implementation of a C-plus-COME-FROM-and-NEXT
|
|
|
4293 language, and doing so would not be particularly difficult.)
|
|
|
4294
|
|
|
4295 Note that INTERCAL variables are not stored on the C stack, nor are any
|
|
|
4296 of the metadata surrounding them, and so are not affected unduly by
|
|
|
4297 control flow operations.
|
|
|
4298
|
|
|
4299 14.2 External Calls to Funge-98
|
|
|
4300 ===============================
|
|
|
4301
|
|
|
4302 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
4303 ------------------------------------------------------------------------
|
|
|
4304 no version 0.29+ no no
|
|
|
4305
|
|
|
4306 C-INTERCAL supports linking INTERCAL programs with Funge-98 programs
|
|
|
4307 (to be precise, only Befunge-98 programs are currently supported).
|
|
|
4308 However, it does not ship with a Funge-98 interpreter, and such an
|
|
|
4309 interpreter needs to be linked to the resulting program in order to run
|
|
|
4310 the Befunge program. Therefore, you need to convert a third-party
|
|
|
4311 Funge-98 interpreter to a library usable by C-INTERCAL before you can
|
|
|
4312 use this part of the external calls system (*note Creating the Funge-98
|
|
|
4313 Library::); however, this only has to be done once.
|
|
|
4314
|
|
|
4315 Once the library has been created, you can link an INTERCAL program
|
|
|
4316 with a Befunge-98 program by invoking `ick' like this:
|
|
|
4317
|
|
|
4318 ick -e intercalprogram.i befungeprogram.b98
|
|
|
4319
|
|
|
4320 You can link no more than one Befunge-98 program at once (just like you
|
|
|
4321 can link no more than one INTERCAL program at once). Also, the
|
|
|
4322 INTERCAL program must come first on the command line.
|
|
|
4323
|
|
|
4324 It is legal to link INTERCAL, C, and Befunge-98 simultaneously;
|
|
|
4325 however, the identifiers used in the third-party Funge-98 interpreter
|
|
|
4326 have not been mangled to avoid collisions, and therefore problems may
|
|
|
4327 be caused if the C program uses the same identifiers as the Funge-98
|
|
|
4328 interpreter.
|
|
|
4329
|
|
|
4330 14.2.1 Creating the Funge-98 Library
|
|
|
4331 ------------------------------------
|
|
|
4332
|
|
|
4333 Before external calls to Funge-98 can be used, the relevant library
|
|
|
4334 must be compiled. (After the library has been compiled, then you will
|
|
|
4335 need to reinstall C-INTERCAL; however, you will not need to recompile
|
|
|
4336 C-INTERCAL.)
|
|
|
4337
|
|
|
4338 At present, only the cfunge Funge-98 interpreter can be converted into
|
|
|
4339 a library suitable for use by C-INTERCAL; also, doing this is only
|
|
|
4340 supported on POSIX systems (although if someone gets it to work on
|
|
|
4341 DOS/Windows, the author of this manual would be interested to hear
|
|
|
4342 about it.) Also, a source-code distribution (rather than a binary
|
|
|
4343 distribution) is needed. One way to obtain the latest cfunge sources
|
|
|
4344 is via the bzr version-control system, using the following command
|
|
|
4345 (correct as of the time of writing, but as always, links can become
|
|
|
4346 dead):
|
|
|
4347
|
|
|
4348 bzr branch http://rage.kuonet.org/~anmaster/bzr/cfunge
|
|
|
4349
|
|
|
4350 (As a licensing note, note that cfunge is licensed under the GNU
|
|
|
4351 General Public licence version 3, whereas C-INTERCAL is licensed under
|
|
|
4352 version 2 and all later versions of that licence; although these terms
|
|
|
4353 are obviously compatible with each other, you must ensure yourself that
|
|
|
4354 your program has appropriate licensing terms to allow a GPLv3 library
|
|
|
4355 to be linked to it.)
|
|
|
4356
|
|
|
4357 Once you have downloaded the cfunge sources, you need to compile them
|
|
|
4358 into a library suitable for use with C-INTERCAL (note that this is a
|
|
|
4359 somewhat different process to compiling them into a standalone Funge-98
|
|
|
4360 interpreter). There is a script provided in the C-INTERCAL
|
|
|
4361 distribution to do this, `etc/cftoec.sh'. It must be run in the `etc'
|
|
|
4362 subdirectory of the C-INTERCAL distribution (i.e. the directory the
|
|
|
4363 script itself is in), and must be given the path to the root directory
|
|
|
4364 of the cfunge source distribution (that is, the directory that contains
|
|
|
4365 the `src', `lib' and `tools' subdirectories of that distribution) as
|
|
|
4366 its only argument. Note that it may give some compiler warnings on
|
|
|
4367 compilation; my experience is that warnings about C99 inlining can be
|
|
|
4368 safely ignored (they reflect a deficiency in `gcc' itself that luckily
|
|
|
4369 seems to be irrelevant in this case), but other warnings may indicate
|
|
|
4370 problems in the exact versions of the sources that you downloaded (and
|
|
|
4371 errors definitely indicate such problems).
|
|
|
4372
|
|
|
4373 Once the library has been created, it will appear as the new file
|
|
|
4374 `lib/libick_ecto_b98.a' in the C-INTERCAL distribution (the cfunge
|
|
|
4375 distribution will be left unchanged); reinstalling C-INTERCAL will
|
|
|
4376 install this file to its proper location. (It is also in a valid
|
|
|
4377 location to be able to be run if you aren't installing C-INTERCAL but
|
|
|
4378 instead just running it from the distribution's directory.)
|
|
|
4379
|
|
|
4380 14.2.2 The IFFI Fingerprint
|
|
|
4381 ---------------------------
|
|
|
4382
|
|
|
4383 This section will not make much sense to a non-Funge programmer;
|
|
|
4384 therefore, if you are not used to Funge, you probably want to skip it.
|
|
|
4385
|
|
|
4386 To a Funge program, the external calls interface is accessed via a
|
|
|
4387 Funge-98 'fingerprint' defined by the interpreter. The name of the
|
|
|
4388 fingerprint is 0x49464649, or as text, `IFFI'.
|
|
|
4389
|
|
|
4390 When a program formed by linking INTERCAL and Befunge-98 is run, the
|
|
|
4391 first thing that happens is some internal INTERCAL initialisation which
|
|
|
4392 is not visible to either program, and then initialisation routines
|
|
|
4393 specified in the Befunge-98 program run (if an initialisation routine
|
|
|
4394 is also specified in a linked C program using ick_startup, it is
|
|
|
4395 unspecified whether the C or Befunge-98 initialisation happens first.)
|
|
|
4396 In the Befunge program, the initialisation routine consists of
|
|
|
4397 everything that happens until the `Y' command in the `IFFI' fingerprint
|
|
|
4398 is run; the author of the Funge-98 must load the `IFFI' fingerprint
|
|
|
4399 themselves during this initialisation to access that command. (This is
|
|
|
4400 so that the Befunge program ends up complying with the Funge-98
|
|
|
4401 standard; commands not defined in that standard cannot be used until a
|
|
|
4402 fingerprint is loaded.) During initialisation, no commands from the
|
|
|
4403 `IFFI' fingerprint may be used except `Y' and `A'. (If a different
|
|
|
4404 command is used, `C', `M', and `X' remove the arguments they would use
|
|
|
4405 from the stack (if any) but otherwise do nothing, and the other
|
|
|
4406 commands in the `IFFI' fingerprint reflect.)
|
|
|
4407
|
|
|
4408 After the `Y' command is called, the INTERCAL program starts running;
|
|
|
4409 in order for the Befunge program to regain control, it has to be
|
|
|
4410 `NEXT'ed to from the INTERCAL program, or `COME' or `NEXT FROM' the
|
|
|
4411 INTERCAL program, or contain the line label to which syntax in the
|
|
|
4412 INTERCAL program was `CREATE'd. (In other words, the normal INTERCAL
|
|
|
4413 ways of transferring information between parts of a program.) In order
|
|
|
4414 to do this, therefore, line labels and INTERCAL control flow statements
|
|
|
4415 must be placed into the Befunge program.
|
|
|
4416
|
|
|
4417 Code like `COME FROM (100)' is a single statement in INTERCAL, but
|
|
|
4418 several statements in Funge-98; therefore, some method of telling the
|
|
|
4419 interpreter where to start executing to look for `COME FROM's, `NEXT
|
|
|
4420 FROM's, and line labels is needed. The method used by C-INTERCAL is
|
|
|
4421 that of the 'marker'; a marker is represented by character 0xB7 (a
|
|
|
4422 mid-dot in Latin-1) in the input Funge-98 program, but is transformed
|
|
|
4423 to a capital `M' by `ick'. (The reason for using a special character
|
|
|
4424 for a marker and transforming it rather than just using `M' is to
|
|
|
4425 prevent occurences of `M' in comments and string literals, etc., having
|
|
|
4426 an effect on the control flow of the program.) Whenever a `NEXT' or
|
|
|
4427 line label is encountered (in the INTERCAL program, the Funge program
|
|
|
4428 or elsewhere), the Funge program is executed starting from each marker
|
|
|
4429 in each cardinal direction to look for line labels or `COME'/`NEXT
|
|
|
4430 FROM's respectively. Therefore, `COME FROM (100)' is written in
|
|
|
4431 Funge-98 as `Maa*C' (where the M is a marker in the source code), and
|
|
|
4432 likewise the line label `(100)' would be written as `Maa*L'. (This
|
|
|
4433 code can be written in any cardinal direction, that is left to right,
|
|
|
4434 top to bottom, right to left, or bottom to top, but not diagonally or
|
|
|
4435 flying.) There are likely to be unused directions from markers, which
|
|
|
4436 will be evaluated too; you can (and must) close these off by reflecting
|
|
|
4437 code execution back into that marker, another marker, or a non-marker
|
|
|
4438 `M'. Note also that a marker remains in Funge-space even if the `M' on
|
|
|
4439 the same square is deleted (the marker itself is not visible to the `g'
|
|
|
4440 command, though).
|
|
|
4441
|
|
|
4442 Here are the commands in the `IFFI' fingerprint:
|
|
|
4443 `A'
|
|
|
4444 This command pops a line number and then an 0"gnirts"-format string
|
|
|
4445 from the stack; they are used as the line number and signature to
|
|
|
4446 `CREATE' syntax in the INTERCAL program; for details of the format
|
|
|
4447 of the signature, see *note ick_create::. Although using this
|
|
|
4448 command during speculative execution works, doing so is not
|
|
|
4449 recommended; if the target line number for `CREATE'd syntax is
|
|
|
4450 changed during speculative execution to find the line that that
|
|
|
4451 syntax corresponds to, its effect is delayed until after the
|
|
|
4452 original line is found and execution continues from that point.
|
|
|
4453 (Side effects during speculative execution are never recommended,
|
|
|
4454 because they might or might not be optimised away.)
|
|
|
4455
|
|
|
4456 `C'
|
|
|
4457 During speculative execution to find `COME FROM's and `NEXT
|
|
|
4458 FROM's, pops a line label off the top of the stack and does a
|
|
|
4459 `COME FROM' that location. During speculative excution to find
|
|
|
4460 line labels, pops the top of the stack and ends that particular
|
|
|
4461 speculative execution as a failure. When not doing speculative
|
|
|
4462 execution, pops and discards the top element of the stack.
|
|
|
4463
|
|
|
4464 `D'
|
|
|
4465 This command must only be used when the Funge program is executing
|
|
|
4466 a `CREATE'd command, and allows access to the arguments that
|
|
|
4467 command has. It pops an integer off the top of the stack, and
|
|
|
4468 treats it as an argument position (0-based, so 0 refers to the
|
|
|
4469 first argument, 1 refers to the second, and so on). Note that
|
|
|
4470 providing an invalid argument number, or running this command when
|
|
|
4471 not implementing a `CREATE'd command, leads to undefined behaviour
|
|
|
4472 (possibly a reflection, possibly a segfault, possibly worse).
|
|
|
4473
|
|
|
4474 The command pushes information about the argument chosen onto the
|
|
|
4475 stack; the following information is pushed from bottom to top:
|
|
|
4476 * The data type of the argument, in bits (16 if the argument
|
|
|
4477 was a onespot variable or expression of onespot type, and 32
|
|
|
4478 if the argument was a twospot variable or expression of
|
|
|
4479 twospot type). Note that this is under the C-INTERCAL typing
|
|
|
4480 rules, rather than the INTERCAL-72 typing rules (that is,
|
|
|
4481 select's type is always that of its right argument no matter
|
|
|
4482 how many bits are actually selected).
|
|
|
4483
|
|
|
4484 * 1 if the argument is an array variable, 0 if it is a scalar
|
|
|
4485 value.
|
|
|
4486
|
|
|
4487 * 0 if the argument is not a variable, or the variable's number
|
|
|
4488 if it is (e.g. `.123' would push 123 here, but `.1~.2' would
|
|
|
4489 push 0).
|
|
|
4490
|
|
|
4491 * The argument's value at the time that the `CREATE'd
|
|
|
4492 instruction was called.
|
|
|
4493
|
|
|
4494 * The argument's value now, or alternatively a repeat of the
|
|
|
4495 previous stack element if `-a' (*note -a::) was not used.
|
|
|
4496 (Without `-a', the information needed to re-evaluate the
|
|
|
4497 expression is not available.)
|
|
|
4498
|
|
|
4499 `F'
|
|
|
4500 During speculative execution, this command reflects; otherwise,
|
|
|
4501 this command pops an integer from the top of stack, and `FORGET's
|
|
|
4502 that many `NEXT' stack entries (or all of them if the argument
|
|
|
4503 given is negative).
|
|
|
4504
|
|
|
4505 `G'
|
|
|
4506 This command pops an integer from the top of stack. If it is
|
|
|
4507 positive, the value of the onespot variable whose name is the
|
|
|
4508 popped integer is pushed onto the stack; if it is negative, the
|
|
|
4509 value of the twospot variable whose name is minus the popped
|
|
|
4510 integer is pushed onto the stack; and if it is zero, the command
|
|
|
4511 reflects. If the referenced variable is not in the INTERCAL
|
|
|
4512 program at all, this causes an INTERCAL error due to referencing a
|
|
|
4513 nonexistent variable.
|
|
|
4514
|
|
|
4515 `L'
|
|
|
4516 During speculative execution to find `COME FROM's and `NEXT
|
|
|
4517 FROM's, this command pops and discards the top stack element, then
|
|
|
4518 ends that speculative execution. During speculative execution to
|
|
|
4519 find a line label, this command pops an integer from the top of
|
|
|
4520 stack and succeeds with that integer as the line label (that is,
|
|
|
4521 it is possible to `NEXT' to an `L' in the Funge program if a
|
|
|
4522 marker, followed by code to push the correct line number onto the
|
|
|
4523 stack, precedes that `L'). When not doing speculative execution,
|
|
|
4524 the integer on the top of the stack is used as a line label
|
|
|
4525 (assuming it is in the range 1-65535, otherwise it is popped and
|
|
|
4526 discarded), and a search is made for `COME FROM's and `NEXT FROM's
|
|
|
4527 aiming for that line label (including in the INTERCAL program and
|
|
|
4528 the Befunge program itself, as well as programs in any other
|
|
|
4529 language which may be linked in). Note that just as in INTERCAL,
|
|
|
4530 it is possible to `NEXT' to a line label which has a `COME FROM'
|
|
|
4531 aiming for it, in which case the `COME FROM' will come from that
|
|
|
4532 line label as soon as the `NEXT' transfers control to it.
|
|
|
4533
|
|
|
4534 `M'
|
|
|
4535 Does nothing if not in speculative execution, or ends the current
|
|
|
4536 speculative execution with failure. (This is so that code like
|
|
|
4537 v
|
|
|
4538 >M5C
|
|
|
4539 ^
|
|
|
4540 does exactly the same thing as `COME FROM (5)', even when, for
|
|
|
4541 instance, it is entered from the left in the Funge program, rather
|
|
|
4542 than gaining control from the line label `(5)'.)
|
|
|
4543
|
|
|
4544 `N'
|
|
|
4545 During speculative execution, reflects. Otherwise, pops the top
|
|
|
4546 stack element, interprets it as a line label, and `NEXT's to that
|
|
|
4547 line label (this may start speculative execution to look for line
|
|
|
4548 labels, but might not if it isn't needed, for instance if the line
|
|
|
4549 label in question is in the INTERCAL program or in a C program
|
|
|
4550 linked to the Befunge program).
|
|
|
4551
|
|
|
4552 `R'
|
|
|
4553 During speculative execution, reflects. Otherwise, pops the top
|
|
|
4554 stack element, removes that many items from the `NEXT' stack, and
|
|
|
4555 `RESUME's at the last item removed. (If the top stack element was
|
|
|
4556 zero, negative, or too large, this will cause a fatal error in the
|
|
|
4557 INTERCAL program.)
|
|
|
4558
|
|
|
4559 `S'
|
|
|
4560 Pops a variable number (interpreted as onespot if positive, or
|
|
|
4561 minus the number of a twospot variable if negative) and an integer
|
|
|
4562 from the stack, and sets the referenced variable to the integer.
|
|
|
4563 This reflects if an attempt is made to set the nonexistent
|
|
|
4564 variable 0, causes a fatal error in the INTERCAL program if an
|
|
|
4565 attempt is made to set a variable that doesn't exist there, and
|
|
|
4566 does not set read-only variables (but pops the stack anyway). If
|
|
|
4567 the integer is too high for the variable it is being stored in,
|
|
|
4568 only the least significant 16 or 32 bits from it will be used; and
|
|
|
4569 likewise, if it is negative, it will be treated as the two's
|
|
|
4570 complement of the number given.
|
|
|
4571
|
|
|
4572 `V'
|
|
|
4573 Pops a `CREATE'd argument index and an integer from the top of
|
|
|
4574 stack. (This is undefined behaviour if not in the implementation
|
|
|
4575 of a `CREATE'd statement, or if the referenced argument does not
|
|
|
4576 exist; as with the `D' instruction, 0 refers to the first
|
|
|
4577 argument, 1 to the second, and so on.) If the `-a' option is not
|
|
|
4578 used, this command does nothing; otherwise, the value of the
|
|
|
4579 argument will be set to the integer. (This involves doing a
|
|
|
4580 reverse assignment if the argument is a non-variable expression,
|
|
|
4581 as usual, and causes a fatal error in the INTERCAL program if the
|
|
|
4582 reverse assignment is impossible or an attempt is made to assign a
|
|
|
4583 scalar to an array.)
|
|
|
4584
|
|
|
4585 `X'
|
|
|
4586 This is identical to `C', except that it does a `NEXT FROM' rather
|
|
|
4587 than a `COME FROM'.
|
|
|
4588
|
|
|
4589 As with external calls to C, terminating any program involved (whether
|
|
|
4590 the INTERCAL program with `GIVE UP', the Befunge program with `@' or
|
|
|
4591 `q', or a C program with `exit()') causes all programs involved to
|
|
|
4592 terminate, and likewise a fatal error will end all programs with an
|
|
|
4593 error.
|
|
|
4594
|
|
|
4595 One final point which is probably worth mentioning is that flow control
|
|
|
4596 instructions only record the IP's position and direction, nothing else;
|
|
|
4597 so for instance, if the stack is modified in one part of the code,
|
|
|
4598 those modifications will remain even after a `RESUME', for instance.
|
|
|
4599
|
|
|
4600 14.3 Miscellaneous External Calls
|
|
|
4601 =================================
|
|
|
4602
|
|
|
4603 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
4604 ------------------------------------------------------------------------
|
|
|
4605 no version 0.29+ no no
|
|
|
4606
|
|
|
4607 It is possible to specify other information to the external calls
|
|
|
4608 system by using the filename list after all the options are given. To
|
|
|
4609 be precise, certain filename patterns are recognised and used to change
|
|
|
4610 the options that are used to compile the externally-called files.
|
|
|
4611
|
|
|
4612 The `.c99' extension is treated identically to `.c', except that it
|
|
|
4613 causes the file with that extension to be preprocessed as C99 (the more
|
|
|
4614 modern version of the C standard, the older C89 is more common), and
|
|
|
4615 that all C files involved will be compiled and linked as C99. (This
|
|
|
4616 corresponds to `-std=c99' in `gcc'.)
|
|
|
4617
|
|
|
4618 The `.a' extension indicates that an object-code library should be
|
|
|
4619 linked in to the final program. This is most commonly used to link in
|
|
|
4620 the maths library `libm.a' and other such system libraries. If the
|
|
|
4621 filename is of the form `lib*.a', then the file will be searched for in
|
|
|
4622 the standard directories for libraries on your system, and also where
|
|
|
4623 the C-INTERCAL libraries are stored (which may be the same place);
|
|
|
4624 otherwise, the current directory will be searched. (Specifying
|
|
|
4625 `libm.a' on the command line corresponds to passing `-lm' to `gcc'.)
|
|
|
4626
|
|
|
4627 14.4 Using External Calls
|
|
|
4628 =========================
|
|
|
4629
|
|
|
4630 Whatever language your source files are written in, when `-e' is used
|
|
|
4631 (*note -e::), the compiler will go through much the same steps.
|
|
|
4632
|
|
|
4633 First, the INTERCAL program specified is compiled into a C program that
|
|
|
4634 uses the INTERCAL external call conventions for its control flow
|
|
|
4635 operations. The resulting `.c' file will be left behind in the same
|
|
|
4636 directory (even if `-g' isn't used); if you look at it, you'll see the
|
|
|
4637 `#include <ick_ec.h>' line, and the other hallmarks of an external call
|
|
|
4638 program (for instance, INTERCAL `NEXT's will translate into slightly
|
|
|
4639 modified `ick_next's; the modification is simply to allow the correct
|
|
|
4640 line number to be displayed in case of error).
|
|
|
4641
|
|
|
4642 After that, the resulting files are preprocessed twice. First, the C
|
|
|
4643 preprocessor is run on the files; then, a special C-INTERCAL
|
|
|
4644 `preprocessor' is run on the files. (`Preprocessor' is a bit of a
|
|
|
4645 misnomer here, as it's near the end of the compilation process;
|
|
|
4646 `postprocessor' would likely be more accurate, or maybe
|
|
|
4647 `interprocessor'.) Its job is to fix line labels between the gotos
|
|
|
4648 that are used to implement jumping into the middle of a C function, to
|
|
|
4649 assign unique numbers to things that need them, and to keep track of
|
|
|
4650 which functions need to be checked for line labels and for `COME FROM's
|
|
|
4651 and `NEXT FROM's. The resulting file will have the extension `.cio';
|
|
|
4652 it is almost human-readable, especially if you run it through a C code
|
|
|
4653 indenter, and consists of C code (or code in whatever language is being
|
|
|
4654 linked to the INTERCAL code, but so far only C is accepted) and
|
|
|
4655 instructions to `gcc'. The `.cio' file will be left behind for you to
|
|
|
4656 look at, if you like.
|
|
|
4657
|
|
|
4658 Once the `.cio' files have been produced, `gcc' is used to compile all
|
|
|
4659 the `.cio' files and link them together into an executable; the
|
|
|
4660 executable will have the same name as the INTERCAL source, minus any
|
|
|
4661 extension (and on DJGPP, assuming that its version of `gcc' could
|
|
|
4662 handle the resulting command line (not necessarily guaranteed), a
|
|
|
4663 `.exe' extension is added), and will consist of all the C files linked
|
|
|
4664 together with the INTERCAL. Any functions named `main' in the C files
|
|
|
4665 will be deleted; likewise, if there is a name clash between any two
|
|
|
4666 functions, the one in the file named earlier on the command line will
|
|
|
4667 be used. There is presumably some use for this feature, although I
|
|
|
4668 haven't figured out what it is yet.
|
|
|
4669
|
|
|
4670 Extending this to other compiled languages is mostly a problem of
|
|
|
4671 determining how they fit into the INTERCAL control structure, which is
|
|
|
4672 not a trivial task, and of figuring out how to link them to C code,
|
|
|
4673 which in some cases is trivial (especially if the language is one that
|
|
|
4674 `gcc' can compile!) and in other cases is very difficult. If anyone
|
|
|
4675 has any ideas of new languages that could be added to the external
|
|
|
4676 calls system, feel free to contact the current C-INTERCAL maintainer
|
|
|
4677 with suggestions or patches.
|
|
|
4678
|
|
|
4679 14.5 Expansion Libraries
|
|
|
4680 ========================
|
|
|
4681
|
|
|
4682 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
4683 ------------------------------------------------------------------------
|
|
|
4684 no version 0.28+ no no
|
|
|
4685
|
|
|
4686 The C-INTERCAL distribution comes with libraries that can be used to
|
|
|
4687 extend its capabilities; they are implemented using the external call
|
|
|
4688 mechanism, and are in effect standard files to include using that
|
|
|
4689 mechanism. To use an expansion library, give the `-e' option to `ick'
|
|
|
4690 (note that this means you cannot use them with the debugger or
|
|
|
4691 profiler, nor with multithreaded or backtracking programs), and specify
|
|
|
4692 the expansion library's name at the end of the command line (or to be
|
|
|
4693 precise, anywhere after the initial INTERCAL file). The libraries
|
|
|
4694 themselves are written in C and have a `.c' extension, and are
|
|
|
4695 human-readable; C-INTERCAL will look for them in the same places as it
|
|
|
4696 looks for the system library (including in the current directory, so
|
|
|
4697 you can test your own expansion libraries without having to install
|
|
|
4698 them).
|
|
|
4699
|
|
|
4700 Expansion libraries use C identifiers which start with the string
|
|
|
4701 `ick_my_' (this is not used by the compiler, and is explicitly not
|
|
|
4702 affected by the prohibition on identifiers starting `ick_' when writing
|
|
|
4703 an expansion library), and use line labels in the range (1600) to
|
|
|
4704 (1699). (Most programs will be avoiding this range anyway, because
|
|
|
4705 it's inside the (1000) to (1999) range reserved for the system library,
|
|
|
4706 but the system library doesn't use it, in much the same way that the
|
|
|
4707 identifiers used are inside the range reserved for the compiler, but
|
|
|
4708 the compiler doesn't use them.)
|
|
|
4709
|
|
|
4710 Expansion libraries are available from C-INTERCAL version 0.28;
|
|
|
4711 CLC-INTERCAL has a similar concept (that of `preloads'), but
|
|
|
4712 implemented a completely different way.
|
|
|
4713
|
|
|
4714 syslibc
|
|
|
4715 -------
|
|
|
4716
|
|
|
4717 `syslibc' is an implementation of the base-2 INTERCAL system library in
|
|
|
4718 C (*note System Library::); using it in programs running in other bases
|
|
|
4719 is accepted by the compiler, but likely to produce unpredictable
|
|
|
4720 results. When using this expansion library, you also need to give the
|
|
|
4721 `-E' option (*note -E: -E+.) so that the main system library is not
|
|
|
4722 included, or it will be used in preference to the expansion library.
|
|
|
4723 All documented features of the INTERCAL base-2 system library are
|
|
|
4724 implemented, but most undocumented features are not, so INTERCAL
|
|
|
4725 programs which relied on them (dubious behaviour in any case) will not
|
|
|
4726 work with `syslibc'. The main reason to use this library is to
|
|
|
4727 increase the speed of an INTERCAL program; however, note that the speed
|
|
|
4728 gains in arithmetic will be accompanied by the performance penalty of
|
|
|
4729 using the external calls infrastructure, unless you were already using
|
|
|
4730 it.
|
|
|
4731
|
|
|
4732 compunex
|
|
|
4733 --------
|
|
|
4734
|
|
|
4735 As an example of using `ick_create', a very simple expansion library is
|
|
|
4736 provided to enable a computed NEXT capability, by defining a new
|
|
|
4737 command `COMPUNEX'. It is used as `DO .1 COMPUNEX' (allowing any
|
|
|
4738 expression in place of the .1), and is similar to an ordinary `NEXT',
|
|
|
4739 but has two limitations: it takes up two `NEXT' stack entries, and the
|
|
|
4740 top one should not be `RESUMEd' past or forgotten (thus it isn't a
|
|
|
4741 particularly useful command, except maybe to produce the equivalent of
|
|
|
4742 something like function pointers). By the way, note that C-INTERCAL
|
|
|
4743 avoids computed `NEXT' mainstream for much the same way that
|
|
|
4744 CLC-INTERCAL avoids `NEXT' altogether; it makes things too easy. This
|
|
|
4745 example is provided mostly just to demonstrate the syntax, and the care
|
|
|
4746 that needs to be taken with implementing flow control operators.
|
|
|
4747
|
|
|
4748 `compunex' is double-deprecated; an alternative is the following
|
|
|
4749 sequence of commands involving computed `CREATE':
|
|
|
4750
|
|
|
4751 DO CREATE .1 ABC
|
|
|
4752 DO ABC
|
|
|
4753
|
|
|
4754 This sequence emulates all features of `NEXT' (although it has
|
|
|
4755 different gerunds and is two statements, not one), making it much more
|
|
|
4756 useful for simulating computed `NEXT' than `COMPUNEX' is. (There's no
|
|
|
4757 need to avoid forgetting the return value; although this skips the
|
|
|
4758 `CREATE' cleanup, none is required because the created statement `ABC'
|
|
|
4759 (any other statement would do just as well) takes no arguments.)
|
|
|
4760
|
|
|
4761 15 Differences to Other Compilers
|
|
|
4762 *********************************
|
|
|
4763
|
|
|
4764 The C-INTERCAL compiler exists in a world of several other compilers.
|
|
|
4765
|
|
|
4766 Differences to the Princeton compiler
|
|
|
4767 -------------------------------------
|
|
|
4768
|
|
|
4769 The Princeton compiler was the first INTERCAL compiler available, and
|
|
|
4770 compiled INTERCAL-72. Using `convickt' (*note convickt::) to translate
|
|
|
4771 its programs from the original EBCDIC to Latin-1 or Atari-syntax ASCII
|
|
|
4772 is required to run them under the C-INTERCAL compiler, but apart from
|
|
|
4773 that there should be no problems; everything that that compiler can do
|
|
|
4774 can be reproduced by C-INTERCAL, even including some of its bugs. The
|
|
|
4775 only potential problems may be where constructs were nonportable or
|
|
|
4776 dubious to begin with (such as the `IGNORE'/`RETRIEVE' interaction), or
|
|
|
4777 where commands intended to be syntax errors were used in the program
|
|
|
4778 but have a meaning in C-INTERCAL. For extra portability, it's possible
|
|
|
4779 to use the `-t' compiler option to `ick' (*note -t::) to tell it to
|
|
|
4780 interpret the program as INTERCAL-72, but as C-INTERCAL's dialect of
|
|
|
4781 INTERCAL is basically backward-compatible anyway this mostly serves to
|
|
|
4782 check newer programs for compatibility with older compilers.
|
|
|
4783
|
|
|
4784 Differences to the Atari compiler
|
|
|
4785 ---------------------------------
|
|
|
4786
|
|
|
4787 The Atari compiler was another implementation of INTERCAL-72, which was
|
|
|
4788 basically identical to the Princeton compiler apart from its use of
|
|
|
4789 ASCII and Atari syntax. Everything said under the previous section
|
|
|
4790 applies, except that as it uses the same syntax as C-INTERCAL anyway
|
|
|
4791 (C-INTERCAL's syntax was based on the Atari compiler's), there is no
|
|
|
4792 need to use `convickt'.
|
|
|
4793
|
|
|
4794 Differences to J-INTERCAL
|
|
|
4795 -------------------------
|
|
|
4796
|
|
|
4797 The J-INTERCAL compiler is an implementation of INTERCAL written in Java
|
|
|
4798 that compiles INTERCAL into Java (and so has a similar relationship
|
|
|
4799 with Java to that of the C-INTERCAL compiler (which is written in C and
|
|
|
4800 compiles into C) with C). J-INTERCAL has much the same feature set as
|
|
|
4801 older versions of C-INTERCAL, with a few changes (such as the addition
|
|
|
4802 of Esperanto and error messages coming up in different situations).
|
|
|
4803 J-INTERCAL programs should run fine on C-INTERCAL without trouble (as
|
|
|
4804 it is also an Atari syntax compiler), except in nonportable cases such
|
|
|
4805 as `IGNORE'/`RETRIEVE' interaction.
|
|
|
4806
|
|
|
4807 Differences to CLC-INTERCAL
|
|
|
4808 ---------------------------
|
|
|
4809
|
|
|
4810 The CLC-INTERCAL compiler is the most modern INTERCAL compiler apart
|
|
|
4811 from C-INTERCAL (both compilers are maintained and updated every now
|
|
|
4812 and then as of the time of writing, so which is more modern is normally
|
|
|
4813 a matter of when you happen to check). Unlike the other three compilers
|
|
|
4814 mentioned above, it has a quite significant feature set, including many
|
|
|
4815 features not implemented or only partially implemented in C-INTERCAL,
|
|
|
4816 and is responsible for the origin of many of the features added in more
|
|
|
4817 recent versions of C-INTERCAL. Generally speaking, a CLC-INTERCAL
|
|
|
4818 program that uses its advanced features is unlikely to run on
|
|
|
4819 C-INTERCAL, or vice versa, whatever you do (apart from completely
|
|
|
4820 rewriting the more advanced parts of the program.)
|
|
|
4821
|
|
|
4822 However, there are certain steps that can be taken to transfer less
|
|
|
4823 advanced programs from one compiler to the other. First, translate the
|
|
|
4824 program to Latin-1 Princeton syntax (if translating from CLC-INTERCAL
|
|
|
4825 to C-INTERCAL) or Atari syntax (if translating from C-INTERCAL to
|
|
|
4826 CLC-INTERCAL), maybe using `convickt', if necessary. (Note that here
|
|
|
4827 the program is being translated to the syntax that is not default for
|
|
|
4828 the target compiler.) Then use command-line arguments to switch the
|
|
|
4829 compiler into the correct emulation mode for the other compiler;
|
|
|
4830 C-INTERCAL uses the options `-xX', and on CLC-INTERCAL this is done by
|
|
|
4831 selecting the appropriate preloads, or by changing the program's file
|
|
|
4832 extension to `.ci'. In each case other options may be needed to turn
|
|
|
4833 on various extensions (maybe `-m' or `-v' if translating to C-INTERCAL,
|
|
|
4834 maybe the preload for gerund-based `COME FROM' if translating to
|
|
|
4835 CLC-INTERCAL), and if translating to CLC-INTERCAL you need to append
|
|
|
4836 the system library to your program yourself because CLC-INTERCAL
|
|
|
4837 doesn't load it automatically.
|
|
|
4838
|
|
|
4839 In the case of very simple programs, or if you want to spend the effort
|
|
|
4840 in translating compiler-specific code from one compiler to another, you
|
|
|
4841 may be able to work without emulation options. (This is a good target
|
|
|
4842 to aim for, in any case.) In such a case, you would do nothing other
|
|
|
4843 than possibly edit the program to be more portable and a possible
|
|
|
4844 character set and syntax change using `convickt'. If you need
|
|
|
4845 compiler-specific code, you may be able to detect the compiler in the
|
|
|
4846 code itself and adapt accordingly; making use of the
|
|
|
4847 `IGNORE'/`RETRIEVE' interaction is one way to do this, as it differs
|
|
|
4848 between C-INTERCAL, J-INTERCAL, and CLC-INTERCAL. The other things to
|
|
|
4849 watch out for when doing this are that CLC-INTERCAL needs an explicit
|
|
|
4850 option to enable the use of `NEXT', that CLC-INTERCAL doesn't load the
|
|
|
4851 system library itself (you need to manually append it to the end of the
|
|
|
4852 program) and that you probably shouldn't number a line (666) unless you
|
|
|
4853 know what you're doing, because that line number has a special meaning
|
|
|
4854 in CLC-INTERCAL.
|
|
|
4855
|
|
|
4856 PART IV: APPENDICES AND INDICES
|
|
|
4857 *******************************
|
|
|
4858
|
|
|
4859 Appendix A Character Sets
|
|
|
4860 *************************
|
|
|
4861
|
|
|
4862 The following table explains the equivalences between the various
|
|
|
4863 character sets used for INTERCAL: 7-bit ASCII Atari syntax, 5-bit
|
|
|
4864 Baudot Princeton syntax, 8-bit EBCDIC Princeton syntax, and 8-bit
|
|
|
4865 Latin-1 Princeton syntax. (The Baudot and EBCDIC are the CLC-INTERCAL
|
|
|
4866 versions, which are used by INTERCAL compilers but basically nowhere
|
|
|
4867 else.) The characters themselves are not shown in the table below,
|
|
|
4868 because they would have to be shown in some syntax, which would be
|
|
|
4869 misleading. (Atari syntax is used throughout this manual; you could
|
|
|
4870 convert from that, assuming you have an ASCII table handy.) You can
|
|
|
4871 also use the `convickt' command-line tool to translate INTERCAL
|
|
|
4872 programs from one format to another (*note convickt::). Note that
|
|
|
4873 Baudot has more than one 'shift state'; the shift state (1, 2, 3, or 4)
|
|
|
4874 is written before the hexadecimal code for each character, and *
|
|
|
4875 represents a character available in every shift state. To change from
|
|
|
4876 one shift state to another, use character 1f to change from shift
|
|
|
4877 states 3 or 4 to 1, or from 1 or 2 to 2, and character 1b to change
|
|
|
4878 from shift states 1 or 2 to 3, or from 3 or 4 to 4.
|
|
|
4879
|
|
|
4880 Atari Baudot EBCDIC Latin-1
|
|
|
4881 ------------------------------------
|
|
|
4882 09 N/A 09 09
|
|
|
4883 0a * 02 0a 0a
|
|
|
4884 0d * 08 0d 0d
|
|
|
4885 20 * 04 40 20
|
|
|
4886 21 3 0d 4f 21
|
|
|
4887 22 3 11 7f 22
|
|
|
4888 23 4 06 7b 23
|
|
|
4889 24 4 01 4a a2
|
|
|
4890 25 4 1c 6c 25
|
|
|
4891 26 3 1a 50 26
|
|
|
4892 27 3 0b 7d 27
|
|
|
4893 28 3 0f 4d 28
|
|
|
4894 29 3 12 5d 29
|
|
|
4895 2a 4 09 5c 2a
|
|
|
4896 2b 4 03 4e 2b
|
|
|
4897 2c 3 0c 6b 2c
|
|
|
4898 2d 3 03 60 2d
|
|
|
4899 2e 3 1c 4b 2e
|
|
|
4900 2f 3 1d 61 2f
|
|
|
4901 30 3 16 f0 30
|
|
|
4902 31 3 17 f1 31
|
|
|
4903 32 3 13 f2 32
|
|
|
4904 33 3 01 f3 33
|
|
|
4905 34 3 0a f4 34
|
|
|
4906 35 3 10 f5 35
|
|
|
4907 36 3 15 f6 36
|
|
|
4908 37 3 07 f7 37
|
|
|
4909 38 3 06 f8 38
|
|
|
4910 39 3 18 f9 39
|
|
|
4911 3a 3 0e 7a 3a
|
|
|
4912 3b 3 1e 5e 3b
|
|
|
4913 3c 4 0f 4c 3c
|
|
|
4914 3d 4 07 7e 3d
|
|
|
4915 3e 4 12 6e 3e
|
|
|
4916 3f 4 0c 65 a5
|
|
|
4917 40 3 19 6f 3f
|
|
|
4918 41 1 03 c1 41
|
|
|
4919 42 1 19 c2 42
|
|
|
4920 43 1 0e c3 43
|
|
|
4921 44 1 09 c4 44
|
|
|
4922 45 1 01 c5 45
|
|
|
4923 46 1 0d c6 46
|
|
|
4924 47 1 1a c7 47
|
|
|
4925 48 1 14 c8 48
|
|
|
4926 49 1 06 c9 49
|
|
|
4927 4a 1 0b d1 4a
|
|
|
4928 4b 1 0f d2 4b
|
|
|
4929 4c 1 13 d3 4c
|
|
|
4930 4d 1 1c d4 4d
|
|
|
4931 4e 1 0c d5 4e
|
|
|
4932 4f 1 18 d6 4f
|
|
|
4933 50 1 16 d7 50
|
|
|
4934 51 1 17 d8 51
|
|
|
4935 52 1 0a d9 52
|
|
|
4936 53 1 05 e2 53
|
|
|
4937 54 1 10 e3 54
|
|
|
4938 55 1 07 e4 55
|
|
|
4939 56 1 1e e5 56
|
|
|
4940 57 1 12 e6 57
|
|
|
4941 58 1 1d e7 58
|
|
|
4942 59 1 15 e8 59
|
|
|
4943 5a 1 11 e9 5a
|
|
|
4944 5b 4 10 9e 5b
|
|
|
4945 5c 4 05 N/A 5c
|
|
|
4946 5d 4 13 5a 5d
|
|
|
4947 5e 4 0d 6a 7c
|
|
|
4948 5f 4 15 7c 40
|
|
|
4949 60 N/A N/A 60
|
|
|
4950 61 2 03 81 61
|
|
|
4951 62 2 19 82 62
|
|
|
4952 63 2 0e 83 63
|
|
|
4953 64 2 09 84 64
|
|
|
4954 65 2 01 85 65
|
|
|
4955 66 2 0d 86 66
|
|
|
4956 67 2 1a 87 67
|
|
|
4957 68 2 14 88 68
|
|
|
4958 69 2 06 89 69
|
|
|
4959 6a 2 0b 91 6a
|
|
|
4960 6b 2 0f 92 6b
|
|
|
4961 6c 2 13 93 6c
|
|
|
4962 6d 2 1c 94 6d
|
|
|
4963 6e 2 0c 95 6e
|
|
|
4964 6f 2 18 96 6f
|
|
|
4965 70 2 16 97 70
|
|
|
4966 71 2 17 98 71
|
|
|
4967 72 2 0a 99 72
|
|
|
4968 73 2 05 a2 73
|
|
|
4969 74 2 10 a3 74
|
|
|
4970 75 2 07 a4 75
|
|
|
4971 76 2 1e a5 76
|
|
|
4972 77 2 12 a6 77
|
|
|
4973 78 2 1d a7 78
|
|
|
4974 79 2 15 a8 79
|
|
|
4975 7a 2 11 a9 7a
|
|
|
4976 7b 4 0a 9c 7b
|
|
|
4977 7c 4 1e fe N/A
|
|
|
4978 7d 4 11 dc 7d
|
|
|
4979 7e 4 0b a1 7e
|
|
|
4980
|
|
|
4981 Appendix B convickt
|
|
|
4982 *******************
|
|
|
4983
|
|
|
4984 A variety of character sets have historically been used to represent
|
|
|
4985 INTERCAL programs. Atari syntax was designed specifically for use with
|
|
|
4986 ASCII-7, and all Atari-syntax-based INTERCAL compilers accept that
|
|
|
4987 character set as possible input. (C-INTERCAL also accepts Latin-1 and
|
|
|
4988 UTF-8.) However, the story is more complicated with Princeton syntax;
|
|
|
4989 the original Princeton compiler was designed to work with EBCDIC, but
|
|
|
4990 because modern computers are often not designed to work with this
|
|
|
4991 character set other character sets are often used to represent it,
|
|
|
4992 particularly Latin-1. The CLC-INTERCAL compiler accepts Latin-1, a
|
|
|
4993 custom dialect of EBCDIC, Baudot, and a punched-card format as input;
|
|
|
4994 C-INTERCAL can cope with Latin-1 Princeton syntax, but for the other
|
|
|
4995 character sets, for other compilers, or just for getting something
|
|
|
4996 human-readable, it's useful to have a conversion program. `convickt'
|
|
|
4997 is an INTERCAL character set conversion program designed with these
|
|
|
4998 needs in mind.
|
|
|
4999
|
|
|
5000 The syntax for using `convickt' is
|
|
|
5001
|
|
|
5002 convickt INPUTSET OUTPUTSET [PADDING]
|
|
|
5003
|
|
|
5004 (that is, the input and output character sets are compulsory, but the
|
|
|
5005 parameter specifying what sort of padding to use is optional).
|
|
|
5006
|
|
|
5007 The following values for INPUTSET and OUTPUTSET are permissible:
|
|
|
5008
|
|
|
5009 `latin1'
|
|
|
5010 Latin-1, or to give it its official name ISO-8859-1, is the
|
|
|
5011 character set most commonly used for transmitting CLC-INTERCAL
|
|
|
5012 programs, and therefore nowadays the most popular character set
|
|
|
5013 for Princeton syntax programs. Because it is identical to ASCII-7
|
|
|
5014 in all codepoints that don't have the high bit set, most of the
|
|
|
5015 characters in it can be read by most modern editors and terminals.
|
|
|
5016 It is also far more likely to be supported by modern editors than
|
|
|
5017 EBCDIC, Baudot, or punched cards, all of which have fallen into
|
|
|
5018 relative disuse since 1972. It is also the only input character
|
|
|
5019 set that C-INTERCAL supports for Princeton syntax programs. It
|
|
|
5020 uses 8 bit characters.
|
|
|
5021
|
|
|
5022 `ebcdic'
|
|
|
5023 EBCDIC is an 8-bit character set that was an alternative to ASCII
|
|
|
5024 in 1972, and is the character set used by the original Princeton
|
|
|
5025 compiler. Unfortunately, there is no single standard version; the
|
|
|
5026 version of EBCDIC used by `convickt' is the one that CLC-INTERCAL
|
|
|
5027 uses. It is the default input character set that CLC-INTERCAL uses
|
|
|
5028 (although more recent versions of CLC-INTERCAL instead try to
|
|
|
5029 guess the input character set based on the input program.)
|
|
|
5030
|
|
|
5031 `baudot'
|
|
|
5032 Baudot is a 5-bit character set with shift codes; therefore when
|
|
|
5033 storing it in a file on an 8-bit computer, padding is needed to
|
|
|
5034 fill in the remaining three bits. The standard Baudot character
|
|
|
5035 set does not contain all the characters needed by INTERCAL;
|
|
|
5036 therefore, CLC-INTERCAL uses repeated shift codes to add two more
|
|
|
5037 sets of characters. `convickt' uses the CLC-INTERCAL version of
|
|
|
5038 Baudot, so as to be able to translate programs designed for that
|
|
|
5039 compiler; however, standard Baudot is also accepted in input if it
|
|
|
5040 contains no redundant shift codes, and if the input contains no
|
|
|
5041 characters not in standard Baudot, the output will be written so
|
|
|
5042 that it is both correct standard Baudot and correct CLC-INTERCAL
|
|
|
5043 Baudot for those characters.
|
|
|
5044
|
|
|
5045 `atari'
|
|
|
5046 This option causes `convickt' to attempt a limited conversion to
|
|
|
5047 or from Atari syntax; this uses ASCII-7 as the character set, but
|
|
|
5048 also tries to translate between Atari and Princeton syntax at the
|
|
|
5049 character level, which is sometimes but not always effective. For
|
|
|
5050 instance, `?' is translated from Atari to Princeton as a yen sign,
|
|
|
5051 and from Princeton to Atari as a whirlpool (`@'); this sort of
|
|
|
5052 behaviour is often capable of translating expressions
|
|
|
5053 automatically, but will fail when characters outside ASCII-7
|
|
|
5054 (Atari) or Latin-1 (Princeton) are used, and will not, for
|
|
|
5055 instance, translate a Princeton `V', backspace, `-' into Atari
|
|
|
5056 `?', but instead leave it untouched. ASCII-7 is a 7-bit character
|
|
|
5057 set, so on an 8 bit computer, there is one bit of padding that
|
|
|
5058 needs to be generated; note, however, that it is usual nowadays to
|
|
|
5059 clear the top bit when transmitting ASCII-7, which the `printable'
|
|
|
5060 and `zero' padding styles will do, but the `random' style may not
|
|
|
5061 do.
|
|
|
5062
|
|
|
5063
|
|
|
5064 When using a character set where not all bits in each byte are
|
|
|
5065 specified, a third argument can be given to specify what sort of
|
|
|
5066 padding to use for the top bits of each character. There are three
|
|
|
5067 options for this:
|
|
|
5068
|
|
|
5069 Option Meaning
|
|
|
5070 -----------------------------------------------------------------
|
|
|
5071 printable Keep the output in the range 32-126 where possible
|
|
|
5072 zero Zero the high bits in the output
|
|
|
5073 random Pad with random bits (avoiding all-zero bytes)
|
|
|
5074
|
|
|
5075 Note that not all conversions are possible. If a character cannot be
|
|
|
5076 converted, it will normally be converted to a NUL byte (which is
|
|
|
5077 invalid in every character set); note that this will prevent
|
|
|
5078 round-tripping, because NUL is interpreted as end-of-input if given in
|
|
|
5079 the input. There is one exception; if the character that could not be
|
|
|
5080 converted is a tab character, it will be converted to the other
|
|
|
5081 character set's representation of a space character, if possible,
|
|
|
5082 because the two characters have the same meaning in INTERCAL (the only
|
|
|
5083 difference is if the command is a syntax error that's printed as an
|
|
|
5084 error message). (The exception exists to make it possible to translate
|
|
|
5085 existing INTERCAL source code into Baudot.)
|
|
|
5086
|
|
|
5087 Appendix C Optimizer Idiom Language
|
|
|
5088 ***********************************
|
|
|
5089
|
|
|
5090 One file in the C-INTERCAL distribution (`src/idiotism.oil') is written
|
|
|
5091 in Optimizer Idiom Language, a programming language designed especially
|
|
|
5092 for expressing optimizer idioms for INTERCAL in an easily editable form
|
|
|
5093 (well, at least it's easier than the unmaintainable set of idioms
|
|
|
5094 hard-coded in C that were used in previous versions of the INTERCAL
|
|
|
5095 compiler).
|
|
|
5096
|
|
|
5097 C.1 OIL Basics
|
|
|
5098 ==============
|
|
|
5099
|
|
|
5100 The structure of an OIL file consists of a sequence of idioms. An
|
|
|
5101 optimizer idiom looks for a certain pattern in an expression (which
|
|
|
5102 could be an INTERCAL expression, or an expression that has already been
|
|
|
5103 partly optimized and therefore contains some non-INTERCAL operators),
|
|
|
5104 and replaces it with a replacement that's `simpler' in some sense (in
|
|
|
5105 the case of C-INTERCAL, `simpler' is interpreted to mean `compiles into
|
|
|
5106 a faster or smaller executable when run through a C compiler'). When an
|
|
|
5107 OIL program acts on an input INTERCAL file, it keeps on matching idioms
|
|
|
5108 to simplify expressions, until none of the idioms act any more (and if
|
|
|
5109 a situation occurs where idioms can keep matching indefinitely, the
|
|
|
5110 compiler goes into an infinite loop; so don't allow that to happen); at
|
|
|
5111 present, the idioms are tried from left to right, from the leaves of an
|
|
|
5112 expression to its root, and from the start of the OIL file to the end;
|
|
|
5113 but don't rely on that, because it's subject to change (and gets
|
|
|
5114 confusing when you think about what happens when the program actually
|
|
|
5115 does a replacement). Anyway, the point is that if an idiom can match
|
|
|
5116 an expression, and another idiom doesn't change it first, then the
|
|
|
5117 idiom will be matched against that part of the expression eventually,
|
|
|
5118 and the program won't end until there are no idioms that match the
|
|
|
5119 optimized expression.
|
|
|
5120
|
|
|
5121 At present, the only place that OIL is used in the C-INTERCAL compiler
|
|
|
5122 is when the `-O' option (*note -O: -O+.) is used in base 2. (Syntax is
|
|
|
5123 planned to extend OIL to higher bases, and some of this is documented
|
|
|
5124 and even implemented, but there's no way to use it.) The idioms are
|
|
|
5125 read from the file `src/idiotism.oil' during the compilation of the
|
|
|
5126 C-INTERCAL from sources; you can change the idioms, but you will then
|
|
|
5127 have to recompile the distribution (and if you are using the
|
|
|
5128 `config.sh' method, also reinstall, but that will be pretty fast.)
|
|
|
5129
|
|
|
5130 C.2 OIL Syntax
|
|
|
5131 ==============
|
|
|
5132
|
|
|
5133 An OIL file is encoded as an ASCII text file using no codepoints
|
|
|
5134 outside the range 0-127; using 10 for newline (as on a UNIX or Linux
|
|
|
5135 system) is always acceptable, but using 13 then 10 (as is common on
|
|
|
5136 Windows or DOS) for newline is acceptable only if your C compiler
|
|
|
5137 recognizes that as a newline. I have no idea what happens if you use
|
|
|
5138 just 13 on an Apple computer on which that is the common newline
|
|
|
5139 convention.
|
|
|
5140
|
|
|
5141 Comments can be given anywhere in the file by writing lines starting
|
|
|
5142 with semicolons (known as hybrids to INTERCAL programmers). It's also
|
|
|
5143 possible to write a semicolon after part of a line to comment out the
|
|
|
5144 rest of the line. Inside braced C expressions, comments can be given
|
|
|
5145 anywhere whitespace would be allowed by placing them between `/*' and
|
|
|
5146 `*/' (in such cases, the comments will be copied verbatim to the C
|
|
|
5147 temporary files used when building the C-INTERCAL compiler, where your
|
|
|
5148 C compiler will ignore them). Whitespace is ignored nearly everywhere;
|
|
|
5149 the only places it isn't ignored are in the middle of a decimal
|
|
|
5150 constant, inside square brackets, immediately after one of the
|
|
|
5151 characters `.:#_}', and anywhere that C doesn't allow it in quoted C
|
|
|
5152 code. (This means that you can even place it inside operators like &&
|
|
|
5153 if you like, as long as they're part of OIL code and not C code,
|
|
|
5154 although doing this is not recommended.) If you use whitespace in a
|
|
|
5155 situation where it isn't ignored, that's almost certainly an error.
|
|
|
5156
|
|
|
5157 Idioms are grouped into groups of idioms by placing an identifier in
|
|
|
5158 square brackets before the group; this follows the rules for C
|
|
|
5159 identifiers, except that there's a maximum length of 30 characters.
|
|
|
5160 This identifier is the `name' of the group, which has no effect except
|
|
|
5161 on optimizer debug output; for that matter, the only effect a group has
|
|
|
5162 is that all idioms in the group look the same in optimizer debug output,
|
|
|
5163 because they have the same name. It's recommended that idioms only have
|
|
|
5164 the same name if they are the same idiom, possibly written in several
|
|
|
5165 ways. For example, a shift by 0 has no effect and may as well be
|
|
|
5166 removed from the output; the way to express this in OIL is:
|
|
|
5167
|
|
|
5168 [nullshift]
|
|
|
5169 (_1 >> #0)->(_1)
|
|
|
5170 (_1 << #0)->(_1)
|
|
|
5171
|
|
|
5172 Here, nullshift is the name of the group of idioms, and two idioms are
|
|
|
5173 given; one which removes a null rightshift, and one which removes a null
|
|
|
5174 leftshift.
|
|
|
5175
|
|
|
5176 As the example above shows, the syntax of an idiom itself is
|
|
|
5177
|
|
|
5178 (pattern)->(replacement)
|
|
|
5179
|
|
|
5180 The parentheses here are actually part of the pattern and/or
|
|
|
5181 replacement, and as such sparks (apostrophes) or rabbit-ears (double
|
|
|
5182 quotes) can be used instead; they're shown in the syntax because the
|
|
|
5183 outer layer of parenthesising is always required. Both the pattern and
|
|
|
5184 replacement are OIL expressions, although they both have their own
|
|
|
5185 special syntax elements as well.
|
|
|
5186
|
|
|
5187 C.3 OIL Expressions
|
|
|
5188 ===================
|
|
|
5189
|
|
|
5190 An OIL expression is built around subexpressions connected by infix
|
|
|
5191 binary operators and/or preceded by prefix unary operators, the same
|
|
|
5192 way as in C or INTERCAL (although unary operators must be entirely
|
|
|
5193 before their argument; the one character later position is not allowed.)
|
|
|
5194 As in INTERCAL, there is no operator precedence; expressions must be
|
|
|
5195 very fully bracketed to show unambiguously what the precedences must
|
|
|
5196 be, and then more so; for instance, bracketing marks must be placed
|
|
|
5197 around the argument of a unary operator in most circumstances.
|
|
|
5198 Bracketing of expressions can be done with parentheses, sparks
|
|
|
5199 (apostrophes) or rabbit-ears (double-quotes).
|
|
|
5200
|
|
|
5201 The following unary and binary operators are allowed in OIL expressions:
|
|
|
5202
|
|
|
5203 `$' INTERCAL mingle
|
|
|
5204 `~' INTERCAL select
|
|
|
5205 `&16' INTERCAL unary AND (16-bit)
|
|
|
5206 `V16' INTERCAL unary OR (16-bit)
|
|
|
5207 `?16' INTERCAL unary XOR (16-bit)
|
|
|
5208 `^16' INTERCAL unary sharkfin (16-bit)
|
|
|
5209 `@16' INTERCAL unary whirlpool (16-bit)
|
|
|
5210 `@216..@516' INTERCAL unary generalised whirlpool (16-bit)
|
|
|
5211 `&32' INTERCAL unary AND (32-bit)
|
|
|
5212 `V32' INTERCAL unary OR (32-bit)
|
|
|
5213 `?32' INTERCAL unary XOR (32-bit)
|
|
|
5214 `^32' INTERCAL unary sharkfin (32-bit)
|
|
|
5215 `@32' INTERCAL unary whirlpool (32-bit)
|
|
|
5216 `@232..@532' INTERCAL unary generalised whirlpool (32-bit)
|
|
|
5217 `&' C binary bitwise AND
|
|
|
5218 `|' C binary bitwise OR
|
|
|
5219 `^' C binary bitwise XOR
|
|
|
5220 `+' C addition
|
|
|
5221 `-' C subtraction
|
|
|
5222 `*' C multiplication
|
|
|
5223 `/' C integer division
|
|
|
5224 `%' C modulus
|
|
|
5225 `>' C greater than
|
|
|
5226 `<' C less than
|
|
|
5227 `~' C unary bitwise complement
|
|
|
5228 `!=' C not equals operator
|
|
|
5229 `==' C equals operator
|
|
|
5230 `&&' C logical AND
|
|
|
5231 `||' C logical OR
|
|
|
5232 `>>' C bitwise rightshift
|
|
|
5233 `<<' C bitwise leftshift
|
|
|
5234 `!' C unary logical NOT
|
|
|
5235
|
|
|
5236 (Note that in some cases two operators are expressed the same way, but
|
|
|
5237 that this doesn't matter because one is unary and the other is binary so
|
|
|
5238 that there can't be any ambiguity, only confusion. Also note that
|
|
|
5239 unlike INTERCAL unary logic operators, OIL unary logic operators must
|
|
|
5240 have a bitwidth stated.)
|
|
|
5241
|
|
|
5242 It hasn't yet been explained what operands these operators have to
|
|
|
5243 operate on; the syntax for those depends on whether it's a pattern or
|
|
|
5244 replacement that the expression is representing.
|
|
|
5245
|
|
|
5246 C.4 OIL Patterns
|
|
|
5247 ================
|
|
|
5248
|
|
|
5249 Patterns are simply OIL expressions; the expressions match either
|
|
|
5250 original INTERCAL input or expressions produced by earlier idioms.
|
|
|
5251 Each operator must match the same operator in the (possibly
|
|
|
5252 partially-optimised) input; the operands themselves are pattern
|
|
|
5253 templates specifying what operands in the input they can match.
|
|
|
5254
|
|
|
5255 One special simple form of match is possible: `#NUMBER', where NUMBER
|
|
|
5256 is in decimal, matches a constant with that value. (Unlike in
|
|
|
5257 INTERCAL, this constant is not limited to being a onespot value; it is,
|
|
|
5258 however, limited to being at most twospot, as are all operands and
|
|
|
5259 intermediate values in OIL.)
|
|
|
5260
|
|
|
5261 Otherwise, an operand consists of the following parts, written in order:
|
|
|
5262
|
|
|
5263 1. A character to specify the data type of what's being matched.
|
|
|
5264 Usually, this will be `_' to specify that any data type can be
|
|
|
5265 matched. In a few cases, you may want to use `.' or `:' to
|
|
|
5266 specify that you only want to match a onespot or twospot value
|
|
|
5267 respectively (that is, 16- or 32-bit). You can also use `#'; this
|
|
|
5268 specifies a value that can be any width, but must be known to be a
|
|
|
5269 constant with a known value at optimize time (either because it
|
|
|
5270 was hardcoded as a constant originally or because a constant was
|
|
|
5271 produced there by the optimizer, for instance via a constant
|
|
|
5272 folding optimization).
|
|
|
5273
|
|
|
5274 2. Optionally, an expression in braces (`{' and `}'). This
|
|
|
5275 expression is written in C, not OIL (as are all expressions in
|
|
|
5276 braces), and puts an extra condition on whether the pattern
|
|
|
5277 matches. The exact meaning of this will be explained later.
|
|
|
5278
|
|
|
5279 3. A reference number, which must be one decimal digit long. A
|
|
|
5280 reference number of 0 causes the operand to be discarded
|
|
|
5281 immediately after matching; normally, you will want to specify a
|
|
|
5282 positive reference number. Two operands with the same reference
|
|
|
5283 number must be exactly the same for the pattern to match (for
|
|
|
5284 instance, both references to the same variable, or identical
|
|
|
5285 subexpressions). The reference number also allows the operand to
|
|
|
5286 be referenced by C expressions on other operands and by
|
|
|
5287 replacements. Reference numbers must be unique within the idiom
|
|
|
5288 (unless two or reference numbers are deliberately the same so that
|
|
|
5289 the operands they reference have to be identical to produce a
|
|
|
5290 match), and they are scoped only as far as the containing idiom;
|
|
|
5291 they don't carry from one idiom to another.
|
|
|
5292
|
|
|
5293
|
|
|
5294 Note that syntax like `#2' is ambiguous given what comes so far; the
|
|
|
5295 first interpretation is the one that is taken in practice, and if the
|
|
|
5296 second interpretation is wanted the operand should be expressed as
|
|
|
5297 `#{1}2', using a no-op braced expression to tell them apart. This
|
|
|
5298 particular no-op is recommended because it's detected and optimized by
|
|
|
5299 the `OIL' compiler.
|
|
|
5300
|
|
|
5301 Braced expressions, which must be written purely in C, add extra
|
|
|
5302 conditions; they must return nonzero to allow a possible match or zero
|
|
|
5303 to prevent one. They can reference the following variables and
|
|
|
5304 functions:
|
|
|
5305
|
|
|
5306 `c'
|
|
|
5307 `cNUMBER'
|
|
|
5308 This accesses a calculation made automatically by the compiled OIL
|
|
|
5309 program to identify which bits of the operand can possibly be set,
|
|
|
5310 and which ones cannot be. `c' by itself refers to the operand to
|
|
|
5311 which the braced expression is attached; if a number is given, it
|
|
|
5312 refers to another node (the number is interpreted as a reference
|
|
|
5313 number). The actual value of `c' is a 32-bit unsigned integer,
|
|
|
5314 each bit of which is true, or 1, if there is any chance that the
|
|
|
5315 corresponding bit of the operand might be 1, and false, or 0, if
|
|
|
5316 it's known for certain that the corresponding bit of the operand
|
|
|
5317 is 0.
|
|
|
5318
|
|
|
5319 For instance:
|
|
|
5320
|
|
|
5321 _{!(c&4294901760LU)}1
|
|
|
5322
|
|
|
5323 The constant given here is FFFF0000 when expressed in hexadecimal;
|
|
|
5324 the point is that the expression matches any operand that is known
|
|
|
5325 to have a value no greater than 65535. Unless the operand is the
|
|
|
5326 argument to a unary AND, this check generally makes more sense
|
|
|
5327 than explicitly specifying `.' rather than `_', because it will
|
|
|
5328 identify both 16- and 32-bit values as long as they're small
|
|
|
5329 enough to fit into a onespot variable. This code could, for
|
|
|
5330 instance, be used to check that an argument to a mingle must be
|
|
|
5331 small enough before optimising it (this is important because an
|
|
|
5332 optimisation shouldn't optimise an error - in this case, an
|
|
|
5333 overflowing mingle - into a non-error).
|
|
|
5334
|
|
|
5335 `x'
|
|
|
5336 `xNUMBER'
|
|
|
5337 `x' is like `c', and refers to operands in the same way, except
|
|
|
5338 that it can only refer to an operand marked with `#'. It holds
|
|
|
5339 the value of that constant (a 32-bit unsigned integer), which will
|
|
|
5340 be known to the optimizer at optimize time. One common use of
|
|
|
5341 this is to detect whether a constant happens to be a power of 2,
|
|
|
5342 although there are many other possibilities that may be useful.
|
|
|
5343
|
|
|
5344 `r'
|
|
|
5345 When inside a loop, `r' is the value of the loop counter. (It's
|
|
|
5346 almost certainly a mistake if you have a loop but don't reference
|
|
|
5347 the loop counter at least once, and usually at least twice, within
|
|
|
5348 the loop.) *Note OIL Loops::.
|
|
|
5349
|
|
|
5350 `and16'
|
|
|
5351 `and32'
|
|
|
5352 `or16'
|
|
|
5353 `or32'
|
|
|
5354 `xor16'
|
|
|
5355 `xor32'
|
|
|
5356 `iselect'
|
|
|
5357 `mingle'
|
|
|
5358 These are all functions with one argument (apart from iselect and
|
|
|
5359 mingle, which each take two arguments); they exist so that INTERCAL
|
|
|
5360 operators can be used by C expressions. They all take unsigned
|
|
|
5361 longs as input and output, even if they are onespot operators.
|
|
|
5362 Note that it's entirely possible for these to cause a compile-time
|
|
|
5363 error if used on invalid arguments (such as mingling with an
|
|
|
5364 operand over 65535), or to silently truncate an invalid argument
|
|
|
5365 down to the right number of bits; both of these should be avoided
|
|
|
5366 if possible, so the optimiser should check first to make sure that
|
|
|
5367 it doesn't use any of these functions on invalid arguments.
|
|
|
5368
|
|
|
5369 `xselx'
|
|
|
5370 This function returns its argument selected with itself; so
|
|
|
5371 `xselx(c)' is shorthand for `iselect(c,c)'. When the argument is
|
|
|
5372 very complicated, this can save a lot of space in the original OIL
|
|
|
5373 program.
|
|
|
5374
|
|
|
5375 `setbitcount'
|
|
|
5376 This function simply returns the number of bits with value 1 in its
|
|
|
5377 argument. This is sometimes useful with respect to various
|
|
|
5378 select-related optimisations, and can be a useful alternative to
|
|
|
5379 having to take logarithms in various situations.
|
|
|
5380
|
|
|
5381 `smudgeright'
|
|
|
5382 `smudgeleft'
|
|
|
5383 The `smudgeright' function returns its argument but with all the
|
|
|
5384 bits less significant than the most significant bit with value 1
|
|
|
5385 set to 1; likewise, `smudgeleft' returns its argument with all the
|
|
|
5386 bits more significant than the least significant bit with value 1
|
|
|
5387 set to 1.
|
|
|
5388
|
|
|
5389
|
|
|
5390 Note that all OIL character is done internally using unsigned 32-bit
|
|
|
5391 numbers, and C expressions you write should do the same. The practical
|
|
|
5392 upshot of this is that you should write `LU' after any constant you
|
|
|
5393 write in C code; if you don't do this, you are reasonably likely to get
|
|
|
5394 compiler warnings, and the resulting program may not work reliably,
|
|
|
5395 although the OIL compiler itself will not complain.
|
|
|
5396
|
|
|
5397 Here's a more complicated example of an optimizer operand:
|
|
|
5398
|
|
|
5399 #{!(x&2863311530LU)&&iselect(x,1431655765LU)==
|
|
|
5400 xselx(iselect(x,1431655765LU))}3
|
|
|
5401
|
|
|
5402 It helps to understand this if you know that 2863311530 in hexadecimal
|
|
|
5403 is AAAAAAAA and 1431655765 in hexadecimal is 55555555. (It's worth
|
|
|
5404 putting a comment with some frequently-used decimal constants in an OIL
|
|
|
5405 input file to help explain what these numbers mean and make the code
|
|
|
5406 more maintainable.) The operand matches any constant integer which has
|
|
|
5407 no bits in common with AAAAAAAA, and for which if any bit in common
|
|
|
5408 with 55555555 is set, all less significant bits in common with that
|
|
|
5409 number are also set.
|
|
|
5410
|
|
|
5411 C.5 OIL Replacements
|
|
|
5412 ====================
|
|
|
5413
|
|
|
5414 Replacements have much the same syntax as patterns. The expressions are
|
|
|
5415 parsed in much the same way; however, one peculiarity of replacements is
|
|
|
5416 that bitwidths must be specified. INTERCAL has a typecaster that
|
|
|
5417 figures out whether each expression is 16 bits or 32 bits wide, but it
|
|
|
5418 runs before the optimizer, and as the optimizer can produce expressions
|
|
|
5419 whose bitwidths don't obey INTERCAL's rules, this information needs to
|
|
|
5420 be inserted somehow in a replacement. In C-INTERCAL, it usually
|
|
|
5421 doesn't matter what the bitwidth is, and in cases where it doesn't
|
|
|
5422 matter the normal operators (`$', `~', and so on) can be used. (Note
|
|
|
5423 that the bit width of the entire replacement is always set to the same
|
|
|
5424 bit width as the bit width of the expression matched by the pattern; so
|
|
|
5425 you don't have to worry about the effect on unary logical operators
|
|
|
5426 that might be operating on the expression being optimized. This is an
|
|
|
5427 exception to the normal bitwidth rules for a replacement.) In cases
|
|
|
5428 where it does matter (due to C-INTERCAL's lenient interpretation of
|
|
|
5429 bitwidth on mingle inputs, the only place it matters is in the input to
|
|
|
5430 INTERCAL unary logical operators), both the bitwidth of the operator
|
|
|
5431 and the argument on which it operates must be explicitly given, and
|
|
|
5432 given as the same value; to set the bitwidth of an operator's result,
|
|
|
5433 simply write the bitwidth (16 or 32 for onespot and twospot
|
|
|
5434 respectively) immediately after the operator; for instance, `!=32' will
|
|
|
5435 generate a not-equals operation with a 32-bit bitwidth. If an
|
|
|
5436 operator's width is set to 16, and during the course of execution of
|
|
|
5437 the optimized program, a value that doesn't fit into 16 bits is
|
|
|
5438 encountered, that's undefined behaviour and anything might happen (most
|
|
|
5439 likely, though, the program will just act as though its width had been
|
|
|
5440 set to 32 bits instead); this error condition is not detected. Also
|
|
|
5441 note that operators like `&32' already have a bitwidth specified, so
|
|
|
5442 specifying `&3232' (or worse, `&3216') is not allowed.
|
|
|
5443
|
|
|
5444 Replacement operands are simpler than pattern operands, because there
|
|
|
5445 are only a few forms they can take.
|
|
|
5446
|
|
|
5447 `_NUMBER'
|
|
|
5448 `.NUMBER'
|
|
|
5449 `:NUMBER'
|
|
|
5450 This tells the optimiser to copy the operand or expression with
|
|
|
5451 reference number NUMBER to this point in the replacement used for
|
|
|
5452 the expression matched by the pattern. The three forms are
|
|
|
5453 identical; the last two are provided for aesthetic reasons (it can
|
|
|
5454 look better and be clearer to match `.1' in the pattern with `.1'
|
|
|
5455 in the replacement, for instance). You cannot use `#NUMBER' here
|
|
|
5456 to copy in a constant from the left-hand side, though, nor
|
|
|
5457 `#{1}NUMBER', because the first means something else and the
|
|
|
5458 second is undefined behaviour (that is, no behaviour for the second
|
|
|
5459 case has been specifically implemented in the compiler and
|
|
|
5460 therefore its behaviour is unpredictable and subject to change in
|
|
|
5461 future versions); use `_NUMBER' to copy over a constant with an
|
|
|
5462 unknown at optimizer compile time (but known at optimize time)
|
|
|
5463 value from the left hand side, as you can do with any other
|
|
|
5464 operand being copied.
|
|
|
5465
|
|
|
5466 `#NUMBER'
|
|
|
5467 Insert a constant with the literal value NUMBER here.
|
|
|
5468
|
|
|
5469 `#{EXPRESSION}0'
|
|
|
5470 Calculate the value of EXPRESSION (a C expression, which can
|
|
|
5471 reference the same variables and functions as a C expression in a
|
|
|
5472 pattern can; see *note C functions in OIL::) and insert a constant
|
|
|
5473 with the calculated value here. (That is, a value is calculated at
|
|
|
5474 optimise-time and the resulting value is therefore constant at
|
|
|
5475 runtime.)
|
|
|
5476
|
|
|
5477
|
|
|
5478 As an example, here's an idiom that moves C bitwise AND operations
|
|
|
5479 inside leftshifts. (This is useful because if the optimizer has
|
|
|
5480 generated a large sequence of mixed ANDs and bitshifts, moving all the
|
|
|
5481 ANDs to one end allows them to be clumped together and optimized down to
|
|
|
5482 one AND, whilst the shifts can all be combined into one large shift.)
|
|
|
5483
|
|
|
5484 ((_1 << #{1}2) & #{1}3)->((_1 & #{x3>>x2}0) << _2)
|
|
|
5485
|
|
|
5486 C.6 OIL Loops
|
|
|
5487 =============
|
|
|
5488
|
|
|
5489 When writing idioms, sometimes instead of using very complicated
|
|
|
5490 expressions to try to match multiple situations at once it's easier to
|
|
|
5491 have a separate idiom for each possible situation; for instance, it's
|
|
|
5492 easier to write idioms for right-shift by 1, right-shift by 2,
|
|
|
5493 right-shift by 3, etc., rather than a general idiom to rightshift by any
|
|
|
5494 amount. When the idioms follow a pattern, as they will do in basically
|
|
|
5495 every case of this sort, it's possible to automatically generate them
|
|
|
5496 using a loop. For instance, idioms to optimize a one-bit rightshift
|
|
|
5497 and a two-bit rightshift are:
|
|
|
5498
|
|
|
5499 (_1~#{xselx(x)<<1==x&&x}2)->((_1&_2)>>#1)
|
|
|
5500 (_1~#{xselx(x)<<2==x&&x}2)->((_1&_2)>>#2)
|
|
|
5501
|
|
|
5502 Adding a loop to automatically generate the idioms, and placing a name
|
|
|
5503 for the group of idioms at the start, produces the following code:
|
|
|
5504
|
|
|
5505 [rshift]
|
|
|
5506 <#1-#31
|
|
|
5507 (_1~#{xselx(x)<<r==x&&x}2)->((_1&_2)>>#{r}0)
|
|
|
5508 >
|
|
|
5509
|
|
|
5510 That's 31 different idioms, generated with a loop. As the above example
|
|
|
5511 shows, a loop starts with `<#NUMBER-#NUMBER' and ends with `>'; a
|
|
|
5512 different idiom is generated for each possible value of the loop
|
|
|
5513 counter `r' in the range given by the opening line of the loop. Loops
|
|
|
5514 must be placed around idioms, but inside a group of idioms. Note the
|
|
|
5515 use of `#{r}0' to generate a constant whose value is equal to the value
|
|
|
5516 of the loop counter.
|
|
|
5517
|
|
|
5518 C.7 OIL Tips
|
|
|
5519 ============
|
|
|
5520
|
|
|
5521 Here are some tips for the best use of OIL:
|
|
|
5522
|
|
|
5523 * The OIL compiler has a few deficiencies, such as error messages
|
|
|
5524 that don't give you much of an idea of what you did wrong (to
|
|
|
5525 compensate for this, it does give a reasonably accurate line and
|
|
|
5526 character number where the error happened), limits on things like
|
|
|
5527 how deep expressions can be nested and how many idioms are allowed
|
|
|
5528 (if you hit the first, you should really break it up into smaller
|
|
|
5529 idioms if possible, and if you hit the second, increase
|
|
|
5530 `MAXTOFREE' in oil.y; this isn't a limit on the number of idioms
|
|
|
5531 but on the number of strings that are allocated internally to
|
|
|
5532 process the idioms), and lack of error checking (invalid OIL may
|
|
|
5533 produce errors in the OIL compiler, or cause the output C code to
|
|
|
5534 contain errors or warnings, or may even appear to work).
|
|
|
5535
|
|
|
5536 * When you have symmetrical operators in an idiom (like C binary
|
|
|
5537 logical operators), you need to write the idiom both ways round
|
|
|
5538 (in the same group of idioms, preferably), or write another idiom
|
|
|
5539 to standardise the format first; the first method can get very
|
|
|
5540 tedious when there are many symmetrical operators in an idiom, and
|
|
|
5541 the second is prone to optimizer loops and subtle errors (both
|
|
|
5542 methods have been used in the provided `idiotism.oil' file.)
|
|
|
5543
|
|
|
5544 * Idioms should preferably be as general as possible, broken down
|
|
|
5545 into many separate idioms rather than all as one big idiom, and
|
|
|
5546 match the smallest part of the expression being optimized that is
|
|
|
5547 necessary for the idiom to be correct in all circumstances; all of
|
|
|
5548 these help to improve the performance of the optimizer in terms of
|
|
|
5549 what it can optimize.
|
|
|
5550
|
|
|
5551 * If a program's optimizing incorrectly, or you just want to see how
|
|
|
5552 the optimizer deals with a particular program, it's possible to
|
|
|
5553 debug the optimizer by giving the `-h', `-H', or `-hH' (*note
|
|
|
5554 -h::) switch to the C-INTERCAL compiler, which will cause debug
|
|
|
5555 information to be output on stderr. `-h' will show the initial
|
|
|
5556 and final expressions for each expression that was given as input
|
|
|
5557 to the optimizer, as well as a list of all optimizations used, in
|
|
|
5558 a language that's a sort of mix of C, INTERCAL, and OIL; `-H' will
|
|
|
5559 do the same, and also show the intermediate stages in the
|
|
|
5560 optimization. `-hH' is like `-H', but produces its output
|
|
|
5561 entirely in C, so that the various intermediate stages can be
|
|
|
5562 tried with a C compiler, or for people who are fed up of reading
|
|
|
5563 INTERCAL. `-H' can be a useful learning resource for people who
|
|
|
5564 want to understand how a particular INTERCAL expression works.
|
|
|
5565
|
|
|
5566 * Make sure that the optimizer doesn't change a statement from a
|
|
|
5567 run-time error into something that silently succeeds! Checking
|
|
|
5568 which bits can and can't be 1 is one good way to avoid this,
|
|
|
5569 especially with mingles. (At present, there are some idioms that
|
|
|
5570 can turn run-time errors into compile-time errors, such as with
|
|
|
5571 the expression `''#65535$#65535'$#0''; this could be avoided, but
|
|
|
5572 for the time being it isn't.)
|
|
|
5573
|
|
|
5574 * You can help! If you find an idiom that the optimizer isn't
|
|
|
5575 optimizing correctly, feel free to add it, or multiple idioms that
|
|
|
5576 come to the same thing, to `idiotism.oil'. In such a case, it
|
|
|
5577 would help other users if you would submit your new optimizer
|
|
|
5578 idiom to the project (*note Reporting Bugs::); this will help
|
|
|
5579 other users and future releases of INTERCAL, and also has a chance
|
|
|
5580 of allowing other users to check your new idioms to see if they
|
|
|
5581 cause problems or could be written better.
|
|
|
5582
|
|
|
5583
|
|
|
5584 C.8 OIL Example
|
|
|
5585 ===============
|
|
|
5586
|
|
|
5587 To finish off this appendix, here's an example of the power of OIL;
|
|
|
5588 this is the optimization of an idiom from the INTERCAL-72 system
|
|
|
5589 library, as shown with `-H'; this should give a good idea of how OIL
|
|
|
5590 programs work. (All the relevant idioms are in `idiotism.oil' as of
|
|
|
5591 the time of writing.) Note how the expression is reduced one small
|
|
|
5592 step at a time; the smallness of the steps makes the optimizer more
|
|
|
5593 general, because if the original expression had been slightly
|
|
|
5594 different, the optimizer wouldn't have come to the same result but
|
|
|
5595 could have optimized it quite a bit of the way, up to the point where
|
|
|
5596 the optimizations were no longer valid; in an older version of
|
|
|
5597 INTERCAL, this idiom was simply hardcoded as a special case and so
|
|
|
5598 slight variations of it weren't optimized at all. If you look at the
|
|
|
5599 idioms themselves, it'll also be apparent how `c' (the record of which
|
|
|
5600 bits of an expression can be 1 and which bits can't be) is important
|
|
|
5601 information in being able to apply an optimization more aggressively.
|
|
|
5602
|
|
|
5603 .3 <- ((((((((.3 $ 0x0) ~ (0x7fff $ 0x1)) $ 0x0) ~ (0x7fff $ 0x1))
|
|
|
5604 $ 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5605 [minglefold]
|
|
|
5606 .3 <- ((((((((.3 $ 0x0) ~ 0x2aaaaaab) $ 0x0) ~ (0x7fff $ 0x1)) $
|
|
|
5607 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5608 [lshift16]
|
|
|
5609 .3 <- ((((((((((.3 >> 0x0) & 0x7fff) << 0x1) | 0x0) $ 0x0) ~
|
|
|
5610 (0x7fff $ 0x1)) $ 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5611 [noopor]
|
|
|
5612 .3 <- (((((((((.3 >> 0x0) & 0x7fff) << 0x1) $ 0x0) ~ (0x7fff $
|
|
|
5613 0x1)) $ 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5614 [minglefold]
|
|
|
5615 .3 <- (((((((((.3 >> 0x0) & 0x7fff) << 0x1) $ 0x0) ~ 0x2aaaaaab) $
|
|
|
5616 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5617 [lshift16]
|
|
|
5618 .3 <- (((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff) <<
|
|
|
5619 0x1) | 0x0) $ 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5620 [noopor]
|
|
|
5621 .3 <- ((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff) <<
|
|
|
5622 0x1) $ 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5623 [minglefold]
|
|
|
5624 .3 <- ((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff) <<
|
|
|
5625 0x1) $ 0x0) ~ 0xaaaaaaf) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5626 [lshift16]
|
|
|
5627 .3 <- ((((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff)
|
|
|
5628 << 0x1) >> 0x1) & 0x1fff) << 0x3) | 0x0) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5629 [noopor]
|
|
|
5630 .3 <- (((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff) <<
|
|
|
5631 0x1) >> 0x1) & 0x1fff) << 0x3) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5632 [minglefold]
|
|
|
5633 .3 <- (((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff) <<
|
|
|
5634 0x1) >> 0x1) & 0x1fff) << 0x3) $ 0x0) ~ 0xaaaaff)
|
|
|
5635 [lshift16]
|
|
|
5636 .3 <- (((((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff)
|
|
|
5637 << 0x1) >> 0x1) & 0x1fff) << 0x3) >> 0x3) & 0x1ff) << 0x7) | 0x0)
|
|
|
5638 [noopor]
|
|
|
5639 .3 <- ((((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff)
|
|
|
5640 << 0x1) >> 0x1) & 0x1fff) << 0x3) >> 0x3) & 0x1ff) << 0x7)
|
|
|
5641 [nullshift]
|
|
|
5642 .3 <- (((((((((((.3 & 0x7fff) << 0x1) >> 0x0) & 0x7fff) << 0x1) >>
|
|
|
5643 0x1) & 0x1fff) << 0x3) >> 0x3) & 0x1ff) << 0x7)
|
|
|
5644 [combinelrshift]
|
|
|
5645 .3 <- ((((((((((.3 & 0x7fff) << 0x1) & 0x7fff) << 0x1) >> 0x1) &
|
|
|
5646 0x1fff) << 0x3) >> 0x3) & 0x1ff) << 0x7)
|
|
|
5647 [andintolshift]
|
|
|
5648 .3 <- ((((((((((.3 & 0x7fff) & 0x3fff) << 0x1) << 0x1) >> 0x1) &
|
|
|
5649 0x1fff) << 0x3) >> 0x3) & 0x1ff) << 0x7)
|
|
|
5650 [combinellshift]
|
|
|
5651 .3 <- (((((((((.3 & 0x7fff) & 0x3fff) << 0x2) >> 0x1) & 0x1fff) <<
|
|
|
5652 0x3) >> 0x3) & 0x1ff) << 0x7)
|
|
|
5653 [combinelrshift]
|
|
|
5654 .3 <- ((((((((.3 & 0x7fff) & 0x3fff) << 0x1) & 0x1fff) << 0x3) >>
|
|
|
5655 0x3) & 0x1ff) << 0x7)
|
|
|
5656 [andintolshift]
|
|
|
5657 .3 <- ((((((((.3 & 0x7fff) & 0x3fff) & 0xfff) << 0x1) << 0x3) >>
|
|
|
5658 0x3) & 0x1ff) << 0x7)
|
|
|
5659 [combinellshift]
|
|
|
5660 .3 <- (((((((.3 & 0x7fff) & 0x3fff) & 0xfff) << 0x4) >> 0x3) &
|
|
|
5661 0x1ff) << 0x7)
|
|
|
5662 [combinelrshift]
|
|
|
5663 .3 <- ((((((.3 & 0x7fff) & 0x3fff) & 0xfff) << 0x1) & 0x1ff) <<
|
|
|
5664 0x7)
|
|
|
5665 [andintolshift]
|
|
|
5666 .3 <- ((((((.3 & 0x7fff) & 0x3fff) & 0xfff) & 0xff) << 0x1) << 0x7)
|
|
|
5667 [combinellshift]
|
|
|
5668 .3 <- (((((.3 & 0x7fff) & 0x3fff) & 0xfff) & 0xff) << 0x8)
|
|
|
5669 [combineand]
|
|
|
5670 .3 <- ((((.3 & 0x3fff) & 0xfff) & 0xff) << 0x8)
|
|
|
5671 [combineand]
|
|
|
5672 .3 <- (((.3 & 0xfff) & 0xff) << 0x8)
|
|
|
5673 [combineand]
|
|
|
5674 .3 <- ((.3 & 0xff) << 0x8)
|
|
|
5675
|
|
|
5676 Appendix D Copying
|
|
|
5677 ******************
|
|
|
5678
|
|
|
5679 The majority of the files in the C-INTERCAL distribution are licensed
|
|
|
5680 under the GNU General Public License (version 2 or later), but with
|
|
|
5681 some exceptions. The files `ick-wrap.c' and `pickwrap.c' are licensed
|
|
|
5682 under a license that allows them to be used for any purpose and
|
|
|
5683 redistributed at will, and are explicitly not GPL'd. This means that C
|
|
|
5684 source code generated by the compiler has the same copyright conditions
|
|
|
5685 as the original INTERCAL source. (Note that the libraries `libick.a'
|
|
|
5686 and `libickmt.a' are GPL, though, so you cannot redistribute an
|
|
|
5687 executable produced by `ick' or by linking a C file to either of those
|
|
|
5688 libraries unless the original INTERCAL source was GPL.) For similar
|
|
|
5689 reasons, the expansion libraries `syslibc.c' and `compunex.c'
|
|
|
5690 (currently the only ones in the distribution) is explicitly public
|
|
|
5691 domain. Also, this manual, and the files that are the source code for
|
|
|
5692 creating it, are licensed under the GNU Free Documentation License
|
|
|
5693 rather than the GPL, and the licenses themselves (`fdl-1-2.txi' and
|
|
|
5694 `COPYING.txt') are licensed under a license that allows verbatim
|
|
|
5695 redistribution but not creation of derivative works. All other files,
|
|
|
5696 though (including the `man' pages, which are not part of _this_
|
|
|
5697 manual), are licensed under the GPL. For the full text of the GPL, see
|
|
|
5698 the file `COPYING.txt' in the distribution.
|
|
|
5699
|
|
|
5700 D.1 GNU Free Documentation License
|
|
|
5701 ==================================
|
|
|
5702
|
|
|
5703 Version 1.2, November 2002
|
|
|
5704
|
|
|
5705 Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
|
|
|
5706 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
|
|
|
5707
|
|
|
5708 Everyone is permitted to copy and distribute verbatim copies
|
|
|
5709 of this license document, but changing it is not allowed.
|
|
|
5710
|
|
|
5711 0. PREAMBLE
|
|
|
5712
|
|
|
5713 The purpose of this License is to make a manual, textbook, or other
|
|
|
5714 functional and useful document "free" in the sense of freedom: to
|
|
|
5715 assure everyone the effective freedom to copy and redistribute it,
|
|
|
5716 with or without modifying it, either commercially or
|
|
|
5717 noncommercially. Secondarily, this License preserves for the
|
|
|
5718 author and publisher a way to get credit for their work, while not
|
|
|
5719 being considered responsible for modifications made by others.
|
|
|
5720
|
|
|
5721 This License is a kind of "copyleft", which means that derivative
|
|
|
5722 works of the document must themselves be free in the same sense.
|
|
|
5723 It complements the GNU General Public License, which is a copyleft
|
|
|
5724 license designed for free software.
|
|
|
5725
|
|
|
5726 We have designed this License in order to use it for manuals for
|
|
|
5727 free software, because free software needs free documentation: a
|
|
|
5728 free program should come with manuals providing the same freedoms
|
|
|
5729 that the software does. But this License is not limited to
|
|
|
5730 software manuals; it can be used for any textual work, regardless
|
|
|
5731 of subject matter or whether it is published as a printed book.
|
|
|
5732 We recommend this License principally for works whose purpose is
|
|
|
5733 instruction or reference.
|
|
|
5734
|
|
|
5735 1. APPLICABILITY AND DEFINITIONS
|
|
|
5736
|
|
|
5737 This License applies to any manual or other work, in any medium,
|
|
|
5738 that contains a notice placed by the copyright holder saying it
|
|
|
5739 can be distributed under the terms of this License. Such a notice
|
|
|
5740 grants a world-wide, royalty-free license, unlimited in duration,
|
|
|
5741 to use that work under the conditions stated herein. The
|
|
|
5742 "Document", below, refers to any such manual or work. Any member
|
|
|
5743 of the public is a licensee, and is addressed as "you". You
|
|
|
5744 accept the license if you copy, modify or distribute the work in a
|
|
|
5745 way requiring permission under copyright law.
|
|
|
5746
|
|
|
5747 A "Modified Version" of the Document means any work containing the
|
|
|
5748 Document or a portion of it, either copied verbatim, or with
|
|
|
5749 modifications and/or translated into another language.
|
|
|
5750
|
|
|
5751 A "Secondary Section" is a named appendix or a front-matter section
|
|
|
5752 of the Document that deals exclusively with the relationship of the
|
|
|
5753 publishers or authors of the Document to the Document's overall
|
|
|
5754 subject (or to related matters) and contains nothing that could
|
|
|
5755 fall directly within that overall subject. (Thus, if the Document
|
|
|
5756 is in part a textbook of mathematics, a Secondary Section may not
|
|
|
5757 explain any mathematics.) The relationship could be a matter of
|
|
|
5758 historical connection with the subject or with related matters, or
|
|
|
5759 of legal, commercial, philosophical, ethical or political position
|
|
|
5760 regarding them.
|
|
|
5761
|
|
|
5762 The "Invariant Sections" are certain Secondary Sections whose
|
|
|
5763 titles are designated, as being those of Invariant Sections, in
|
|
|
5764 the notice that says that the Document is released under this
|
|
|
5765 License. If a section does not fit the above definition of
|
|
|
5766 Secondary then it is not allowed to be designated as Invariant.
|
|
|
5767 The Document may contain zero Invariant Sections. If the Document
|
|
|
5768 does not identify any Invariant Sections then there are none.
|
|
|
5769
|
|
|
5770 The "Cover Texts" are certain short passages of text that are
|
|
|
5771 listed, as Front-Cover Texts or Back-Cover Texts, in the notice
|
|
|
5772 that says that the Document is released under this License. A
|
|
|
5773 Front-Cover Text may be at most 5 words, and a Back-Cover Text may
|
|
|
5774 be at most 25 words.
|
|
|
5775
|
|
|
5776 A "Transparent" copy of the Document means a machine-readable copy,
|
|
|
5777 represented in a format whose specification is available to the
|
|
|
5778 general public, that is suitable for revising the document
|
|
|
5779 straightforwardly with generic text editors or (for images
|
|
|
5780 composed of pixels) generic paint programs or (for drawings) some
|
|
|
5781 widely available drawing editor, and that is suitable for input to
|
|
|
5782 text formatters or for automatic translation to a variety of
|
|
|
5783 formats suitable for input to text formatters. A copy made in an
|
|
|
5784 otherwise Transparent file format whose markup, or absence of
|
|
|
5785 markup, has been arranged to thwart or discourage subsequent
|
|
|
5786 modification by readers is not Transparent. An image format is
|
|
|
5787 not Transparent if used for any substantial amount of text. A
|
|
|
5788 copy that is not "Transparent" is called "Opaque".
|
|
|
5789
|
|
|
5790 Examples of suitable formats for Transparent copies include plain
|
|
|
5791 ASCII without markup, Texinfo input format, LaTeX input format,
|
|
|
5792 SGML or XML using a publicly available DTD, and
|
|
|
5793 standard-conforming simple HTML, PostScript or PDF designed for
|
|
|
5794 human modification. Examples of transparent image formats include
|
|
|
5795 PNG, XCF and JPG. Opaque formats include proprietary formats that
|
|
|
5796 can be read and edited only by proprietary word processors, SGML or
|
|
|
5797 XML for which the DTD and/or processing tools are not generally
|
|
|
5798 available, and the machine-generated HTML, PostScript or PDF
|
|
|
5799 produced by some word processors for output purposes only.
|
|
|
5800
|
|
|
5801 The "Title Page" means, for a printed book, the title page itself,
|
|
|
5802 plus such following pages as are needed to hold, legibly, the
|
|
|
5803 material this License requires to appear in the title page. For
|
|
|
5804 works in formats which do not have any title page as such, "Title
|
|
|
5805 Page" means the text near the most prominent appearance of the
|
|
|
5806 work's title, preceding the beginning of the body of the text.
|
|
|
5807
|
|
|
5808 A section "Entitled XYZ" means a named subunit of the Document
|
|
|
5809 whose title either is precisely XYZ or contains XYZ in parentheses
|
|
|
5810 following text that translates XYZ in another language. (Here XYZ
|
|
|
5811 stands for a specific section name mentioned below, such as
|
|
|
5812 "Acknowledgements", "Dedications", "Endorsements", or "History".)
|
|
|
5813 To "Preserve the Title" of such a section when you modify the
|
|
|
5814 Document means that it remains a section "Entitled XYZ" according
|
|
|
5815 to this definition.
|
|
|
5816
|
|
|
5817 The Document may include Warranty Disclaimers next to the notice
|
|
|
5818 which states that this License applies to the Document. These
|
|
|
5819 Warranty Disclaimers are considered to be included by reference in
|
|
|
5820 this License, but only as regards disclaiming warranties: any other
|
|
|
5821 implication that these Warranty Disclaimers may have is void and
|
|
|
5822 has no effect on the meaning of this License.
|
|
|
5823
|
|
|
5824 2. VERBATIM COPYING
|
|
|
5825
|
|
|
5826 You may copy and distribute the Document in any medium, either
|
|
|
5827 commercially or noncommercially, provided that this License, the
|
|
|
5828 copyright notices, and the license notice saying this License
|
|
|
5829 applies to the Document are reproduced in all copies, and that you
|
|
|
5830 add no other conditions whatsoever to those of this License. You
|
|
|
5831 may not use technical measures to obstruct or control the reading
|
|
|
5832 or further copying of the copies you make or distribute. However,
|
|
|
5833 you may accept compensation in exchange for copies. If you
|
|
|
5834 distribute a large enough number of copies you must also follow
|
|
|
5835 the conditions in section 3.
|
|
|
5836
|
|
|
5837 You may also lend copies, under the same conditions stated above,
|
|
|
5838 and you may publicly display copies.
|
|
|
5839
|
|
|
5840 3. COPYING IN QUANTITY
|
|
|
5841
|
|
|
5842 If you publish printed copies (or copies in media that commonly
|
|
|
5843 have printed covers) of the Document, numbering more than 100, and
|
|
|
5844 the Document's license notice requires Cover Texts, you must
|
|
|
5845 enclose the copies in covers that carry, clearly and legibly, all
|
|
|
5846 these Cover Texts: Front-Cover Texts on the front cover, and
|
|
|
5847 Back-Cover Texts on the back cover. Both covers must also clearly
|
|
|
5848 and legibly identify you as the publisher of these copies. The
|
|
|
5849 front cover must present the full title with all words of the
|
|
|
5850 title equally prominent and visible. You may add other material
|
|
|
5851 on the covers in addition. Copying with changes limited to the
|
|
|
5852 covers, as long as they preserve the title of the Document and
|
|
|
5853 satisfy these conditions, can be treated as verbatim copying in
|
|
|
5854 other respects.
|
|
|
5855
|
|
|
5856 If the required texts for either cover are too voluminous to fit
|
|
|
5857 legibly, you should put the first ones listed (as many as fit
|
|
|
5858 reasonably) on the actual cover, and continue the rest onto
|
|
|
5859 adjacent pages.
|
|
|
5860
|
|
|
5861 If you publish or distribute Opaque copies of the Document
|
|
|
5862 numbering more than 100, you must either include a
|
|
|
5863 machine-readable Transparent copy along with each Opaque copy, or
|
|
|
5864 state in or with each Opaque copy a computer-network location from
|
|
|
5865 which the general network-using public has access to download
|
|
|
5866 using public-standard network protocols a complete Transparent
|
|
|
5867 copy of the Document, free of added material. If you use the
|
|
|
5868 latter option, you must take reasonably prudent steps, when you
|
|
|
5869 begin distribution of Opaque copies in quantity, to ensure that
|
|
|
5870 this Transparent copy will remain thus accessible at the stated
|
|
|
5871 location until at least one year after the last time you
|
|
|
5872 distribute an Opaque copy (directly or through your agents or
|
|
|
5873 retailers) of that edition to the public.
|
|
|
5874
|
|
|
5875 It is requested, but not required, that you contact the authors of
|
|
|
5876 the Document well before redistributing any large number of
|
|
|
5877 copies, to give them a chance to provide you with an updated
|
|
|
5878 version of the Document.
|
|
|
5879
|
|
|
5880 4. MODIFICATIONS
|
|
|
5881
|
|
|
5882 You may copy and distribute a Modified Version of the Document
|
|
|
5883 under the conditions of sections 2 and 3 above, provided that you
|
|
|
5884 release the Modified Version under precisely this License, with
|
|
|
5885 the Modified Version filling the role of the Document, thus
|
|
|
5886 licensing distribution and modification of the Modified Version to
|
|
|
5887 whoever possesses a copy of it. In addition, you must do these
|
|
|
5888 things in the Modified Version:
|
|
|
5889
|
|
|
5890 A. Use in the Title Page (and on the covers, if any) a title
|
|
|
5891 distinct from that of the Document, and from those of
|
|
|
5892 previous versions (which should, if there were any, be listed
|
|
|
5893 in the History section of the Document). You may use the
|
|
|
5894 same title as a previous version if the original publisher of
|
|
|
5895 that version gives permission.
|
|
|
5896
|
|
|
5897 B. List on the Title Page, as authors, one or more persons or
|
|
|
5898 entities responsible for authorship of the modifications in
|
|
|
5899 the Modified Version, together with at least five of the
|
|
|
5900 principal authors of the Document (all of its principal
|
|
|
5901 authors, if it has fewer than five), unless they release you
|
|
|
5902 from this requirement.
|
|
|
5903
|
|
|
5904 C. State on the Title page the name of the publisher of the
|
|
|
5905 Modified Version, as the publisher.
|
|
|
5906
|
|
|
5907 D. Preserve all the copyright notices of the Document.
|
|
|
5908
|
|
|
5909 E. Add an appropriate copyright notice for your modifications
|
|
|
5910 adjacent to the other copyright notices.
|
|
|
5911
|
|
|
5912 F. Include, immediately after the copyright notices, a license
|
|
|
5913 notice giving the public permission to use the Modified
|
|
|
5914 Version under the terms of this License, in the form shown in
|
|
|
5915 the Addendum below.
|
|
|
5916
|
|
|
5917 G. Preserve in that license notice the full lists of Invariant
|
|
|
5918 Sections and required Cover Texts given in the Document's
|
|
|
5919 license notice.
|
|
|
5920
|
|
|
5921 H. Include an unaltered copy of this License.
|
|
|
5922
|
|
|
5923 I. Preserve the section Entitled "History", Preserve its Title,
|
|
|
5924 and add to it an item stating at least the title, year, new
|
|
|
5925 authors, and publisher of the Modified Version as given on
|
|
|
5926 the Title Page. If there is no section Entitled "History" in
|
|
|
5927 the Document, create one stating the title, year, authors,
|
|
|
5928 and publisher of the Document as given on its Title Page,
|
|
|
5929 then add an item describing the Modified Version as stated in
|
|
|
5930 the previous sentence.
|
|
|
5931
|
|
|
5932 J. Preserve the network location, if any, given in the Document
|
|
|
5933 for public access to a Transparent copy of the Document, and
|
|
|
5934 likewise the network locations given in the Document for
|
|
|
5935 previous versions it was based on. These may be placed in
|
|
|
5936 the "History" section. You may omit a network location for a
|
|
|
5937 work that was published at least four years before the
|
|
|
5938 Document itself, or if the original publisher of the version
|
|
|
5939 it refers to gives permission.
|
|
|
5940
|
|
|
5941 K. For any section Entitled "Acknowledgements" or "Dedications",
|
|
|
5942 Preserve the Title of the section, and preserve in the
|
|
|
5943 section all the substance and tone of each of the contributor
|
|
|
5944 acknowledgements and/or dedications given therein.
|
|
|
5945
|
|
|
5946 L. Preserve all the Invariant Sections of the Document,
|
|
|
5947 unaltered in their text and in their titles. Section numbers
|
|
|
5948 or the equivalent are not considered part of the section
|
|
|
5949 titles.
|
|
|
5950
|
|
|
5951 M. Delete any section Entitled "Endorsements". Such a section
|
|
|
5952 may not be included in the Modified Version.
|
|
|
5953
|
|
|
5954 N. Do not retitle any existing section to be Entitled
|
|
|
5955 "Endorsements" or to conflict in title with any Invariant
|
|
|
5956 Section.
|
|
|
5957
|
|
|
5958 O. Preserve any Warranty Disclaimers.
|
|
|
5959
|
|
|
5960 If the Modified Version includes new front-matter sections or
|
|
|
5961 appendices that qualify as Secondary Sections and contain no
|
|
|
5962 material copied from the Document, you may at your option
|
|
|
5963 designate some or all of these sections as invariant. To do this,
|
|
|
5964 add their titles to the list of Invariant Sections in the Modified
|
|
|
5965 Version's license notice. These titles must be distinct from any
|
|
|
5966 other section titles.
|
|
|
5967
|
|
|
5968 You may add a section Entitled "Endorsements", provided it contains
|
|
|
5969 nothing but endorsements of your Modified Version by various
|
|
|
5970 parties--for example, statements of peer review or that the text
|
|
|
5971 has been approved by an organization as the authoritative
|
|
|
5972 definition of a standard.
|
|
|
5973
|
|
|
5974 You may add a passage of up to five words as a Front-Cover Text,
|
|
|
5975 and a passage of up to 25 words as a Back-Cover Text, to the end
|
|
|
5976 of the list of Cover Texts in the Modified Version. Only one
|
|
|
5977 passage of Front-Cover Text and one of Back-Cover Text may be
|
|
|
5978 added by (or through arrangements made by) any one entity. If the
|
|
|
5979 Document already includes a cover text for the same cover,
|
|
|
5980 previously added by you or by arrangement made by the same entity
|
|
|
5981 you are acting on behalf of, you may not add another; but you may
|
|
|
5982 replace the old one, on explicit permission from the previous
|
|
|
5983 publisher that added the old one.
|
|
|
5984
|
|
|
5985 The author(s) and publisher(s) of the Document do not by this
|
|
|
5986 License give permission to use their names for publicity for or to
|
|
|
5987 assert or imply endorsement of any Modified Version.
|
|
|
5988
|
|
|
5989 5. COMBINING DOCUMENTS
|
|
|
5990
|
|
|
5991 You may combine the Document with other documents released under
|
|
|
5992 this License, under the terms defined in section 4 above for
|
|
|
5993 modified versions, provided that you include in the combination
|
|
|
5994 all of the Invariant Sections of all of the original documents,
|
|
|
5995 unmodified, and list them all as Invariant Sections of your
|
|
|
5996 combined work in its license notice, and that you preserve all
|
|
|
5997 their Warranty Disclaimers.
|
|
|
5998
|
|
|
5999 The combined work need only contain one copy of this License, and
|
|
|
6000 multiple identical Invariant Sections may be replaced with a single
|
|
|
6001 copy. If there are multiple Invariant Sections with the same name
|
|
|
6002 but different contents, make the title of each such section unique
|
|
|
6003 by adding at the end of it, in parentheses, the name of the
|
|
|
6004 original author or publisher of that section if known, or else a
|
|
|
6005 unique number. Make the same adjustment to the section titles in
|
|
|
6006 the list of Invariant Sections in the license notice of the
|
|
|
6007 combined work.
|
|
|
6008
|
|
|
6009 In the combination, you must combine any sections Entitled
|
|
|
6010 "History" in the various original documents, forming one section
|
|
|
6011 Entitled "History"; likewise combine any sections Entitled
|
|
|
6012 "Acknowledgements", and any sections Entitled "Dedications". You
|
|
|
6013 must delete all sections Entitled "Endorsements."
|
|
|
6014
|
|
|
6015 6. COLLECTIONS OF DOCUMENTS
|
|
|
6016
|
|
|
6017 You may make a collection consisting of the Document and other
|
|
|
6018 documents released under this License, and replace the individual
|
|
|
6019 copies of this License in the various documents with a single copy
|
|
|
6020 that is included in the collection, provided that you follow the
|
|
|
6021 rules of this License for verbatim copying of each of the
|
|
|
6022 documents in all other respects.
|
|
|
6023
|
|
|
6024 You may extract a single document from such a collection, and
|
|
|
6025 distribute it individually under this License, provided you insert
|
|
|
6026 a copy of this License into the extracted document, and follow
|
|
|
6027 this License in all other respects regarding verbatim copying of
|
|
|
6028 that document.
|
|
|
6029
|
|
|
6030 7. AGGREGATION WITH INDEPENDENT WORKS
|
|
|
6031
|
|
|
6032 A compilation of the Document or its derivatives with other
|
|
|
6033 separate and independent documents or works, in or on a volume of
|
|
|
6034 a storage or distribution medium, is called an "aggregate" if the
|
|
|
6035 copyright resulting from the compilation is not used to limit the
|
|
|
6036 legal rights of the compilation's users beyond what the individual
|
|
|
6037 works permit. When the Document is included in an aggregate, this
|
|
|
6038 License does not apply to the other works in the aggregate which
|
|
|
6039 are not themselves derivative works of the Document.
|
|
|
6040
|
|
|
6041 If the Cover Text requirement of section 3 is applicable to these
|
|
|
6042 copies of the Document, then if the Document is less than one half
|
|
|
6043 of the entire aggregate, the Document's Cover Texts may be placed
|
|
|
6044 on covers that bracket the Document within the aggregate, or the
|
|
|
6045 electronic equivalent of covers if the Document is in electronic
|
|
|
6046 form. Otherwise they must appear on printed covers that bracket
|
|
|
6047 the whole aggregate.
|
|
|
6048
|
|
|
6049 8. TRANSLATION
|
|
|
6050
|
|
|
6051 Translation is considered a kind of modification, so you may
|
|
|
6052 distribute translations of the Document under the terms of section
|
|
|
6053 4. Replacing Invariant Sections with translations requires special
|
|
|
6054 permission from their copyright holders, but you may include
|
|
|
6055 translations of some or all Invariant Sections in addition to the
|
|
|
6056 original versions of these Invariant Sections. You may include a
|
|
|
6057 translation of this License, and all the license notices in the
|
|
|
6058 Document, and any Warranty Disclaimers, provided that you also
|
|
|
6059 include the original English version of this License and the
|
|
|
6060 original versions of those notices and disclaimers. In case of a
|
|
|
6061 disagreement between the translation and the original version of
|
|
|
6062 this License or a notice or disclaimer, the original version will
|
|
|
6063 prevail.
|
|
|
6064
|
|
|
6065 If a section in the Document is Entitled "Acknowledgements",
|
|
|
6066 "Dedications", or "History", the requirement (section 4) to
|
|
|
6067 Preserve its Title (section 1) will typically require changing the
|
|
|
6068 actual title.
|
|
|
6069
|
|
|
6070 9. TERMINATION
|
|
|
6071
|
|
|
6072 You may not copy, modify, sublicense, or distribute the Document
|
|
|
6073 except as expressly provided for under this License. Any other
|
|
|
6074 attempt to copy, modify, sublicense or distribute the Document is
|
|
|
6075 void, and will automatically terminate your rights under this
|
|
|
6076 License. However, parties who have received copies, or rights,
|
|
|
6077 from you under this License will not have their licenses
|
|
|
6078 terminated so long as such parties remain in full compliance.
|
|
|
6079
|
|
|
6080 10. FUTURE REVISIONS OF THIS LICENSE
|
|
|
6081
|
|
|
6082 The Free Software Foundation may publish new, revised versions of
|
|
|
6083 the GNU Free Documentation License from time to time. Such new
|
|
|
6084 versions will be similar in spirit to the present version, but may
|
|
|
6085 differ in detail to address new problems or concerns. See
|
|
|
6086 `http://www.gnu.org/copyleft/'.
|
|
|
6087
|
|
|
6088 Each version of the License is given a distinguishing version
|
|
|
6089 number. If the Document specifies that a particular numbered
|
|
|
6090 version of this License "or any later version" applies to it, you
|
|
|
6091 have the option of following the terms and conditions either of
|
|
|
6092 that specified version or of any later version that has been
|
|
|
6093 published (not as a draft) by the Free Software Foundation. If
|
|
|
6094 the Document does not specify a version number of this License,
|
|
|
6095 you may choose any version ever published (not as a draft) by the
|
|
|
6096 Free Software Foundation.
|
|
|
6097
|
|
|
6098 ADDENDUM: How to use this License for your documents
|
|
|
6099 ====================================================
|
|
|
6100
|
|
|
6101 To use this License in a document you have written, include a copy of
|
|
|
6102 the License in the document and put the following copyright and license
|
|
|
6103 notices just after the title page:
|
|
|
6104
|
|
|
6105 Copyright (C) YEAR YOUR NAME.
|
|
|
6106 Permission is granted to copy, distribute and/or modify this document
|
|
|
6107 under the terms of the GNU Free Documentation License, Version 1.2
|
|
|
6108 or any later version published by the Free Software Foundation;
|
|
|
6109 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
|
|
|
6110 Texts. A copy of the license is included in the section entitled ``GNU
|
|
|
6111 Free Documentation License''.
|
|
|
6112
|
|
|
6113 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
|
|
|
6114 replace the "with...Texts." line with this:
|
|
|
6115
|
|
|
6116 with the Invariant Sections being LIST THEIR TITLES, with
|
|
|
6117 the Front-Cover Texts being LIST, and with the Back-Cover Texts
|
|
|
6118 being LIST.
|
|
|
6119
|
|
|
6120 If you have Invariant Sections without Cover Texts, or some other
|
|
|
6121 combination of the three, merge those two alternatives to suit the
|
|
|
6122 situation.
|
|
|
6123
|
|
|
6124 If your document contains nontrivial examples of program code, we
|
|
|
6125 recommend releasing these examples in parallel under your choice of
|
|
|
6126 free software license, such as the GNU General Public License, to
|
|
|
6127 permit their use in free software.
|
|
|
6128
|
|
|
6129 Index
|
|
|
6130 *****
|
|
|
6131
|
|
|
6132 This is the index of everything in this manual. (Note that in some
|
|
|
6133 versions of the manual this is called `Main Index' to prevent it
|
|
|
6134 transforming into a page called `index.html' in the HTML version of the
|
|
|
6135 manual. The complications that that caused were really odd.)
|
|
|
6136
|
|
|
6137 ": See 6.2. (line 2055)
|
|
|
6138 #: See 6.1. (line 2014)
|
|
|
6139 $: See 6.3.1. (line 2161)
|
|
|
6140 %: See 5.4. (line 1936)
|
|
|
6141 &: See 6.3.3. (line 2275)
|
|
|
6142 ': See 6.2. (line 2055)
|
|
|
6143 +help: See 2.6. (line 938)
|
|
|
6144 +instapipe: See 2.6. (line 959)
|
|
|
6145 +mystery: See 2.6. (line 984)
|
|
|
6146 +printflow: See 2.6. (line 967)
|
|
|
6147 +printflow, enabling: See 2.2. (line 810)
|
|
|
6148 +traditional: See 2.6. (line 955)
|
|
|
6149 +wimpmode: See 2.6. (line 945)
|
|
|
6150 ,: See 6.1. (line 2014)
|
|
|
6151 -@: See 2.5. (line 922)
|
|
|
6152 -a: See 2.1. (line 687)
|
|
|
6153 -b: See 2.1. (line 633)
|
|
|
6154 -c: See 2.3. (line 862)
|
|
|
6155 -C: See 2.1. (line 710)
|
|
|
6156 -d: See 2.2. (line 763)
|
|
|
6157 -E: See 2.1. (line 671)
|
|
|
6158 -e: See 2.1. (line 659)
|
|
|
6159 -F: See 2.4. (line 898)
|
|
|
6160 -f: See 2.4. (line 891)
|
|
|
6161 -g: See 2.2. (line 769)
|
|
|
6162 -H: See 2.2. (line 778)
|
|
|
6163 -h: See 2.2. (line 778)
|
|
|
6164 -help: See 2.6. (line 938)
|
|
|
6165 -hH: See 2.2. (line 778)
|
|
|
6166 -instapipe: See 2.6. (line 959)
|
|
|
6167 -l: See 2.2. (line 788)
|
|
|
6168 -m: See 2.1. (line 647)
|
|
|
6169 -mystery: See 2.6. (line 984)
|
|
|
6170 -O: See 2.4. (line 907)
|
|
|
6171 -o: See 2.3. (line 876)
|
|
|
6172 -p: See 2.2. (line 795)
|
|
|
6173 -P: See 2.1. (line 715)
|
|
|
6174 -printflow: See 2.6. (line 967)
|
|
|
6175 -t: See 2.1. (line 681)
|
|
|
6176 -traditional: See 2.6. (line 955)
|
|
|
6177 -U: See 2.2. (line 837)
|
|
|
6178 -u: See 2.2. (line 817)
|
|
|
6179 -v: See 2.1. (line 696)
|
|
|
6180 -w: See 2.2. (line 810)
|
|
|
6181 -wimpmode: See 2.6. (line 945)
|
|
|
6182 -x: See 2.1. (line 740)
|
|
|
6183 -X: See 2.1. (line 728)
|
|
|
6184 -Y: See 2.2. (line 831)
|
|
|
6185 -y: See 2.2. (line 826)
|
|
|
6186 .: See 6.1. (line 2014)
|
|
|
6187 .b98: See 14.2. (line 4302)
|
|
|
6188 .b98, no external library: See 3.1. (line 1466)
|
|
|
6189 /: See 11. (line 3469)
|
|
|
6190 16 bit overflow: See 3.1. (line 1214)
|
|
|
6191 32 bit overflow: See 3.1. (line 1305)
|
|
|
6192 :: See 6.1. (line 2014)
|
|
|
6193 ;: See 6.1. (line 2014)
|
|
|
6194 ?: See 6.3.3. (line 2275)
|
|
|
6195 @: See 9. (line 3108)
|
|
|
6196 ^: See 9. (line 3108)
|
|
|
6197 About this manual:
|
|
|
6198 See ``About this manual''. (line 126)
|
|
|
6199 ABSTAIN: See 7.6. (line 2646)
|
|
|
6200 abstain, at program start: See 5.3. (line 1885)
|
|
|
6201 abstain, during execution: See 7.6. (line 2646)
|
|
|
6202 ABSTAIN, nonexistent target: See 3.1. (line 1129)
|
|
|
6203 ABSTAIN, self-abstaining: See 5.5. (line 1959)
|
|
|
6204 abstained state: See 5.3. (line 1885)
|
|
|
6205 ABSTAINING: See 7.6. (line 2646)
|
|
|
6206 add-without-carry: See 9. (line 3108)
|
|
|
6207 AGAIN: See 5.5. (line 1959)
|
|
|
6208 alloca: See 14.1.11. (line 4215)
|
|
|
6209 ampersand: See 6.3.3. (line 2275)
|
|
|
6210 and: See 6.3.3. (line 2275)
|
|
|
6211 and16: See C.4. (line 5358)
|
|
|
6212 and32: See C.4. (line 5358)
|
|
|
6213 Arabic numberals, enabling: See 2.6. (line 945)
|
|
|
6214 array, invalid dimension: See 3.1. (line 1179)
|
|
|
6215 array, out of bounds: See 3.1. (line 1186)
|
|
|
6216 array, wrong dimension: See 3.1. (line 1186)
|
|
|
6217 arrays, dimensioning: See 7.2. (line 2451)
|
|
|
6218 arrays, subscripting: See 6.3.4. (line 2350)
|
|
|
6219 assigning to constants: See 2.1. (line 696)
|
|
|
6220 assignment: See 7.2. (line 2451)
|
|
|
6221 Atari compiler: See 15. (line 4787)
|
|
|
6222 Atari syntax: See 5.1. (line 1817)
|
|
|
6223 Atari, character set: See Appendix A.
|
|
|
6224 (line 4862)
|
|
|
6225 auto: See 14.1.11. (line 4215)
|
|
|
6226 backtracking: See 10.3. (line 3381)
|
|
|
6227 Backtracking INTERCAL: See 10. (line 3190)
|
|
|
6228 backtracking, debugging: See 2.6. (line 967)
|
|
|
6229 backtracking, enabling: See 2.1. (line 647)
|
|
|
6230 backtracking, not enabled: See 3.1. (line 1280)
|
|
|
6231 backtracking, out of memory: See 3.1. (line 1474)
|
|
|
6232 Baudot <1>: See Appendix A.
|
|
|
6233 (line 4862)
|
|
|
6234 Baudot: See 7.7.3. (line 2855)
|
|
|
6235 Befunge: See 14.2. (line 4302)
|
|
|
6236 Befunge, fingerprint: See 14.2.2. (line 4383)
|
|
|
6237 Befunge, installing: See 14.2.1. (line 4333)
|
|
|
6238 Befunge, marker: See 14.2.2. (line 4417)
|
|
|
6239 Befunge, no external library: See 3.1. (line 1466)
|
|
|
6240 black lagoon: See 3.1. (line 1090)
|
|
|
6241 blocks, labeled: See 14.1.4. (line 3937)
|
|
|
6242 book: See 6.3.3. (line 2275)
|
|
|
6243 breakpoints, too many: See 3.1. (line 1451)
|
|
|
6244 bugs, reporting: See 1.7. (line 494)
|
|
|
6245 BUT: See 9. (line 3108)
|
|
|
6246 c: See C.4. (line 5308)
|
|
|
6247 C: See 14.1. (line 3791)
|
|
|
6248 C code, debugging: See 2.2. (line 769)
|
|
|
6249 C code, leaving in place: See 2.2. (line 769)
|
|
|
6250 C, auto/alloca: See 14.1.11. (line 4215)
|
|
|
6251 C, CREATE: See 14.1.10. (line 4099)
|
|
|
6252 C, external call infrastructure: See 14.1.1. (line 3818)
|
|
|
6253 C, stopping after C is generated: See 2.3. (line 862)
|
|
|
6254 C, system library: See 14.5. (line 4717)
|
|
|
6255 C, within OIL: See C.4. (line 5306)
|
|
|
6256 C-INTERCAL, distributing: See 1.8. (line 555)
|
|
|
6257 C-INTERCAL, I/O: See 7.7.2. (line 2813)
|
|
|
6258 C-INTERCAL, obtaining a copy: See 1.1. (line 182)
|
|
|
6259 C-INTERCAL, unpacking: See 1.2. (line 208)
|
|
|
6260 C-INTERCAL, unzipping: See 1.2. (line 208)
|
|
|
6261 c1--c9: See C.4. (line 5308)
|
|
|
6262 C99: See 14.3. (line 4603)
|
|
|
6263 calculate: See 7.2. (line 2451)
|
|
|
6264 CALCULATING: See 7.2. (line 2451)
|
|
|
6265 calls, external: See 14. (line 3759)
|
|
|
6266 character sets <1>: See Appendix A.
|
|
|
6267 (line 4862)
|
|
|
6268 character sets: See 5.1. (line 1785)
|
|
|
6269 character sets, converting: See Appendix B.
|
|
|
6270 (line 4984)
|
|
|
6271 choicepoints: See 10.3. (line 3381)
|
|
|
6272 choicepoints, activating: See 10.3. (line 3419)
|
|
|
6273 choicepoints, creating: See 10.3. (line 3401)
|
|
|
6274 choicepoints, discarding: See 10.3. (line 3456)
|
|
|
6275 CLC-INTERCAL: See 15. (line 4810)
|
|
|
6276 CLC-INTERCAL compatibility mode: See 2.1. (line 740)
|
|
|
6277 CLC-INTERCAL I/O: See 7.7.3. (line 2855)
|
|
|
6278 clockface mode: See 2.1. (line 710)
|
|
|
6279 code generation, stopping at C code: See 2.3. (line 862)
|
|
|
6280 COME FROM: See 7.10. (line 2941)
|
|
|
6281 COME FROM, ambiguity: See 3.1. (line 1317)
|
|
|
6282 COME FROM, in C: See 14.1.5. (line 3960)
|
|
|
6283 COME FROM, in Funge: See 14.2.2. (line 4457)
|
|
|
6284 COME FROM, multithreading: See 10.1. (line 3219)
|
|
|
6285 COME FROM, no target: See 3.1. (line 1296)
|
|
|
6286 command line options: See 2. (line 606)
|
|
|
6287 command line, showing intermediates: See 2.2. (line 831)
|
|
|
6288 COMMENT: See 7.1. (line 2402)
|
|
|
6289 comment: See 7.1. (line 2402)
|
|
|
6290 COMMENTING: See 7.1. (line 2402)
|
|
|
6291 COMMENTS: See 7.1. (line 2402)
|
|
|
6292 comments, OIL: See C.2. (line 5141)
|
|
|
6293 compatibility, CLC-INTERCAL: See 2.1. (line 740)
|
|
|
6294 compatibility, INTERCAL-72: See 2.1. (line 681)
|
|
|
6295 compiling, ick itself: See 1.3. (line 269)
|
|
|
6296 compiling, INTERCAL source code: See 2. (line 606)
|
|
|
6297 compunex: See 14.5. (line 4735)
|
|
|
6298 computed NEXT: See 14.5. (line 4735)
|
|
|
6299 config.sh: See 1.3. (line 269)
|
|
|
6300 configuring: See 1.3. (line 269)
|
|
|
6301 connected threads: See 10.2. (line 3291)
|
|
|
6302 constant: See 6.1. (line 2014)
|
|
|
6303 constant, twospot: See 3.1. (line 1060)
|
|
|
6304 constants, assigning to: See 2.1. (line 696)
|
|
|
6305 controlled unary operator: See 9. (line 3108)
|
|
|
6306 converting between character sets: See Appendix B.
|
|
|
6307 (line 4984)
|
|
|
6308 convickt: See Appendix B.
|
|
|
6309 (line 4984)
|
|
|
6310 copying conditions: See Appendix D.
|
|
|
6311 (line 5679)
|
|
|
6312 copyright: See Appendix D.
|
|
|
6313 (line 5679)
|
|
|
6314 CREATE: See 13. (line 3642)
|
|
|
6315 CREATE, enabling: See 2.1. (line 687)
|
|
|
6316 CREATE, in C: See 14.1.10. (line 4099)
|
|
|
6317 CREATE, in Funge: See 14.2.2. (line 4444)
|
|
|
6318 CREATE, operators: See 13. (line 3718)
|
|
|
6319 CREATE, signatures: See 14.1.10. (line 4136)
|
|
|
6320 creating syntax: See 13. (line 3642)
|
|
|
6321 Debian: See 1.3. (line 329)
|
|
|
6322 debug options: See 2.2. (line 757)
|
|
|
6323 debugging, C code: See 2.2. (line 769)
|
|
|
6324 debugging, flow: See 2.6. (line 967)
|
|
|
6325 debugging, internal errors: See 2.2. (line 837)
|
|
|
6326 debugging, lexical analyser: See 2.2. (line 763)
|
|
|
6327 debugging, multithreaded programs: See 2.6. (line 967)
|
|
|
6328 debugging, OIL: See 2.2. (line 778)
|
|
|
6329 debugging, optimizer: See 2.2. (line 778)
|
|
|
6330 debugging, parser: See 2.2. (line 763)
|
|
|
6331 debugging, runtime: See 4. (line 1642)
|
|
|
6332 debugging, yuk: See 4. (line 1642)
|
|
|
6333 dialect options: See 2.1. (line 622)
|
|
|
6334 dialects of syntax: See 5.1. (line 1785)
|
|
|
6335 dimensioning arrays: See 7.2. (line 2451)
|
|
|
6336 directory problems: See 2.2. (line 817)
|
|
|
6337 directory problems, source file: See 3.1. (line 1417)
|
|
|
6338 distributing C-INTERCAL: See 1.8. (line 555)
|
|
|
6339 DJGPP: See 1.4. (line 359)
|
|
|
6340 DO: See 5.3. (line 1885)
|
|
|
6341 dormant thread: See 10.3. (line 3381)
|
|
|
6342 DOS: See 1.4. (line 359)
|
|
|
6343 double-oh-seven: See 5.4. (line 1936)
|
|
|
6344 dumping core on error: See 2.2. (line 837)
|
|
|
6345 duplicate line label: See 3.1. (line 1136)
|
|
|
6346 E000: See 3.1. (line 1052)
|
|
|
6347 E017: See 3.1. (line 1060)
|
|
|
6348 E079: See 3.1. (line 1066)
|
|
|
6349 E099: See 3.1. (line 1074)
|
|
|
6350 E111: See 3.1. (line 1081)
|
|
|
6351 E123: See 3.1. (line 1090)
|
|
|
6352 E127: See 3.1. (line 1103)
|
|
|
6353 E127, debugging: See 2.2. (line 817)
|
|
|
6354 E129: See 3.1. (line 1115)
|
|
|
6355 E139: See 3.1. (line 1129)
|
|
|
6356 E182: See 3.1. (line 1136)
|
|
|
6357 E197: See 3.1. (line 1147)
|
|
|
6358 E200: See 3.1. (line 1156)
|
|
|
6359 E222: See 3.1. (line 1166)
|
|
|
6360 E240: See 3.1. (line 1179)
|
|
|
6361 E241: See 3.1. (line 1186)
|
|
|
6362 E252: See 3.1. (line 1196)
|
|
|
6363 E256: See 3.1. (line 1203)
|
|
|
6364 E256, avoiding: See 2.1. (line 715)
|
|
|
6365 E275: See 3.1. (line 1214)
|
|
|
6366 E277: See 3.1. (line 1225)
|
|
|
6367 E281: See 3.1. (line 1243)
|
|
|
6368 E333: See 3.1. (line 1254)
|
|
|
6369 E345: See 3.1. (line 1262)
|
|
|
6370 E404: See 3.1. (line 1271)
|
|
|
6371 E405: See 3.1. (line 1280)
|
|
|
6372 E436: See 3.1. (line 1290)
|
|
|
6373 E444: See 3.1. (line 1296)
|
|
|
6374 E533: See 3.1. (line 1305)
|
|
|
6375 E555: See 3.1. (line 1317)
|
|
|
6376 E562: See 3.1. (line 1329)
|
|
|
6377 E579: See 3.1. (line 1339)
|
|
|
6378 E621: See 3.1. (line 1348)
|
|
|
6379 E632: See 3.1. (line 1357)
|
|
|
6380 E633: See 3.1. (line 1365)
|
|
|
6381 E652: See 3.1. (line 1380)
|
|
|
6382 E652, avoiding: See 2.1. (line 715)
|
|
|
6383 E666: See 3.1. (line 1390)
|
|
|
6384 E774: See 3.1. (line 1404)
|
|
|
6385 E774, disabling: See 2.1. (line 633)
|
|
|
6386 E777: See 3.1. (line 1417)
|
|
|
6387 E778: See 3.1. (line 1424)
|
|
|
6388 E778, debugging: See 2.2. (line 837)
|
|
|
6389 E810: See 3.1. (line 1444)
|
|
|
6390 E811: See 3.1. (line 1451)
|
|
|
6391 E888: See 3.1. (line 1458)
|
|
|
6392 E899: See 3.1. (line 1465)
|
|
|
6393 E991: See 3.1. (line 1474)
|
|
|
6394 E993: See 3.1. (line 1484)
|
|
|
6395 E995: See 3.1. (line 1492)
|
|
|
6396 E997: See 3.1. (line 1500)
|
|
|
6397 E998: See 3.1. (line 1510)
|
|
|
6398 E999: See 3.1. (line 1519)
|
|
|
6399 E999, debugging: See 2.2. (line 817)
|
|
|
6400 ears: See 6.2. (line 2055)
|
|
|
6401 ears, nesting limit: See 3.1. (line 1243)
|
|
|
6402 EBCDIC: See Appendix A.
|
|
|
6403 (line 4862)
|
|
|
6404 embedded systems: See 12. (line 3549)
|
|
|
6405 end of file: See 3.1. (line 1329)
|
|
|
6406 environment variables: See 2.7. (line 992)
|
|
|
6407 EOF: See 3.1. (line 1329)
|
|
|
6408 errors: See 3.1. (line 1048)
|
|
|
6409 errors and warnings: See 3. (line 1021)
|
|
|
6410 examples, OIL: See C.8. (line 5587)
|
|
|
6411 exclusive or: See 6.3.3. (line 2275)
|
|
|
6412 execution chance: See 5.4. (line 1936)
|
|
|
6413 exiting: See 7.8. (line 2905)
|
|
|
6414 exor: See 6.3.3. (line 2275)
|
|
|
6415 expansion libraries: See 14.5. (line 4682)
|
|
|
6416 expressions: See 6. (line 2003)
|
|
|
6417 expressions, OIL: See C.3. (line 5190)
|
|
|
6418 external calls: See 14. (line 3759)
|
|
|
6419 external calls, and auto: See 14.1.11. (line 4215)
|
|
|
6420 external calls, Befunge: See 14.2. (line 4302)
|
|
|
6421 external calls, C infrastructure: See 14.1.1. (line 3818)
|
|
|
6422 external calls, C99: See 14.3. (line 4603)
|
|
|
6423 external calls, debugging: See 2.2. (line 831)
|
|
|
6424 external calls, enabling: See 2.1. (line 659)
|
|
|
6425 external calls, from Funge's view: See 14.2.2. (line 4383)
|
|
|
6426 external calls, Funge: See 14.2. (line 4302)
|
|
|
6427 external calls, libraries: See 14.3. (line 4603)
|
|
|
6428 external calls, miscellaneous: See 14.3. (line 4603)
|
|
|
6429 external calls, to C: See 14.1. (line 3791)
|
|
|
6430 external calls, using: See 14.4. (line 4630)
|
|
|
6431 external libraries, unavailable: See 3.1. (line 1466)
|
|
|
6432 extreme optimization: See 2.4. (line 898)
|
|
|
6433 FDL: See D.1. (line 5703)
|
|
|
6434 file type, unsupported: See 3.1. (line 1510)
|
|
|
6435 fingerprint: See 14.2.2. (line 4383)
|
|
|
6436 flow control, INTERCAL-72: See 7.3. (line 2495)
|
|
|
6437 flow optimization: See 2.4. (line 891)
|
|
|
6438 flow, printing: See 2.6. (line 967)
|
|
|
6439 flushing: See 2.6. (line 959)
|
|
|
6440 foreign functions: See 14. (line 3759)
|
|
|
6441 FORGET: See 7.3. (line 2495)
|
|
|
6442 FORGET, in C: See 14.1.8. (line 4045)
|
|
|
6443 FORGET, in Funge: See 14.2.2. (line 4500)
|
|
|
6444 FORGETTING: See 7.3. (line 2495)
|
|
|
6445 Free Documentation License: See D.1. (line 5703)
|
|
|
6446 functions, OIL in C: See C.4. (line 5306)
|
|
|
6447 Funge: See 14.2. (line 4302)
|
|
|
6448 Funge, fingerprint: See 14.2.2. (line 4383)
|
|
|
6449 Funge, installing: See 14.2.1. (line 4333)
|
|
|
6450 Funge, marker: See 14.2.2. (line 4417)
|
|
|
6451 Funge, no external library: See 3.1. (line 1466)
|
|
|
6452 generated programs, options: See 2.6. (line 931)
|
|
|
6453 GFDL: See D.1. (line 5703)
|
|
|
6454 GIVE UP: See 7.8. (line 2905)
|
|
|
6455 GNU Free Documentation License: See D.1. (line 5703)
|
|
|
6456 GO AHEAD: See 10.3. (line 3456)
|
|
|
6457 GO AHEAD, no choicepoint: See 3.1. (line 1271)
|
|
|
6458 GO AHEAD, not enabled: See 3.1. (line 1280)
|
|
|
6459 GO BACK: See 10.3. (line 3419)
|
|
|
6460 GO BACK, no choicepoint: See 3.1. (line 1271)
|
|
|
6461 GO BACK, not enabled: See 3.1. (line 1280)
|
|
|
6462 goto, time-reversed: See 7.10. (line 2941)
|
|
|
6463 grouping rules: See 6.2. (line 2055)
|
|
|
6464 help with options: See 2.5. (line 922)
|
|
|
6465 hybrid: See 6.1. (line 2014)
|
|
|
6466 I/O: See 7.7. (line 2736)
|
|
|
6467 I/O, Baudot: See 7.7.3. (line 2855)
|
|
|
6468 I/O, C-INTERCAL: See 7.7.2. (line 2813)
|
|
|
6469 I/O, CLC-INTERCAL: See 7.7.3. (line 2855)
|
|
|
6470 I/O, INTERCAL-72: See 7.7.1. (line 2754)
|
|
|
6471 I/O, out of memory: See 3.1. (line 1196)
|
|
|
6472 I/O, PIC-INTERCAL: See 12. (line 3599)
|
|
|
6473 ick, command line options: See 2. (line 606)
|
|
|
6474 ick, errors: See 3.1. (line 1048)
|
|
|
6475 ick, errors and warnings: See 3. (line 1021)
|
|
|
6476 ick, installing: See 1. (line 164)
|
|
|
6477 ick, invoking: See 2. (line 606)
|
|
|
6478 ick, not installating: See 1.5. (line 430)
|
|
|
6479 ick, options: See 2. (line 606)
|
|
|
6480 ick, uninstalling: See 1.6. (line 462)
|
|
|
6481 ick, using without installation: See 1.5. (line 430)
|
|
|
6482 ick, warnings: See 3.2. (line 1532)
|
|
|
6483 ick-0-29.tgz: See 1.2. (line 208)
|
|
|
6484 ick_comefrom: See 14.1.5. (line 3960)
|
|
|
6485 ick_comefromif: See 14.1.5. (line 3982)
|
|
|
6486 ick_ec.h: See 14.1.1. (line 3823)
|
|
|
6487 ICK_EC_FUNC_END: See 14.1.1. (line 3838)
|
|
|
6488 ICK_EC_FUNC_START: See 14.1.1. (line 3838)
|
|
|
6489 ick_forget: See 14.1.8. (line 4045)
|
|
|
6490 ick_getonespot: See 14.1.9. (line 4074)
|
|
|
6491 ick_gettwospot: See 14.1.9. (line 4074)
|
|
|
6492 ick_labeledblock: See 14.1.4. (line 3937)
|
|
|
6493 ick_linelabel: See 14.1.3. (line 3904)
|
|
|
6494 ick_next: See 14.1.6. (line 3996)
|
|
|
6495 ick_nextfrom: See 14.1.5. (line 3960)
|
|
|
6496 ick_nextfromif: See 14.1.5. (line 3982)
|
|
|
6497 ick_resume: See 14.1.7. (line 4023)
|
|
|
6498 ick_return_or_resume: See 14.1.7. (line 4035)
|
|
|
6499 ick_setonespot: See 14.1.9. (line 4074)
|
|
|
6500 ick_settwospot: See 14.1.9. (line 4074)
|
|
|
6501 ick_startup: See 14.1.2. (line 3889)
|
|
|
6502 idiom: See C.2. (line 5176)
|
|
|
6503 idiom optimization: See 2.4. (line 907)
|
|
|
6504 idiotism.oil: See C.1. (line 5100)
|
|
|
6505 IFFI: See 14.2.2. (line 4383)
|
|
|
6506 IFFI, commands: See 14.2.2. (line 4442)
|
|
|
6507 IGNORE: See 7.5. (line 2613)
|
|
|
6508 IGNORE/RETRIEVE interaction: See 7.4. (line 2587)
|
|
|
6509 IGNORING: See 7.5. (line 2613)
|
|
|
6510 ignorret test: See 7.4. (line 2587)
|
|
|
6511 illegal array dimension: See 3.1. (line 1179)
|
|
|
6512 illegal line label value: See 3.1. (line 1147)
|
|
|
6513 illegal variable number: See 3.1. (line 1156)
|
|
|
6514 impossible reverse assignment: See 3.1. (line 1225)
|
|
|
6515 initial abstention: See 5.3. (line 1885)
|
|
|
6516 input: See 7.7. (line 2736)
|
|
|
6517 input, C-INTERCAL: See 7.7.2. (line 2813)
|
|
|
6518 input, CLC-INTERCAL: See 7.7.3. (line 2855)
|
|
|
6519 input, EOF: See 3.1. (line 1329)
|
|
|
6520 input, in Arabic numerals: See 2.6. (line 945)
|
|
|
6521 input, INTERCAL-72: See 7.7.1. (line 2754)
|
|
|
6522 input, invalid: See 3.1. (line 1339)
|
|
|
6523 installation: See 1. (line 164)
|
|
|
6524 installation, Debian: See 1.3. (line 329)
|
|
|
6525 installation, non-root: See 1.5. (line 430)
|
|
|
6526 installation, on DOS or Windows: See 1.4. (line 359)
|
|
|
6527 installation, simple: See 1.3. (line 269)
|
|
|
6528 installation, Ubuntu: See 1.3. (line 329)
|
|
|
6529 installation, via autoconf and make: See 1.3. (line 269)
|
|
|
6530 INTERCAL compilers: See 15. (line 4764)
|
|
|
6531 INTERCAL, syntax: See 5. (line 1767)
|
|
|
6532 INTERCAL-72 compatibility mode: See 2.1. (line 681)
|
|
|
6533 INTERCAL-72, I/O: See 7.7.1. (line 2754)
|
|
|
6534 interleave: See 6.3.1. (line 2161)
|
|
|
6535 internal errors: See 3.1. (line 1424)
|
|
|
6536 internal errors, debugging: See 2.2. (line 837)
|
|
|
6537 internal errors, dumping core: See 2.2. (line 837)
|
|
|
6538 invalid array dimension: See 3.1. (line 1179)
|
|
|
6539 invalid line label value: See 3.1. (line 1147)
|
|
|
6540 invalid variable number: See 3.1. (line 1156)
|
|
|
6541 iselect: See C.4. (line 5358)
|
|
|
6542 J-INTERCAL: See 15. (line 4797)
|
|
|
6543 labeled blocks: See 14.1.4. (line 3937)
|
|
|
6544 language-affecting options: See 2.1. (line 622)
|
|
|
6545 Latin-1: See Appendix A.
|
|
|
6546 (line 4862)
|
|
|
6547 lexical analyser, debugging: See 2.2. (line 763)
|
|
|
6548 libick_ecto_b98.a: See 14.2.1. (line 4333)
|
|
|
6549 libraries: See 14.5. (line 4682)
|
|
|
6550 libraries, Befunge: See 14.2.1. (line 4333)
|
|
|
6551 libraries, external calls: See 14.3. (line 4603)
|
|
|
6552 libraries, Funge: See 14.2.1. (line 4333)
|
|
|
6553 line label: See 5.2. (line 1847)
|
|
|
6554 line label, duplicate: See 3.1. (line 1136)
|
|
|
6555 line label, illegal value: See 3.1. (line 1147)
|
|
|
6556 line label, in Funge: See 14.2.2. (line 4516)
|
|
|
6557 line labels, C: See 14.1.3. (line 3904)
|
|
|
6558 line number: See 5.2. (line 1847)
|
|
|
6559 line too long: See 3.1. (line 1390)
|
|
|
6560 live CD/USB stick: See 1.5. (line 430)
|
|
|
6561 loops, entire program: See 7.9. (line 2923)
|
|
|
6562 loops, OIL: See C.6. (line 5489)
|
|
|
6563 make: See 1.3. (line 269)
|
|
|
6564 make install: See 1.3. (line 269)
|
|
|
6565 makeick.bat: See 1.4. (line 359)
|
|
|
6566 makeick.sh: See 1.4. (line 359)
|
|
|
6567 making a live CD/USB stick: See 1.5. (line 430)
|
|
|
6568 marker: See 14.2.2. (line 4417)
|
|
|
6569 MAXTOFREE: See C.7. (line 5523)
|
|
|
6570 MAYBE: See 10.3. (line 3401)
|
|
|
6571 MAYBE, not enabled: See 3.1. (line 1280)
|
|
|
6572 mesh: See 6.1. (line 2014)
|
|
|
6573 microcontrollers: See 12. (line 3549)
|
|
|
6574 mingle <1>: See C.4. (line 5358)
|
|
|
6575 mingle: See 6.3.1. (line 2161)
|
|
|
6576 miscellaneous external calls: See 14.3. (line 4603)
|
|
|
6577 multithreading: See 10. (line 3190)
|
|
|
6578 multithreading, connected threads: See 10.2. (line 3291)
|
|
|
6579 multithreading, debugging: See 2.6. (line 967)
|
|
|
6580 multithreading, enabling: See 2.1. (line 647)
|
|
|
6581 multithreading, not enabled: See 3.1. (line 1280)
|
|
|
6582 multithreading, out of memory: See 3.1. (line 1474)
|
|
|
6583 multithreading, separate threads: See 10.1. (line 3219)
|
|
|
6584 N'T: See 5.3. (line 1885)
|
|
|
6585 nesting limit: See 3.1. (line 1243)
|
|
|
6586 NEXT: See 7.3. (line 2495)
|
|
|
6587 NEXT FROM: See 7.10. (line 2941)
|
|
|
6588 NEXT FROM, in C: See 14.1.5. (line 3960)
|
|
|
6589 NEXT FROM, in Funge: See 14.2.2. (line 4586)
|
|
|
6590 NEXT FROM, multithreading: See 10.1. (line 3219)
|
|
|
6591 NEXT FROM, no target: See 3.1. (line 1296)
|
|
|
6592 NEXT stack: See 7.3. (line 2495)
|
|
|
6593 NEXT, computed: See 14.5. (line 4735)
|
|
|
6594 NEXT, in C: See 14.1.6. (line 3996)
|
|
|
6595 NEXT, in Funge: See 14.2.2. (line 4545)
|
|
|
6596 NEXT, nonexistent target: See 3.1. (line 1115)
|
|
|
6597 NEXT, stack overflow: See 3.1. (line 1090)
|
|
|
6598 NEXTING: See 7.3. (line 2495)
|
|
|
6599 no source file: See 3.1. (line 1417)
|
|
|
6600 non-INTERCAL-72 warning: See 3.2. (line 1558)
|
|
|
6601 non-root installation: See 1.5. (line 430)
|
|
|
6602 NOT: See 5.3. (line 1885)
|
|
|
6603 not installing: See 1.5. (line 430)
|
|
|
6604 obtaining C-INTERCAL: See 1.1. (line 182)
|
|
|
6605 OIL: See Appendix C.
|
|
|
6606 (line 5090)
|
|
|
6607 OIL, basics: See C.1. (line 5100)
|
|
|
6608 OIL, comments: See C.2. (line 5141)
|
|
|
6609 OIL, debugging: See 2.2. (line 778)
|
|
|
6610 OIL, example: See C.8. (line 5587)
|
|
|
6611 OIL, execution: See C.1. (line 5100)
|
|
|
6612 OIL, expressions: See C.3. (line 5190)
|
|
|
6613 OIL, functions in C: See C.4. (line 5306)
|
|
|
6614 OIL, idiom groups: See C.2. (line 5157)
|
|
|
6615 OIL, idioms: See C.2. (line 5176)
|
|
|
6616 OIL, loops: See C.6. (line 5489)
|
|
|
6617 OIL, operators: See C.3. (line 5203)
|
|
|
6618 OIL, optimizing code: See 2.4. (line 907)
|
|
|
6619 OIL, patterns: See C.4. (line 5249)
|
|
|
6620 OIL, replacements: See C.5. (line 5414)
|
|
|
6621 OIL, syntax: See C.2. (line 5133)
|
|
|
6622 OIL, tips: See C.7. (line 5521)
|
|
|
6623 ONCE: See 5.5. (line 1959)
|
|
|
6624 onespot: See 6.1. (line 2014)
|
|
|
6625 onespot overflow: See 3.1. (line 1214)
|
|
|
6626 onespot, overflow warning: See 3.2. (line 1580)
|
|
|
6627 operand overloading: See 11. (line 3469)
|
|
|
6628 operand overloading, impossible: See 3.1. (line 1225)
|
|
|
6629 operands, OIL, in patterns: See C.4. (line 5263)
|
|
|
6630 operands, OIL, in replacements: See C.5. (line 5444)
|
|
|
6631 operator: See 6.3. (line 2146)
|
|
|
6632 operators, OIL: See C.3. (line 5203)
|
|
|
6633 optimization: See 2.4. (line 887)
|
|
|
6634 optimization, control flow: See 2.4. (line 891)
|
|
|
6635 optimization, extreme: See 2.4. (line 898)
|
|
|
6636 optimization, flow: See 2.4. (line 891)
|
|
|
6637 optimization, idioms: See 2.4. (line 907)
|
|
|
6638 optimization, OIL: See 2.4. (line 907)
|
|
|
6639 Optimizer Idiom Language: See Appendix C.
|
|
|
6640 (line 5090)
|
|
|
6641 optimizer options: See 2.4. (line 887)
|
|
|
6642 optimizer, debugging: See 2.2. (line 778)
|
|
|
6643 options, debug: See 2.2. (line 757)
|
|
|
6644 options, dialect: See 2.1. (line 622)
|
|
|
6645 options, help: See 2.5. (line 922)
|
|
|
6646 options, language-affecting: See 2.1. (line 622)
|
|
|
6647 options, optimizer: See 2.4. (line 887)
|
|
|
6648 options, other: See 2.5. (line 919)
|
|
|
6649 options, output: See 2.3. (line 855)
|
|
|
6650 options, to generated programs: See 2.6. (line 931)
|
|
|
6651 options, to ick: See 2. (line 606)
|
|
|
6652 or: See 6.3.3. (line 2275)
|
|
|
6653 or16: See C.4. (line 5358)
|
|
|
6654 or32: See C.4. (line 5358)
|
|
|
6655 other languages: See 14. (line 3759)
|
|
|
6656 other languages, C: See 14.1. (line 3791)
|
|
|
6657 other options: See 2.5. (line 919)
|
|
|
6658 out of bounds: See 3.1. (line 1186)
|
|
|
6659 out of memory: See 3.1. (line 1262)
|
|
|
6660 out of memory, backtracking: See 3.1. (line 1474)
|
|
|
6661 out of memory, during compile: See 3.1. (line 1390)
|
|
|
6662 out of memory, during STASH: See 3.1. (line 1166)
|
|
|
6663 out of memory, I/O: See 3.1. (line 1196)
|
|
|
6664 out of memory, multithreading: See 3.1. (line 1474)
|
|
|
6665 output: See 7.7. (line 2736)
|
|
|
6666 output file, failure to write: See 3.1. (line 1459)
|
|
|
6667 output options: See 2.3. (line 855)
|
|
|
6668 output, C only: See 2.3. (line 862)
|
|
|
6669 output, C-INTERCAL: See 7.7.2. (line 2813)
|
|
|
6670 output, CLC-INTERCAL: See 7.7.3. (line 2855)
|
|
|
6671 output, flushing: See 2.6. (line 959)
|
|
|
6672 output, in Arabic numerals: See 2.6. (line 945)
|
|
|
6673 output, INTERCAL-72: See 7.7.1. (line 2754)
|
|
|
6674 output, to standard output: See 2.3. (line 876)
|
|
|
6675 overflow, in constant: See 3.1. (line 1060)
|
|
|
6676 overflow, over 16 bits: See 3.1. (line 1214)
|
|
|
6677 overflow, over 32 bits: See 3.1. (line 1305)
|
|
|
6678 overflow, over onespot: See 3.1. (line 1214)
|
|
|
6679 overflow, over twospot: See 3.1. (line 1305)
|
|
|
6680 overflow, warning: See 3.2. (line 1580)
|
|
|
6681 parser, debugging: See 2.2. (line 763)
|
|
|
6682 patches, submitting: See 1.7. (line 494)
|
|
|
6683 patterns: See C.4. (line 5249)
|
|
|
6684 patterns, operands: See C.4. (line 5263)
|
|
|
6685 PIC-INTERCAL: See 12. (line 3549)
|
|
|
6686 PIC-INTERCAL, command line option: See 2.1. (line 715)
|
|
|
6687 PIC-INTERCAL, unsupported command: See 3.1. (line 1203)
|
|
|
6688 PIN: See 12. (line 3599)
|
|
|
6689 PIN, in a non-PIC program: See 3.1. (line 1380)
|
|
|
6690 PLEASE: See 5.3. (line 1885)
|
|
|
6691 PLEASE, proportion required: See 3.1. (line 1066)
|
|
|
6692 politesse: See 3.1. (line 1066)
|
|
|
6693 portability, unary operators: See 3.2. (line 1620)
|
|
|
6694 positional precedence: See 6.2. (line 2055)
|
|
|
6695 Princeton compiler: See 15. (line 4769)
|
|
|
6696 Princeton syntax: See 5.1. (line 1790)
|
|
|
6697 Princeton syntax, option: See 2.1. (line 728)
|
|
|
6698 printflow, enabling: See 2.2. (line 810)
|
|
|
6699 profiling: See 2.2. (line 795)
|
|
|
6700 quitting: See 7.8. (line 2905)
|
|
|
6701 r: See C.4. (line 5345)
|
|
|
6702 rabbit-ears: See 6.2. (line 2055)
|
|
|
6703 rabbit-ears, nesting limit: See 3.1. (line 1243)
|
|
|
6704 random bug: See 2.1. (line 633)
|
|
|
6705 random bug, error message: See 3.1. (line 1404)
|
|
|
6706 READ OUT: See 7.7. (line 2736)
|
|
|
6707 read-only variables: See 7.5. (line 2613)
|
|
|
6708 read-write variables: See 7.5. (line 2613)
|
|
|
6709 READING OUT: See 7.7. (line 2736)
|
|
|
6710 REINSTATE: See 7.6. (line 2646)
|
|
|
6711 reinstate, at program start: See 5.3. (line 1885)
|
|
|
6712 reinstate, during execution: See 7.6. (line 2646)
|
|
|
6713 REINSTATE, self-reinstating: See 5.5. (line 1959)
|
|
|
6714 reinstated state: See 5.3. (line 1885)
|
|
|
6715 REINSTATING: See 7.6. (line 2646)
|
|
|
6716 REINTSTATE, nonexistent target: See 3.1. (line 1129)
|
|
|
6717 releasing C-INTERCAL: See 1.8. (line 555)
|
|
|
6718 REMEMBER: See 7.5. (line 2613)
|
|
|
6719 REMEMBERING: See 7.5. (line 2613)
|
|
|
6720 replacements: See C.5. (line 5414)
|
|
|
6721 replacements, operands: See C.5. (line 5444)
|
|
|
6722 reporting bugs: See 1.7. (line 494)
|
|
|
6723 RESUME: See 7.3. (line 2495)
|
|
|
6724 RESUME, by 0: See 3.1. (line 1348)
|
|
|
6725 RESUME, in C: See 14.1.7. (line 4023)
|
|
|
6726 RESUME, in Funge: See 14.2.2. (line 4553)
|
|
|
6727 RESUMING: See 7.3. (line 2495)
|
|
|
6728 RETRIEVE: See 7.4. (line 2558)
|
|
|
6729 RETRIEVE, without stashing: See 3.1. (line 1290)
|
|
|
6730 RETRIEVE/IGNORE interaction: See 7.4. (line 2587)
|
|
|
6731 RETRIEVING: See 7.4. (line 2558)
|
|
|
6732 reverse assignment: See 11. (line 3469)
|
|
|
6733 reverse assignment, error: See 3.1. (line 1225)
|
|
|
6734 reverse assignment, impossible: See 3.1. (line 1225)
|
|
|
6735 reverse goto: See 7.10. (line 2941)
|
|
|
6736 Roman numerals: See 7.7.1. (line 2754)
|
|
|
6737 Roman numerals, disabling: See 2.6. (line 945)
|
|
|
6738 runtime debugger: See 4. (line 1642)
|
|
|
6739 self-abstaining: See 5.5. (line 1959)
|
|
|
6740 self-reinstating: See 5.5. (line 1959)
|
|
|
6741 SENESTMAX: See 3.1. (line 1243)
|
|
|
6742 separate threads: See 10.1. (line 3219)
|
|
|
6743 setbitcount: See C.4. (line 5376)
|
|
|
6744 sharkfin: See 9. (line 3108)
|
|
|
6745 sharkfin, in base 2: See 3.1. (line 1500)
|
|
|
6746 signatures: See 14.1.10. (line 4136)
|
|
|
6747 simple installation: See 1.3. (line 269)
|
|
|
6748 skeleton file, directory problems: See 2.2. (line 817)
|
|
|
6749 skeleton file, errors: See 3.1. (line 1519)
|
|
|
6750 slat: See 11. (line 3469)
|
|
|
6751 smudgeleft: See C.4. (line 5383)
|
|
|
6752 smudgeright: See C.4. (line 5383)
|
|
|
6753 spark: See 6.2. (line 2055)
|
|
|
6754 spark, nesting limit: See 3.1. (line 1243)
|
|
|
6755 src/idiotism.oil: See C.1. (line 5100)
|
|
|
6756 stack overflow: See 3.1. (line 1090)
|
|
|
6757 stack, instruction pointer: See 7.3. (line 2495)
|
|
|
6758 stack, NEXT: See 7.3. (line 2495)
|
|
|
6759 stack, variable: See 7.4. (line 2558)
|
|
|
6760 standard output: See 2.3. (line 876)
|
|
|
6761 startup code, C: See 14.1.2. (line 3889)
|
|
|
6762 STASH: See 7.4. (line 2558)
|
|
|
6763 stash failure: See 3.1. (line 1290)
|
|
|
6764 stashes: See 7.4. (line 2558)
|
|
|
6765 STASHING: See 7.4. (line 2558)
|
|
|
6766 statement identifier: See 5.3. (line 1885)
|
|
|
6767 statements: See 7. (line 2388)
|
|
|
6768 statements, INTERCAL: See 7. (line 2388)
|
|
|
6769 SUB: See 6.3.4. (line 2350)
|
|
|
6770 submitting patches: See 1.7. (line 494)
|
|
|
6771 subscripts: See 6.3.4. (line 2350)
|
|
|
6772 subtract-without-borrow: See 9. (line 3108)
|
|
|
6773 syntax error <1>: See 7.1. (line 2402)
|
|
|
6774 syntax error: See 3.1. (line 1052)
|
|
|
6775 syntax, Atari: See 5.1. (line 1817)
|
|
|
6776 syntax, creating: See 13. (line 3642)
|
|
|
6777 syntax, dialects: See 5.1. (line 1785)
|
|
|
6778 syntax, INTERCAL: See 5. (line 1767)
|
|
|
6779 syntax, of OIL: See C.2. (line 5133)
|
|
|
6780 syntax, Princeton <1>: See 5.1. (line 1790)
|
|
|
6781 syntax, Princeton: See 2.1. (line 728)
|
|
|
6782 syslib: See 8. (line 3008)
|
|
|
6783 syslib, directory problems: See 2.2. (line 817)
|
|
|
6784 syslib, errors: See 3.1. (line 1103)
|
|
|
6785 syslibc: See 14.5. (line 4717)
|
|
|
6786 system libary: See 8. (line 3008)
|
|
|
6787 system library, directory problems: See 2.2. (line 817)
|
|
|
6788 system library, disabling: See 2.1. (line 671)
|
|
|
6789 system library, errors: See 3.1. (line 1103)
|
|
|
6790 system library, in C: See 14.5. (line 4717)
|
|
|
6791 tail: See 6.1. (line 2014)
|
|
|
6792 ternary: See 9. (line 3108)
|
|
|
6793 Threaded INTERCAL: See 10. (line 3190)
|
|
|
6794 threading: See 10. (line 3190)
|
|
|
6795 threading, connected: See 10.2. (line 3291)
|
|
|
6796 threading, dormant: See 10.3. (line 3381)
|
|
|
6797 threading, in series: See 10.3. (line 3381)
|
|
|
6798 threading, separate: See 10.1. (line 3219)
|
|
|
6799 threading, unwoven: See 10.1. (line 3219)
|
|
|
6800 threading, woven: See 10.2. (line 3291)
|
|
|
6801 time-reversed goto: See 7.10. (line 2941)
|
|
|
6802 tips, OIL: See C.7. (line 5521)
|
|
|
6803 too many input files: See 3.1. (line 1390)
|
|
|
6804 TriINTERCAL: See 9. (line 3108)
|
|
|
6805 TriINTERCAL, operators in base 2: See 3.1. (line 1500)
|
|
|
6806 TRY AGAIN: See 7.9. (line 2923)
|
|
|
6807 TRY AGAIN, not last: See 3.1. (line 1484)
|
|
|
6808 trying out ick: See 1.5. (line 430)
|
|
|
6809 Turing Tape: See 7.7.2. (line 2813)
|
|
|
6810 twospot: See 6.1. (line 2014)
|
|
|
6811 twospot overflow: See 3.1. (line 1305)
|
|
|
6812 Ubuntu: See 1.3. (line 329)
|
|
|
6813 unary binary logic: See 6.3.3. (line 2275)
|
|
|
6814 unary operator, infix: See 6.2. (line 2116)
|
|
|
6815 unary operator, prefix: See 6.2. (line 2116)
|
|
|
6816 unary operators, portability: See 3.2. (line 1620)
|
|
|
6817 uninstalling: See 1.6. (line 462)
|
|
|
6818 unpacking C-INTERCAL: See 1.2. (line 208)
|
|
|
6819 unsupported file type: See 3.1. (line 1510)
|
|
|
6820 unwoven threads: See 10.1. (line 3219)
|
|
|
6821 unzipping C-INTERCAL: See 1.2. (line 208)
|
|
|
6822 usage instructions, printing: See 2.5. (line 922)
|
|
|
6823 using external calls: See 14.4. (line 4630)
|
|
|
6824 V: See 6.3.3. (line 2275)
|
|
|
6825 variable: See 6.1. (line 2014)
|
|
|
6826 variable, illegal number: See 3.1. (line 1156)
|
|
|
6827 variables, assignment: See 7.2. (line 2451)
|
|
|
6828 variables, from C: See 14.1.9. (line 4074)
|
|
|
6829 variables, Funge, accessing: See 14.2.2. (line 4506)
|
|
|
6830 variables, Funge, setting: See 14.2.2. (line 4560)
|
|
|
6831 variables, ignoring: See 7.5. (line 2613)
|
|
|
6832 variables, limit: See 3.1. (line 1254)
|
|
|
6833 variables, read-only: See 7.5. (line 2613)
|
|
|
6834 variables, read-write: See 7.5. (line 2613)
|
|
|
6835 variables, remembering: See 7.5. (line 2613)
|
|
|
6836 variables, stashes: See 7.4. (line 2558)
|
|
|
6837 W016: See 3.2. (line 1538)
|
|
|
6838 W018: See 3.2. (line 1545)
|
|
|
6839 W112: See 3.2. (line 1558)
|
|
|
6840 W128: See 3.2. (line 1568)
|
|
|
6841 W239: See 3.2. (line 1591)
|
|
|
6842 W276: See 3.2. (line 1580)
|
|
|
6843 W278: See 3.2. (line 1600)
|
|
|
6844 W450: See 3.2. (line 1611)
|
|
|
6845 W534: See 3.2. (line 1620)
|
|
|
6846 W622: See 3.2. (line 1631)
|
|
|
6847 warnings: See 3.2. (line 1532)
|
|
|
6848 warnings, enabling: See 2.2. (line 788)
|
|
|
6849 warnings, non-INTERCAL-72: See 3.2. (line 1558)
|
|
|
6850 what: See 6.3.3. (line 2275)
|
|
|
6851 WHILE: See 10.2. (line 3291)
|
|
|
6852 WHILE, not enabled: See 3.1. (line 1280)
|
|
|
6853 whirlpool: See 9. (line 3108)
|
|
|
6854 whirlpool, in base 2: See 3.1. (line 1500)
|
|
|
6855 wimpmode: See 2.6. (line 945)
|
|
|
6856 Windows: See 1.4. (line 359)
|
|
|
6857 woven threads: See 10.2. (line 3291)
|
|
|
6858 WRITE IN: See 7.7. (line 2736)
|
|
|
6859 WRITING IN: See 7.7. (line 2736)
|
|
|
6860 wrong array dimension: See 3.1. (line 1186)
|
|
|
6861 x: See C.4. (line 5337)
|
|
|
6862 x1--x9: See C.4. (line 5337)
|
|
|
6863 xor: See 6.3.3. (line 2275)
|
|
|
6864 xor16: See C.4. (line 5358)
|
|
|
6865 xor32: See C.4. (line 5358)
|
|
|
6866 xselx: See C.4. (line 5370)
|
|
|
6867 yuk: See 4. (line 1642)
|
|
|
6868 yuk, breakpoint overflow: See 3.1. (line 1451)
|
|
|
6869 yuk, command line option: See 2.2. (line 826)
|
|
|
6870 yuk, commands: See 4. (line 1669)
|
|
|
6871 yuk, input overflow: See 3.1. (line 1444)
|
|
|
6872 yuk, profiling: See 2.2. (line 795)
|
|
|
6873 yuk, too many breakpoints: See 3.1. (line 1451)
|
|
|
6874
|
|
|
6875
|
|
|
6876 Local Variables:
|
|
|
6877 coding: iso-8859-1
|
|
|
6878 End:
|
