|
996
|
1 This is ../doc/ick.info, produced by makeinfo version 4.11 from
|
|
|
2 ../doc/ick.txi.
|
|
|
3
|
|
|
4 INFO-DIR-SECTION INTERCAL
|
|
|
5 START-INFO-DIR-ENTRY
|
|
|
6 * C-INTERCAL: (ick). The C-INTERCAL language and compiler.
|
|
|
7 * ick: (ick) Invoking ick. Invoking the C-INTERCAL compiler.
|
|
|
8 * convickt: (ick) convickt. The command-line character set converter.
|
|
|
9 END-INFO-DIR-ENTRY
|
|
|
10
|
|
|
11 This manual is for C-INTERCAL version 0.29. It does not replace the
|
|
|
12 old groff manual, nor is it designed to be read in conjunction with it;
|
|
|
13 instead, it serves a different purpose, of providing information useful
|
|
|
14 to users of C-INTERCAL (unlike the other manual, it is not derived from
|
|
|
15 the original INTERCAL-72 manual).
|
|
|
16
|
|
|
17 Copyright (C) 2007 Alex Smith.
|
|
|
18
|
|
|
19 Permission is granted to copy, distribute and/or modify this
|
|
|
20 document under the terms of the GNU Free Documentation License,
|
|
|
21 Version 1.2 or any later version published by the Free Software
|
|
|
22 Foundation; with no Invariant Sections, with no Front-Cover Texts,
|
|
|
23 and with no Back-Cover Texts. A copy of the license is included
|
|
|
24 in the section entitled "GNU Free Documentation License."
|
|
|
25
|
|
|
26
|
|
|
27
|
|
|
28 File: ick.info, Node: Top, Next: About this manual, Up: (dir)
|
|
|
29
|
|
|
30 C-INTERCAL 0.29
|
|
|
31 ***************
|
|
|
32
|
|
|
33 This manual is for C-INTERCAL version 0.29. It does not replace the
|
|
|
34 old groff manual, nor is it designed to be read in conjunction with it;
|
|
|
35 instead, it serves a different purpose, of providing information useful
|
|
|
36 to users of C-INTERCAL (unlike the other manual, it is not derived from
|
|
|
37 the original INTERCAL-72 manual).
|
|
|
38
|
|
|
39 Copyright (C) 2007 Alex Smith.
|
|
|
40
|
|
|
41 Permission is granted to copy, distribute and/or modify this
|
|
|
42 document under the terms of the GNU Free Documentation License,
|
|
|
43 Version 1.2 or any later version published by the Free Software
|
|
|
44 Foundation; with no Invariant Sections, with no Front-Cover Texts,
|
|
|
45 and with no Back-Cover Texts. A copy of the license is included
|
|
|
46 in the section entitled "GNU Free Documentation License."
|
|
|
47
|
|
|
48
|
|
|
49 * Menu:
|
|
|
50
|
|
|
51 * About this manual:: What is covered in this manual
|
|
|
52
|
|
|
53 The C-INTERCAL compiler
|
|
|
54 * Installation:: How to install C-INTERCAL
|
|
|
55 * Invoking ick:: Options to give to the compiler ick
|
|
|
56 * Errors and Warnings:: Error messages, and what to do about them
|
|
|
57 * The yuk debugger:: How to use the runtime debugger
|
|
|
58
|
|
|
59 Basic INTERCAL features
|
|
|
60 * Syntax:: Holding statements together
|
|
|
61 * Expressions:: Operators, operands, and grouping
|
|
|
62 * Statements:: What an INTERCAL statement can do
|
|
|
63 * System Library:: Pre-existing INTERCAL routines
|
|
|
64
|
|
|
65 INTERCAL dialects and extensions
|
|
|
66 * TriINTERCAL:: INTERCAL in non-binary bases
|
|
|
67 * Multithreading and Backtracking:: Running INTERCAL programs in parallel
|
|
|
68 * Operand Overloading:: Where one expression stands for another
|
|
|
69 * PIC-INTERCAL:: INTERCAL on embedded systems
|
|
|
70 * CREATE:: Creating new syntax at runtime
|
|
|
71 * External Calls:: Linking INTERCAL with other languages
|
|
|
72 * Differences to Other Compilers:: C-INTERCAL vs. CLC-INTERCAL
|
|
|
73
|
|
|
74 Appendices and indices
|
|
|
75 * Character Sets:: A list of character sets used by INTERCAL
|
|
|
76 * convickt:: The command-line character set converter
|
|
|
77 * Optimizer Idiom Language:: The syntax to specify optimizer idioms
|
|
|
78 * Copying:: License information for the code and manual
|
|
|
79 * Main Index:: An index of all the pages in this manual
|
|
|
80
|
|
|
81
|
|
|
82 File: ick.info, Node: About this manual, Next: Installation, Prev: Top, Up: Top
|
|
|
83
|
|
|
84 About this manual
|
|
|
85 *****************
|
|
|
86
|
|
|
87 This is the Revamped Instruction Manual for C-INTERCAL (this version is
|
|
|
88 distributed with C-INTERCAL version 0.29). It is divided into four
|
|
|
89 parts.
|
|
|
90
|
|
|
91 The first part is about the C-INTERCAL compiler `ick', and how to use
|
|
|
92 it. It covers installing the compiler, using the compiler, what error
|
|
|
93 and warning messages are produced by the compiler, and some information
|
|
|
94 on how to use the debugger.
|
|
|
95
|
|
|
96 The second part is about the core INTERCAL language, invented in 1972,
|
|
|
97 and some other commands since then which don't feel like they're
|
|
|
98 extensions. (This is a pretty arbitrary distinction, but people who
|
|
|
99 write the documentation are entitled to arbitrary distinctions. The
|
|
|
100 manual's licensed under a license that lets you change it (*note
|
|
|
101 Copying::), so if you disagree you can move the commands from section
|
|
|
102 to section yourself.) Mostly only commands that are implemented in
|
|
|
103 C-INTERCAL are covered here (if you're interested in the other commands
|
|
|
104 implemented in other compilers, read CLC-INTERCAL's documentation).
|
|
|
105 However, a comprehensive guide to portability of these commands between
|
|
|
106 C-INTERCAL and other INTERCAL compilers is given.
|
|
|
107
|
|
|
108 The third part covers the INTERCAL extensions and dialects that are
|
|
|
109 implemented by C-INTERCAL, such as TriINTERCAL and Threaded INTERCAL.
|
|
|
110 Again, extensions and dialects not implemented have been mostly left
|
|
|
111 out.
|
|
|
112
|
|
|
113 The final part contains appendices (which were known as `tonsils' in
|
|
|
114 the original INTERCAL manual), such as character sets used by INTERCAL,
|
|
|
115 programs other than `ick' in the C-INTERCAL distribution, information
|
|
|
116 on how to read and update the list of optimizer idioms used by the
|
|
|
117 compiler, and the copyright.
|
|
|
118
|
|
|
119
|
|
|
120 File: ick.info, Node: Installation, Next: Invoking ick, Prev: About this manual, Up: Top
|
|
|
121
|
|
|
122 1 Installation
|
|
|
123 **************
|
|
|
124
|
|
|
125 The C-INTERCAL distribution is distributed in source code form; this
|
|
|
126 means that before using it, you first have to compile it. Don't worry:
|
|
|
127 if you have the right software, it's not at all difficult. Most
|
|
|
128 Linux-based and UNIX-based computers are likely to have the software
|
|
|
129 needed already; the software needed to compile source-distributed
|
|
|
130 packages is also readily available for free for other operating
|
|
|
131 systems. The following instructions will help you install the
|
|
|
132 distribution in a method appropriate for your system.
|
|
|
133
|
|
|
134 (If you happen to be using Debian or Ubuntu, you can also obtain and
|
|
|
135 install binaries with the command `sudo apt-get install intercal',
|
|
|
136 making the rest of this chapter redundant. If you do this, use
|
|
|
137 Debian's bug tracker to report bugs, rather than reporting them
|
|
|
138 directly to the maintainers.)
|
|
|
139
|
|
|
140 * Menu:
|
|
|
141
|
|
|
142 * Obtaining:: How to get a C-INTERCAL distribution to install
|
|
|
143 * Unpacking:: What to do with the distribution file
|
|
|
144 * Simple Installation:: How to install things the easy way
|
|
|
145 * Uninstalling:: If you don't want to use the software
|
|
|
146 * Reporting Bugs:: If it doesn't work or you know how to fix it
|
|
|
147 * Distributing:: How to make your own C-INTERCAL distribution
|
|
|
148
|
|
|
149
|
|
|
150 File: ick.info, Node: Obtaining, Next: Unpacking, Up: Installation
|
|
|
151
|
|
|
152 1.1 Obtaining
|
|
|
153 =============
|
|
|
154
|
|
|
155 C-INTERCAL distributions have been stored in many different places over
|
|
|
156 time; it can sometimes be hard to make sure that you are finding the
|
|
|
157 most recent version. In order to make sure that you have the most
|
|
|
158 recent version, the easiest way is to look at the alt.lang.intercal
|
|
|
159 newsgroup; all releases of the C-INTERCAL compiler ought to be
|
|
|
160 announced there. (If you are interested in what other INTERCAL
|
|
|
161 compilers are available, it may also be worth looking there.) If you
|
|
|
162 don't have access to a newsreader, your newsreader doesn't cover that
|
|
|
163 newsgroup, or the distance between releases has been too large for your
|
|
|
164 news server to keep the message, it's likely that you can find the
|
|
|
165 announcement in an archive on the World Wide Web; at the time of
|
|
|
166 writing (2007), the archives of the newsgroup are stored by Google
|
|
|
167 Groups (http://groups.google.com), and a search for `alt.lang.intercal'
|
|
|
168 there should tell you where to find a copy.
|
|
|
169
|
|
|
170 If you're looking for the latest version, note that the number after the
|
|
|
171 dot represents the major version number; you want to maximise this in
|
|
|
172 favour of the number before the dot, which is the bugfix level within a
|
|
|
173 major version. (Major versions are released as version 0.whatever; if a
|
|
|
174 new version comes out that fixes bugs but adds no new features, nowadays
|
|
|
175 its number will be of the form 1.whatever, with the same major number.
|
|
|
176 This has not always been the case, though.)
|
|
|
177
|
|
|
178
|
|
|
179 File: ick.info, Node: Unpacking, Next: Simple Installation, Prev: Obtaining, Up: Installation
|
|
|
180
|
|
|
181 1.2 Unpacking
|
|
|
182 =============
|
|
|
183
|
|
|
184 C-INTERCAL is distributed in compressed pax format; for instance, you
|
|
|
185 may find as a `.pax.lzma' file if you have the `unlzma' decompression
|
|
|
186 program (this is advised, as it's the smallest); `.pax.bz2' is larger
|
|
|
187 and `.pax.gz' is larger still. Most computers can decompress files in
|
|
|
188 this format, even if they don't realise it, because pax is
|
|
|
189 forwards-compatible with tar; try renaming the extension from `.pax' to
|
|
|
190 `.tar' after decompressing to see if you have a progam that can
|
|
|
191 decompress it. (If you're wondering why such an apparently
|
|
|
192 non-standard format is being used, this is is actually a case where
|
|
|
193 C-INTERCAL is being perfectly nonstandard by conforming to the
|
|
|
194 standards; tar is no longer specified by POSIX, and pax is its
|
|
|
195 replacement. It's just that pax never really caught on.)
|
|
|
196
|
|
|
197 It doesn't matter where you extract the distribution file to: it's best
|
|
|
198 if you don't put it anywhere special. If you aren't an administrator,
|
|
|
199 you should extract the file to somewhere in your home directory (Linux
|
|
|
200 or UNIX-like systems) or to your My Documents directory (recent versions
|
|
|
201 of Windows; if you're using an older version, then you _are_ an
|
|
|
202 administrator, or at least have the same privileges, and can extract it
|
|
|
203 anywhere). Some commands that you might use to extract it:
|
|
|
204
|
|
|
205 Generic UNIX/Linux
|
|
|
206 unlzma ick-0-29.pax.lzma
|
|
|
207 tar xvf ick-0-29.pax
|
|
|
208 or
|
|
|
209 bunzip2 ick-0-29.pax.bz2
|
|
|
210 tar xvf ick-0-29.pax
|
|
|
211 or
|
|
|
212 gunzip ick-0-29.pax.gz
|
|
|
213 tar xvf ick-0-29.pax
|
|
|
214
|
|
|
215 On most UNIX-based and Linux-based systems, `tar' will be
|
|
|
216 available to unpack the installation files once they've been
|
|
|
217 uncompressed with `gunzip'. (I've heard that some BSD systems
|
|
|
218 have `pax' itself to decompress the files, although have not been
|
|
|
219 able to verify this; some Linux distributions also have `pax' in
|
|
|
220 their package managers. Both tar and pax should work fine,
|
|
|
221 though.) `gunzip' is also likely to be available (and `bunzip2'
|
|
|
222 and `unlzma' are less likely, but use those versions if you have
|
|
|
223 them to save on your bandwidth); if it isn't, you will need to
|
|
|
224 download a copy from the Internet.
|
|
|
225
|
|
|
226 Using GNU tar
|
|
|
227 tar xzvf ick-0-29.pax.gz
|
|
|
228 or
|
|
|
229 tar xqvf ick-0-29.pax.bz2
|
|
|
230
|
|
|
231 If you are using the GNU version of `tar' (which is very likely on
|
|
|
232 Linux), you can combine the two steps into one as shown here,
|
|
|
233 except when using the lzma-compressed version.
|
|
|
234
|
|
|
235 Using DJGPP
|
|
|
236 djtar -x ick-0-29.pax.gz
|
|
|
237
|
|
|
238 On a DOS system, you will have to install DJGPP anyway to be able
|
|
|
239 to compile the distribution, and once you've done that you will be
|
|
|
240 able to use DJGPP's decompressing and unpacking utility to extract
|
|
|
241 the files needed to install the distribution. (You will need to
|
|
|
242 type this at the command line; on Windows 95 and later, try
|
|
|
243 choosing Run... from the start menu then typing `cmd' (or
|
|
|
244 `command' if that fails) in the dialog box that opens to get a
|
|
|
245 command prompt, which you can exit by typing `exit'. After typing
|
|
|
246 any command at a command line, press <RET> to tell the shell to
|
|
|
247 execute that command.)
|
|
|
248
|
|
|
249 On Windows
|
|
|
250 If you're running a Windows system, you could always try
|
|
|
251 double-clicking on the ick-0-29.pax.gz file; probably renaming it
|
|
|
252 to have the extension `.tgz' is likely to give the best results.
|
|
|
253 It's quite possible that you'll have a program installed that's
|
|
|
254 capable of decompressing and unpacking it. Unfortunately, I can't
|
|
|
255 guess what program that might be, so I can't give you any
|
|
|
256 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
|
|
|
267 File: ick.info, Node: Simple Installation, Next: Uninstalling, Prev: Unpacking, Up: Installation
|
|
|
268
|
|
|
269 1.3 Simple Installation
|
|
|
270 =======================
|
|
|
271
|
|
|
272 There are scripts included in the distribution to automate the process
|
|
|
273 of installing, in various ways. The simplest method of installing is to
|
|
|
274 use the following routine:
|
|
|
275
|
|
|
276 1. Configure C-INTERCAL, by running `configure'. Although building
|
|
|
277 in the distribution directory works; it is recommended that you
|
|
|
278 build elsewhere; create a directory to build in (using `mkdir' on
|
|
|
279 most operating systems), then run `configure' from inside that
|
|
|
280 directory (for instance, you could do this from inside the main
|
|
|
281 installation directory:
|
|
|
282 mkdir build
|
|
|
283 cd build
|
|
|
284 ../configure
|
|
|
285 to build in a subdirectory of the distribution called "build").
|
|
|
286 You also specify where you want the files to be installed at this
|
|
|
287 stage; the default of `/usr/local' is good for many people, but
|
|
|
288 you may want to install elsewhere (in particular, if you want to
|
|
|
289 test out C-INTERCAL without installing it, create a new directory
|
|
|
290 somewhere you own and specify that as the place to install it, so
|
|
|
291 the install will actually just copy the files into the right
|
|
|
292 structure for use instead of installing them). To specify a
|
|
|
293 location, give the option `--prefix=LOCATION' to configure; for
|
|
|
294 instance, `configure --prefix=/usr' would install in /usr.
|
|
|
295
|
|
|
296 2. Compile the source code, with the command `make'. The Makefile
|
|
|
297 will be set up for your version of `make', and to automatically
|
|
|
298 recompile only what needs compiling (it will even recompile the
|
|
|
299 build system if you change that).
|
|
|
300
|
|
|
301 3. Optionally, create libraries from third-party interpreters to add
|
|
|
302 support for more languages to the C-INTERCAL external calls
|
|
|
303 system; see *note Creating the Funge-98 Library::. (This step can
|
|
|
304 be skipped; you can also do it later, but if you do so you need to
|
|
|
305 run the next step again.)
|
|
|
306
|
|
|
307 4. Install the executables, help files, include files, and libraries,
|
|
|
308 using `make install'. (This is the only step that needs
|
|
|
309 root/administrator permissions; so on a system that uses sudo to
|
|
|
310 elevate permissions, for instance, write it as `sudo make install'
|
|
|
311 if you're installing into a directory that you can't write to as a
|
|
|
312 non-administrative user.)
|
|
|
313
|
|
|
314
|
|
|
315 On all systems, it's worth just trying this to see if it works. This
|
|
|
316 requires a lot of software on your computer to work, but all of it is
|
|
|
317 standard on Linux and UNIX systems. The first command is a
|
|
|
318 shell-script which will analyse your system and set settings
|
|
|
319 accordingly; it will explain what it's doing and what settings it
|
|
|
320 detected, and create several files in the installation directory to
|
|
|
321 record its results. (This is a configure script produced by the GNU
|
|
|
322 autoconf (configure); its autoconf source code is available in the file
|
|
|
323 `configure.ac'.) The second command actually compiles the source code
|
|
|
324 to produce binaries; this takes the longest of any of the steps. You
|
|
|
325 will see all the commands that it's running as it runs them. The third
|
|
|
326 command will copy the files it's compiled to appropriate shared
|
|
|
327 locations on your system so that anyone on the system can just use
|
|
|
328 `ick'.
|
|
|
329
|
|
|
330 There may be various factors that prevent this simple installation
|
|
|
331 method working. On a system not based on UNIX or Linux, you may find
|
|
|
332 that you don't have some of the software required to run this (for
|
|
|
333 instance, you may be missing the shell `sh', and don't have the shell
|
|
|
334 `bash' which can emulate it, and so can't run `sh config.sh' that
|
|
|
335 depends on one of those shells being available) and so this method
|
|
|
336 won't work for you. In such cases, one solution may be to install all
|
|
|
337 the software required; the GNU project has a version of all the
|
|
|
338 commands required, for instance, and there may be ports available for
|
|
|
339 your operating system. However, the only software absolutely required
|
|
|
340 is a C compiler (C-INTERCAL was designed to work with `gcc' and is
|
|
|
341 tested mostly with that compiler, but in theory it should work with
|
|
|
342 other C compilers too, and this is tested on occasion) and the
|
|
|
343 associated software needed to compile C files to object files and
|
|
|
344 executables, combine object files into libraries, etc.
|
|
|
345
|
|
|
346 Another possibility that might stop this process working is if your
|
|
|
347 version of the relevant software is incompatible with the GNU versions
|
|
|
348 that were used for testing. For instance, I have come across
|
|
|
349 proprietary versions of `lex' that need directives in the source file
|
|
|
350 to say in advance how much memory the lexer-generator needs to
|
|
|
351 allocate. In such cases, pay attention to the error messages you're
|
|
|
352 getting; normally they will suggest trivial modifications to the source
|
|
|
353 files that will cause the compilation to work again.
|
|
|
354
|
|
|
355 Some Linux and UNIX systems (notably Debian and Ubuntu) don't have the
|
|
|
356 required files for compilation installed by default. To install them,
|
|
|
357 just download and install the required packages: for Ubuntu at the time
|
|
|
358 of writing, they are `binutils', `cpp', `gcc', `libc6-dev', `make' to
|
|
|
359 compile C-INTERCAL, and if you want to modify it, you may also need
|
|
|
360 `autoconf', `automake', `bison', and `flex'. For debugging help, you
|
|
|
361 may also want `gdb', and to recompile the documentation, you may need
|
|
|
362 `groff', `tetex-bin', `texinfo', and `tidy'. Of course, if INTERCAL
|
|
|
363 ever (the author of this sentence was going to write something like
|
|
|
364 "becomes popular, someone will probably package up a compiler for
|
|
|
365 Debian or Ubuntu anyway", but at that point on a whim did an Ubuntu
|
|
|
366 package search for 'intercal' and actually came up with two results,
|
|
|
367 which look suspiciously like C-INTERCAL and CLC-INTERCAL, later
|
|
|
368 confirming this. The author was vaguely aware that there was a
|
|
|
369 CLC-INTERCAL package floating around, but was unaware of the C-INTERCAL
|
|
|
370 package, and as a result was too surprised to finish the sentence.)
|
|
|
371
|
|
|
372 If you're trying to do something unusual, you probably want to set some
|
|
|
373 of the settings yourself rather than letting the compilation process
|
|
|
374 guess everything. In this case, use `configure --help' to view the
|
|
|
375 options that you can set on `configure'; there's a wide range of
|
|
|
376 settings that you can set available there, and one of them may be what
|
|
|
377 you want.
|
|
|
378
|
|
|
379
|
|
|
380 File: ick.info, Node: Uninstalling, Next: Reporting Bugs, Prev: Simple Installation, Up: Installation
|
|
|
381
|
|
|
382 1.4 Uninstalling
|
|
|
383 ================
|
|
|
384
|
|
|
385 It may happen that you decide to uninstall C-INTERCAL after installing
|
|
|
386 it; this may be useful if you want to test the installation system, or
|
|
|
387 change the location you install programs, or for some reason you don't
|
|
|
388 want it on your computer. It's worth uninstalling just before you
|
|
|
389 install a new version of C-INTERCAL because this will save some disk
|
|
|
390 space; you cannot install two versions of C-INTERCAL at once (at least,
|
|
|
391 not in the same directory; but you can change the -prefix of one of the
|
|
|
392 installations to get two versions at once).
|
|
|
393
|
|
|
394 If you installed C-INTERCAL using `make install', you can uninstall it
|
|
|
395 by using `make uninstall' from the installation directory, assuming
|
|
|
396 that it still exists. If you can't use that method for some reason,
|
|
|
397 you can uninstall it by deleting the files `ick' and `convickt' where
|
|
|
398 your computer installs binaries (with an extension like `.exe' added if
|
|
|
399 that's usual for binaries on your operating system), `libick.a',
|
|
|
400 `libickmt.a', `libickec.a', and `libyuk.a' where your computer installs
|
|
|
401 libraries, and the subdirectories `ick-0.29' in the places where your
|
|
|
402 computer installs data files and include files, and their contents.
|
|
|
403
|
|
|
404 You can go further than uninstalling. Running `make clean' will delete
|
|
|
405 any files created by compilation; `make distclean' will delete those
|
|
|
406 files, and also any files created by configuring. It's probably a wise
|
|
|
407 idea to uninstall before doing a distclean, though, as otherwise
|
|
|
408 information needed to uninstall will be deleted, as that information is
|
|
|
409 generated by `configure'.
|
|
|
410
|
|
|
411
|
|
|
412 File: ick.info, Node: Reporting Bugs, Next: Distributing, Prev: Uninstalling, Up: Installation
|
|
|
413
|
|
|
414 1.5 Reporting Bugs
|
|
|
415 ==================
|
|
|
416
|
|
|
417 If you can't get C-INTERCAL to install at all, or something goes wrong
|
|
|
418 when you're using it, reporting a bug is probably a good idea. (This is
|
|
|
419 still important even if you figure out how to fix it, and the
|
|
|
420 information isn't in the manual, because the fix can be added to the
|
|
|
421 source code if possible, or at least to the manual, to benefit future
|
|
|
422 users.) For general help, you may want to post to the
|
|
|
423 alt.lang.intercal news group; to report a bug or submit a patch, email
|
|
|
424 the person who released the most recent C-INTERCAL version (which you
|
|
|
425 can determine by looking at that newsgroup).
|
|
|
426
|
|
|
427 If you do find a bug (either the compiler not behaving in the way you'd
|
|
|
428 expect, or if you find a way to cause E778 (*note E778::) without
|
|
|
429 modifying the source code), it helps a lot if you can submit a bug
|
|
|
430 report explaining what causes it. If you're not sure, say that; it
|
|
|
431 helps if you give examples of input, command line options, etc. that
|
|
|
432 cause the bug. There are several debug options (*note Debug Options::)
|
|
|
433 that you can use to help pin down a bug if you're interested in trying
|
|
|
434 to solve the problem yourself; looking at the output C code can also
|
|
|
435 help pin down a bug if the compiler gets that far.
|
|
|
436
|
|
|
437 Information that should be given in a bug report is what you expect to
|
|
|
438 happen, what actually happens, what input and command line options you
|
|
|
439 gave to the compiler, what operating system you're using, any ideas you
|
|
|
440 might have as to what the problem is, and any appropriate debug traces
|
|
|
441 (for instance, `-H' (*note -H: -H+.) output if you think the bug is in
|
|
|
442 the optimizer). Core dumps aren't portable between systems, so don't
|
|
|
443 send those; however, if you're getting an internal error and can dump
|
|
|
444 core with `-U' (*note -U: -U+.), it helps if you can load a debugger
|
|
|
445 (such as `gdb') on the core dump, use the debugger to produce a
|
|
|
446 backtrace, and send that backtrace.
|
|
|
447
|
|
|
448 If you figure out how to solve the bug yourself, and want to submit the
|
|
|
449 patches to help other users (this also carries the advantage that your
|
|
|
450 patches will then be maintained along with the rest of the distribution,
|
|
|
451 and that you won't have to reapply them every time you upgrade to a
|
|
|
452 newer version of C-INTERCAL), you must first agree to license your code
|
|
|
453 under the same license as the code that surrounds it (normally, that's
|
|
|
454 the GNU General Public License, but if you submit a patch to a file with
|
|
|
455 a different license, like this manual (yes, documentation patches are
|
|
|
456 useful too), you must agree to that license). You will be credited for
|
|
|
457 the patch in the source code unless you specifically ask not to be or
|
|
|
458 you don't give your name (in both these cases, you must license the code
|
|
|
459 to the public domain so that it can be incorporated without the
|
|
|
460 attribution requirement). Preferably, patches should be submitted in
|
|
|
461 the format created by the command `diff -u'; this command is likely to
|
|
|
462 be available on UNIX and Linux systems and versions are also available
|
|
|
463 for DOS and Windows (including a DJGPP port of the GNU version). If
|
|
|
464 you can't manage that, just submit your new code with enough lines of
|
|
|
465 old code around it to show where it's meant to go, and a description of
|
|
|
466 approximately where in the file it was. Patches should be submitted by
|
|
|
467 email to the person who most recently released a version of C-INTERCAL.
|
|
|
468
|
|
|
469 If you have a suggestion for a new feature, it makes sense to first
|
|
|
470 discuss it on the alt.lang.intercal news group; other INTERCAL compiler
|
|
|
471 maintainers may also want to implement that feature. If you have
|
|
|
472 developed code to implement that feature in C-INTERCAL, you can submit
|
|
|
473 it the same way that you would submit a patch for a bug.
|
|
|
474
|
|
|
475
|
|
|
476 File: ick.info, Node: Distributing, Prev: Reporting Bugs, Up: Installation
|
|
|
477
|
|
|
478 1.6 Distributing
|
|
|
479 ================
|
|
|
480
|
|
|
481 Due to the licensing conditions of C-INTERCAL, you are allowed to
|
|
|
482 release your own version or distribution if you want to. In such
|
|
|
483 cases, it's recommended that you follow the following guidelines:
|
|
|
484
|
|
|
485 1. Make sure the new version is based on the most recent existing
|
|
|
486 version. Looking at the alt.lang.intercal newsgroup will normally
|
|
|
487 let you know what version is most recent.
|
|
|
488
|
|
|
489 2. Increment the version number; if you add any new features,
|
|
|
490 increment the major version number (after the decimal point) and
|
|
|
491 drop the minor version number (before the decimal point) to 0, and
|
|
|
492 otherwise increment the minor version number. You have to update
|
|
|
493 the version number in the following files: `configure.ac',
|
|
|
494 `configure', and `doc/ick.txi'. You also have to rename the
|
|
|
495 installation directory to reflect the new version number.
|
|
|
496
|
|
|
497 3. Add an entry to the `NEWS' file explaining what's new in the
|
|
|
498 version that you're releasing, following the same format as the
|
|
|
499 other entries.
|
|
|
500
|
|
|
501 4. Update the `README' with a description of any new files you may
|
|
|
502 have added.
|
|
|
503
|
|
|
504 5. Remove any autosave or backup files that may be littering the
|
|
|
505 installation directory or its subdirectories.
|
|
|
506
|
|
|
507 6. Run `make distcheck', which will make the distribution paxballs,
|
|
|
508 and rename them to have the correct extensions (Automake thinks
|
|
|
509 they're tarballs, so will use `.tar' rather than `.pax', and you
|
|
|
510 have to fix this by hand). `make distcheck' will also perform
|
|
|
511 some sanity checks on the build system of the resulting paxball,
|
|
|
512 which will help to ensure that nothing important is missing from
|
|
|
513 it.
|
|
|
514
|
|
|
515 7. Place the new version somewhere on the Internet, and announce the
|
|
|
516 location and the fact that a new version has been released on
|
|
|
517 alt.lang.intercal.
|
|
|
518
|
|
|
519
|
|
|
520
|
|
|
521 File: ick.info, Node: Invoking ick, Next: Errors and Warnings, Prev: Installation, Up: Top
|
|
|
522
|
|
|
523 2 Invoking ick
|
|
|
524 **************
|
|
|
525
|
|
|
526 All operations on INTERCAL source code available in C-INTERCAL are
|
|
|
527 currently carried out by the compiler `ick'.
|
|
|
528
|
|
|
529 The syntax is
|
|
|
530
|
|
|
531 ick -options INPUTFILE
|
|
|
532
|
|
|
533 (Options can be given preceded by separate hyphens, or all in a row
|
|
|
534 after one hyphen, or a mixture; they're all single characters.) By
|
|
|
535 default, this compiles one INTERCAL program given as the input file
|
|
|
536 directly to an executable without doing anything fancy; usually you will
|
|
|
537 want to give options, which are described below.
|
|
|
538
|
|
|
539 * Menu:
|
|
|
540
|
|
|
541 * Language-affecting Options:: Options that specify language dialect
|
|
|
542 * Debug Options:: Debug your code or ick itself
|
|
|
543 * Output Options:: Specifying output format and location
|
|
|
544 * Optimizer Options:: Yes, you can optimize INTERCAL!
|
|
|
545 * Other Options:: Options not covered in other sections
|
|
|
546 * Options to Generated Programs:: Generated executables allow options too
|
|
|
547 * Environment Variables:: What environment variables affect ick
|
|
|
548
|
|
|
549
|
|
|
550 File: ick.info, Node: Language-affecting Options, Next: Debug Options, Up: Invoking ick
|
|
|
551
|
|
|
552 2.1 Language-affecting Options
|
|
|
553 ==============================
|
|
|
554
|
|
|
555 The following command-line options to `ick' affect what dialect of the
|
|
|
556 INTERCAL language is compiled by the compiler; you may need to set one
|
|
|
557 or more of these options if your input is not the default C-INTERCAL but
|
|
|
558 instead some other language like INTERCAL-72 or CLC-INTERCAL, or just
|
|
|
559 because you like certainty or like being different with respect to your
|
|
|
560 output. Note that there is no command-line option corresponding to
|
|
|
561 TriINTERCAL (or the base 4-7 versions); instead, the numeric base to
|
|
|
562 use is determined by looking at the filename extension (`.i' for base
|
|
|
563 2, the default, or `.3i' to `.7i' for the base 3-7 versions.)
|
|
|
564
|
|
|
565 `-b'
|
|
|
566 If this option is _not_ given, there is a small chance that a
|
|
|
567 random bug appears in the compiler, which causes the programs it
|
|
|
568 creates to manifest a bug that causes error E774 (*note E774::).
|
|
|
569 Giving the option means that this bug will not happen. (You may
|
|
|
570 wonder why this bug was preserved; it is in fact a bug that was
|
|
|
571 carefully preserved since the days of INTERCAL-72, in this case,
|
|
|
572 but the option to turn it off is available as a workaround.
|
|
|
573 (There are no plans to fix this or any of the other carefully
|
|
|
574 preserved bugs any time soon, because that would kind of defeat
|
|
|
575 the point of having preserved them.) Interestingly, the
|
|
|
576 INTERCAL-72 compiler documentation mentions a similar command-line
|
|
|
577 option that is a workaround for the same bug.)
|
|
|
578
|
|
|
579 `-m'
|
|
|
580 This option needs to be given to allow any multithreading or
|
|
|
581 backtracking commands or identifiers to be used. (Unlike with
|
|
|
582 other language features, this is not autodetected because it's
|
|
|
583 legal to have a program with multiple COME FROM (*note COME
|
|
|
584 FROM::) commands aiming at the same line even when it isn't
|
|
|
585 multithreaded, in which case the commands cause error E555 (*note
|
|
|
586 E555::) when that line is encountered (with the usual caveats
|
|
|
587 about both commands having to be active at the time).) Attempts
|
|
|
588 to use non-COME FROM multithreading or backtracking commands
|
|
|
589 without this option produce error E405 (*note E405::).
|
|
|
590
|
|
|
591 `-e'
|
|
|
592 This option makes it possible to link non-INTERCAL programs with
|
|
|
593 INTERCAL programs; instead of giving INTERCAL programs only on the
|
|
|
594 command line, give one INTERCAL program, followed by any number of
|
|
|
595 programs in other languages that have been written to be able to
|
|
|
596 link to INTERCAL programs. It also allows expansion libraries to
|
|
|
597 be specified on the command line, after the INTERCAL program
|
|
|
598 (expansion libraries are given with no extension). For more
|
|
|
599 information, see *note External Calls::. Also, both the `-a' and
|
|
|
600 `-e' options must be set to use CREATEd operators (regardless of
|
|
|
601 whether external calls are used or not).
|
|
|
602
|
|
|
603 `-E'
|
|
|
604 This option causes the system library to never be linked; this
|
|
|
605 option is only useful if your program references a line number in
|
|
|
606 the range 1000 to 1999, contains no line numbers in that range,
|
|
|
607 and yet still doesn't want the system library to be linked in;
|
|
|
608 therefore, it is mostly useful with `-e' when adding in a custom
|
|
|
609 replacement system library written in a non-INTERCAL language,
|
|
|
610 especially the expansion library `syslibc' (a system library
|
|
|
611 replacement written in C).
|
|
|
612
|
|
|
613 `-t'
|
|
|
614 This option tells the compiler to treat the source code as
|
|
|
615 INTERCAL-72; as a result, any language constructs that are used
|
|
|
616 but weren't available in 1972 will trigger error E111 (*note
|
|
|
617 E111::).
|
|
|
618
|
|
|
619 `-a'
|
|
|
620 This option allows the CREATE statement (*note CREATE::) to be
|
|
|
621 used. Note that enabling it carries a run-time penalty, as it
|
|
|
622 means that operand overloading code has to be generated for every
|
|
|
623 variable in the program. (This option is not necessarily needed
|
|
|
624 for the external call version of CREATE to work, but the external
|
|
|
625 call version has fewer features without it.) Note that `-e'
|
|
|
626 (*note -e::) also needs to be set to be able to CREATE operators.
|
|
|
627
|
|
|
628 `-v'
|
|
|
629 It is possible to write INTERCAL code sufficiently tortuous that
|
|
|
630 it ends up assigning to a constant. Generally speaking, this
|
|
|
631 isn't what you wanted to do, so the compiler will kindly cause an
|
|
|
632 error (E277; *note E277::) that stops the insanity at that point,
|
|
|
633 but at the cost of a significant amount of performance you can
|
|
|
634 give this option to tell the compiler to simply change the
|
|
|
635 constant and keep on going anyway. (Note that unlike
|
|
|
636 CLC-INTERCAL, this only changes uses of the constant preceded by
|
|
|
637 `#' in your program, not things like line numbers; you want Forte
|
|
|
638 (http://esolangs.org/wiki/Forte) for that.) This option also
|
|
|
639 allows you to write arbitary expressions on the left of an
|
|
|
640 assignment statement if you wish.
|
|
|
641
|
|
|
642 `-C'
|
|
|
643 When this option is given, the generated programs will write the
|
|
|
644 number 4 as `IIII' rather than `IV', in case you're writing a clock
|
|
|
645 program.
|
|
|
646
|
|
|
647 `-P'
|
|
|
648 This tells the compiler to treat the input as PIC-INTERCAL (*note
|
|
|
649 PIC-INTERCAL::) rather than ordinary C-INTERCAL input, and generate
|
|
|
650 PIC output code accordingly. There are a lot of options that are
|
|
|
651 incompatible with this, as well as many language features, due to
|
|
|
652 the limited memory available on a PIC. If you get error E256
|
|
|
653 (*note E256::), you have this option given when it shouldn't be;
|
|
|
654 likewise, if you get error E652 (*note E652::), you should be
|
|
|
655 using this option but aren't. (A few simple programs are
|
|
|
656 C-INTERCAL/PIC-INTERCAL polyglots, but such programs are incapable
|
|
|
657 of doing input or output, meaning that they aren't particularly
|
|
|
658 useful.)
|
|
|
659
|
|
|
660 `-X'
|
|
|
661 The C-INTERCAL and CLC-INTERCAL compilers use different notation
|
|
|
662 for various things, sometimes to the extent where the same
|
|
|
663 notation is legal in both cases but has a different meaning. As
|
|
|
664 this is the C-INTERCAL compiler, it rather guessably uses its own
|
|
|
665 notation by default; however, the CLC-INTERCAL notation can be
|
|
|
666 used as the default instead using this option. (In most
|
|
|
667 situations where there isn't an ambiguity about what something
|
|
|
668 means, you can use the `wrong' syntax freely.) The option causes
|
|
|
669 ambiguous characters like `?' to be interpreted with Princeton
|
|
|
670 rather than Atari meanings.
|
|
|
671
|
|
|
672 `-x'
|
|
|
673 This option causes some constructs with different meanings in
|
|
|
674 C-INTERCAL and CLC-INTERCAL to use the CLC-INTERCAL meaning rather
|
|
|
675 than the C-INTERCAL meaning. At present, it affects the abstention
|
|
|
676 of a GIVE UP (*note GIVE UP::) command by line number, which is
|
|
|
677 possible as long as this switch isn't given; reading through the
|
|
|
678 INTERCAL-72 manual, there are a lot of things that imply that this
|
|
|
679 probably wasn't intended to be possible, but as far as I can tell
|
|
|
680 that manual doesn't actually _say_ anywhere that this particular
|
|
|
681 case is disallowed, even though it rules out all other similar
|
|
|
682 cases. It also causes I/O on array variables to be done in
|
|
|
683 CLC-INTERCAL's extended Baudot syntax, rather than using the
|
|
|
684 Turing Tape method.
|
|
|
685
|
|
|
686
|
|
|
687
|
|
|
688 File: ick.info, Node: Debug Options, Next: Output Options, Prev: Language-affecting Options, Up: Invoking ick
|
|
|
689
|
|
|
690 2.2 Debug Options
|
|
|
691 =================
|
|
|
692
|
|
|
693 Sometimes things will go wrong with your program, or with the way `ick'
|
|
|
694 was installed. There may even be unknown bugs in `ick' itself (if you
|
|
|
695 find one of these, please report it). The following options are used
|
|
|
696 to debug the whole system on various levels.
|
|
|
697
|
|
|
698 `-d'
|
|
|
699 If you think that something has gone wrong with the parser, or you
|
|
|
700 want to see how your program is being parsed, you can give this
|
|
|
701 option on the command line. All the debug output produced by the
|
|
|
702 parser and lexical analyser will be output.
|
|
|
703
|
|
|
704 `-g'
|
|
|
705 This option allows debugging of the final executable at the C code
|
|
|
706 level. Any C code generated will be left in place, and the `-g'
|
|
|
707 option will be given to the C compiler that's used to compile the
|
|
|
708 code, so all the information needed for a C debugger to be used on
|
|
|
709 the executable will be present there.
|
|
|
710
|
|
|
711 `-h'
|
|
|
712 `-H'
|
|
|
713 `-hH'
|
|
|
714 These options allow debugging of the optimiser, or produce output
|
|
|
715 helpful for understanding how your program has been summarised.
|
|
|
716 `-h' produces a summary of what optimiser rules were used, the
|
|
|
717 initial expression and what it was optimised to; `-H' produces a
|
|
|
718 more expanded view that shows each intermediate step of
|
|
|
719 optimisation, and `-hH' shows the same output as `-H', but written
|
|
|
720 completely using C syntax (the other options output in a strange
|
|
|
721 mix of INTERCAL and C).
|
|
|
722
|
|
|
723 `-l'
|
|
|
724 This option turns on generation of warnings (*note Warnings::).
|
|
|
725 To make sure that they aren't actually useful, or are only
|
|
|
726 marginally useful, the warning generator is far too sensitive, and
|
|
|
727 there is no way to decide which warnings are given and which ones
|
|
|
728 aren't; you either get all of them or none.
|
|
|
729
|
|
|
730 `-p'
|
|
|
731 This option causes the program to run immediately after being
|
|
|
732 compiled, and profiles the resulting program to identify
|
|
|
733 performance bottlenecks, etc. The usefulness of this depends on
|
|
|
734 the resolution of the timers on the computer and operating system;
|
|
|
735 DOS, in particular, is really bad with timer resolution. The
|
|
|
736 output will be saved in a file called `yuk.out' when the program
|
|
|
737 finishes running. It's legal to turn on both the profiler and the
|
|
|
738 interactive debugger at the same time, but if you do this the
|
|
|
739 profiler will also identify bottlenecks in the person typing in
|
|
|
740 commands to step through the program! The profiler will, in fact,
|
|
|
741 identify all the timings that particular commands in the program
|
|
|
742 take; so `WRITE IN' instructions will often show up as taking a
|
|
|
743 long time due to their need to wait for input.
|
|
|
744
|
|
|
745 `-w'
|
|
|
746 This option causes the produced program to support the `printflow'
|
|
|
747 option fully; when this option is not given, `printflow' will in
|
|
|
748 most cases have partial or no support (except in multithreaded
|
|
|
749 programs, where this option is redundant), because not all the
|
|
|
750 code needed for it will be included in the program to save space.
|
|
|
751
|
|
|
752 `-u'
|
|
|
753 When you are getting problems with finding files - for instance,
|
|
|
754 the compiler can't find the skeleton file (*note E999::) or the
|
|
|
755 system library (*note E127::) - this option will let you know, on
|
|
|
756 standard error, where the compiler is looking for files. This may
|
|
|
757 hopefully help you pin down where the file-finding problems are
|
|
|
758 coming from, and also offers the option of simply placing copies
|
|
|
759 of the files where the compiler is looking as a last resort.
|
|
|
760
|
|
|
761 `-y'
|
|
|
762 This is the main debugging option: it loads yuk, an interactive
|
|
|
763 INTERCAL debugger with ability to step through the program, set
|
|
|
764 breakpoints, view and modify variables, etc. *Note yuk::.
|
|
|
765
|
|
|
766 `-Y'
|
|
|
767 This options causes the command line to be displayed for all calls
|
|
|
768 to other programs that `ick' makes (mostly to `gcc'); it is
|
|
|
769 therefore useful for debugging problems with the command lines used
|
|
|
770 when using the external calls system (*note External Calls::).
|
|
|
771
|
|
|
772 `-U'
|
|
|
773 The internal error E778 (*note E778::) should never happen.
|
|
|
774 However, there are all sorts of potential problems that may come
|
|
|
775 up, and if part of the code detects something impossible, or more
|
|
|
776 usually when the operating system detects things have got too
|
|
|
777 insane and segfaults, normally this error will just be generated
|
|
|
778 and that's that. (I most often get this when I've been writing a
|
|
|
779 new section of code and have made a mistake; hopefully, all or at
|
|
|
780 least most of these errors are fixed before release, though.) If
|
|
|
781 you want more information as to what's going on, you can give the
|
|
|
782 `-U' option, which will cause the compiler to raise an abort
|
|
|
783 signal when an internal error happens. This can generally be
|
|
|
784 caught by a debugger that's being run on `ick' itself at the time;
|
|
|
785 on many systems, it will also cause a core dump.
|
|
|
786
|
|
|
787
|
|
|
788
|
|
|
789 File: ick.info, Node: Output Options, Next: Optimizer Options, Prev: Debug Options, Up: Invoking ick
|
|
|
790
|
|
|
791 2.3 Output Options
|
|
|
792 ==================
|
|
|
793
|
|
|
794 These options allow you to control how far to compile (all the way to an
|
|
|
795 executable, or only to C, etc.), and where the output will be created.
|
|
|
796 Note that the output options may change depending on the other options
|
|
|
797 selected; for instance, many of the debug options will prevent the code
|
|
|
798 being compiled all the way to an executable.
|
|
|
799
|
|
|
800 `-c'
|
|
|
801 By default, the original INTERCAL code will be compiled all the
|
|
|
802 way to an executable, and the intermediate C and object files
|
|
|
803 produced will be deleted. Giving this option causes the compiler
|
|
|
804 to stop when it has finished producing the C file, leaving the C
|
|
|
805 file there as the final output of the compiler. (Its filename is
|
|
|
806 the same as the source file, but with `.c' as its extension/suffix
|
|
|
807 rather than the source file's extension.) Without this option, an
|
|
|
808 executable will be produced with the extension changed to
|
|
|
809 whatever's appropriate for the system you are on (or omitted
|
|
|
810 entirely if that's appropriate for the system).
|
|
|
811
|
|
|
812 This option also places verbose comments in the output C file.
|
|
|
813
|
|
|
814 `-o'
|
|
|
815 This option causes the compiler to progress no further than
|
|
|
816 producing the C output file, but instead of writing it to a file
|
|
|
817 writes it directly to standard output. This might occasionally be
|
|
|
818 useful when using `ick' as part of a pipe; it can also be useful
|
|
|
819 to see how far the compiler gets with compiling code before an
|
|
|
820 error happens, when you're trying to track down an error.
|
|
|
821
|
|
|
822
|
|
|
823
|
|
|
824 File: ick.info, Node: Optimizer Options, Next: Other Options, Prev: Output Options, Up: Invoking ick
|
|
|
825
|
|
|
826 2.4 Optimizer Options
|
|
|
827 =====================
|
|
|
828
|
|
|
829 There are various command line options that can be used to tell `ick'
|
|
|
830 whether and in what ways to optimize code.
|
|
|
831
|
|
|
832 `-f'
|
|
|
833 This option requests the compiler to attempt to analyse the flow
|
|
|
834 of the program and optimize accordingly; for instance, it will
|
|
|
835 detect which commands can't possibly be `ABSTAINED' from and
|
|
|
836 refrain from generating code to check the abstention status of
|
|
|
837 those commands.
|
|
|
838
|
|
|
839 `-F'
|
|
|
840 This option tells the compiler to optimize the output for speed.
|
|
|
841 This is done to crazy extremes; the compiler may take several
|
|
|
842 hours/days analysing the program in some cases and still not come
|
|
|
843 up with an improvement. It turns on all the other optimizer
|
|
|
844 options. Note that not all systems accept this option, because it
|
|
|
845 sometimes outputs a shell script disguised as an executable rather
|
|
|
846 than an actual executable.
|
|
|
847
|
|
|
848 `-O'
|
|
|
849 This option tells the compiler to apply optimizer idioms to the
|
|
|
850 expressions in the code given, when appropriate. The list of
|
|
|
851 idioms is stored in the file `src/idiotism.oil'; note that it is
|
|
|
852 compiled into the compiler, though, so you will have to rebuild
|
|
|
853 and reinstall the compiler if you change it. For more information
|
|
|
854 about changing the list of idioms, see *note Optimizer Idiom
|
|
|
855 Language::.
|
|
|
856
|
|
|
857
|
|
|
858
|
|
|
859 File: ick.info, Node: Other Options, Next: Options to Generated Programs, Prev: Optimizer Options, Up: Invoking ick
|
|
|
860
|
|
|
861 2.5 Other Options
|
|
|
862 =================
|
|
|
863
|
|
|
864 Some options just can't be classified.
|
|
|
865
|
|
|
866 `-@'
|
|
|
867 If this option is given, the compiler doesn't run at all, but
|
|
|
868 instead prints a set of instructions for using it, explaining
|
|
|
869 which options are available on the system you're on and which
|
|
|
870 options conflict with which other options.
|
|
|
871
|
|
|
872
|
|
|
873
|
|
|
874 File: ick.info, Node: Options to Generated Programs, Next: Environment Variables, Prev: Other Options, Up: Invoking ick
|
|
|
875
|
|
|
876 2.6 Options to Generated Programs
|
|
|
877 =================================
|
|
|
878
|
|
|
879 Once the compiler runs and produces an output executable, that
|
|
|
880 executable itself will accept a range of options that control the way it
|
|
|
881 runs. None of these options have to be used; a default value will be
|
|
|
882 assumed if they aren't.
|
|
|
883
|
|
|
884 `+help'
|
|
|
885 `-help'
|
|
|
886 Whether `+' or `-' is given at the start of this option, it will
|
|
|
887 cause the program to print out what options are available and what
|
|
|
888 state they are in. It will then cause the program to exit via an
|
|
|
889 internal error.
|
|
|
890
|
|
|
891 `+wimpmode'
|
|
|
892 `-wimpmode'
|
|
|
893 If the `+' version of this is given (rather than the default `-'),
|
|
|
894 then the program will print a message explaining that you are a
|
|
|
895 wimp (the mode itself is known as wimpmode), and for the rest of
|
|
|
896 execution will input in Arabic numerals (`123' rather than `ONE
|
|
|
897 TWO THREE') and likewise will output in Arabic numerals rather
|
|
|
898 than Roman numerals (such as `CXXIII'). True INTERCAL programmers
|
|
|
899 should rarely have to use this mode.
|
|
|
900
|
|
|
901 `+traditional'
|
|
|
902 `-traditional'
|
|
|
903 This option does not actually appear to do anything.
|
|
|
904
|
|
|
905 `+instapipe'
|
|
|
906 `-instapipe'
|
|
|
907 This option causes standard output to be flushed whenever any
|
|
|
908 characters are output when the `+' version is used, rather than on
|
|
|
909 each newline (the default `-' version). It is most useful for
|
|
|
910 more responsive pipes when outputting binary data, and also useful
|
|
|
911 for debugging very slow programs.
|
|
|
912
|
|
|
913 `+printflow'
|
|
|
914 `-printflow'
|
|
|
915 The usual debugging methods don't work with multithreaded or
|
|
|
916 backtracking programs. This option exists to give at least a slim
|
|
|
917 chance of working out what is going on with them. It causes the
|
|
|
918 program to print the line number of the command it thinks it may be
|
|
|
919 executing next (i.e. the line number that would be printed if that
|
|
|
920 line had an error) immediately after executing each command, and
|
|
|
921 also an internal identifier for the thread that that command was
|
|
|
922 in. It also prints a trace of what parts of the multithreader are
|
|
|
923 being activated; so for instance, it will tell you when a thread
|
|
|
924 is being forked into multiple threads or when a choicepoint has
|
|
|
925 been deleted. Note that the `-w' option (*note -w::) must be
|
|
|
926 given to gain full support for flow printing in non-multithreaded
|
|
|
927 non-backtracking programs, because otherwise the required code to
|
|
|
928 print this information will not be generated.
|
|
|
929
|
|
|
930 `+mystery'
|
|
|
931 `-mystery'
|
|
|
932 This option is occasionally capable of doing something, but is
|
|
|
933 deliberately undocumented. Normally changing it will have no
|
|
|
934 effect, but changing it is not recommended.
|
|
|
935
|
|
|
936
|
|
|
937
|
|
|
938 File: ick.info, Node: Environment Variables, Prev: Options to Generated Programs, Up: Invoking ick
|
|
|
939
|
|
|
940 2.7 Environment Variables
|
|
|
941 =========================
|
|
|
942
|
|
|
943 Various environment variables can be set to affect the operation of
|
|
|
944 `ick'.
|
|
|
945
|
|
|
946 Variable Meaning
|
|
|
947 --------------------------------------------------------------------------
|
|
|
948 ICKINCLUDEDIR These three environment variables suggest
|
|
|
949 ICKLIBDIR locations in which `ick' should look to find
|
|
|
950 ICKDATADIR various files that it needs: the skeleton file,
|
|
|
951 system library, C header files and libraries that
|
|
|
952 it needs, constant-output optimiser, and the GNU
|
|
|
953 General Public License (which the debugger needs
|
|
|
954 to be able to display on demand for legal
|
|
|
955 reasons).
|
|
|
956 CC The name of a C compiler to use (defaults to gcc,
|
|
|
957 which is the only compiler with which C-INTERCAL
|
|
|
958 has been tested recently). This option has no
|
|
|
959 effect on DJGPP, where gcc is always used.
|
|
|
960 ICKTEMP On DJGPP, `ick' creates temporary files to pass
|
|
|
961 TMPDIR options to gcc as a method of getting around the
|
|
|
962 TEMP limit on the length of a command line that can
|
|
|
963 TMP sometimes affect DOS programs. These four
|
|
|
964 environment variables are tried (in this order)
|
|
|
965 to determine a location for the temporary file;
|
|
|
966 if none of them are set, the current directory is
|
|
|
967 used.
|
|
|
968
|
|
|
969
|
|
|
970 File: ick.info, Node: Errors and Warnings, Next: The yuk debugger, Prev: Invoking ick, Up: Top
|
|
|
971
|
|
|
972 3 Errors and Warnings
|
|
|
973 *********************
|
|
|
974
|
|
|
975 Things may go wrong, either during the compilation or the execution of
|
|
|
976 your program. Note that some things that would be compile-time errors
|
|
|
977 in many other languages - such as syntax errors - are in fact run-time
|
|
|
978 errors in INTERCAL.
|
|
|
979
|
|
|
980 Errors and warnings appear as an error code starting with `ICL',
|
|
|
981 followed by a three digit number, followed by `I' for an error or `W'
|
|
|
982 for a warning. However, they will be notated here as `E000', etc., to
|
|
|
983 save space and because consistency was never a strong point of
|
|
|
984 INTERCAL. This is followed by a text description of the error, and a
|
|
|
985 hint as to the location of the error. This is not the line on which
|
|
|
986 the error occurred, but rather the line on which the next command to be
|
|
|
987 executed is. To add to the fun, the calculation of the next command to
|
|
|
988 be executed is done at compile-time rather than runtime, so it may be
|
|
|
989 completely wrong due to things like abstention on `COME FROM's or
|
|
|
990 computed `COME FROM's. The moral of this story is that, if you really
|
|
|
991 want to know where the error is, use a debugger. Note also that if the
|
|
|
992 error happens at compile-time, there is no guarantee that the line
|
|
|
993 number given makes any sense at all. Some errors don't give next line
|
|
|
994 numbers, mostly those for which it doesn't make logical sense, such as
|
|
|
995 E633 (*note E633::). After this is a suggestion to correct (or
|
|
|
996 reconsider) the source code and to resubnit it. (This typo has been
|
|
|
997 carefully preserved for over a decade.)
|
|
|
998
|
|
|
999 * Menu:
|
|
|
1000
|
|
|
1001 * Errors:: Error messages that might be produced
|
|
|
1002 * Warnings:: Warnings produced by the `-l' option
|
|
|
1003
|
|
|
1004
|
|
|
1005 File: ick.info, Node: Errors, Next: Warnings, Up: Errors and Warnings
|
|
|
1006
|
|
|
1007 3.1 Errors
|
|
|
1008 ==========
|
|
|
1009
|
|
|
1010 This is a list of the error messages that might be produced during the
|
|
|
1011 compilation or execution of an INTERCAL program.
|
|
|
1012
|
|
|
1013 E000
|
|
|
1014 This is an unusual error; it's what's printed when a syntax error
|
|
|
1015 is encounted at runtime, in a situation in which it would be
|
|
|
1016 executed. (An `ABSTAIN'ed syntax error, for instance, would not
|
|
|
1017 be executed; this is one of the mechanisms available for writing
|
|
|
1018 comments.) The text of the error message is simply the statement
|
|
|
1019 that couldn't be decoded.
|
|
|
1020
|
|
|
1021 E017
|
|
|
1022 DO YOU EXPECT ME TO FIGURE THIS OUT?
|
|
|
1023
|
|
|
1024 This error occurs when there is an attempt to use a constant with a
|
|
|
1025 value outside the onespot range; it's a compile-time error.
|
|
|
1026
|
|
|
1027 E079
|
|
|
1028 PROGRAMMER IS INSUFFICIENTLY POLITE
|
|
|
1029
|
|
|
1030 The balance between various statement identifiers is important.
|
|
|
1031 If less than approximately one fifth of the statement identifiers
|
|
|
1032 used are the polite versions containing `PLEASE', that causes this
|
|
|
1033 error at compile time.
|
|
|
1034
|
|
|
1035 E099
|
|
|
1036 PROGRAMMER IS OVERLY POLITE
|
|
|
1037
|
|
|
1038 Of course, the same problem can happen in the other direction; this
|
|
|
1039 error is caused at compile time if over about one third of the
|
|
|
1040 statement identifiers are the polite form.
|
|
|
1041
|
|
|
1042 E111
|
|
|
1043 COMMUNIST PLOT DETECTED, COMPILER IS SUICIDING
|
|
|
1044
|
|
|
1045 This error happens when you give the `-t' option (*note -t::) but
|
|
|
1046 you use a language construct that wasn't available in INTERCAL-72.
|
|
|
1047 If this happens, then either there's a mistake in the program that
|
|
|
1048 prevents it being INTERCAL-72 or you shouldn't be compiling it as
|
|
|
1049 INTERCAL-72 in the first place.
|
|
|
1050
|
|
|
1051 E123
|
|
|
1052 PROGRAM HAS DISAPPEARED INTO THE BLACK LAGOON
|
|
|
1053
|
|
|
1054 There is a hard limit of 80 `NEXT's at a time; this is to
|
|
|
1055 discourage excessive use of `NEXTING' for things like recursion.
|
|
|
1056 (Recursive programs are entirely legal; you simply have to figure
|
|
|
1057 out how to do it with computed `COME FROM' instead. (For the
|
|
|
1058 record, it is possible. (Using lots of nested brackets when
|
|
|
1059 talking about recursion is great (yay!).))) Another problem with
|
|
|
1060 writing the source code that can cause this error is a failure to
|
|
|
1061 properly `FORGET' the entry on the `NEXT' stack created when
|
|
|
1062 trying to simulate a goto.
|
|
|
1063
|
|
|
1064 E127
|
|
|
1065 SAYING 'ABRACADABRA' WITHOUT A MAGIC WAND WON'T DO YOU ANY
|
|
|
1066 GOOD
|
|
|
1067 Your program asked to include the system library (by specifying a
|
|
|
1068 line number from 1000 to 1999 inclusive without including a line
|
|
|
1069 with that number), but due to installation problems the compiler
|
|
|
1070 couldn't find the system library to include. You could try using
|
|
|
1071 the `-u' (*note -u::) option to see where the compiler's looking;
|
|
|
1072 that may give you an idea of where you need to copy the system
|
|
|
1073 library so that the compilation will work. This error happens at
|
|
|
1074 compile time and doesn't give a next command line number.
|
|
|
1075
|
|
|
1076 E129
|
|
|
1077 PROGRAM HAS GOTTEN LOST
|
|
|
1078
|
|
|
1079 This error happens at compile time when the compiler can't figure
|
|
|
1080 out where a `NEXT' command is actually aiming (normally due to a
|
|
|
1081 typo in either the line label given or the line label on the line
|
|
|
1082 aimed for). The logic behind this error means that the next line
|
|
|
1083 to be executed is unknown (after all, that's the whole point of
|
|
|
1084 the error) and is therefore not given. The `-e' command-line
|
|
|
1085 option (*note -e::) makes this error into a run-time error,
|
|
|
1086 because it allows `NEXT' commands to dynamically change targets at
|
|
|
1087 runtime, as well as line labels to dynamically change values, and
|
|
|
1088 thus the error is impossible to detect at compile time.
|
|
|
1089
|
|
|
1090 E139
|
|
|
1091 I WASN'T PLANNING TO GO THERE ANYWAY
|
|
|
1092
|
|
|
1093 This error happens at compile time when an `ABSTAIN' or
|
|
|
1094 `REINSTATE' references a non-existent target line. This generally
|
|
|
1095 happens for much the same reasons as E129 (*note E129::).
|
|
|
1096
|
|
|
1097 E182
|
|
|
1098 YOU MUST LIKE THIS LABEL A LOT!
|
|
|
1099
|
|
|
1100 At present, it's impossible to have more than one line with the
|
|
|
1101 same line number. That would make `NEXT' act too much like `COME
|
|
|
1102 FROM' in reverse to be interesting. This error happens at compile
|
|
|
1103 time. (For inconsistency, it is possible to have multiple lines
|
|
|
1104 with the same number as long as at most one of them is in an
|
|
|
1105 INTERCAL program (the others have to be in programs in other
|
|
|
1106 languages included via the external calls system).)
|
|
|
1107
|
|
|
1108 E197
|
|
|
1109 SO! 65535 LABELS AREN'T ENOUGH FOR YOU?
|
|
|
1110
|
|
|
1111 Legal values for line labels are 1 to 65535 (with values from 1000
|
|
|
1112 to 1999 reserved if you want to use the system library, and 1600
|
|
|
1113 to 1699 reserved if you're using other expansion libraries). This
|
|
|
1114 error comes up if you use nonpositive or twospot values for a line
|
|
|
1115 label.
|
|
|
1116
|
|
|
1117 E200
|
|
|
1118 NOTHING VENTURED, NOTHING GAINED
|
|
|
1119
|
|
|
1120 You used a variable that isn't actually in your program. Failing
|
|
|
1121 that (which would be quite impressive and is probably impossible,
|
|
|
1122 at least in the present version of C-INTERCAL), you specified an
|
|
|
1123 illegal number for a variable (legal numbers are positive and
|
|
|
1124 onespot). This error happens at compile time, at least for
|
|
|
1125 illegal variable numbers.
|
|
|
1126
|
|
|
1127 E222
|
|
|
1128 BUMMER, DUDE!
|
|
|
1129
|
|
|
1130 In INTERCAL, you're allowed to `STASH' as much as you like; this
|
|
|
1131 makes the language Turing-complete and allows for unlimited
|
|
|
1132 recursion when combined with computed `COME FROM' in the right way.
|
|
|
1133 Unfortunately, real computers aren't so idealised; if you manage to
|
|
|
1134 write a program so memory-intensive that the computer runs out of
|
|
|
1135 memory to store stashes, it causes this error at runtime. To fix
|
|
|
1136 this error, you either have to simplify the program or upgrade
|
|
|
1137 your computer's memory, and even then that will only help to some
|
|
|
1138 extent.
|
|
|
1139
|
|
|
1140 E240
|
|
|
1141 ERROR HANDLER PRINTED SNIDE REMARK
|
|
|
1142
|
|
|
1143 Arrays have to be large enough to hold at least one element; you
|
|
|
1144 tried to dimension an array which isn't large enough to hold any
|
|
|
1145 data. This error happens at run time.
|
|
|
1146
|
|
|
1147 E241
|
|
|
1148 VARIABLES MAY NOT BE STORED IN WEST HYPERSPACE
|
|
|
1149
|
|
|
1150 This error happens at run time when the subscripts given to an
|
|
|
1151 array are inconsistent with the way the array was dimensioned,
|
|
|
1152 either because there were the wrong number of subscripts or
|
|
|
1153 because a subscript was too large to fit in the array. It can
|
|
|
1154 also happen when a multidimensional array is given to a command,
|
|
|
1155 such as `WRITE IN', that expects it to be monodimensional.
|
|
|
1156
|
|
|
1157 E252
|
|
|
1158 I'VE FORGOTTEN WHAT I WAS ABOUT TO SAY
|
|
|
1159
|
|
|
1160 This run-time error message is caused by the compiler running out
|
|
|
1161 of memory whilst trying to do I/O; at present, it can only happen
|
|
|
1162 during CLC-INTERCAL-style I/O.
|
|
|
1163
|
|
|
1164 E256
|
|
|
1165 THAT'S TOO HARD FOR MY TINY BRAIN
|
|
|
1166
|
|
|
1167 Some commands simply aren't available in PIC-INTERCAL. I mean,
|
|
|
1168 PICs generally have less than a kilobyte of memory; you're not
|
|
|
1169 going to be able to use some of the more confusing language
|
|
|
1170 features with that sort of resource limitation. The solution is
|
|
|
1171 to replace the affected command, or to not give the `-P' option
|
|
|
1172 (*note -P: -P+.) if you didn't mean to compile as PIC-INTERCAL in
|
|
|
1173 the first place.
|
|
|
1174
|
|
|
1175 E275
|
|
|
1176 DON'T BYTE OFF MORE THAN YOU CAN CHEW
|
|
|
1177
|
|
|
1178 This error happens when there is an attempt to store a twospot
|
|
|
1179 value in a onespot variable. The actual size of the value is what
|
|
|
1180 matters when counting its spots; so you can store the output of a
|
|
|
1181 mingle in a onespot variable if it happens to be less than or
|
|
|
1182 equal to 65535, for instance. (This is not necessarily the case
|
|
|
1183 in versions of INTERCAL other than C-INTERCAL, though, so you have
|
|
|
1184 to be careful with portability when doing this.)
|
|
|
1185
|
|
|
1186 E277
|
|
|
1187 YOU CAN ONLY DISTORT THE LAWS OF MATHEMATICS SO FAR
|
|
|
1188
|
|
|
1189 Reverse assignments are not always mathematically possible. Also,
|
|
|
1190 sometimes they require changing the value of a constant; this is
|
|
|
1191 only legal if you specifically specified that it was legal by
|
|
|
1192 using the `-v' option. In the case of an impossible reverse
|
|
|
1193 assignment (including a situation in which operand overloading
|
|
|
1194 causes a reverse assignment to happen), this error happens at
|
|
|
1195 runtime.
|
|
|
1196
|
|
|
1197 This error can also come up when a scalar variable is overloaded
|
|
|
1198 to an array (which doesn't make sense, but could happen if someone
|
|
|
1199 exploited bugs in the CREATE statement (*note CREATE::)), and an
|
|
|
1200 attempt is made to read or assign to that variable. (Subscripting
|
|
|
1201 a scalar variable is a syntax error, so there is no use for doing
|
|
|
1202 such an overload anyway.)
|
|
|
1203
|
|
|
1204 E281
|
|
|
1205 THAT MUCH QUOTATION AMOUNTS TO PLAGIARISM
|
|
|
1206
|
|
|
1207 There is a limit of 256 on the number of nested spark/ears groups
|
|
|
1208 allowed. If you somehow manage to exceed that limit, that will
|
|
|
1209 cause this error. Try breaking the expression up into smaller
|
|
|
1210 expressions. (The limit is trivial to increase by changing
|
|
|
1211 `SENESTMAX' in `ick.h'; if you ever actually come across a program
|
|
|
1212 that hits the limit but wasn't designed to, just email the
|
|
|
1213 maintainer to request a higher limit.)
|
|
|
1214
|
|
|
1215 E333
|
|
|
1216 YOU CAN'T HAVE EVERYTHING, WHERE WOULD YOU PUT IT?
|
|
|
1217
|
|
|
1218 Your program references so many variables that the compiler
|
|
|
1219 couldn't cope. This error is unlikely to ever happen; if it does,
|
|
|
1220 try reducing the number of variables you use by combining some
|
|
|
1221 into arrays. This is a compile-time error.
|
|
|
1222
|
|
|
1223 E345
|
|
|
1224 THAT'S TOO COMPLEX FOR ME TO GRASP
|
|
|
1225
|
|
|
1226 This is another compile-time error that's unlikely to ever happen;
|
|
|
1227 this one signifies the compiler itself running out of memory
|
|
|
1228 trying to compile your program. The only solutions to this are to
|
|
|
1229 simplify your program, or to make more memory available to the
|
|
|
1230 compiler.
|
|
|
1231
|
|
|
1232 E404
|
|
|
1233 I'M ALL OUT OF CHOICES!
|
|
|
1234
|
|
|
1235 Your program asked that a choicepoint be backtracked to or
|
|
|
1236 removed, but there aren't any choicepoints at the moment. This
|
|
|
1237 runtime error usually indicates a logic mistake in your program.
|
|
|
1238 In backtracking programs translated from other backtracking
|
|
|
1239 languages, this indicates that the program has failed.
|
|
|
1240
|
|
|
1241 E405
|
|
|
1242 PROGRAM REJECTED FOR MENTAL HEALTH REASONS
|
|
|
1243
|
|
|
1244 Your program used a construct that only makes sense when
|
|
|
1245 multithreading or backtracking (`WHILE', `MAYBE', `GO BACK', or `GO
|
|
|
1246 AHEAD'), but you didn't specify the `-m' option (*note -m::). If
|
|
|
1247 you meant to write a multithreaded or backtracking program, just
|
|
|
1248 give that option; if you didn't, be careful what words you use in
|
|
|
1249 comments! This error happens at compile-time.
|
|
|
1250
|
|
|
1251 E436
|
|
|
1252 THROW STICK BEFORE RETRIEVING!
|
|
|
1253
|
|
|
1254 In order to `RETRIEVE' a variable, it has to be `STASH'ed first;
|
|
|
1255 if it isn't, then this error happens at runtime.
|
|
|
1256
|
|
|
1257 E444
|
|
|
1258 IT CAME FROM BEYOND SPACE
|
|
|
1259
|
|
|
1260 A `COME FROM' aiming at a line label -- as opposed to a computed
|
|
|
1261 `COME FROM', which is allowed to be pointing at a nonexistent line
|
|
|
1262 -- must point to a valid line label. The same applies to `NEXT
|
|
|
1263 FROM'. This error happens at compile time if a nonexistent line
|
|
|
1264 label is found in one of these contexts.
|
|
|
1265
|
|
|
1266 E533
|
|
|
1267 YOU WANT MAYBE WE SHOULD IMPLEMENT 64-BIT VARIABLES?
|
|
|
1268
|
|
|
1269 This error is like E275 (*note E275::), but applies when an
|
|
|
1270 attempt is made at runtime to store a threespot value (or even a
|
|
|
1271 fourspot or morespot value) in a twospot variable, or a threespot
|
|
|
1272 or greater value is produced as an intermediate during a
|
|
|
1273 calculation (for instance by a mingle operation). No values above
|
|
|
1274 twospot are allowed at any point during an INTERCAL program; if
|
|
|
1275 you want to process higher numbers, you have to figure out a
|
|
|
1276 different way of storing them.
|
|
|
1277
|
|
|
1278 E553
|
|
|
1279 BETTER LATE THAN NEVER
|
|
|
1280 Oops! The compiler just noticed that it had a buffer overflow.
|
|
|
1281 (Normally programs catch buffer overflows before they happen;
|
|
|
1282 C-INTERCAL catches them just afterwards instead.) This only
|
|
|
1283 happens on systems which don't have a modern C standard library.
|
|
|
1284 Try using shorter or fewer filenames on the command line, to
|
|
|
1285 reduce the risk of such an overflow.
|
|
|
1286
|
|
|
1287 E555
|
|
|
1288 FLOW DIAGRAM IS EXCESSIVELY CONNECTED
|
|
|
1289
|
|
|
1290 Aiming two `COME FROM's at the same line only makes sense in a
|
|
|
1291 multithreaded program. In a non-multithread program, doing that
|
|
|
1292 will cause this error at compile time (if neither `COME FROM' is
|
|
|
1293 computed) or at run time (if the command that has just finished
|
|
|
1294 running is simultaneously the target of two or more `COME FROM's).
|
|
|
1295 This either indicates an error in your program or that you've
|
|
|
1296 forgotten to use the `-m' option (*note -m::) if you are actually
|
|
|
1297 trying to split the program into two threads.
|
|
|
1298
|
|
|
1299 E562
|
|
|
1300 I DO NOT COMPUTE
|
|
|
1301
|
|
|
1302 The program asked for input, but for some reason it wasn't
|
|
|
1303 available. (This is a runtime error, obviously.) The error may
|
|
|
1304 happen because the input is being piped in from a command or file
|
|
|
1305 which has reached end-of-file, or because the user typed
|
|
|
1306 `<CTRL>-<D>' (UNIX/Linux) or `<CTRL>-<Z>' (DOS/Windows) while the
|
|
|
1307 program was trying to `WRITE IN' some data.
|
|
|
1308
|
|
|
1309 E579
|
|
|
1310 WHAT BASE AND/OR LANGUAGE INCLUDES STRING?
|
|
|
1311
|
|
|
1312 When reading spelt-out-digit input, the input didn't seem to be a
|
|
|
1313 valid digit in English, Sanskrit, Basque, Tagalog, Classical
|
|
|
1314 Nahuatl, Georgian, Kwakiutl, Volapük, or Latin. This seems to
|
|
|
1315 have languages covered pretty well; what on earth were you using,
|
|
|
1316 or did you just make a spelling mistake?
|
|
|
1317
|
|
|
1318 E621
|
|
|
1319 ERROR TYPE 621 ENCOUNTERED
|
|
|
1320
|
|
|
1321 The compiler encountered error E621 (*note E621::). This happens
|
|
|
1322 at runtime when the program requests that no entries are removed
|
|
|
1323 from the `NEXT' stack (which is possible), but that the last entry
|
|
|
1324 removed should be jumped to (which given the circumstances isn't,
|
|
|
1325 because no entries were removed).
|
|
|
1326
|
|
|
1327 E632
|
|
|
1328 THE NEXT STACK RUPTURES. ALL DIE. OH, THE EMBARRASSMENT!
|
|
|
1329
|
|
|
1330 When an attempt is made to `RESUME' past the end of the `NEXT'
|
|
|
1331 stack, the program ends; however, this cause the program to end in
|
|
|
1332 a manner other than via `GIVE UP' or `DON'T TRY AGAIN', so an
|
|
|
1333 error message must be printed, and this is that error message.
|
|
|
1334
|
|
|
1335 E633
|
|
|
1336 PROGRAM FELL OFF THE EDGE
|
|
|
1337
|
|
|
1338 You can't just let execution run off the end of the program. At
|
|
|
1339 least, that is, if it doesn't end with `TRY AGAIN'. An attempt to
|
|
|
1340 do that causes this error at runtime. Note that if your program
|
|
|
1341 references the system library, then it counts as being appended to
|
|
|
1342 your program and so the program will run into the first line of
|
|
|
1343 the system library rather than cause this error. As it happens,
|
|
|
1344 the first line of the system library is a syntax error, so doing
|
|
|
1345 this will cause E000 (*note E000::) with the error text `PLEASE
|
|
|
1346 KNOCK BEFORE ENTERING'. There isn't a next statement to be
|
|
|
1347 executed with E633, so the next statement won't be given in the
|
|
|
1348 error message.
|
|
|
1349
|
|
|
1350 E652
|
|
|
1351 HOW DARE YOU INSULT ME!
|
|
|
1352
|
|
|
1353 The `PIN' command doesn't make much sense for anything bigger than
|
|
|
1354 a PIC; using it in a non-PIC program causes this error at
|
|
|
1355 compile-time. Try using the normal input and output mechanisms
|
|
|
1356 instead. This error may also be a clue that you are trying to
|
|
|
1357 compile a PIC-INTERCAL program without giving the `-P' option
|
|
|
1358 (*note -P: -P+.).
|
|
|
1359
|
|
|
1360 E666
|
|
|
1361 COMPILER HAS INDIGESTION
|
|
|
1362
|
|
|
1363 There isn't a limit on the length of an input program other than
|
|
|
1364 your computer's memory; if your computer does run out of memory
|
|
|
1365 during compilation, it causes this error. This error can also be
|
|
|
1366 caused if too many input files are specified on the command line;
|
|
|
1367 if you suspect this is the problem, split the compilation into
|
|
|
1368 separate compilations if you can, or otherwise you may be able to
|
|
|
1369 concatenate together your input files into larger but fewer files.
|
|
|
1370 Yet another potential cause of this error is if a line in an input
|
|
|
1371 program is too long; sensible line-wrapping techniques are
|
|
|
1372 encouraged.
|
|
|
1373
|
|
|
1374 E774
|
|
|
1375 RANDOM COMPILER BUG
|
|
|
1376
|
|
|
1377 No compiler is perfect; sometimes errors just happen at random.
|
|
|
1378 In this case, the random error is E774. If you don't like the
|
|
|
1379 idea that your program may be shot down by a random compiler bug,
|
|
|
1380 or you are doing something important, you can use the `-b' option
|
|
|
1381 (*note -b::) to prevent this bug happening. (You may wonder why
|
|
|
1382 this bug is in there at all if it's so easily prevented. The
|
|
|
1383 answer is that such a bug was present in the original INTERCAL-72
|
|
|
1384 compiler, which also had an option to turn the bug off. It's also
|
|
|
1385 a reward for people who actually read the manual.)
|
|
|
1386
|
|
|
1387 E777
|
|
|
1388 A SOURCE IS A SOURCE, OF COURSE, OF COURSE
|
|
|
1389
|
|
|
1390 You specified a file to compile on the command line, but the
|
|
|
1391 compiler couldn't find or couldn't open it. This is almost
|
|
|
1392 certainly because you made a typo specifying the file.
|
|
|
1393
|
|
|
1394 E778
|
|
|
1395 UNEXPLANED COMPILER BUG
|
|
|
1396
|
|
|
1397 This should never come up, either at compile time or at run time.
|
|
|
1398 It could come up at either when an internal check by the compiler
|
|
|
1399 or the runtime libraries realises that something has gone badly
|
|
|
1400 wrong; mistakes happen, and in such cases the mistake will have
|
|
|
1401 been detected. (If this happens at compile time you can use the
|
|
|
1402 `-U' option (*note -U: -U+.) to cause the compiler to send an
|
|
|
1403 abort signal - which normally causes a core dump - when the error
|
|
|
1404 happens, to help debug what's causing it.) More often, this error
|
|
|
1405 comes up when the operating system has noticed something
|
|
|
1406 impossible, like an attempt to free allocated memory twice or to
|
|
|
1407 write to a null pointer, and tells the compiler an error has
|
|
|
1408 occured, in which case the same response of putting up this error
|
|
|
1409 happens. The point is that in all cases this error indicates a
|
|
|
1410 bug in the compiler (even if it happens at run time); in such
|
|
|
1411 cases, it would be very helpful if you figure out what caused it
|
|
|
1412 and send a bug report (*note Reporting Bugs::).
|
|
|
1413
|
|
|
1414 E810
|
|
|
1415 ARE ONE-CHARACTER COMMANDS TOO SHORT FOR YOU?
|
|
|
1416
|
|
|
1417 This is a debug-time error caused when you give too much input to
|
|
|
1418 the debugger when all it wanted was to know what you wanted to do
|
|
|
1419 next.
|
|
|
1420
|
|
|
1421 E811
|
|
|
1422 PROGRAM IS TOO BADLY BROKEN TO RUN
|
|
|
1423
|
|
|
1424 There's a limit to how many breakpoints you can have in a program;
|
|
|
1425 you've broken the limit and therefore broken the debugger. This
|
|
|
1426 is a debug-time error.
|
|
|
1427
|
|
|
1428 E888
|
|
|
1429 I HAVE NO FILE AND I MUST SCREAM
|
|
|
1430
|
|
|
1431 The output file couldn't be written, maybe because the disk is
|
|
|
1432 full or because there's already a read-only file with the same
|
|
|
1433 name. This is a compile-time error.
|
|
|
1434
|
|
|
1435 E899
|
|
|
1436 HELLO? CAN ANYONE GIVE ME A HAND HERE?
|
|
|
1437
|
|
|
1438 This error occurs at compile-time if a file type was requested for
|
|
|
1439 which the required libraries are unavailable. (Support for Funge
|
|
|
1440 does not ship with the compiler; instead, you need to generate the
|
|
|
1441 library yourself from the cfunge sources. For more information,
|
|
|
1442 see *note Creating the Funge-98 Library::.)
|
|
|
1443
|
|
|
1444 E991
|
|
|
1445 YOU HAVE TOO MUCH ROPE TO HANG YOURSELF
|
|
|
1446
|
|
|
1447 There is no limit on the number of threads or choicepoints that
|
|
|
1448 you can have in a multithreaded or backtracking program (in a
|
|
|
1449 program that isn't multithreaded or backtracking, these are
|
|
|
1450 obviously limited to 1 and 0 respectively). However, your
|
|
|
1451 computer may not be able to cope; if it runs out of memory in the
|
|
|
1452 multithreader, it will cause this error at runtime.
|
|
|
1453
|
|
|
1454 E993
|
|
|
1455 I GAVE UP LONG AGO
|
|
|
1456
|
|
|
1457 `TRY AGAIN' has to be the last command in a program, if it's there
|
|
|
1458 at all; you can't even follow it by comments, not even if you know
|
|
|
1459 in advance that they won't be `REINSTATE'd. This error happens at
|
|
|
1460 compile time if a command is found after a `TRY AGAIN'.
|
|
|
1461
|
|
|
1462 E995
|
|
|
1463 DO YOU REALLY EXPECT ME TO HAVE IMPLEMENTED THAT?
|
|
|
1464
|
|
|
1465 Some parts of the code haven't been written yet. There ought to
|
|
|
1466 be no way to cause those to actually run; however, if you do
|
|
|
1467 somehow find a way to cause them to run, they will cause this
|
|
|
1468 error at compile time.
|
|
|
1469
|
|
|
1470 E997
|
|
|
1471 ILLEGAL POSSESSION OF A CONTROLLED UNARY OPERATOR
|
|
|
1472
|
|
|
1473 Some operators (such as whirlpool (`@') and sharkfin (`^')) only
|
|
|
1474 make sense in TriINTERCAL programs, and some have a minimum base
|
|
|
1475 in which they make sense. This error happens at compile-time if
|
|
|
1476 you try to use an operator that conflicts with the base you're in
|
|
|
1477 (such as using TriINTERCAL operators in an INTERCAL program in the
|
|
|
1478 default base 2).
|
|
|
1479
|
|
|
1480 E998
|
|
|
1481 EXCUSE ME, YOU MUST HAVE ME CONFUSED WITH SOME OTHER COMPILER
|
|
|
1482
|
|
|
1483 This error occurs just before compile-time if a file is
|
|
|
1484 encountered on the command line that C-INTERCAL doesn't recognise.
|
|
|
1485 (If this error occurs due to a `.a', `.b98', `.c', or `.c99', then
|
|
|
1486 you forgot to enable the external calls system using `-e' (*note
|
|
|
1487 -e::).)
|
|
|
1488
|
|
|
1489 E999
|
|
|
1490 NO SKELETON IN MY CLOSET, WOE IS ME!
|
|
|
1491
|
|
|
1492 The skeleton file `ick-wrap.c' or `pickwrap.c' is needed to be
|
|
|
1493 able to compile INTERCAL to C. If the compiler can't find it, it
|
|
|
1494 will give this error message. This indicates a problem with the
|
|
|
1495 way the compiler has been installed; try using the `-u' option
|
|
|
1496 (*note -u::) to find out where it's looking (you may be able to
|
|
|
1497 place a copy of the skeleton file in one of those places).
|
|
|
1498
|
|
|
1499
|
|
|
1500
|
|
|
1501 File: ick.info, Node: Warnings, Prev: Errors, Up: Errors and Warnings
|
|
|
1502
|
|
|
1503 3.2 Warnings
|
|
|
1504 ============
|
|
|
1505
|
|
|
1506 This is a list of the warnings stored in the warning database.
|
|
|
1507 Warnings only come up when the `-l' option (*note -l::) is given; even
|
|
|
1508 then, some of the warnings are not currently implemented and therefore
|
|
|
1509 will never come up.
|
|
|
1510
|
|
|
1511 W016
|
|
|
1512 DON'T TYPE THAT SO HASTILY
|
|
|
1513
|
|
|
1514 The positional precedence rules for unary operators are somewhat
|
|
|
1515 complicated, and it's easy to make a mistake. This warning is
|
|
|
1516 meant to detect such mistakes, but is not currently implemented.
|
|
|
1517
|
|
|
1518 W018
|
|
|
1519 THAT WAS MEANT TO BE A JOKE
|
|
|
1520
|
|
|
1521 If an INTERCAL expression has been translated from another
|
|
|
1522 language such as C, the optimiser is generally capable of
|
|
|
1523 translating it back into something similar to the original, at
|
|
|
1524 least in base 2. When after optimisation there are still INTERCAL
|
|
|
1525 operators left in an expression, then this warning is produced.
|
|
|
1526 (Therefore, it's likely to come up quite a lot if optimisation
|
|
|
1527 isn't used!) The system library produces some of these warnings
|
|
|
1528 (you can tell if a warning has come up in the system library
|
|
|
1529 because you'll get a line number after the end of your program).
|
|
|
1530
|
|
|
1531 W112
|
|
|
1532 THAT RELIES ON THE NEW WORLD ORDER
|
|
|
1533
|
|
|
1534 This warning comes up whenever the compiler recognises that you've
|
|
|
1535 added some code that didn't exist in INTERCAL-72. This allows you
|
|
|
1536 to check whether your code is valid INTERCAL-72 (although `-t'
|
|
|
1537 (*note -t::) is more useful for that); it also warns you that code
|
|
|
1538 might not be portable (because INTERCAL-72 is implemented by most
|
|
|
1539 INTERCAL compilers, but more recent language features may not be).
|
|
|
1540
|
|
|
1541 W128
|
|
|
1542 SYSLIB IS OPTIMIZED FOR OBUSCATION
|
|
|
1543
|
|
|
1544 There is an idiom used in the system library that does a
|
|
|
1545 right-shift by selecting alternate bits from a twospot number and
|
|
|
1546 then mingling them the other way round. A rightshift can much
|
|
|
1547 more easily be done with a single rightshift, so this is a silly
|
|
|
1548 way to do it, and this warning warns that this idiom was used.
|
|
|
1549 However, the present optimizer is incapable of recognising whether
|
|
|
1550 this problem exists or not, so the warning is not currently
|
|
|
1551 implemented.
|
|
|
1552
|
|
|
1553 W276
|
|
|
1554 YOU CAN'T EXPECT ME TO CHECK BACK THAT FAR
|
|
|
1555
|
|
|
1556 It's an error to assign a twospot value (a value over 65535) to a
|
|
|
1557 onespot variable, or to use it as an argument to a mingle. If the
|
|
|
1558 optimizer can't guarantee at compile time that there won't be an
|
|
|
1559 overflow, it issues this warning. (Note that this doesn't
|
|
|
1560 necessarily mean there's a problem -- for instance, the system
|
|
|
1561 library generates some of these warnings -- only that the
|
|
|
1562 optimiser couldn't work out for sure that there wasn't a problem.)
|
|
|
1563
|
|
|
1564 W239
|
|
|
1565 WARNING HANDLER PRINTED SNIDE REMARK
|
|
|
1566
|
|
|
1567 Your code looks like it's trying to assign 0 to an array, giving
|
|
|
1568 it no dimension; this is an error. This warning is produced at
|
|
|
1569 compile time if it looks like a line in your code will cause this
|
|
|
1570 error, but it isn't necessarily an error because that line of code
|
|
|
1571 might never be executed.
|
|
|
1572
|
|
|
1573 W278
|
|
|
1574 FROM A CONTRADICTION, ANYTHING FOLLOWS
|
|
|
1575
|
|
|
1576 It's sometimes impossible to reverse an assignment (a reverse
|
|
|
1577 assignment can happen if the `-v' option (*note -v::) is used and
|
|
|
1578 an expression is placed on the left of an assignment, or in
|
|
|
1579 operand overloading); if the compiler detects that a reversal
|
|
|
1580 failure is inevitable, it will cause this warning. Note that this
|
|
|
1581 doesn't always cause an error, because the relevant code might
|
|
|
1582 never be executed.
|
|
|
1583
|
|
|
1584 W450
|
|
|
1585 THE DOCUMENTOR IS NOT ALWAYS RIGHT
|
|
|
1586
|
|
|
1587 There is no way to get this warning to come up; it isn't even
|
|
|
1588 written anywhere in C-INTERCAL's source code, is not implemented
|
|
|
1589 by anything, and there are no circumstances in which it is even
|
|
|
1590 meant to come up. It is therefore not at all obvious why it is
|
|
|
1591 documented.
|
|
|
1592
|
|
|
1593 W534
|
|
|
1594 KEEP LOOKING AT THE TOP BIT
|
|
|
1595
|
|
|
1596 C-INTERCAL uses a slightly different typing mechanism to some
|
|
|
1597 other INTERCAL compilers; types are calculated at compile time
|
|
|
1598 rather than run time. This only makes a difference in some cases
|
|
|
1599 involving unary operators. It's impossible to detect at compile
|
|
|
1600 time for certain whether such a case has come up or not, but if
|
|
|
1601 the compiler or optimizer thinks that such a case might have come
|
|
|
1602 up, it will issue this warning.
|
|
|
1603
|
|
|
1604 W622
|
|
|
1605 WARNING TYPE 622 ENCOUNTERED
|
|
|
1606
|
|
|
1607 Your code looks like it's trying to resume by 0; this is an error.
|
|
|
1608 This warning is produced at compile time if it looks like a line
|
|
|
1609 in your code will cause this error, but it isn't necessarily an
|
|
|
1610 error because that line of code might never be executed.
|
|
|
1611
|
|
|
1612
|
|
|
1613
|
|
|
1614 File: ick.info, Node: The yuk debugger, Next: Syntax, Prev: Errors and Warnings, Up: Top
|
|
|
1615
|
|
|
1616 4 The yuk debugger
|
|
|
1617 ******************
|
|
|
1618
|
|
|
1619 The C-INTERCAL distribution contains a runtime debugger called `yuk'.
|
|
|
1620 Unlike most other debuggers, it is stored as object code rather than as
|
|
|
1621 an executable, and it is compiled into the code rather than operating on
|
|
|
1622 it. To debug code, add `-y' (*note -y::) to the command line of `ick'
|
|
|
1623 when invoking it; that tells it to compile the debugger into the code
|
|
|
1624 and then execute the resulting combination. (The resulting hybrid
|
|
|
1625 debugger/input executable is deleted afterwards; this is to prevent it
|
|
|
1626 being run by mistake, and to prevent spreading the debugger's licence
|
|
|
1627 onto the code it was compiled with.)
|
|
|
1628
|
|
|
1629 yuk can also be used as a profiler using the `-p' option (*note -p::);
|
|
|
1630 this produces a file `yuk.out' containing information on how much time
|
|
|
1631 was spent running each command in your program, and does not prompt for
|
|
|
1632 debugger commands.
|
|
|
1633
|
|
|
1634 Note that some command line arguments are incompatible with the
|
|
|
1635 debugger, such as `-m' and `-f'. In particular, this means that
|
|
|
1636 multithreaded programs and programs that use backtracking cannot be
|
|
|
1637 debugged using this method; the `+printflow' option (*note
|
|
|
1638 +printflow::) to a compiled program may or may not be useful for
|
|
|
1639 debugging multithreaded programs.
|
|
|
1640
|
|
|
1641 When the debugger starts, it will print a copyright message and a
|
|
|
1642 message on how to access online help; then you can enter commands to
|
|
|
1643 run/debug the program. The debugger will show a command prompt,
|
|
|
1644 `yuk007 ', to let you know you can input a command.
|
|
|
1645
|
|
|
1646 Here are the commands available. Commands are single characters
|
|
|
1647 followed by newlines, or followed by a line number (in decimal) and a
|
|
|
1648 newline or a variable name (a `.', `,', `:' or `;' followed by a number
|
|
|
1649 in decimal; note that some commands only allow onespot and twospot
|
|
|
1650 variables as arguments).
|
|
|
1651
|
|
|
1652 Command Description
|
|
|
1653 --------------------------------------------------------------------------
|
|
|
1654 aLINE All non-abstained commands on line LINE become abstained from
|
|
|
1655 once.
|
|
|
1656 bLINE A breakpoint is set on line LINE. The breakpoint causes
|
|
|
1657 execution with `c' to stop when it is reached.
|
|
|
1658 c The program is run until it ends (which also ends the
|
|
|
1659 debugger) or a breakpoint is reached.
|
|
|
1660 dLINE Any breakpoint that may be on line LINE is removed.
|
|
|
1661 eLINE An explanation of the main expression in each command on
|
|
|
1662 line LINE is printed to the screen. The explanation is in
|
|
|
1663 the same format as the format produced by `-h' (*note -h::)
|
|
|
1664 and shows what the optimiser optimised the expression to (or
|
|
|
1665 the original expression if the optimiser wasn't used).
|
|
|
1666 fLINE Removes the effect of the `m' command on line LINE.
|
|
|
1667 gLINE Causes the current command to be the first command on LINE
|
|
|
1668 (if not on that line already) or the next command on LINE,
|
|
|
1669 as if that line was `NEXT'ed to and then that `NEXT' stack
|
|
|
1670 item was forgotten.
|
|
|
1671 h Lists 10 lines either side of the current line; if there
|
|
|
1672 aren't 10 lines to one or the other side of the current
|
|
|
1673 line, instead more lines will be shown on the other side to
|
|
|
1674 compensate, if available.
|
|
|
1675 iVAR Causes variable VAR to become `IGNORE'd, making it read-only.
|
|
|
1676 jVAR Causes variable VAR to become `REMEMBER'ed, making it no
|
|
|
1677 longer read-only.
|
|
|
1678 k Continues executing commands until the `NEXT' stack is the
|
|
|
1679 same size or smaller than it was before. In other words, if
|
|
|
1680 the current command is not a `NEXT' and doesn't have a `NEXT
|
|
|
1681 FROM' aiming at it, one command is executed; but if a `NEXT'
|
|
|
1682 does happen, execution will continue until that `NEXT'
|
|
|
1683 returns or is forgotten. A breakpoint or the end of the
|
|
|
1684 program also end this.
|
|
|
1685 lLINE Lists 10 lines of source code either side of line LINE, the
|
|
|
1686 same way as with `h', but using a line stated in the command
|
|
|
1687 rather than the current line.
|
|
|
1688 mLINE Produces a message onscreen every time a command on line
|
|
|
1689 LINE is executed, but without interrupting the program.
|
|
|
1690 n Show the `NEXT' stack on the screen.
|
|
|
1691 o Continue executing commands until the `NEXT' stack is smaller
|
|
|
1692 than it was before. If you are using `NEXT's like
|
|
|
1693 procedures, then this effectively means that the procedure
|
|
|
1694 will run until it returns. A breakpoint or the end of the
|
|
|
1695 program also end this.
|
|
|
1696 p Displays the value of all onespot and twospot variables.
|
|
|
1697 q Aborts the current program and exits the debugger.
|
|
|
1698 rLINE Reinstates once all abstained commands on line LINE.
|
|
|
1699 s Executes one command.
|
|
|
1700 t Continues execution until the end of the program or a
|
|
|
1701 breakpoint: each command that executes is displayed while
|
|
|
1702 this command is running.
|
|
|
1703 uLINE Continues execution of the program until just before a
|
|
|
1704 command on line LINE is run (or a breakpoint or the end of
|
|
|
1705 the program).
|
|
|
1706 vVAR Adds a `view' on variable VAR (which must be onespot or
|
|
|
1707 twospot), causing its value to be displayed on the screen
|
|
|
1708 whenever a command is printed on screen (for instance,
|
|
|
1709 because the command has just been stepped past, or due to
|
|
|
1710 the `m' or `t' commands).
|
|
|
1711 w Displays the current line and current command onscreen.
|
|
|
1712 xVAR Removes any view and any action that may be associated with
|
|
|
1713 it on variable VAR (which must be onespot or twospot).
|
|
|
1714 yVAR Adds a view on variable VAR; also causes a break, as if a
|
|
|
1715 breakpoint was reached, whenever the value of that variable
|
|
|
1716 changes.
|
|
|
1717 zVAR Adds a view on variable VAR; also causes a break, as if a
|
|
|
1718 breakpoint was reached, whenever that variable's value
|
|
|
1719 becomes 0.
|
|
|
1720 VAR A onespot or twospot variable written by itself prints out
|
|
|
1721 the value of that variable.
|
|
|
1722 <VAR `WRITEs IN' a new value for variable VAR. Note that input
|
|
|
1723 must be in the normal `ONE TWO THREE' format; input in any
|
|
|
1724 other format will cause error E579 (*note E579::) and as
|
|
|
1725 that is a fatal error, the debugger and program it's
|
|
|
1726 debugging will end.
|
|
|
1727 * Displays the license conditions under which `ick' is
|
|
|
1728 distributed.
|
|
|
1729 ? Displays a summary of what each command does. (`@' does the
|
|
|
1730 same thing.)
|
|
|
1731
|
|
|
1732 While the code is executing (for instance, during a `c', `k', `o', `t'
|
|
|
1733 or `u' command), it's possible to interrupt it with `<CTRL>-<C>' (on
|
|
|
1734 UNIX/Linux) or `<CTRL>-<BREAK>' (on Windows/DOS); this will cause the
|
|
|
1735 current command to finish running and the debugger prompt to come back
|
|
|
1736 up.
|
|
|
1737
|
|
|
1738
|
|
|
1739 File: ick.info, Node: Syntax, Next: Expressions, Prev: The yuk debugger, Up: Top
|
|
|
1740
|
|
|
1741 5 Syntax
|
|
|
1742 ********
|
|
|
1743
|
|
|
1744 INTERCAL programs consist of a list of statements. Execution of a
|
|
|
1745 program starts with its first statement; generally speaking each
|
|
|
1746 statement runs after the previous statement, although many situations
|
|
|
1747 can change this.
|
|
|
1748
|
|
|
1749 Whitespace is generally insignificant in INTERCAL programs; it cannot be
|
|
|
1750 added in the middle of a keyword (unless the keyword contains whitespace
|
|
|
1751 itself) or inside a decimal number, but it can be added more or less
|
|
|
1752 anywhere else, and it can be removed from anywhere in the program as
|
|
|
1753 well.
|
|
|
1754
|
|
|
1755 An INTERCAL statement consists of an optional line label, a statement
|
|
|
1756 identifier, an optional execution chance, the statement itself (*note
|
|
|
1757 Statements::), and optionally `ONCE' or `AGAIN'.
|
|
|
1758
|
|
|
1759 * Menu:
|
|
|
1760
|
|
|
1761 * Princeton and Atari Syntax:: There are two syntaxes for INTERCAL
|
|
|
1762 * Line Labels:: Allowing lines to be referred to
|
|
|
1763 * Statement Identifiers:: Marking the start of a statement
|
|
|
1764 * Execution Chance:: Statements that might not execute
|
|
|
1765 * ONCE and AGAIN:: Self-abstaining and self-reinstating statements
|
|
|
1766
|
|
|
1767
|
|
|
1768 File: ick.info, Node: Princeton and Atari Syntax, Next: Line Labels, Up: Syntax
|
|
|
1769
|
|
|
1770 5.1 Princeton and Atari Syntax
|
|
|
1771 ==============================
|
|
|
1772
|
|
|
1773 The history of INTERCAL is plagued with multiple syntaxes and character
|
|
|
1774 sets. The result has settled down with two versions of the syntax; the
|
|
|
1775 original Princeton syntax, and the Atari syntax (which is more suited
|
|
|
1776 to the operating systems of today).
|
|
|
1777
|
|
|
1778 Princeton syntax
|
|
|
1779 ----------------
|
|
|
1780
|
|
|
1781 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
1782 ------------------------------------------------------------------------
|
|
|
1783 some versions version 0.18+ all versions no
|
|
|
1784
|
|
|
1785 The original INTERCAL-72 compiler was the Princeton compiler, which
|
|
|
1786 introduced what has become known as the Princeton syntax for INTERCAL;
|
|
|
1787 this is the syntax used in the original manual, for instance, and can
|
|
|
1788 be considered to be the `original' or `official' INTERCAL syntax. It
|
|
|
1789 is notable for containing various characters not found in some
|
|
|
1790 character sets; for instance, it writes the operator for mingle as a
|
|
|
1791 cent sign (known as `change'). The other operator that often causes
|
|
|
1792 problems is the bookworm operator `V', backspace, `-', which is used
|
|
|
1793 for exclusive-or; the backspace can cause problems on some systems
|
|
|
1794 (which was probably the original intention). This syntax is also the
|
|
|
1795 default syntax in the CLC-INTERCAL compiler, which is the de facto
|
|
|
1796 standard for expanding the Princeton syntax to modern INTERCAL features
|
|
|
1797 that are not found in INTERCAL-72; however, it does not appear to have
|
|
|
1798 been used as the default syntax in any other compilers. Nowadays,
|
|
|
1799 there are other ways to write the required characters than using
|
|
|
1800 backspace; for instance, the cent sign appears in Latin-1 and UTF-8,
|
|
|
1801 and there are various characters that approximate bookworms (for
|
|
|
1802 instance, CLC-INTERCAL uses the Latin-1 yen symbol for this, which just
|
|
|
1803 to make things confusing, refers to a mingle in modern Atari syntax).
|
|
|
1804
|
|
|
1805 Atari syntax
|
|
|
1806 ------------
|
|
|
1807
|
|
|
1808 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
1809 ------------------------------------------------------------------------
|
|
|
1810 some versions yes version 0.05+ yes
|
|
|
1811
|
|
|
1812 The other main syntax is the Atari syntax, so called because it was
|
|
|
1813 originally used by the "Atari implementation" of INTERCAL-72. It is not
|
|
|
1814 clear why the implementation was given this name, because the authors
|
|
|
1815 of the implementation are not known; it is not clear whether it has any
|
|
|
1816 connection with Atari other than running on an Atari computer, for
|
|
|
1817 instance. The syntax was designed to work better on ASCII-based
|
|
|
1818 systems, by avoiding the change character (although it can still be
|
|
|
1819 written as `c', backspace, `/', which the Atari compiler documentation
|
|
|
1820 claims that the Princeton compiler supported) in favour of a `big
|
|
|
1821 money' character (`$'), and using the `what' (`?') as an alternative
|
|
|
1822 character for exclusive-or. This is the syntax that C-INTERCAL and
|
|
|
1823 J-INTERCAL have always used, and is the one most commonly used for
|
|
|
1824 communicating INTERCAL programs on Usenet and other similar fora (where
|
|
|
1825 ASCII is one of the most reliable-to-send character sets). It is also
|
|
|
1826 the syntax used for examples in this manual, for much the same reason.
|
|
|
1827 The Atari syntax for constructs more modern than INTERCAL-72 is
|
|
|
1828 normally taken to be that used by the C-INTERCAL compiler, because it is
|
|
|
1829 the only Atari-syntax-based compiler that contains non-INTERCAL-72
|
|
|
1830 constructs that actually need their own notation.
|
|
|
1831
|
|
|
1832
|
|
|
1833 File: ick.info, Node: Line Labels, Next: Statement Identifiers, Prev: Princeton and Atari Syntax, Up: Syntax
|
|
|
1834
|
|
|
1835 5.2 Line Labels
|
|
|
1836 ===============
|
|
|
1837
|
|
|
1838 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
1839 ------------------------------------------------------------------------
|
|
|
1840 yes all versions all versions all versions
|
|
|
1841
|
|
|
1842 The first part of an INTERCAL statement is a line label that specifies
|
|
|
1843 what its line number is. This is optional; it's allowed to have a
|
|
|
1844 statement without a line number, although that prevents other commands
|
|
|
1845 referring to it by number. Line numbers must be constants, and unique
|
|
|
1846 within the program. However, they do not have to be in order; unlike
|
|
|
1847 some other languages with line numbers, a line with a higher number can
|
|
|
1848 come earlier in the program than a line with a lower number, and the
|
|
|
1849 numbers don't affect the order in which commands are executed.
|
|
|
1850
|
|
|
1851 A line label is a integer expressed in decimal within a wax/wane pair
|
|
|
1852 (`(' and `)'). For instance, this is a valid line label:
|
|
|
1853
|
|
|
1854 (1000)
|
|
|
1855
|
|
|
1856 Note that line numbers from 1000 to 1999 are used by the system library,
|
|
|
1857 so using them within your own programs may produce unexpected errors if
|
|
|
1858 the system library is included. Apart from this, line numbers from 1 to
|
|
|
1859 65535 are allowed.
|
|
|
1860
|
|
|
1861 It has become reasonably customary for people writing INTERCAL libraries
|
|
|
1862 to pick a range of 1000 line numbers (for instance, 3000 to 3999) and
|
|
|
1863 stick to that range for all line numbers used in the program (apart from
|
|
|
1864 when calling the system library), so if you want to write an INTERCAL
|
|
|
1865 library, it may be a good idea to look at the existing libraries (in the
|
|
|
1866 `pit/lib' directory in the C-INTERCAL distribution) and choose a range
|
|
|
1867 of numbers that nobody else has used. If you aren't writing a library,
|
|
|
1868 it may be a good idea to avoid such number ranges (that is, use only
|
|
|
1869 line numbers below 1000 or very high numbers that are unlikely to be
|
|
|
1870 used by libraries in the future), so that you can easily add libraries
|
|
|
1871 to your program without renumbering in the future.
|
|
|
1872
|
|
|
1873
|
|
|
1874 File: ick.info, Node: Statement Identifiers, Next: Execution Chance, Prev: Line Labels, Up: Syntax
|
|
|
1875
|
|
|
1876 5.3 Statement Identifiers
|
|
|
1877 =========================
|
|
|
1878
|
|
|
1879 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
1880 ------------------------------------------------------------------------
|
|
|
1881 yes all versions all versions all versions
|
|
|
1882
|
|
|
1883 After the line label (if a statement has one) comes the statement
|
|
|
1884 identifier, which marks where the statement starts. Either the label or
|
|
|
1885 the statement identifier, whichever one comes first, marks where the
|
|
|
1886 preceding statement finishes.
|
|
|
1887
|
|
|
1888 The main statement identifier is `DO'. It also has two synonyms,
|
|
|
1889 `PLEASE' and `PLEASE DO'; these synonyms are the 'polite' forms of
|
|
|
1890 statement identifiers. Although the three identifiers have the same
|
|
|
1891 meaning, using either polite or non-polite identifiers too much can
|
|
|
1892 cause an error; the correct proportion is approximately 3 non-polite
|
|
|
1893 identifiers for every polite identifier used. None of these identifiers
|
|
|
1894 actually does anything else apart from marking where the statement
|
|
|
1895 starts; they leave the statements in the default `reinstated' state.
|
|
|
1896
|
|
|
1897 Adding `NOT' or `N'T' to the end of any of these identifiers, to create
|
|
|
1898 a statement identifier such as `DO NOT' or `PLEASE DON'T', also creates
|
|
|
1899 a valid statement identifier. These differ in meanings from the
|
|
|
1900 previous set of identifiers, though; they cause the statement they
|
|
|
1901 precede to not be executed by default; that is, the command will be
|
|
|
1902 skipped during execution (this is known as the `abstained' state).
|
|
|
1903 This applies even if the command in question is in fact a syntax error,
|
|
|
1904 thus causing this to be a useful method of writing comments. One
|
|
|
1905 common idiom is to write code like this:
|
|
|
1906
|
|
|
1907 PLEASE NOTE: This is a comment.
|
|
|
1908
|
|
|
1909 The statement identifier (`PLEASE NOT') is the only part of this
|
|
|
1910 statement that is valid INTERCAL; however, because the statement
|
|
|
1911 identifier is in the negated form that contains `NOT', the syntax error
|
|
|
1912 won't be executed, and therefore this is a valid statement. (In
|
|
|
1913 INTERCAL, syntax errors happen at runtime, so a program containing a
|
|
|
1914 statement like `DOUBT THIS WILL WORK' will still compile, and will not
|
|
|
1915 end due to the syntax error unless that statement is actually executed.
|
|
|
1916 *Note E000::.)
|
|
|
1917
|
|
|
1918 The `ABSTAIN' and `REINSTATE' statements can override the `NOT' or
|
|
|
1919 otherwise on a statement identifier; see *note ABSTAIN::.
|
|
|
1920
|
|
|
1921 In backtracking programs, `MAYBE' is also a valid statement identifier;
|
|
|
1922 see *note MAYBE::. It comes before the other keywords in the statement
|
|
|
1923 identifier, and an implicit `DO' is added if there wasn't one already
|
|
|
1924 in the statement identifier (so `MAYBE', `MAYBE DO', `MAYBE DON'T',
|
|
|
1925 `MAYBE PLEASE', and so on are all valid statement identifiers).
|
|
|
1926
|
|
|
1927
|
|
|
1928 File: ick.info, Node: Execution Chance, Next: ONCE and AGAIN, Prev: Statement Identifiers, Up: Syntax
|
|
|
1929
|
|
|
1930 5.4 Execution Chance
|
|
|
1931 ====================
|
|
|
1932
|
|
|
1933 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
1934 ------------------------------------------------------------------------
|
|
|
1935 yes all versions version 0.02+ all versions
|
|
|
1936
|
|
|
1937 It's possible to specify that a command should be run only a certain
|
|
|
1938 proportion of the time, at random. This is a rarely used feature of
|
|
|
1939 INTERCAL, although it is the only way to introduce randomness into a
|
|
|
1940 program. (The C-INTERCAL compiler approximates this with
|
|
|
1941 pseudorandomness.) An execution chance specification comes immediately
|
|
|
1942 after the statement identifier, but before the rest of the statement,
|
|
|
1943 and consists of a double-oh-seven (`%') followed by an integer from 1
|
|
|
1944 to 99 inclusive, written in decimal; this gives the percentage chance
|
|
|
1945 of the statement running. The execution chance only acts to prevent a
|
|
|
1946 statement running when it otherwise would have run; it cannot cause a
|
|
|
1947 statement that would otherwise not have run to run. For instance, the
|
|
|
1948 statement `DO %40 WRITE OUT #1' has a 40% chance of writing out `I',
|
|
|
1949 but the statement `DON'T %40 WRITE OUT #1' has no chance of writing out
|
|
|
1950 `I' or anything else, because the `N'T' prevents it running and the
|
|
|
1951 double-oh-seven cannot override that.
|
|
|
1952
|
|
|
1953
|
|
|
1954 File: ick.info, Node: ONCE and AGAIN, Prev: Execution Chance, Up: Syntax
|
|
|
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
|
|
|
2001 File: ick.info, Node: Expressions, Next: Statements, Prev: Syntax, Up: Top
|
|
|
2002
|
|
|
2003 6 Expressions
|
|
|
2004 *************
|
|
|
2005
|
|
|
2006 Many INTERCAL statements take expressions as arguments. Expressions are
|
|
|
2007 made up out of operands and operators between them. Note that there is
|
|
|
2008 no operator precedence in INTERCAL; different compilers resolve
|
|
|
2009 ambiguities different ways, and some versions of some compilers
|
|
|
2010 (including the original INTERCAL-72 compiler) will cause error messages
|
|
|
2011 on compiling or executing an ambiguous expression, so it's safest to
|
|
|
2012 fully group each expression.
|
|
|
2013
|
|
|
2014 * Menu:
|
|
|
2015
|
|
|
2016 * Constants and Variables:: The basic operands that make up expressions
|
|
|
2017 * Grouping Rules:: How to specify grouping in expressions
|
|
|
2018 * Operators:: Joining operands into more complex expressions
|
|
|
2019
|
|
|
2020
|
|
|
2021 File: ick.info, Node: Constants and Variables, Next: Grouping Rules, Up: Expressions
|
|
|
2022
|
|
|
2023 6.1 Constants and Variables
|
|
|
2024 ===========================
|
|
|
2025
|
|
|
2026 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2027 ------------------------------------------------------------------------
|
|
|
2028 yes all versions all versions all versions
|
|
|
2029
|
|
|
2030 The basic operands in INTERCAL are constants and variables. These
|
|
|
2031 together make up what in other languages are known as `lvalues', that
|
|
|
2032 is, operands to which values can be assigned. (Constants can also be
|
|
|
2033 lvalues in INTERCAL, but by default C-INTERCAL turns this off because it
|
|
|
2034 carries an efficiency penalty and can be confusing; this can be turned
|
|
|
2035 on with the `-v' option (*note -v::).)
|
|
|
2036
|
|
|
2037 Constants can have any integer value from 0 to 65535 inclusive; higher
|
|
|
2038 values (up to 4294967295) can be generated in programs, but cannot be
|
|
|
2039 specified literally as constants. (The usual way to work around this
|
|
|
2040 limitation is to interleave two constants together; see *note
|
|
|
2041 Mingle::.) A constant is written as a mesh (`#') followed by a number in
|
|
|
2042 decimal. At the start of the program, all constants have the same value
|
|
|
2043 as the number that identifies them; for instance, `#100' has 100 as its
|
|
|
2044 value, and it's strongly advised not to change the value of a constant
|
|
|
2045 during the execution of a program.
|
|
|
2046
|
|
|
2047 There are four types of variable: 16-bit and 32-bit unsigned integers,
|
|
|
2048 and arrays of 16-bit and 32-bit unsigned integers. These are
|
|
|
2049 represented with a spot, twospot, tail, and hybrid (`.', `:', `,', and
|
|
|
2050 `;') respectively. For this reason, integers within the range 0 to
|
|
|
2051 65535 inclusive are known as `onespot numbers', and integers within the
|
|
|
2052 range 0 to 4294967295 inclusive are known as `twospot numbers';
|
|
|
2053 variables with those ranges are known as onespot and twospot variables.
|
|
|
2054 (Note that arrays did not work in C-INTERCAL before version 0.7.)
|
|
|
2055
|
|
|
2056 Variables are represented with a character representing their data type,
|
|
|
2057 followed by an integer from 1 to 65535 inclusive, written in decimal.
|
|
|
2058 Non-array variables don't need to be declared before they are used; they
|
|
|
2059 automatically exist in any program that uses them. For instance, `.1'
|
|
|
2060 and `.001' are the same variable, onespot number 1. Array variables
|
|
|
2061 need to be dimensioned before they are used, by assigning dimensions to
|
|
|
2062 them; see *note Calculate::.
|
|
|
2063
|
|
|
2064
|
|
|
2065 File: ick.info, Node: Grouping Rules, Next: Operators, Prev: Constants and Variables, Up: Expressions
|
|
|
2066
|
|
|
2067 6.2 Grouping Rules
|
|
|
2068 ==================
|
|
|
2069
|
|
|
2070 Because there are no operator precedences in INTERCAL, there are various
|
|
|
2071 solutions to specifying what precedences actually are.
|
|
|
2072
|
|
|
2073 The portable solution
|
|
|
2074 All known versions of INTERCAL accept the INTERCAL-72 grouping
|
|
|
2075 rules. These state that it's possible to specify that an operator
|
|
|
2076 takes precedence by grouping it inside sparks (`'') or rabbit-ears
|
|
|
2077 (`"'), the same way as wax/wane pairs (parentheses) are used in
|
|
|
2078 other programming languages. INTERCAL-72 and earlier C-INTERCAL
|
|
|
2079 versions demanded that expressions were grouped fully like this,
|
|
|
2080 and this practice is still recommended because it leads to
|
|
|
2081 portable programs and is easier to understand. Whether sparks or
|
|
|
2082 rabbit-ears (often called just `ears' for short) are used normally
|
|
|
2083 doesn't matter, and programmers can use one or the other for
|
|
|
2084 clarity or for aesthetic appeal. (One common technique is to use
|
|
|
2085 just sparks at the outermost level of grouping, just ears at the
|
|
|
2086 next level, just sparks at the next level, and so on; but
|
|
|
2087 expressions like `''#1~#2'~"#3~#4"'~#5' are completely
|
|
|
2088 unambiguous, at least to the compiler.)
|
|
|
2089
|
|
|
2090 There are, however, some complicated situations involving array
|
|
|
2091 subscripting where it is necessary to use sparks and ears at
|
|
|
2092 alternate levels, if you want to write a portable program. This
|
|
|
2093 limitation is in C-INTERCAL to simplify the parsing process;
|
|
|
2094 INTERCAL-72 has the same limitation, probably for the same reason.
|
|
|
2095 Compare these two statements:
|
|
|
2096
|
|
|
2097 DO .1 <- ,3SUB",2SUB.1".2
|
|
|
2098 DO .1 <- ,3SUB",2SUB.1".2~.3"".4
|
|
|
2099
|
|
|
2100 The problem is that in the first statement, the ears close a
|
|
|
2101 group, and in the second statement, the ears open a group, and
|
|
|
2102 it's impossible to tell the difference without unlimited lookahead
|
|
|
2103 in the expression. Therefore, in similar situations (to be
|
|
|
2104 precise, in situations where a group is opened inside an array
|
|
|
2105 subscript), it's necessary to use the other grouping character to
|
|
|
2106 the one that opened the current group if you want a portable
|
|
|
2107 program.
|
|
|
2108
|
|
|
2109 One final comment about sparks and rabbit-ears; if the next
|
|
|
2110 character in the program is a spot, as often happens because
|
|
|
2111 onespot variables are common choices for operands, a spark and the
|
|
|
2112 following spot can be combined into a wow (`!'). Unfortunately,
|
|
|
2113 none of the character sets that C-INTERCAL accepts as input
|
|
|
2114 (UTF-8, Latin-1, and ASCII-7) contain the rabbit character,
|
|
|
2115 although the Hollerith input format that CLC-INTERCAL can use does.
|
|
|
2116
|
|
|
2117 Positional precedences: CLC-INTERCAL rules
|
|
|
2118 The precedence rules used by CLC-INTERCAL for grouping when full
|
|
|
2119 grouping isn't used are simple to explain: the largest part of the
|
|
|
2120 input that looks like an expression is taken to be that
|
|
|
2121 expression. The main practical upshot of this is that binary
|
|
|
2122 operators right-associate; that is, `.1~.2~.3' is equivalent to
|
|
|
2123 `.1~'.2~.3''. C-INTERCAL versions 0.26 and later also
|
|
|
2124 right-associate binary operators so as to produce the same results
|
|
|
2125 as CLC-INTERCAL rules in this situation, but as nobody has yet
|
|
|
2126 tried to work out what the other implications of CLC-INTERCAL
|
|
|
2127 rules are they are not emulated in C-INTERCAL, except possibly by
|
|
|
2128 chance.
|
|
|
2129
|
|
|
2130 Prefix and infix unary operators
|
|
|
2131 In INTERCAL-72 and versions of C-INTERCAL before 0.26, unary
|
|
|
2132 operators were always in the `infix' position. (If you're
|
|
|
2133 confused about how you can have an infix unary operator: they go
|
|
|
2134 one character inside a group that they apply to, or one character
|
|
|
2135 after the start of a constant or variable representation; so for
|
|
|
2136 instance, to portably apply the unary operator `&' to the variable
|
|
|
2137 `:1', write `:&1', and to portably apply it to the expression
|
|
|
2138 `'.1~.2'', write `'&.1~.2''.) CLC-INTERCAL, and versions of
|
|
|
2139 C-INTERCAL from 0.26 onwards, allow the `prefix' position of a
|
|
|
2140 unary operator, which is just before whatever it applies to (as in
|
|
|
2141 `&:1'). This leads to ambiguities as to whether an operator is
|
|
|
2142 prefix or infix. The portable solution is, of course, to use only
|
|
|
2143 infix operators and fully group everything, but when writing for
|
|
|
2144 recent versions of C-INTERCAL, it's possible to rely on its
|
|
|
2145 grouping rule, which is: unary operators are interpreted as infix
|
|
|
2146 where possible, but at most one infix operator is allowed to apply
|
|
|
2147 to each variable, constant, or group, and infix operators can't
|
|
|
2148 apply to anything else. So for instance, the C-INTERCAL
|
|
|
2149 `'&&&.1~.2'' is equivalent to the portable `'&"&.&1"~.2'' (or the
|
|
|
2150 more readable version of this, `"&'"&.&1"~.2'"', which is also
|
|
|
2151 portable). If these rules are counter-intuitive to you, remember
|
|
|
2152 that this is INTERCAL we're talking about; note also that this
|
|
|
2153 rule is unique to C-INTERCAL, at least at the time of writing, and
|
|
|
2154 in particular CLC-INTERCAL is likely to interpret this expression
|
|
|
2155 differently.
|
|
|
2156
|
|
|
2157
|
|
|
2158
|
|
|
2159 File: ick.info, Node: Operators, Prev: Grouping Rules, Up: Expressions
|
|
|
2160
|
|
|
2161 6.3 Operators
|
|
|
2162 =============
|
|
|
2163
|
|
|
2164 Operators are used to operate on operands, to produce more complicated
|
|
|
2165 expressions that actually calculate something rather than just fetch
|
|
|
2166 information from memory. There are two types of operators, unary and
|
|
|
2167 binary operators, which operate on one and two arguments respectively.
|
|
|
2168 Binary operators are always written between their two operands; to
|
|
|
2169 portably write a unary operator, it should be in the `infix' position,
|
|
|
2170 one character after the start of its operand; see *note Prefix and
|
|
|
2171 infix unary operators:: for the full details of how to write unary
|
|
|
2172 operators portably, and how else you can use them if you aren't aiming
|
|
|
2173 for portability. This section only describes INTERCAL-72 operators;
|
|
|
2174 many INTERCAL extensions add their own operators.
|
|
|
2175
|
|
|
2176 * Menu:
|
|
|
2177
|
|
|
2178 * Mingle:: Interleaving bits in two operands
|
|
|
2179 * Select:: Selecting from one operand according to another
|
|
|
2180 * Unary Binary Logic:: Binary logic on adjacent bits of an operand
|
|
|
2181 * Array Subscript:: Selecting elements of arrays
|
|
|
2182
|
|
|
2183
|
|
|
2184 File: ick.info, Node: Mingle, Next: Select, Up: Operators
|
|
|
2185
|
|
|
2186 6.3.1 Mingle
|
|
|
2187 ------------
|
|
|
2188
|
|
|
2189 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2190 ------------------------------------------------------------------------
|
|
|
2191 yes all versions all versions all versions
|
|
|
2192
|
|
|
2193 Mingle, or interleave, is one of the two binary operators in
|
|
|
2194 INTERCAL-72. However, different INTERCAL compilers represent it in
|
|
|
2195 different ways, so it is impossible to write a mingle in a program
|
|
|
2196 completely portably, because it differs between Princeton and Atari
|
|
|
2197 syntax, and worse, the sequence of character codes needed to represent
|
|
|
2198 it in each syntax has varied from compiler to compiler.
|
|
|
2199
|
|
|
2200 The original INTERCAL-72 compiler (the Princeton compiler) used the
|
|
|
2201 'change' (cent) character for a mingle, represented as `c', backspace,
|
|
|
2202 `/'. (By the way, this is still the most portable way to write a
|
|
|
2203 mingle; both C-INTERCAL and CLC-INTERCAL accept it, at least if a
|
|
|
2204 lowercase `c' is used, the Atari compiler accepted it, and its
|
|
|
2205 documentation claimed that the Princeton compiler also accepted it;
|
|
|
2206 CLC-INTERCAL also accepts a capital `C' before the backspace and `/',
|
|
|
2207 and allows `|' rather than `/'.) The Atari compiler, another
|
|
|
2208 INTERCAL-72 compiler, used a 'big money' character (`$') as the mingle
|
|
|
2209 character; this character is also the only one accepted for mingle by
|
|
|
2210 the J-INTERCAL compiler. C-INTERCAL originally also used the `$'
|
|
|
2211 character for mingle, and this character is the one most commonly seen
|
|
|
2212 in existing C-INTERCAL programs, and most often used when giving
|
|
|
2213 examples of INTERCAL on Usenet, because it exists in the ASCII-7
|
|
|
2214 character set, and because it doesn't contain control characters. From
|
|
|
2215 version 0.18 of C-INTERCAL onwards, various other units of currency
|
|
|
2216 (change, quid, and zlotnik if Latin-1 is used as the input, and euro if
|
|
|
2217 Latin-9 is used as the input) are accepted; from version 0.20 onwards,
|
|
|
2218 in addition to the Latin-1 characters, all the currency symbols in
|
|
|
2219 Unicode are accepted if UTF-8 is used as the input format.
|
|
|
2220 CLC-INTERCAL has always used the change character (either the Latin-1
|
|
|
2221 version or the version that contains a backspace) for mingle. In this
|
|
|
2222 manual, mingle will be represented as `$', but it's important to bear
|
|
|
2223 in mind that this character is not the most portable choice.
|
|
|
2224
|
|
|
2225 The mingle operator should be applied to two operands or expressions.
|
|
|
2226 To be portable, the operands must both be onespot expressions, that is
|
|
|
2227 expressions which have a 16-bit result; C-INTERCAL relaxes this rule
|
|
|
2228 slightly and only requires that the result be in the onespot range.
|
|
|
2229 (This is because the data type of a select operator's value is meant to
|
|
|
2230 be determined at runtime; C-INTERCAL determines all data types at
|
|
|
2231 compile time, so has to guess a 32-bit result for a select with a
|
|
|
2232 32-bit type as its right operand even when the result might actually
|
|
|
2233 turn out to be of a 16-bit type, and so this behaviour prevents an
|
|
|
2234 error when a select operation returns a value with a 16-bit data type
|
|
|
2235 and is used as an argument to a mingle.) The result is a 32-bit value
|
|
|
2236 (that is, it is of a 32-bit data type, even if its value fits into the
|
|
|
2237 onespot range), which consists of bits alternated from the two
|
|
|
2238 arguments; to be precise, its most significant bit is the most
|
|
|
2239 significant bit of its first argument, its second most significant bit
|
|
|
2240 is the most significant bit of its second argument, its third most
|
|
|
2241 significant bit is the second most significant bit of its first
|
|
|
2242 argument, and so on until its least significant bit, which is the least
|
|
|
2243 significant bit of its second argument.
|
|
|
2244
|
|
|
2245 One of the most common uses of interleaving is to create a constant with
|
|
|
2246 a value greater than 65535; for instance, 65536 is `#256$#0'. It is
|
|
|
2247 also commonly used in expressions that need to produce 32-bit results;
|
|
|
2248 except in some simple cases, this is usually coded by calculating
|
|
|
2249 separately the odd-numbered and even-numbered bits of the result, and
|
|
|
2250 mingling them together at the end. It is also used in expressions that
|
|
|
2251 need to left-shift values or perform similar value-increasing
|
|
|
2252 operations, as none of the other operators can easily do this; and
|
|
|
2253 mingle results are commonly used as the argument to unary binary logic
|
|
|
2254 operators, because this causes them to behave more like the binary
|
|
|
2255 logic operators found in some other languages.
|
|
|
2256
|
|
|
2257
|
|
|
2258 File: ick.info, Node: Select, Next: Unary Binary Logic, Prev: Mingle, Up: Operators
|
|
|
2259
|
|
|
2260 6.3.2 Select
|
|
|
2261 ------------
|
|
|
2262
|
|
|
2263 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2264 ------------------------------------------------------------------------
|
|
|
2265 yes all versions all versions all versions
|
|
|
2266
|
|
|
2267 The select operator is one of the two binary operators in INTERCAL-72;
|
|
|
2268 unlike mingle, every known implementation of INTERCAL ever has used the
|
|
|
2269 sqiggle character (`~') as the representation of the select operator,
|
|
|
2270 meaning that writing it portably is easy.
|
|
|
2271
|
|
|
2272 The select operator takes two arguments, which can be of either
|
|
|
2273 datatype (that is, 16- or 32-bit). It returns a value made by
|
|
|
2274 selecting certain bits of its first operand indicated by the second
|
|
|
2275 operand, and right-justifying them. What it does is that it ignores
|
|
|
2276 all the bits of the first operand where the second operand has a 0 as
|
|
|
2277 the corresponding bit, that is, deletes them from a copy of the
|
|
|
2278 operand's value; the bits that are left are squashed together towards
|
|
|
2279 the least-significant end of the number, and the result is filled with
|
|
|
2280 0s to make it up to 16 or 32 bits. (In INTERCAL-72 the minimum multiple
|
|
|
2281 of 16 bits possible that the result fits into is chosen, although if :1
|
|
|
2282 has the value 131061 (in hex, 1FFFF) the expression `#21~:1' produces a
|
|
|
2283 32-bit result because 17 bits were selected, even though many of the
|
|
|
2284 leading bits were zeros; in C-INTERCAL the data type of the result is
|
|
|
2285 the same as of the right operand of the select, so that it can be
|
|
|
2286 determined at compile time, and so using a unary binary logic operator
|
|
|
2287 on the result of select when the right operand has a 32-bit type is
|
|
|
2288 nonportable and not recommended.) As an example, `#21~:1' produces 21
|
|
|
2289 as its result if :1 has the value 131061, 10 as its result if :1 has
|
|
|
2290 the value 30 (1E in hex; the least significant bit of 21 is removed
|
|
|
2291 because it corresponds to a 0 in :1), and 7 as its result if :1 has the
|
|
|
2292 value 21 (because three bits in 21 are set, and those three bits from
|
|
|
2293 21 are therefore selected by 21).
|
|
|
2294
|
|
|
2295 Select is used for right-shifts, to select every second bit from a
|
|
|
2296 number (either to produce what will eventually become an argument to
|
|
|
2297 mingle, or to interpret the result of a unary binary logic operator, or
|
|
|
2298 occasionally both), to test if a number is zero or not (by selecting it
|
|
|
2299 from itself and selecting 1 from the result), in some cases as a limited
|
|
|
2300 version of bitwise-and (that only works if the right operand is 1 less
|
|
|
2301 than a power of 2), and for many other purposes.
|
|
|
2302
|
|
|
2303
|
|
|
2304 File: ick.info, Node: Unary Binary Logic, Next: Array Subscript, Prev: Select, Up: Operators
|
|
|
2305
|
|
|
2306 6.3.3 Unary Binary Logic
|
|
|
2307 ------------------------
|
|
|
2308
|
|
|
2309 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2310 ------------------------------------------------------------------------
|
|
|
2311 yes all versions all versions all versions
|
|
|
2312
|
|
|
2313 There are three unary operators in INTERCAL-72, each of which carries
|
|
|
2314 out a binary logic operation on adjacent bits of the number. The
|
|
|
2315 operators are and, or, and exclusive or; and and or are represented by
|
|
|
2316 an ampersand (`&') and book (`V') respectively, and exclusive or has
|
|
|
2317 the same notational problems as mingle, as it differs between Princeton
|
|
|
2318 and Atari syntax. It was represented by a bookworm, written `V',
|
|
|
2319 backspace, `-', in the Princeton INTERCAL-72 implementation, and this
|
|
|
2320 is still the most portable way to write it (C-INTERCAL and CLC-INTERCAL
|
|
|
2321 accept it). The Atari implementation of INTERCAL-72 wrote it with a
|
|
|
2322 what (`?'), and this is the representation originally used by
|
|
|
2323 C-INTERCAL (and still accepted), the only representation accepted by
|
|
|
2324 J-INTERCAL, the one most commonly used on Usenet, and the one used in
|
|
|
2325 this manual (although again, it's worth pointing out that this isn't
|
|
|
2326 portable). CLC-INTERCAL approximates a bookworm with the yen
|
|
|
2327 character, which being a currency character is one of the possible
|
|
|
2328 representations for mingle in C-INTERCAL; C-INTERCAL uses the rather
|
|
|
2329 confusing method of interpreting a yen character as exclusive-or if
|
|
|
2330 input in Latin-1 but as mingle if input in UTF-8. (This usually does
|
|
|
2331 the right thing, because CLC-INTERCAL doesn't support UTF-8.) In the
|
|
|
2332 same way, CLC-INTERCAL has a C-INTERCAL compatibility option to allow
|
|
|
2333 the use of `?' for exclusive-or.
|
|
|
2334
|
|
|
2335 The operators take each pair of consecutive bits in their arguments
|
|
|
2336 (that is, the least significant with the second least significant, the
|
|
|
2337 second least significant with the third least significant, the third
|
|
|
2338 least significant with the fourth least significant, and so on, with the
|
|
|
2339 pair consisting of the most significant and least significant being used
|
|
|
2340 to calculate the most significant bit of the result), and perform an
|
|
|
2341 appropriate logic operation on them; and sets a bit of the result if and
|
|
|
2342 only if both bits in the pair were set, or sets each bit corresponding
|
|
|
2343 to each pair where either bit was set, and exclusive or sets if and
|
|
|
2344 only if the bits in the pair had different values (that is, one was
|
|
|
2345 set, but not both). So for instance, `#&26' is 16 (26 is 1A in
|
|
|
2346 hexadecimal or 11010 in binary); `#V26' is 31 (11111 in binary), and
|
|
|
2347 `#?26' is 23 (10111 in binary).
|
|
|
2348
|
|
|
2349 The most commonly seen use for these operators is to carry out bitwise
|
|
|
2350 ands, ors, and exclusive ors between two different 16-bit expressions,
|
|
|
2351 by mingling them together, applying a unary binary logic operator, and
|
|
|
2352 selecting every second bit of the result; such code often results due to
|
|
|
2353 people thinking in terms of some other language when writing INTERCAL,
|
|
|
2354 but is still often useful. (Historically, the first idiom added to the
|
|
|
2355 optimizer, apart from constant folding, was the mingle/unary/select
|
|
|
2356 sequence.) There are more imaginative uses; one impressive example is
|
|
|
2357 the exclusive or in the test for greater-than from the original
|
|
|
2358 INTERCAL-72 system library:
|
|
|
2359
|
|
|
2360 DO :5 <- "'?":1~'#65535$#0'"$":2~'#65535$#0'"'
|
|
|
2361 ~'#0$#65535'"$"'?":1~'#0$#65535'"$":2~'#0$
|
|
|
2362 #65535'"'~'#0$#65535'"
|
|
|
2363 DO .5 <- '?"'&"':2~:5'~'"'?"'?":5~:5"~"#65535~
|
|
|
2364 #65535"'~'#65535$#0'"$#32768'~'#0$#65535'"
|
|
|
2365 $"'?":5~:5"~"#65535$#65535"'~'#0$#65535'"'
|
|
|
2366 "$"':5~:5'~#1"'~#1"$#2'~#3
|
|
|
2367
|
|
|
2368 The first statement works out the value of :1 bitwise exclusive or :2;
|
|
|
2369 the second statement then works out whether the most significant set bit
|
|
|
2370 in :5 (that is, the most significant bit that differs between :1 and :2)
|
|
|
2371 corresponds to a set bit in :2 or not. In case that's a bit too
|
|
|
2372 confusing to read, here's the corresponding optimizer idiom (in OIL):
|
|
|
2373
|
|
|
2374 ((_1~:2)~((?32(:2~:2))^#2147483648))->(_1>(:2^_1))
|
|
|
2375
|
|
|
2376 (Here, the ^ refers to a bitwise exclusive or, an operation found in OIL
|
|
|
2377 but not in INTERCAL, which is why the INTERCAL version is so much
|
|
|
2378 longer.) The INTERCAL version also has some extra code to check for
|
|
|
2379 equality and to produce 1 or 2 as the output rather than 0 or 1.
|
|
|
2380
|
|
|
2381
|
|
|
2382 File: ick.info, Node: Array Subscript, Prev: Unary Binary Logic, Up: Operators
|
|
|
2383
|
|
|
2384 6.3.4 Array Subscript
|
|
|
2385 ---------------------
|
|
|
2386
|
|
|
2387 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2388 ------------------------------------------------------------------------
|
|
|
2389 yes version 0.7+ all versions all versions
|
|
|
2390
|
|
|
2391 In order to access the elements of an array, either to read or write
|
|
|
2392 the array, it is necessary to use the array subscript operator `SUB'.
|
|
|
2393 Note that an array element is not a variable, so it is not accepted as
|
|
|
2394 an acceptable argument to statements like `IGNORE'; however, it can be
|
|
|
2395 assigned to.
|
|
|
2396
|
|
|
2397 The syntax for an array element is the array, followed by the keyword
|
|
|
2398 `SUB', followed by an expression for the element number in the array.
|
|
|
2399 In the case of a multidimensional array, more than one expression is
|
|
|
2400 given after the keyword `SUB' to give the location of the element in
|
|
|
2401 each of the array's dimensions. The first element in an array or array
|
|
|
2402 dimension is numbered 1.
|
|
|
2403
|
|
|
2404 For instance, this is a legal (but not particularly useful) INTERCAL
|
|
|
2405 program with no syntax errors that shows some of the syntaxes possible
|
|
|
2406 with array subscripting:
|
|
|
2407
|
|
|
2408 PLEASE ,1 <- #2
|
|
|
2409 DO .1 <- #2
|
|
|
2410 DO ,1 SUB .1 <- #1
|
|
|
2411 DO ,1 SUB #1 <- ,1 SUB #2
|
|
|
2412 PLEASE ;1 <- #2 BY #2
|
|
|
2413 DO ;1 SUB #1 #2 <- ,1 SUB ,1 SUB .1
|
|
|
2414 DO READ OUT ;1SUB#1.1
|
|
|
2415 DO GIVE UP
|
|
|
2416
|
|
|
2417 Grouping can get complicated when nested array subscripting is used,
|
|
|
2418 particularly with multiple subscripts. It is the programmer's job to
|
|
|
2419 write an unambiguous statement, and also obey the extra grouping rules
|
|
|
2420 that apply to array subscripts; see *note Grouping Rules::.
|
|
|
2421
|
|
|
2422
|
|
|
2423 File: ick.info, Node: Statements, Next: System Library, Prev: Expressions, Up: Top
|
|
|
2424
|
|
|
2425 7 Statements
|
|
|
2426 ************
|
|
|
2427
|
|
|
2428 There is a wide range of statements available to INTERCAL programs;
|
|
|
2429 some identifiably belong to a particular variant or dialect (such as
|
|
|
2430 Backtracking INTERCAL), but others can be considered to be part of the
|
|
|
2431 'core language'. The statements listed here are those that the
|
|
|
2432 C-INTERCAL compiler will accept with no compiler switches to turn on
|
|
|
2433 particular dialect options. Note that many statements have slightly
|
|
|
2434 different effects in different implementations of INTERCAL; known
|
|
|
2435 incompatibilities are listed here, but it's important to check your
|
|
|
2436 program on multiple compilers when attempting to write a portable
|
|
|
2437 program.
|
|
|
2438
|
|
|
2439 * Menu:
|
|
|
2440
|
|
|
2441 * Syntax Error:: Why use a deliberate syntax error?
|
|
|
2442 * Calculate:: Assigning to variables and arrays
|
|
|
2443 * NEXT FORGET and RESUME:: INTERCAL-72-style flow control
|
|
|
2444 * STASH and RETRIEVE:: Value stacks and scoping
|
|
|
2445 * IGNORE and REMEMBER:: Creating read-only variables
|
|
|
2446 * ABSTAIN and REINSTATE:: Dynamic DOs and DON'Ts
|
|
|
2447 * READ OUT and WRITE IN:: INTERCAL input and output
|
|
|
2448 * GIVE UP:: How to end a program
|
|
|
2449 * TRY AGAIN:: Control flow without loops
|
|
|
2450 * COME FROM and NEXT FROM:: Time-reversed GOTO
|
|
|
2451
|
|
|
2452
|
|
|
2453 File: ick.info, Node: Syntax Error, Next: Calculate, Up: Statements
|
|
|
2454
|
|
|
2455 7.1 Syntax Error
|
|
|
2456 ================
|
|
|
2457
|
|
|
2458 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2459 ------------------------------------------------------------------------
|
|
|
2460 yes version 0.15+ all versions all versions
|
|
|
2461
|
|
|
2462 One of the more commonly-used commands in INTERCAL is the syntax error.
|
|
|
2463 A properly-written syntax error looks nothing like any known INTERCAL
|
|
|
2464 command; a syntax error that looks vaguely like a command but isn't may
|
|
|
2465 confuse C-INTERCAL before version 0.28, and possibly other compilers,
|
|
|
2466 into bailing out at compile time in some situations (this is known as a
|
|
|
2467 `serious syntax error'), and so is not portable. For other syntax
|
|
|
2468 errors, though, the semantics are easily explained: there is a run-time
|
|
|
2469 error whenever the syntax error is actually executed, and the line
|
|
|
2470 containing the syntax error is used as the error message.
|
|
|
2471
|
|
|
2472 One purpose of this is to allow your programs to produce their own
|
|
|
2473 custom errors at run time; however, it's very important to make sure
|
|
|
2474 that they start and end in the right place, by manipulating where
|
|
|
2475 statement identifiers appear. Here's a correct example from the system
|
|
|
2476 library:
|
|
|
2477
|
|
|
2478 DOUBLE OR SINGLE PRECISION ARITHMETIC OVERFLOW
|
|
|
2479
|
|
|
2480 This is a valid INTERCAL command, that produces an error when run (note
|
|
|
2481 the `DO' at the start). An even more common use is to produce an
|
|
|
2482 initially abstained syntax error by using an appropriate statement
|
|
|
2483 identifier, for instance
|
|
|
2484
|
|
|
2485 PLEASE NOTE THAT THIS IS A COMMENT
|
|
|
2486
|
|
|
2487 This would produce an error if reinstated somehow, but assuming that
|
|
|
2488 this isn't done, this is a line of code that does nothing, which is
|
|
|
2489 therefore equivalent to a comment in other programming languages. (The
|
|
|
2490 initial abstention is achieved with the statement identifier `PLEASE
|
|
|
2491 NOT'; the extra `E' causes the command to be a syntax error, and this
|
|
|
2492 particular construction is idiomatic.)
|
|
|
2493
|
|
|
2494 Referring to the set of all syntax errors in a program (or the set of
|
|
|
2495 all commands of any other given type) is achieved with a special
|
|
|
2496 keyword known as a `gerund'; gerund support for syntax errors is
|
|
|
2497 resonably recent, and only exists in CLC-INTERCAL (version 1.-94.-3 and
|
|
|
2498 later, with `COMMENT', `COMMENTS', or `COMMENTING'), and C-INTERCAL
|
|
|
2499 (`COMMENT' in version 0.26 and later, and also `COMMENTS' and
|
|
|
2500 `COMMENTING' in version 0.27 and later). Therefore, it is not portable
|
|
|
2501 to refer to the set of all syntax errors by gerund; using a line label
|
|
|
2502 is a more portable way to refer to an individual syntax-error command.
|
|
|
2503
|
|
|
2504
|
|
|
2505 File: ick.info, Node: Calculate, Next: NEXT FORGET and RESUME, Prev: Syntax Error, Up: Statements
|
|
|
2506
|
|
|
2507 7.2 Calculate
|
|
|
2508 =============
|
|
|
2509
|
|
|
2510 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2511 ------------------------------------------------------------------------
|
|
|
2512 yes all versions all versions all versions
|
|
|
2513
|
|
|
2514 At present, the only INTERCAL command that contains no keywords (apart
|
|
|
2515 from the statement identifier and possibly `ONCE' or `AGAIN') is what
|
|
|
2516 is known as the `calculate' command. It is used to assign values to
|
|
|
2517 variables, array elements, and arrays; assigning a value to an array
|
|
|
2518 changes the number of elements that that array can hold, and causes the
|
|
|
2519 values of all elements previously in that array to be lost. The syntax
|
|
|
2520 of a calculate command is as follows:
|
|
|
2521
|
|
|
2522 DO .1 <- ':2~:3'~#55
|
|
|
2523
|
|
|
2524 That is, the command is written as a variable or array element, then
|
|
|
2525 the `<-' operator (known as an `angle-worm' and pronounced `gets'),
|
|
|
2526 then an expression to assign to it. In the special case when an array
|
|
|
2527 is being dimensioned by assigning a value to it, the expression can
|
|
|
2528 contain the keyword `BY' to cause the array to become multidimensional;
|
|
|
2529 so for a 3 by 4 by 5 array, it would be possible to write
|
|
|
2530
|
|
|
2531 DO ,1 <- #3 BY #4 BY #5
|
|
|
2532
|
|
|
2533 The calculate command always evaluates the expression, even if for some
|
|
|
2534 reason the assignment can't be done (for instance, if the variable
|
|
|
2535 being assigned to is read-only); this is important if the expression
|
|
|
2536 has side-effects (for instance, giving an overflow error). If the
|
|
|
2537 variable does happen to be read-only, there is not an error; the
|
|
|
2538 expression being assigned to it is just evaluated, with the resulting
|
|
|
2539 value being discarded.
|
|
|
2540
|
|
|
2541 The gerund to refer to calculations is `CALCULATING'; however, if you
|
|
|
2542 are planning to use this, note that a bug in older versions of
|
|
|
2543 C-INTERCAL means that assignments to arrays are not affected by this
|
|
|
2544 gerund before version 0.27.
|
|
|
2545
|
|
|
2546 CLC-INTERCAL from 1.-94.-4 onwards, and C-INTERCAL from 0.26 onwards,
|
|
|
2547 allow arbitrary expressions on the left hand side of an assignment
|
|
|
2548 (C-INTERCAL only if the `-v' option is used); for more information on
|
|
|
2549 how such `reverse assignments' work, see *note Operand Overloading::.
|
|
|
2550
|
|
|
2551
|
|
|
2552 File: ick.info, Node: NEXT FORGET and RESUME, Next: STASH and RETRIEVE, Prev: Calculate, Up: Statements
|
|
|
2553
|
|
|
2554 7.3 NEXT, FORGET and RESUME
|
|
|
2555 ===========================
|
|
|
2556
|
|
|
2557 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2558 ------------------------------------------------------------------------
|
|
|
2559 yes all versions see text all versions
|
|
|
2560
|
|
|
2561 The only flow-control commands in INTERCAL-72 were `NEXT', `RESUME',
|
|
|
2562 and `FORGET'; together these manipulate a stack of locations in the
|
|
|
2563 program known as the `NEXT stack'. Although all INTERCAL compilers
|
|
|
2564 have implemented these, from CLC-INTERCAL version 0.05 onwards
|
|
|
2565 CLC-INTERCAL has considered them obsolete, and therefore a special
|
|
|
2566 command-line switch needs to be used to enable them. (They are still
|
|
|
2567 the most portable flow-control commands currently available, though,
|
|
|
2568 precisely because INTERCAL-72 implements nothing else.) Note that there
|
|
|
2569 is a strict limit of 80 locations on the NEXT stack, enforced by all
|
|
|
2570 known INTERCAL compilers; this helps to enforce good programming style,
|
|
|
2571 by discouraging NEXT-stack leaks (which are otherwise quite easy to
|
|
|
2572 write).
|
|
|
2573
|
|
|
2574 Here are examples to show the syntax of these three statements:
|
|
|
2575
|
|
|
2576 DO (1000) NEXT
|
|
|
2577 DO FORGET '.1~.1'~#1
|
|
|
2578 DO RESUME .5
|
|
|
2579
|
|
|
2580 The `NEXT' command takes a line label as its argument (unlike most
|
|
|
2581 other INTERCAL commands, it comes after its argument rather than
|
|
|
2582 before); both `FORGET' and `RESUME' take expressions. (CLC-INTERCAL
|
|
|
2583 from version 0.05 onwards also allows an expression in `NEXT', rather
|
|
|
2584 than a label, to give a computed `NEXT', but this behaviour was not
|
|
|
2585 implemented in other compilers, and is deprecated in CLC-INTERCAL along
|
|
|
2586 with noncomputed `NEXT'; if computed `NEXT' is ever implemented in
|
|
|
2587 C-INTERCAL, it will likely likewise be deprecated upon introduction).
|
|
|
2588 (Update: it was implemented in C-INTERCAL version 0.28, but only as
|
|
|
2589 part of the external calls system, so it cannot be used in ordinary
|
|
|
2590 programs; a sample expansion library gives in-program access to a
|
|
|
2591 limited form of computed `NEXT', but should probably not be used.)
|
|
|
2592 Running a `NEXT' causes the program control to transfer to the command
|
|
|
2593 whose line label is referenced, and also saves the location in the
|
|
|
2594 program immediately after the `NEXT' command on the top of the NEXT
|
|
|
2595 stack.
|
|
|
2596
|
|
|
2597 In order to remove items from the `NEXT' stack, to prevent it filling
|
|
|
2598 up (which is what happens with a naive attempt to use the `NEXT'
|
|
|
2599 command as an equivalent to what some other languages call GOTO), it is
|
|
|
2600 possible to use the `FORGET' or `RESUME' commands. They each remove a
|
|
|
2601 number of items from the NEXT stack equal to their argument; `RESUME'
|
|
|
2602 also transfers control flow to the last location removed from the
|
|
|
2603 `NEXT' stack this way. Trying to remove no items, or more items than
|
|
|
2604 there are in the stack, does not cause an error when `FORGET' is used
|
|
|
2605 (no items or all the items are removed respectively); however, both of
|
|
|
2606 these cases are errors in a `RESUME' statement.
|
|
|
2607
|
|
|
2608 Traditionally, boolean values in INTERCAL programs have been stored
|
|
|
2609 using #1 and #2 as the two logic levels. This is because the easiest
|
|
|
2610 way to implement an if-like construct in INTERCAL-72 is by `NEXTING',
|
|
|
2611 then `NEXTING' again, then `RESUMING' either by 1 or 2 according to an
|
|
|
2612 expression, and then if the expression evaluated to 1 `FORGETTING' the
|
|
|
2613 remaining NEXT stack entry. By the way, the previous sentence also
|
|
|
2614 explained what the appropriate gerunds are for `NEXT', `RESUME', and
|
|
|
2615 `FORGET'.
|
|
|
2616
|
|
|
2617
|
|
|
2618 File: ick.info, Node: STASH and RETRIEVE, Next: IGNORE and REMEMBER, Prev: NEXT FORGET and RESUME, Up: Statements
|
|
|
2619
|
|
|
2620 7.4 STASH and RETRIEVE
|
|
|
2621 ======================
|
|
|
2622
|
|
|
2623 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2624 ------------------------------------------------------------------------
|
|
|
2625 yes all versions all versions all versions
|
|
|
2626
|
|
|
2627 The NEXT stack is not the only stack available in an INTERCAL program;
|
|
|
2628 each variable used in the program also has its own stack, which holds
|
|
|
2629 values of the same type as the variable. The `STASH' command pushes a
|
|
|
2630 variable's value onto that variable's stack; `RETRIEVE' can be used in
|
|
|
2631 the same way to pop the top element of a variable's stack to replace
|
|
|
2632 that variable's value. The syntax is the same as most other INTERCAL
|
|
|
2633 commands, with the word `STASH' or `RETRIEVE' followed by the variable
|
|
|
2634 or variables to stash or retrieve:
|
|
|
2635
|
|
|
2636 DO STASH .1 + ;2
|
|
|
2637 DO RETRIEVE ,3
|
|
|
2638
|
|
|
2639 Note that it is possible to stash or retrieve multiple variables at
|
|
|
2640 once, by listing their names separated by intersections (`+'); it's
|
|
|
2641 even possible to stash or retrieve a variable twice in the same
|
|
|
2642 statement.
|
|
|
2643
|
|
|
2644 It is not entirely clear how `RETRIEVE' interacts with `IGNORE' in
|
|
|
2645 historical INTERCAL-72 compilers; the three modern INTERCAL compilers
|
|
|
2646 all use different rules for the interaction (and the C-INTERCAL
|
|
|
2647 maintainers recommend that if anyone decides to write their own
|
|
|
2648 compiler, they choose yet another different rule so that looking at the
|
|
|
2649 interaction (the so-called `ignorret test') can be used as a method of
|
|
|
2650 determining which compiler is running):
|
|
|
2651
|
|
|
2652 * C-INTERCAL treats a retrieval just like an assignment. That is, a
|
|
|
2653 read-only variable will not be changed by a retrieval, and will
|
|
|
2654 remain read-only, but the side-effect of popping that variable's
|
|
|
2655 stash will still happen.
|
|
|
2656
|
|
|
2657 * J-INTERCAL ignores the read-only status of a variable when
|
|
|
2658 retrieving it from a stash; the value of the variable changes
|
|
|
2659 despite being read-only. The variable remains read-only; the
|
|
|
2660 `RETRIEVE' simply allows a change to its value despite the
|
|
|
2661 read-only status.
|
|
|
2662
|
|
|
2663 * CLC-INTERCAL is the most complicated; it stores read-only status or
|
|
|
2664 otherwise in the stash, along with the variable's value. This
|
|
|
2665 means that if a variable was stashed when read-only, retrieving it
|
|
|
2666 will retrieve its value and set it to read-only regardless of its
|
|
|
2667 previous read-only status; likewise, if a variable was stashed
|
|
|
2668 when read-write, retrieving it will retrieve its value and set it
|
|
|
2669 to read-write even if it was previously read-only.
|
|
|
2670
|
|
|
2671
|
|
|
2672 The appropriate gerunds for `STASH' and `RETRIEVE' are `STASHING' and
|
|
|
2673 `RETRIEVING' respectively.
|
|
|
2674
|
|
|
2675
|
|
|
2676 File: ick.info, Node: IGNORE and REMEMBER, Next: ABSTAIN and REINSTATE, Prev: STASH and RETRIEVE, Up: Statements
|
|
|
2677
|
|
|
2678 7.5 IGNORE and REMEMBER
|
|
|
2679 =======================
|
|
|
2680
|
|
|
2681 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2682 ------------------------------------------------------------------------
|
|
|
2683 yes all versions all versions all versions
|
|
|
2684
|
|
|
2685 Variables in INTERCAL can be either read-write or read-only. At the
|
|
|
2686 start of a program, all variables are read-write, but this status can
|
|
|
2687 be changed dynamically during execution of a program using the `IGNORE'
|
|
|
2688 and `REMEMBER' statements (whose gerunds are `IGNORING' and
|
|
|
2689 `REMEMBERING' respectively). The syntax is the same as for `STASH' and
|
|
|
2690 `RETRIEVE': the command's name followed by an intersection-separated
|
|
|
2691 list of variables. For instance:
|
|
|
2692
|
|
|
2693 DO IGNORE .4
|
|
|
2694 DO REMEMBER ,4 + ;5
|
|
|
2695
|
|
|
2696 Using the `IGNORE' statement sets a variable to be read-only (or does
|
|
|
2697 nothing if it's read-only already); `REMEMBER' sets it to be
|
|
|
2698 read-write. Any attempt to assign to a read-only variable silently
|
|
|
2699 fails. One place that this is used is in the system library; instead
|
|
|
2700 of not assigning to a variable in certain control flow paths, it
|
|
|
2701 instead sets it to be read-only so that subsequent assignments don't
|
|
|
2702 change its value (and sets it to be read-write at the end, which
|
|
|
2703 succeeds even if it was never set read-only in the first place); the
|
|
|
2704 advantage of this is that it doesn't need to remember what flow path
|
|
|
2705 it's on except in the variable's ignorance status.
|
|
|
2706
|
|
|
2707 The interaction between `IGNORE' and `RETRIEVE' was never defined very
|
|
|
2708 clearly, and is in fact different in C-INTERCAL, CLC-INTERCAL and
|
|
|
2709 J-INTERCAL; for more details, see *note RETRIEVE::.
|
|
|
2710
|
|
|
2711
|
|
|
2712 File: ick.info, Node: ABSTAIN and REINSTATE, Next: READ OUT and WRITE IN, Prev: IGNORE and REMEMBER, Up: Statements
|
|
|
2713
|
|
|
2714 7.6 ABSTAIN and REINSTATE
|
|
|
2715 =========================
|
|
|
2716
|
|
|
2717 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2718 ------------------------------------------------------------------------
|
|
|
2719 yes all versions all versions all versions
|
|
|
2720
|
|
|
2721 The statement identifier of a statement determines whether it's in an
|
|
|
2722 abstained or reinstated state at the start of a program; these states
|
|
|
2723 determine whether the statement runs at all when it's encountered. It
|
|
|
2724 is, however, possible to change this state dynamically during a
|
|
|
2725 program's execution, and the statements to do this are rather
|
|
|
2726 appropriately named `ABSTAIN' and `REINSTATE'. There are two forms of
|
|
|
2727 each, one which takes a single line label (which must be constant in
|
|
|
2728 most compilers, but can instead be an expression in recent CLC-INTERCAL
|
|
|
2729 versions), and one which takes an intersection-delimited list of
|
|
|
2730 gerunds. They look like this:
|
|
|
2731
|
|
|
2732 DO ABSTAIN FROM ABSTAINING + REINSTATING
|
|
|
2733 DO ABSTAIN FROM (10)
|
|
|
2734 DO REINSTATE CALCULATING
|
|
|
2735 DO REINSTATE (22)
|
|
|
2736
|
|
|
2737 (This also illustrates the gerunds used for these commands; note that
|
|
|
2738 `ABSTAINING' from `REINSTATING' is generally a bad idea!) The line
|
|
|
2739 referenced, or every command represented by any gerund referenced, are
|
|
|
2740 reinstated or abstained as appropriate (effectively changing the DO to
|
|
|
2741 DON'T (or PLEASE to PLEASE DON'T, etc.), or vice versa). Using these
|
|
|
2742 forms of `ABSTAIN' and/or `REINSTATE' won't abstain from a command
|
|
|
2743 that's already abstained, or reinstate a command that's already
|
|
|
2744 reinstated.
|
|
|
2745
|
|
|
2746 There is a strange set of restrictions on `ABSTAIN' and `REINSTATE'
|
|
|
2747 that has existed since INTERCAL-72; historically such restrictions have
|
|
|
2748 not always been implemented, or have not been implemented properly.
|
|
|
2749 They together define an unusual interaction of `ABSTAIN' and `GIVE UP'
|
|
|
2750 (note, for instance, that there isn't a gerund for `GIVE UP'). The
|
|
|
2751 wording used in the INTERCAL-72 manual is:
|
|
|
2752
|
|
|
2753 [...] the statement DO ABSTAIN FROM GIVING UP is not accepted, even
|
|
|
2754 though DON'T GIVE UP is. [...] DO REINSTATE GIVING UP is invalid,
|
|
|
2755 and attempting to REINSTATE a GIVE UP statement by line label will
|
|
|
2756 have no effect. Note that this insures that DON'T GIVE UP will
|
|
|
2757 always be a "do-nothing" statement.
|
|
|
2758
|
|
|
2759 This restriction was not implemented at all in the only CLC-INTERCAL
|
|
|
2760 version before 0.02 (i.e. version 0.01), or in C-INTERCAL versions
|
|
|
2761 before 1.26. The restriction was implemented in C-INTERCAL version 1.26
|
|
|
2762 and CLC-INTERCAL versions 0.02 and later as "`GIVE UP' cannot be
|
|
|
2763 `REINSTATED' or `ABSTAINED FROM'"; however, this is not strictly the
|
|
|
2764 same as the definition used by INTERCAL-72 (C-INTERCAL still uses this
|
|
|
2765 definition in CLC-INTERCAL compatibility mode). The J-INTERCAL
|
|
|
2766 implementation of this restriction is to make `REINSTATING' or
|
|
|
2767 `ABSTAINING' from a line label that refers to a `GIVE UP' statement a
|
|
|
2768 compile-time error, but this does not fit the INTERCAL-72 definition
|
|
|
2769 either. The definition adopted with version 0.27 and later of
|
|
|
2770 C-INTERCAL, which is hopefully correct, is to allow abstaining from a
|
|
|
2771 `GIVE UP' statement by line number but to rule out the other three
|
|
|
2772 cases (reinstating by line number silently fails, reinstating or
|
|
|
2773 abstaining by gerund is impossible because there is no gerund).
|
|
|
2774
|
|
|
2775 As well as CLC-INTERCAL's extension to abstain/reinstate by computed
|
|
|
2776 line number, there is also (since version 0.25) a C-INTERCAL-specific
|
|
|
2777 extension to `ABSTAIN', also known as `computed abstain', but with a
|
|
|
2778 different syntax and different semantics. It's written like an
|
|
|
2779 ordinary `ABSTAIN', but with an expression between the words `ABSTAIN'
|
|
|
2780 and `FROM', for instance:
|
|
|
2781
|
|
|
2782 DO ABSTAIN #1 FROM (1000)
|
|
|
2783 DO ABSTAIN .2 FROM WRITING IN
|
|
|
2784
|
|
|
2785 Unlike non-computed `ABSTAIN', this form allows a command to be
|
|
|
2786 abstained from even if it's already been abstained from; so if the
|
|
|
2787 first example command is run and line (1000) is already abstained, it
|
|
|
2788 becomes `double-abstained'. The number of times the statement is
|
|
|
2789 abstained from is equal to the number of times it was already abstained
|
|
|
2790 from, plus the expression (whereas with non-computed abstain, it ends
|
|
|
2791 up abstained once if it wasn't abstained at all, and otherwise stays at
|
|
|
2792 the same abstention status). Reinstating a statement always
|
|
|
2793 de-abstains it exactly once; so double-abstaining from a statement, for
|
|
|
2794 instance, means it needs to be reinstated twice before it will actually
|
|
|
2795 execute.
|
|
|
2796
|
|
|
2797 There are many uses for `ABSTAIN' (both the computed and non-computed
|
|
|
2798 versions) and `REINSTATE', especially when interacting with `ONCE' and
|
|
|
2799 `AGAIN' (*note ONCE and AGAIN::); the computed version, in particular,
|
|
|
2800 is a major part of a particular concise way to write conditionals and
|
|
|
2801 certain kinds of loops. They also play an important role in
|
|
|
2802 multithreaded programs.
|
|
|
2803
|
|
|
2804
|
|
|
2805 File: ick.info, Node: READ OUT and WRITE IN, Next: GIVE UP, Prev: ABSTAIN and REINSTATE, Up: Statements
|
|
|
2806
|
|
|
2807 7.7 READ OUT and WRITE IN
|
|
|
2808 =========================
|
|
|
2809
|
|
|
2810 The `READ OUT' and `WRITE IN' commands are the output and input
|
|
|
2811 commands in INTERCAL; they allow communication between the program and
|
|
|
2812 its user. There was a numeric I/O mechanism implemented in
|
|
|
2813 INTERCAL-72, and it (or trivial variants) have been likewise
|
|
|
2814 implemented in all more modern variants. However, it had some obvious
|
|
|
2815 deficiences (such as not being able to read its own output) which meant
|
|
|
2816 that other methods of I/O were implemented in C-INTERCAL and
|
|
|
2817 CLC-INTERCAL.
|
|
|
2818
|
|
|
2819 The syntax of `READ OUT' and `WRITE IN' is the same in all cases: the
|
|
|
2820 name of the command followed by an intersection-separated list of
|
|
|
2821 items; the form of each item, the compiler you are using, and its
|
|
|
2822 command line arguments together determine what sort of I/O is used,
|
|
|
2823 which can be different for different elements in the list.
|
|
|
2824
|
|
|
2825 * Menu:
|
|
|
2826
|
|
|
2827 * INTERCAL-72 I/O:: Spelt-out numbers and Roman numerals
|
|
|
2828 * C-INTERCAL I/O:: The Turing Tape I/O system
|
|
|
2829 * CLC-INTERCAL I/O:: Baudot and mingled binary
|
|
|
2830
|
|
|
2831
|
|
|
2832 File: ick.info, Node: INTERCAL-72 I/O, Next: C-INTERCAL I/O, Up: READ OUT and WRITE IN
|
|
|
2833
|
|
|
2834 7.7.1 INTERCAL-72 I/O
|
|
|
2835 ---------------------
|
|
|
2836
|
|
|
2837 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2838 ------------------------------------------------------------------------
|
|
|
2839 yes all versions see text all versions
|
|
|
2840
|
|
|
2841 INTERCAL-72 had its own versions of I/O commands; these commands are
|
|
|
2842 available in all modern INTERCAL compilers as well (but CLC-INTERCAL
|
|
|
2843 implements output slightly differently). To distinguish INTERCAL-72
|
|
|
2844 input and output from the other more modern types of I/O, the `READ
|
|
|
2845 OUT' and `WRITE IN' commands must take one of the following values: a
|
|
|
2846 onespot or twospot variable, a single element of a tail or hybrid
|
|
|
2847 array, or (in the case of `READ OUT') a constant, meaning that these
|
|
|
2848 are some examples of the possible forms:
|
|
|
2849
|
|
|
2850 READ OUT .1
|
|
|
2851 READ OUT ;2 SUB .3:4
|
|
|
2852 READ OUT #3
|
|
|
2853 WRITE IN :4
|
|
|
2854 WRITE IN ,5 SUB #6
|
|
|
2855
|
|
|
2856 The statements do what you would expect; `READ OUT' outputs its
|
|
|
2857 argument to the user, and `WRITE IN' inputs a number from the user and
|
|
|
2858 assigns it to the variable or array element referenced. (If the
|
|
|
2859 variable, or the array that contains the array element, happens to be
|
|
|
2860 read-only, the input or output still happens but in the case of `WRITE
|
|
|
2861 IN' silently skips the assignment, instead throwing away the input.)
|
|
|
2862 The formats used for input and output are, however, different from each
|
|
|
2863 other and from the formats used by most mainstream languages.
|
|
|
2864
|
|
|
2865 Input is achieved by writing a number in decimal, one digit at a time,
|
|
|
2866 with each digit written out as a word; so to input the number 12345, a
|
|
|
2867 user would have to type `ONE TWO THREE FOUR FIVE' as input (if they
|
|
|
2868 were using English, the most portable choice of language). In
|
|
|
2869 INTERCAL-72 only English is accepted as a language, but other compilers
|
|
|
2870 accept other languages in addition. C-INTERCAL from version 0.10
|
|
|
2871 onwards accepts English, Sanskrit, Basque, Tagalog, Classical Nahuatl,
|
|
|
2872 Georgian, and Kwakiutl; also Volapük from version 0.11 onwards, and
|
|
|
2873 Latin from version 0.20 onwards. J-INTERCAL accepts the same languages,
|
|
|
2874 except with Esperanto instead of Latin; from version 0.05 of
|
|
|
2875 CLC-INTERCAL onwards, the same list of languages as C-INTERCAL is
|
|
|
2876 supported (apart from Latin, which was added in version 1.-94.-8), plus
|
|
|
2877 Scottish Gaelic.
|
|
|
2878
|
|
|
2879 The format that output can be read in is a modified form of Roman
|
|
|
2880 numerals, known as `butchered' Roman numerals. INTERCAL-72, C-INTERCAL
|
|
|
2881 and J-INTERCAL do this the same way; CLC-INTERCAL is somewhat
|
|
|
2882 different. The characters `I', `V', `X', `L', `C', `D', and `M' mean 1,
|
|
|
2883 5, 10, 50, 100, 500 and 1000 respectively, placing a lower-valued
|
|
|
2884 letter after a higher-valued letter adds them, and placing a
|
|
|
2885 lower-valued letter before a higher-valued letter subtracts it from the
|
|
|
2886 value; so `XI' is 11 and `IX' is 9, for instance. In INTERCAL-72,
|
|
|
2887 C-INTERCAL, and J-INTERCAL, a bar over a numeral multiplies its value
|
|
|
2888 by 1000, and writing a letter in lowercase multiplies its value by
|
|
|
2889 1000000; however, CLC-INTERCAL uses lowercase to represent
|
|
|
2890 multiplication by 1000 and for multiplication by 1000000 writes a
|
|
|
2891 backslash before the relevant numeral.
|
|
|
2892
|
|
|
2893
|
|
|
2894 File: ick.info, Node: C-INTERCAL I/O, Next: CLC-INTERCAL I/O, Prev: INTERCAL-72 I/O, Up: READ OUT and WRITE IN
|
|
|
2895
|
|
|
2896 7.7.2 C-INTERCAL I/O
|
|
|
2897 --------------------
|
|
|
2898
|
|
|
2899 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2900 ------------------------------------------------------------------------
|
|
|
2901 no version 0.07+ version 0.05+ no
|
|
|
2902
|
|
|
2903 C-INTERCAL's method of character-based (rather than numeric) input and
|
|
|
2904 output is known as the Turing Tape method; it is a binary
|
|
|
2905 (character-set-agnostic) input/output mechanism. To specify that
|
|
|
2906 C-INTERCAL-style I/O is being used, an array must be used as the
|
|
|
2907 argument to `READ OUT' or `WRITE IN'; as the syntax is the same as for
|
|
|
2908 CLC-INTERCAL's I/O, command-line arguments and the capabilities of the
|
|
|
2909 version of the compiler being used serve to distinguish the two
|
|
|
2910 mechanisms.
|
|
|
2911
|
|
|
2912 The character-based input writes as many characters into a tail or
|
|
|
2913 hybrid array as will fit, one character in each element. The number
|
|
|
2914 that's written into the array is not the character code, though, but
|
|
|
2915 the difference between the character code and the previous character
|
|
|
2916 code, modulo 256. (To be precise, the code is the new character minus
|
|
|
2917 the previous character, or 256 minus (the previous character minus the
|
|
|
2918 new character) if the previous character had a higher character code;
|
|
|
2919 the 'previous character' is the previous character from the input, not
|
|
|
2920 the previous character written into the array.) End-of-file causes 256
|
|
|
2921 to be written into the array. The concept is that of a circular tape
|
|
|
2922 containing all the characters, where the program measures how many
|
|
|
2923 spaces it needs to move along the tape to reach the next character.
|
|
|
2924 The 'previous character' starts at 0, but is preserved throughout the
|
|
|
2925 entire program, even from one `WRITE IN' to the next.
|
|
|
2926
|
|
|
2927 Character-based output uses a similar model, but conceptually the
|
|
|
2928 output device moves on the inside of the tape, rather than on the
|
|
|
2929 outside. Therefore, the character is that is actually output is the
|
|
|
2930 bit-reversal of the difference between the last character output before
|
|
|
2931 it was bit-reversed and the number found in the array (subtracting in
|
|
|
2932 that order, and adding 256 if the result is negative). (Rather than
|
|
|
2933 trying to parse the previous sentence, you may find it easier to look
|
|
|
2934 either at the source code to the compiler if you have it (the relevant
|
|
|
2935 part is binout in `src/cesspool.c') or at some example C-INTERCAL
|
|
|
2936 programs that do text-based I/O.)
|
|
|
2937
|
|
|
2938
|
|
|
2939 File: ick.info, Node: CLC-INTERCAL I/O, Prev: C-INTERCAL I/O, Up: READ OUT and WRITE IN
|
|
|
2940
|
|
|
2941 7.7.3 CLC-INTERCAL I/O
|
|
|
2942 ----------------------
|
|
|
2943
|
|
|
2944 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2945 ------------------------------------------------------------------------
|
|
|
2946 no see text all versions no
|
|
|
2947
|
|
|
2948 There are also two CLC-INTERCAL-specific I/O mechanisms. These are
|
|
|
2949 Baudot-based text I/O (which is also implemented from C-INTERCAL version
|
|
|
2950 0.27 onwards), and CLC-INTERCAL generalised binary I/O (not implemented
|
|
|
2951 in C-INTERCAL).
|
|
|
2952
|
|
|
2953 Baudot text-based I/O is specified by using a tail array as an argument
|
|
|
2954 to `WRITE IN' or `READ OUT'. (A tail array can also be used to specify
|
|
|
2955 C-INTERCAL-style Turing Tape I/O. In order to determine which is used:
|
|
|
2956 both C-INTERCAL and CLC-INTERCAL use their own sort of I/O unless a
|
|
|
2957 command-line argument instructs them to use the other.) In the case of
|
|
|
2958 `WRITE IN', one line of input is requested from the user (C-INTERCAL
|
|
|
2959 requires this to be input in Latin-1, and will then automatically
|
|
|
2960 convert it; CLC-INTERCAL gives the option of various character sets for
|
|
|
2961 this input as command-line options); the final newline is removed from
|
|
|
2962 this line, then it is converted to extended Baudot and stored in the
|
|
|
2963 tail array specified (causing an error if the array is too small).
|
|
|
2964 Because Baudot is only a 5-bit character set, each element is padded to
|
|
|
2965 16 bits; CLC-INTERCAL pads with zeros, C-INTERCAL pads with random
|
|
|
2966 bits. Trying to input at end-of-file will act as if the input were a
|
|
|
2967 blank line. `READ OUT' is the reverse; it interprets the array as
|
|
|
2968 extended Baudot and converts it to an appropriate character set
|
|
|
2969 (Latin-1 for C-INTERCAL, or whatever was specified on the command line
|
|
|
2970 for CLC-INTERCAL), which is output to the user, followed by a newline.
|
|
|
2971 Note that the Baudot is often longer than the corresponding character
|
|
|
2972 in other character sets due to the need to insert shift codes; for
|
|
|
2973 information on the extended Baudot character set, *note Character
|
|
|
2974 Sets::.
|
|
|
2975
|
|
|
2976 Generalised binary I/O is specified using a hybrid array as an argument
|
|
|
2977 to `WRITE IN' or `READ OUT'. Input works by reading in a number of
|
|
|
2978 bytes equal to the length of the array (without trying to interpret
|
|
|
2979 them or translating them to a different character set), prepending a
|
|
|
2980 byte with 172 to the start, padding each byte to 16 bits with random
|
|
|
2981 data, then replacing each pair of consecutive bytes (that is, the first
|
|
|
2982 and second, the second and third, the third and fourth, and so on) with
|
|
|
2983 (the first element selected from the second element) mingled with (the
|
|
|
2984 complement of the first element selected from the complement of the
|
|
|
2985 second element). Output is the exact opposite of this process.
|
|
|
2986 End-of-file reads a 0, which is padded with 0s rather than random data;
|
|
|
2987 if a non-end-of-file 0 comes in from the data, its padding will contain
|
|
|
2988 at least one 1. Any all-bits-0-even-the-padding being read out will be
|
|
|
2989 skipped.
|
|
|
2990
|
|
|
2991
|
|
|
2992 File: ick.info, Node: GIVE UP, Next: TRY AGAIN, Prev: READ OUT and WRITE IN, Up: Statements
|
|
|
2993
|
|
|
2994 7.8 GIVE UP
|
|
|
2995 ===========
|
|
|
2996
|
|
|
2997 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
2998 ------------------------------------------------------------------------
|
|
|
2999 yes all versions all versions all versions
|
|
|
3000
|
|
|
3001 The `GIVE UP' command causes the program to end (or, in a multithreaded
|
|
|
3002 program, causes the current thread to end). It is written simply as
|
|
|
3003 `GIVE UP'. There is not much else to say about it, except to mention
|
|
|
3004 that it is the only way to end the program without an error unless the
|
|
|
3005 last line of the program is `TRY AGAIN', and that it has an unusual
|
|
|
3006 interaction with `ABSTAIN'; for details of this, see *note ABSTAIN::.
|
|
|
3007 (Going past the last command in the program is an error.)
|
|
|
3008
|
|
|
3009 There is no gerund for `GIVE UP'; in particular, `GIVING UP' is a
|
|
|
3010 syntax error.
|
|
|
3011
|
|
|
3012
|
|
|
3013 File: ick.info, Node: TRY AGAIN, Next: COME FROM and NEXT FROM, Prev: GIVE UP, Up: Statements
|
|
|
3014
|
|
|
3015 7.9 TRY AGAIN
|
|
|
3016 =============
|
|
|
3017
|
|
|
3018 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3019 ------------------------------------------------------------------------
|
|
|
3020 no version 0.25+ no no
|
|
|
3021
|
|
|
3022 The `TRY AGAIN' command is a very simple command with many limitations;
|
|
|
3023 its effect is to place the entire program in a loop. If it exists, it
|
|
|
3024 must be the very last command in the program (it cannot even be
|
|
|
3025 followed by syntax errors), and it causes execution of the program to
|
|
|
3026 go back to the first command. If the `TRY AGAIN' command is abstained
|
|
|
3027 or for some other reason doesn't execute when reached, it exits the
|
|
|
3028 program without the error that would usually be caused by going past
|
|
|
3029 the last line of code.
|
|
|
3030
|
|
|
3031 The gerund for `TRY AGAIN' is `TRYING AGAIN'.
|
|
|
3032
|
|
|
3033
|
|
|
3034 File: ick.info, Node: COME FROM and NEXT FROM, Prev: TRY AGAIN, Up: Statements
|
|
|
3035
|
|
|
3036 7.10 COME FROM and NEXT FROM
|
|
|
3037 ============================
|
|
|
3038
|
|
|
3039 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3040 ------------------------------------------------------------------------
|
|
|
3041 no see text see text see text
|
|
|
3042
|
|
|
3043 The `COME FROM' statement (incidentally also invented in 1972, but not
|
|
|
3044 in connection with INTERCAL) is the main control-flow command in
|
|
|
3045 CLC-INTERCAL (which deprecates `NEXT'), and one of two main control
|
|
|
3046 flow structures in other modern INTERCAL compilers. It takes either a
|
|
|
3047 label or an expression as its argument; these forms are noncomputed
|
|
|
3048 `COME FROM' and computed `COME FROM'.
|
|
|
3049
|
|
|
3050 Noncomputed `COME FROM' was implemented in version 0.5 of C-INTERCAL,
|
|
|
3051 but did not conform to modern-day semantics until version 0.7; it is
|
|
|
3052 available in every version of CLC-INTERCAL and J-INTERCAL. Computed
|
|
|
3053 `COME FROM' support is available in every version of CLC-INTERCAL and
|
|
|
3054 in C-INTERCAL from version 0.25 onwards, but not in J-INTERCAL; the
|
|
|
3055 variant `NEXT FROM' of `COME FROM' is available from CLC-INTERCAL
|
|
|
3056 version 1.-94.-8 and C-INTERCAL version 0.26 (both computed and
|
|
|
3057 noncomputed). C-INTERCAL and CLC-INTERCAL also have a from-gerund form
|
|
|
3058 of `COME FROM' and `NEXT FROM', which was also implemented from
|
|
|
3059 CLC-INTERCAL version 1.-94.-8 and C-INTERCAL version 0.26.
|
|
|
3060
|
|
|
3061 The basic rule of `COME FROM' is that if a `COME FROM' statement
|
|
|
3062 references another statement, whenever that statement is reached,
|
|
|
3063 control flow will be transferred to the `COME FROM' after that
|
|
|
3064 statement finishes executing. (`NEXT FROM' is identical except that in
|
|
|
3065 addition to the `COME FROM' behaviour, the location immediately after
|
|
|
3066 the statement that was nexted from is saved on the NEXT stack, in much
|
|
|
3067 the same way as if the statement being nexted from was itself a `NEXT'.)
|
|
|
3068
|
|
|
3069 Here are examples of noncomputed, computed, and from-gerund `COME FROM':
|
|
|
3070
|
|
|
3071 DO COME FROM (10)
|
|
|
3072 DO COME FROM #2$'.1~#1'
|
|
|
3073 DO COME FROM COMING FROM
|
|
|
3074
|
|
|
3075 (The last example is an infinite loop. If it said `DO NEXT FROM
|
|
|
3076 NEXTING FROM', it would not be an infinite loop because the NEXT stack
|
|
|
3077 would overflow and cause an error. This also establishes the gerunds
|
|
|
3078 used for `COME FROM' and `NEXT FROM'.)
|
|
|
3079
|
|
|
3080 There are some things to be careful with involving `COME FROM' and
|
|
|
3081 `NEXT FROM'. First, if the statement come from or nexted from happens
|
|
|
3082 to be a `NEXT', the `NEXT' doesn't count as 'finishing executing' until
|
|
|
3083 the NEXT stack entry created by the `NEXT' is `RESUME'd to. In
|
|
|
3084 particular, this means that if `FORGET' is used to remove the entry, or
|
|
|
3085 a `RESUME' with a large argument resumes a lower entry, the `COME FROM'
|
|
|
3086 doesn't steal execution at all.
|
|
|
3087
|
|
|
3088 Second, you may be wondering what happens if two `COME FROM's or `NEXT
|
|
|
3089 FROM's aim at the same line. In a non-multithreaded program (whether a
|
|
|
3090 program is multithreaded or not is determined by a compiler option for
|
|
|
3091 those compilers that support it), this is an error; but it is only an
|
|
|
3092 error if the statement that they both point to finishes running, and
|
|
|
3093 both `COME FROM's or `NEXT FROM's try to execute as a result (they
|
|
|
3094 might not if, for instance, one is abstained or has a double-oh-seven
|
|
|
3095 causing it not to run some of the time). If both `COME FROM's or `NEXT
|
|
|
3096 FROM's are noncomputed, however, a compiler can (but does not have to)
|
|
|
3097 give a compile time error if two `COME FROM's or `NEXT FROM's share a
|
|
|
3098 label, and so that situation should be avoided in portable code. (If
|
|
|
3099 it is wanted, one solution that works for C-INTERCAL and CLC-INTERCAL is
|
|
|
3100 to use computed `COME FROM's or `NEXT FROM's with a constant
|
|
|
3101 expression.)
|
|
|
3102
|
|
|
3103
|
|
|
3104 File: ick.info, Node: System Library, Next: TriINTERCAL, Prev: Statements, Up: Top
|
|
|
3105
|
|
|
3106 8 System Library
|
|
|
3107 ****************
|
|
|
3108
|
|
|
3109 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3110 ------------------------------------------------------------------------
|
|
|
3111 yes all versions no all versions
|
|
|
3112
|
|
|
3113 INTERCAL has a system library, called `syslib'. It is included
|
|
|
3114 automatically at the end of your program by the compiler whenever your
|
|
|
3115 program refers to a line from (1000) to (1999) without defining any
|
|
|
3116 line in that range in the program. (Although it is not added
|
|
|
3117 automatically by the compiler in CLC-INTERCAL, it is trivial to
|
|
|
3118 concatenate a copy onto the end of the program; copies of the system
|
|
|
3119 library are available from many sources on the Internet, including a
|
|
|
3120 version in the example code that comes with C-INTERCAL.)
|
|
|
3121
|
|
|
3122 The intention of the system library is to provide a range of useful
|
|
|
3123 capabilities, like multiplication, that can otherwise be hard to write
|
|
|
3124 in INTERCAL. System library routines are used by `NEXTING' to their
|
|
|
3125 line number (*note NEXT::), where they will make changes to certain
|
|
|
3126 variables depending on certain other variables (depending on which
|
|
|
3127 routine is called), and `RESUME' back to the original program. As the
|
|
|
3128 system library is itself written in INTERCAL, there are some
|
|
|
3129 restrictions that need to be obeyed for calls to it to be guaranteed to
|
|
|
3130 work; none of the variables it uses (`.1' to `.6' and `:1' to `:5')
|
|
|
3131 should be read-only or overloaded (although the value of any variables
|
|
|
3132 that aren't mentioned in the routine's description will be preserved by
|
|
|
3133 the routine), and none of the lines in it should have their abstention
|
|
|
3134 status changed by lines outside it (this can happen with blatant
|
|
|
3135 infractions like `DO ABSTAIN FROM (1500)' or more subtle problems like
|
|
|
3136 gerund-abstention) or have `COME FROM's or `NEXT FROM's aiming at them.
|
|
|
3137
|
|
|
3138 The system library is currently available in all bases from 2 to 7
|
|
|
3139 (*note TriINTERCAL::), but not every command is available in every
|
|
|
3140 base, and C-INTERCAL is the only one of the three compilers listed above
|
|
|
3141 that use the system library to ship with a version in bases other than
|
|
|
3142 2. (This table was originally based on the INTERCAL-72 manual, but has
|
|
|
3143 had extra information added for bases other than 2.) Here, "overflow
|
|
|
3144 checked" means that #1 is assigned to .4 if there is not an overflow,
|
|
|
3145 and #2 is assigned to .4 if there is; "overflow captured" means that if
|
|
|
3146 there is overflow, the digit that overflowed is stored in the variable
|
|
|
3147 referenced. In all cases, division by 0 returns 0.
|
|
|
3148
|
|
|
3149 Line Description Bases
|
|
|
3150 -----------------------------------------------------------------------
|
|
|
3151 (1000) .3 <- .1 plus .2, error exit on overflow 2, 3, 4,
|
|
|
3152 5, 6, 7
|
|
|
3153 (1009) .3 <- .1 plus .2, overflow checked 2, 3, 4,
|
|
|
3154 5, 6, 7
|
|
|
3155 (1010) .3 <- .1 minus .2, no action on overflow 2, 3, 4,
|
|
|
3156 5, 6, 7
|
|
|
3157 (1020) .1 <- .1 plus #1, no action on overflow 2, 3, 4,
|
|
|
3158 5, 6, 7
|
|
|
3159 (1030) .3 <- .1 times .2, error exit on overflow 2, 3, 4,
|
|
|
3160 5, 6, 7
|
|
|
3161 (1039) .3 <- .1 times .2, overflow checked 2, 3, 4,
|
|
|
3162 5, 6, 7
|
|
|
3163 (1040) .3 <- .1 divided by .2 2, 3, 4,
|
|
|
3164 5, 6, 7
|
|
|
3165 (1050) .2 <- :1 divided by .1, error exit on overflow 2, 3, 4,
|
|
|
3166 5, 6, 7
|
|
|
3167 (1200) .2 <- .1 times #2, overflow captured in .3 4, 6
|
|
|
3168 (1210) .2 <- .1 divided by #2, one digit after the 4, 6
|
|
|
3169 quartic or sextic point stored in .3
|
|
|
3170 (1500) :3 <- :1 plus :2, error exit on overflow 2, 3, 4,
|
|
|
3171 5, 6, 7
|
|
|
3172 (1509) :3 <- :1 plus :2, overflow checked 2, 3, 4,
|
|
|
3173 5, 6, 7
|
|
|
3174 (1510) :3 <- :1 minus :2, no action on overflow 2, 3, 4,
|
|
|
3175 5, 6, 7
|
|
|
3176 (1520) :1 <- .1 concatenated with .2 2, 3, 4,
|
|
|
3177 5, 6, 7
|
|
|
3178 (1530) :1 <- .1 times .2 2, 3, 4,
|
|
|
3179 5, 6, 7
|
|
|
3180 (1540) :3 <- :1 times :2, error exit on overflow 2, 3, 4,
|
|
|
3181 5, 6, 7
|
|
|
3182 (1549) :3 <- :1 times :2, overflow checked 2, 3, 4,
|
|
|
3183 5, 6, 7
|
|
|
3184 (1550) :3 <- :1 divided by :2 2, 3, 4,
|
|
|
3185 5, 6, 7
|
|
|
3186 (1700) :2 <- :1 times #2, overflow captured in .1 4, 6
|
|
|
3187 (1710) :2 <- :1 divided by #2, one digit after the 4, 6
|
|
|
3188 quartic or sextic point stored in .1
|
|
|
3189 (1720) :2 <- :1 times the least significant digit of 5, 7
|
|
|
3190 .1, overflow captured in .2
|
|
|
3191 (1900) .1 <- uniform random number from #0 to #65535 2, 3, 4,
|
|
|
3192 5, 6, 7
|
|
|
3193 (1910) .2 <- normal random number from #0 to .1, with 2, 3, 4,
|
|
|
3194 standard deviation .1 divided by #12 5, 6, 7
|
|
|
3195
|
|
|
3196 If you happen to be using base 2, and are either using the external
|
|
|
3197 call system (*note External Calls::) or are willing to use it, it is
|
|
|
3198 possible to use a version of the system library written in C for speed,
|
|
|
3199 rather than the default version (which is written in INTERCAL). To do
|
|
|
3200 this, use the command line options `-eE' (before the INTERCAL file),
|
|
|
3201 and `syslibc' (at the end of the command line).
|
|
|
3202
|
|
|
3203
|
|
|
3204 File: ick.info, Node: TriINTERCAL, Next: Multithreading and Backtracking, Prev: System Library, Up: Top
|
|
|
3205
|
|
|
3206 9 TriINTERCAL
|
|
|
3207 *************
|
|
|
3208
|
|
|
3209 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3210 ------------------------------------------------------------------------
|
|
|
3211 no version 0.7+ version no
|
|
|
3212 1.-94.-8+
|
|
|
3213
|
|
|
3214 One extension to INTERCAL that is implemented by both C-INTERCAL and
|
|
|
3215 CLC-INTERCAL is known as TriINTERCAL, and extends INTERCAL to bases
|
|
|
3216 other than binary. Unlike ordinary INTERCAL programs, which have the
|
|
|
3217 extension `.i', TriINTERCAL programs in bases from 3 to 7 (the only
|
|
|
3218 allowed bases) have extensions from `.3i' to `.7i' respectively.
|
|
|
3219
|
|
|
3220 The change of numeric base only affects expressions, and in particular
|
|
|
3221 the behaviour of operators, and the range of variables. (The onespot
|
|
|
3222 and twospot ranges become the highest number of trits or other digits
|
|
|
3223 in the base required that fit inside the binary ranges, so for
|
|
|
3224 instance, the maximum value of a onespot variable in ternary is 59048,
|
|
|
3225 or 3 to the power 10 minus 1.) Interleave/mingle is the simplest to
|
|
|
3226 explain; it alternates digits just as it alternated bits in binary.
|
|
|
3227 The other operators all change, as follows:
|
|
|
3228
|
|
|
3229 * Exclusive-or becomes two operators, known either as
|
|
|
3230 subtract-without-borrow and add-without-carry due to their
|
|
|
3231 mathematical interpretations, or what and sharkfin after their
|
|
|
3232 Atari syntax representations (`?' and `^'). (In Princeton syntax,
|
|
|
3233 these are the bookworm or yen sign, and a spike (`|').) The two
|
|
|
3234 operators do the same thing in binary, but differ in higher bases.
|
|
|
3235 (Nevertheless, it is an error to use a sharkfin in binary, because
|
|
|
3236 it is a so-called `controlled unary operator', as are the rest of
|
|
|
3237 the new operators defined in this section, which has a lower limit
|
|
|
3238 on which base it is allowed in.) Instead of doing the exclusive-or
|
|
|
3239 operation, the bits being combined are either subtracted or added;
|
|
|
3240 if the result is out of range for the base being used, the base is
|
|
|
3241 added or subtracted from the result until it is in range. (For the
|
|
|
3242 subtraction, the bit that was less significant is subtracted from
|
|
|
3243 the bit that was more significant in any given pair of bits,
|
|
|
3244 except for the subtraction between the most and least significant
|
|
|
3245 bits, where the most significant bit is subtracted from the least.)
|
|
|
3246
|
|
|
3247 * The AND and OR operators are generalised into an entire sequence of
|
|
|
3248 operators; the number of operators available is the same as the
|
|
|
3249 base that is being used. In base 3, the third operator is known
|
|
|
3250 as BUT; in other bases, there are no commonly accepted names for
|
|
|
3251 the extra operators, so names that reflect the notation are used
|
|
|
3252 here.
|
|
|
3253
|
|
|
3254 The way to think of it is this: in base 2, an AND gives the result
|
|
|
3255 0 if either argument is a 0, and otherwise a 1, and likewise, an OR
|
|
|
3256 gives the result 1 if either argument is a 1, and otherwise a 0;
|
|
|
3257 they could be said to favour 0 over 1 and 1 over 0 respectively.
|
|
|
3258 In base 3, AND favours 0 over 2 over 1, OR favours 2 over 1 over
|
|
|
3259 0, and BUT favours 1 over 0 over 2. (The symbol for BUT is `@' (a
|
|
|
3260 `whirlpool', which is another name for the BUT operation) in Atari
|
|
|
3261 syntax, and `?' in Princeton syntax.) The pattern continues: in
|
|
|
3262 base 4, AND favours 0 over 3 over 2 over 1, BUT favours 1 over 0
|
|
|
3263 over 3 over 2, 2BUT (written `2@' or `2?') favours 2 over 1 over 0
|
|
|
3264 over 3, and OR favours 3 over 2 over 1 over 0. (This can be
|
|
|
3265 extended to higher bases following the same pattern, introducing
|
|
|
3266 operators `3@' or `3?', etc., to favour 3, etc., when neither AND
|
|
|
3267 (which always favours 0) nor OR (which favours the highest digit
|
|
|
3268 in the base) are available.) All the whirlpool operators are
|
|
|
3269 controlled unary operators, which are only legal when both the base
|
|
|
3270 contains the favoured digit, and they aren't redundant to AND nor
|
|
|
3271 OR.
|
|
|
3272
|
|
|
3273 * Select has its semantics modified to deal with more than one
|
|
|
3274 nonzero digit in the base. It starts off by doing an AND (in
|
|
|
3275 whatever base is being used) between the two numbers being
|
|
|
3276 selected; then the bits of the result are sorted by the bits of
|
|
|
3277 the right-hand argument to the select, with bits corresponding to
|
|
|
3278 0s in the right-hand argument ending up more significant than bits
|
|
|
3279 corresponding to high digits in the right-hand argument. In base
|
|
|
3280 2, this has the same effect as a traditional-style select.
|
|
|
3281
|
|
|
3282
|
|
|
3283 Note that the base doesn't affect anything other than variable ranges
|
|
|
3284 and expressions; in particular, it doesn't affect the bit-reversal used
|
|
|
3285 by Turing Tape I/O. (The tape still has characters written on it in
|
|
|
3286 binary, even though the program uses a different base.)
|
|
|
3287
|
|
|
3288
|
|
|
3289 File: ick.info, Node: Multithreading and Backtracking, Next: Operand Overloading, Prev: TriINTERCAL, Up: Top
|
|
|
3290
|
|
|
3291 10 Multithreading and Backtracking
|
|
|
3292 **********************************
|
|
|
3293
|
|
|
3294 The multithreading and backtracking extensions to INTERCAL were
|
|
|
3295 originally invented by Malcom Ryan, who implemented `COME FROM'-based
|
|
|
3296 multithreading as a modified version of C-INTERCAL, known as Threaded
|
|
|
3297 INTERCAL, but did not implement backtracking. (The same functionality
|
|
|
3298 is implemented in C-INTERCAL today, but with different code. Most
|
|
|
3299 likely, this means that the original code was better.) He also
|
|
|
3300 invented the original version of Backtracking INTERCAL, but did not
|
|
|
3301 implement it; the only known implementation is the C-INTERCAL one. A
|
|
|
3302 different version of multithreading, using `WHILE', was implemented as
|
|
|
3303 part of CLC-INTERCAL (like all extensions first available in
|
|
|
3304 CLC-INTERCAL, it is most likely due to Claudio Calvelli) and then added
|
|
|
3305 to C-INTERCAL, although its implications were not noticed for some time
|
|
|
3306 afterwards.
|
|
|
3307
|
|
|
3308 So nowadays, three freely-mixable threading-like extensions to INTERCAL
|
|
|
3309 exist, all of which are implemented in C-INTERCAL. (A fourth, Quantum
|
|
|
3310 INTERCAL, is implemented in CLC-INTERCAL but not C-INTERCAL, and so
|
|
|
3311 will not be discussed further here.) If you're wondering about the
|
|
|
3312 description of backtracking as a threading-like extension, it's
|
|
|
3313 implemented with much of the same code as multithreading in C-INTERCAL,
|
|
|
3314 because the INTERCAL version can be seen as roughly equivalent to
|
|
|
3315 multithreading where the threads run one after another rather than
|
|
|
3316 simultaneously. (This conceptualisation is probably more confusing
|
|
|
3317 than useful, though, and is also not strictly correct. The same could
|
|
|
3318 probably be said about INTERCAL as a whole, for that matter.)
|
|
|
3319
|
|
|
3320 * Menu:
|
|
|
3321
|
|
|
3322 * Multithreading using COME FROM:: Creating separate threads.
|
|
|
3323 * Multithreading using WHILE:: Creating connected threads.
|
|
|
3324 * Backtracking:: Multithreading in series, not parallel.
|
|
|
3325
|
|
|
3326
|
|
|
3327 File: ick.info, Node: Multithreading using COME FROM, Next: Multithreading using WHILE, Up: Multithreading and Backtracking
|
|
|
3328
|
|
|
3329 10.1 Multithreading using COME FROM
|
|
|
3330 ===================================
|
|
|
3331
|
|
|
3332 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3333 ------------------------------------------------------------------------
|
|
|
3334 no version 0.25+ version 0.05+ no
|
|
|
3335
|
|
|
3336 The original multithreading implementation worked by giving a new
|
|
|
3337 meaning to what was previously an error condition. If in a
|
|
|
3338 multithreaded program (a program is marked as multithreaded using
|
|
|
3339 options to a compiler) two or more `COME FROM's or `NEXT FROM's (or a
|
|
|
3340 mixture of the these) attempt to steal control simultaneously, the
|
|
|
3341 original thread splits into multiple threads, one for each of the
|
|
|
3342 commands trying to take control, and a different command gains control
|
|
|
3343 of the program in each case.
|
|
|
3344
|
|
|
3345 From then on, all the threads run simultaneously. The only thing
|
|
|
3346 shared between threads (apart from the environment in which they run)
|
|
|
3347 is the abstained/reinstated status of each command; everything else is
|
|
|
3348 separate. This means, for instance, that it's possible to change the
|
|
|
3349 value of a variable in one thread, and it will not affect the
|
|
|
3350 corresponding variable in other threads created this way. Likewise,
|
|
|
3351 there is a separate NEXT stack in each thread; if both a `COME FROM'
|
|
|
3352 and a `NEXT FROM' aim at the same line, for instance, the `NEXT FROM'
|
|
|
3353 thread will end up with a NEXT stack entry that isn't in the `COME
|
|
|
3354 FROM' thread, created by the `NEXT FROM' itself. This is known as
|
|
|
3355 unwoven thread creation; none of the threads created this way are
|
|
|
3356 `woven' with any of the other threads created this way. (Whether
|
|
|
3357 threads are woven depends on how they were created.) If the thread
|
|
|
3358 being split was itself woven with other threads, exactly one of the
|
|
|
3359 resulting threads after the split is woven with the threads that the
|
|
|
3360 original thread was woven to, but the rest will not be woven to
|
|
|
3361 anything. (If that seems a somewhat unusual rule: well, this is
|
|
|
3362 INTERCAL.)
|
|
|
3363
|
|
|
3364 In C-INTERCAL, there are other guarantees that can be made about unwoven
|
|
|
3365 threads (that is, threads not woven to any other thread). In
|
|
|
3366 particular, they can all be guaranteed to run at approximately the same
|
|
|
3367 speed; to be more precise, the number of commands that have been given
|
|
|
3368 the chance to execute in any given thread will not differ by more than
|
|
|
3369 2 from the number of commands that have been given the chance to
|
|
|
3370 execute in any other thread that was created at the same time.
|
|
|
3371 (However, `COME FROM's and `NEXT FROM's can make this relationship less
|
|
|
3372 precise; it is unspecified (in the technical sense that means the
|
|
|
3373 compiler can choose any option it likes and change its mind on a whim
|
|
|
3374 without telling anyone) whether a `COME FROM' or `NEXT FROM' aiming at
|
|
|
3375 the current command counts towards the command total or not, thus
|
|
|
3376 causing the relationship to become weaker the more of them have the
|
|
|
3377 chance to execute. In versions of C-INTERCAL from 0.27 onwards, there
|
|
|
3378 is a third guarantee; that if a `COME FROM' comes from itself, it will
|
|
|
3379 actually give other threads at least some chance to run, at some speed,
|
|
|
3380 by counting itself as a command every now and then; previously this
|
|
|
3381 requirement didn't exist, meaning that a `COME FROM' could block all
|
|
|
3382 threads if it aimed for itself due to the speed restrictions and the
|
|
|
3383 fact that `COME FROM's need not count towards the total command count.)
|
|
|
3384 Also, all commands, including any `ONCE' or `AGAIN' attached to the
|
|
|
3385 command, are atomic; this means that it's impossible for another thread
|
|
|
3386 to conflict with what the command is doing. (In a departure from the
|
|
|
3387 usual INTERCAL status quo, these guarantees are somewhat _better_ than
|
|
|
3388 in most other languages that implement threading, amusingly continuing
|
|
|
3389 to leave INTERCAL with the status of being unlike any other mainstream
|
|
|
3390 language.)
|
|
|
3391
|
|
|
3392 The only way to communicate between unwoven threads is by changing the
|
|
|
3393 abstention status of commands; this always affects all threads in the
|
|
|
3394 program, whether woven or not. (The combination of `ABSTAIN' and
|
|
|
3395 `ONCE' is one way to communicate atomically, due to the atomic nature
|
|
|
3396 of `ONCE'.)
|
|
|
3397
|
|
|
3398 If there are at least two threads, the `GIVE UP' command ends the
|
|
|
3399 current thread, rather than the current program.
|
|
|
3400
|
|
|
3401
|
|
|
3402 File: ick.info, Node: Multithreading using WHILE, Next: Backtracking, Prev: Multithreading using COME FROM, Up: Multithreading and Backtracking
|
|
|
3403
|
|
|
3404 10.2 Multithreading using WHILE
|
|
|
3405 ===============================
|
|
|
3406
|
|
|
3407 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3408 ------------------------------------------------------------------------
|
|
|
3409 no version 0.27+ version 0.05+ no
|
|
|
3410
|
|
|
3411 The `WHILE' command (which is not strictly speaking a command, but more
|
|
|
3412 a sort of metacommand that joins commands) is a second method of
|
|
|
3413 achieving multithreading. (In CLC-INTERCAL, there are at least two
|
|
|
3414 other meanings for `WHILE', but only the one implemented in C-INTERCAL
|
|
|
3415 is discussed here.) The syntax is somewhat unusual, and consists of
|
|
|
3416 two commands separated by the `WHILE' keyword, but sharing the
|
|
|
3417 statement identifier, execution chance, and any `ONCE'/`AGAIN' keyword
|
|
|
3418 that may be present. For instance:
|
|
|
3419
|
|
|
3420 (1) DO COME FROM ".2~.2"~#1 WHILE :1 <-
|
|
|
3421 "'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$
|
|
|
3422 "'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
|
|
|
3423
|
|
|
3424 (OK, maybe that's an unnecessarily complicated example, and maybe it
|
|
|
3425 shouldn't have included the `/' operator which is part of another
|
|
|
3426 INTERCAL extension (*note Operand Overloading::). Still, I thought
|
|
|
3427 that maybe you'd want to see how addition can be implemented in
|
|
|
3428 INTERCAL.)
|
|
|
3429
|
|
|
3430 A `WHILE' command starts two threads (the original thread that ran that
|
|
|
3431 command and a new one), one of which runs the command to the left of
|
|
|
3432 the `WHILE' and one of which runs the command to the right. Any line
|
|
|
3433 number applies to the left-hand command, not the WHILE as a whole,
|
|
|
3434 which is a metalanguage construct. `NEXTING FROM', `ABSTAINING FROM'
|
|
|
3435 or similar behaviour with respect to the `WHILE' itself is impossible,
|
|
|
3436 although it's certainly possible to abstain from either of its operands
|
|
|
3437 (and abstaining from the left operand has much the same effect as
|
|
|
3438 abstaining from the `WHILE' itself; the right-hand thread deliberately
|
|
|
3439 takes a bit of time to get started just so that this behaviour
|
|
|
3440 happens). The right-command thread starts just before the left command
|
|
|
3441 is run (so `NEXTING', etc., directly to the left command will not start
|
|
|
3442 that loop in the first place); if that command finishes (which may be
|
|
|
3443 almost immediately for something like a calculate command, or take a
|
|
|
3444 long time for something like `NEXT'), that thread loops and reruns that
|
|
|
3445 command as long as the left command has not finished; `COMING FROM'
|
|
|
3446 that command, or a `NEXT'/`NEXT FROM' from/aiming at that command,
|
|
|
3447 doesn't count as finishing that command until it is `RESUME'd back to
|
|
|
3448 (if possible; if it's come from, that command can never end and the
|
|
|
3449 right-hand loop will continue forever, or until it `GIVE's `UP' or the
|
|
|
3450 loop ends due to the command ending later in another thread). A
|
|
|
3451 `WHILE' command itself exists across all threads of a multithreaded
|
|
|
3452 program in a way; for each left-hand command that ends (in any thread),
|
|
|
3453 the next time a right-hand command of the same `WHILE' ends it will
|
|
|
3454 cause the thread it's looping in to end, regardless of whether that
|
|
|
3455 thread corresponds to the thread in which the left-hand command ended.
|
|
|
3456 (As well as a right-hand command ending, there's also the possibility
|
|
|
3457 that it never got started; there is a delay before the right-hand
|
|
|
3458 command runs during which a left-hand command ending can prevent the
|
|
|
3459 right-hand thread starting in the first place; this counts as the same
|
|
|
3460 sort of event as terminating a right-hand loop, and can substitute for
|
|
|
3461 it anywhere a right-hand command ending is mentioned.) There is one
|
|
|
3462 exception, in that if two or more left-hand commands end in a space of
|
|
|
3463 time in which no right-hand commands for that `WHILE' ends, they
|
|
|
3464 together only cause one right-hand command to end. (What, did you
|
|
|
3465 expect the logical and orthogonal behaviour?)
|
|
|
3466
|
|
|
3467 The two threads produced by a `WHILE' (the original thread and a new
|
|
|
3468 copy of it) have more in common than ordinary INTERCAL threads created
|
|
|
3469 by `COME FROM'; ordinary threads share only `ABSTAIN'/`REINSTATE'
|
|
|
3470 information, whereas the `WHILE'-produced threads count as `woven'
|
|
|
3471 threads which also share variables and stashes. (They still have
|
|
|
3472 separate instruction pointers, separate instruction pointer stacks,
|
|
|
3473 such as the NEXT stack, and separate choicepoint lists. Overloading
|
|
|
3474 information is shared, though.) Being woven is a relationship between
|
|
|
3475 two or more threads, rather than an attribute of a thread, although a
|
|
|
3476 thread can be referred to as being unwoven if it is not woven to any
|
|
|
3477 other thread.
|
|
|
3478
|
|
|
3479 Ordinary multithreading cannot create woven threads. When threads are
|
|
|
3480 created by multiple `COME FROM's from an original thread, which was
|
|
|
3481 woven with at least one other thread, one of the resulting threads
|
|
|
3482 counts as the `original' thread and remains woven; the rest are `new'
|
|
|
3483 threads which initially start out with the same data as the original,
|
|
|
3484 but are not woven with anything. Backtracking in a thread (*note
|
|
|
3485 Backtracking::) causes it to unweave with any threads it may be woven
|
|
|
3486 with at the time (so the data in the thread that backtracks is set back
|
|
|
3487 to the data it, and the threads it was woven with at the time, had at
|
|
|
3488 the time of the `MAYBE', but the other threads continue with the same
|
|
|
3489 data as before). The only way to cause three or more threads to become
|
|
|
3490 woven is with a new `WHILE' inside one of the threads that is already
|
|
|
3491 woven, which causes all the new threads to be woven together (the
|
|
|
3492 weaving relationship is transitive).
|
|
|
3493
|
|
|
3494
|
|
|
3495 File: ick.info, Node: Backtracking, Prev: Multithreading using WHILE, Up: Multithreading and Backtracking
|
|
|
3496
|
|
|
3497 10.3 Backtracking
|
|
|
3498 =================
|
|
|
3499
|
|
|
3500 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3501 ------------------------------------------------------------------------
|
|
|
3502 no version 0.25+ no no
|
|
|
3503
|
|
|
3504 A somewhat unusual threading construct that's available is
|
|
|
3505 backtracking. In case you haven't come across it before (the concept
|
|
|
3506 exists in other languages but is implemented differently and usually in
|
|
|
3507 a less general way), the basic idea is that instead of executing or not
|
|
|
3508 executing a command, you can `MAYBE' execute a command. This causes
|
|
|
3509 the command to be executed, but also creates a dormant thread in which
|
|
|
3510 the command wasn't executed; at any time later, the program can either
|
|
|
3511 decide that it liked the consequences of the command and `GO AHEAD' and
|
|
|
3512 get rid of the dormant thread, or decide that it didn't like the
|
|
|
3513 consquences of the command and `GO BACK' to the dormant thread,
|
|
|
3514 discarding the current one. The dormant thread is more commonly called
|
|
|
3515 a `choicepoint', that is, a point at which a choice was made but a
|
|
|
3516 different choice can still be made, and is generally not thought of as
|
|
|
3517 a thread at all by most programmers. (In case you're wondering:
|
|
|
3518 dormant threads are always unwoven.)
|
|
|
3519
|
|
|
3520 To create a choicepoint, the statement identifier `MAYBE' is used,
|
|
|
3521 rather than the more usual `DO' or `PLEASE'. (Combination statement
|
|
|
3522 identifiers are still allowed, but must be in the order `MAYBE PLEASE
|
|
|
3523 DO NOT' with optionally some parts omitted, or different versions of
|
|
|
3524 `NOT' used, or both.) Here's an example:
|
|
|
3525
|
|
|
3526 MAYBE DON'T GIVE UP
|
|
|
3527
|
|
|
3528 When a command whose statement identifer contains `MAYBE' is reached,
|
|
|
3529 it is executed or not executed as normal, but in addition a choicepoint
|
|
|
3530 is created containing the program as it is at that time. Only
|
|
|
3531 `ABSTAIN' and `REINSTATE', which always affect all threads in a program
|
|
|
3532 (even choicepoints), can alter the values stored in the choicepoint; so
|
|
|
3533 in this way, a choicepoint is also somewhat similar to the concept of a
|
|
|
3534 continuation in other languages. The choicepoint is placed on a
|
|
|
3535 choicepoint stack, which is maintained separately for each thread in
|
|
|
3536 much the same way that stashes and the `NEXT' stack are.
|
|
|
3537
|
|
|
3538 The choicepoint does not actually do anything immediately, but if the
|
|
|
3539 program doesn't like the look of where it's ended up, or it decides to
|
|
|
3540 change its mind, or just wants to try all the possibilities, it can
|
|
|
3541 call the `GO BACK' command (which has no arguments, and is just the
|
|
|
3542 statement identifier, optional execution chance, `GO BACK', and
|
|
|
3543 optional `ONCE' or `AGAIN'). This causes the current thread to unweave
|
|
|
3544 from all other threads and then replace itself with the thread created
|
|
|
3545 by the choicepoint on top of the choicepoint stack. The difference is
|
|
|
3546 that this time, the abstention or reinstatement status of the command
|
|
|
3547 that was modified with `MAYBE' is temporarily reversed for determining
|
|
|
3548 whether it runs or not (this reversal only lasts immediately after the
|
|
|
3549 `GO BACK', and does not affect uses of the command in other threads or
|
|
|
3550 later in the same thread), so unless it has been `ABSTAIN'ed or
|
|
|
3551 `REINSTATE'd in the meantime it will run if and only if it wasn't run
|
|
|
3552 the first time. The choicepoint stack's top entry is replaced by a
|
|
|
3553 `stale' choicepoint that definitely isn't a thread; attempting to `GO
|
|
|
3554 BACK' to a stale choicepoint instead causes the stale choicepoint to be
|
|
|
3555 deleted and the program to continue executing. (This is what gives
|
|
|
3556 INTERCAL's backtracking greater flexibility in some ways than some
|
|
|
3557 other languages; to get backtracking without the stale choicepoints
|
|
|
3558 having an effect, simply run `COME FROM' the `GO BACK' as the previous
|
|
|
3559 statement.)
|
|
|
3560
|
|
|
3561 Note that, though, when a thread splits into separate threads (whether
|
|
|
3562 woven or unwoven), the choicepoint stack doesn't split completely, but
|
|
|
3563 remains joined at the old top of stack. The two choicepoint stacks can
|
|
|
3564 add and remove items independently, but an attempt to `GO BACK' to
|
|
|
3565 before the current thread split off from any other threads that are
|
|
|
3566 still running instead causes the current thread to end, although it
|
|
|
3567 will `GO BACK' as normal if all other threads that split off from it or
|
|
|
3568 that it split off from since the top choicepoint of the stack was
|
|
|
3569 created have ended since. This means that it's possible to backtrack
|
|
|
3570 past a thread splitting and get the effect of the thread unsplitting,
|
|
|
3571 as long as both resulting threads backtrack; this is another way in
|
|
|
3572 which INTERCAL's backtracking is more flexible than that of some other
|
|
|
3573 languages.
|
|
|
3574
|
|
|
3575 If, on the other hand, a program decides that it likes where it is and
|
|
|
3576 doesn't need to `GO BACK', or it wants to `GO BACK' to a choicepoint
|
|
|
3577 lower down the stack while skipping some of the ones nearer the top of
|
|
|
3578 the stack, it can run the `GO AHEAD' command, which removes the top
|
|
|
3579 choicepoint on the stack, whether it's a genuine choicepoint or just a
|
|
|
3580 stale one.
|
|
|
3581
|
|
|
3582 Both `GO AHEAD' and `GO BACK' cause errors if an attempt is made to use
|
|
|
3583 them when the choicepoint stack is empty.
|
|
|
3584
|
|
|
3585
|
|
|
3586 File: ick.info, Node: Operand Overloading, Next: PIC-INTERCAL, Prev: Multithreading and Backtracking, Up: Top
|
|
|
3587
|
|
|
3588 11 Operand Overloading
|
|
|
3589 **********************
|
|
|
3590
|
|
|
3591 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3592 ------------------------------------------------------------------------
|
|
|
3593 no version 0.26+ version 0.05+ no
|
|
|
3594
|
|
|
3595 (Operand overloading in C-INTERCAL is nowhere near as advanced as it is
|
|
|
3596 in CLC-INTERCAL. This chapter only explains the partial implementation
|
|
|
3597 used by C-INTERCAL; for a full implementation, see CLC-INTERCAL and its
|
|
|
3598 documentation.)
|
|
|
3599
|
|
|
3600 Operand overloading is a method of using a onespot or twospot variable
|
|
|
3601 as a substitute for an expression. When a variable is overloaded to an
|
|
|
3602 expression (which could be another variable, or something more
|
|
|
3603 complex), any uses of that variable cause the expression to be
|
|
|
3604 substituted instead.
|
|
|
3605
|
|
|
3606 At the beginning of the program, all variables stand for themselves; so
|
|
|
3607 `.1' really does mean `.1', for instance. The meaning of a variable
|
|
|
3608 can be overloaded using the slat operator (`/'), which is the same in
|
|
|
3609 both Princeton and Atari syntax: it is a binary operator whose left
|
|
|
3610 argument must be a onespot or twospot variable and whose right argument
|
|
|
3611 can be any expression. The slat operator returns the true value of its
|
|
|
3612 left argument, but as a side effect, changes the meaning of its left
|
|
|
3613 argument to be its right argument. Here is an example:
|
|
|
3614
|
|
|
3615 DO .1 <- .2/'.3~.4'
|
|
|
3616
|
|
|
3617 The example causes `.2''s true value to be assigned to `.1' (unless of
|
|
|
3618 course `.1' is read-only), but also causes `.2' from then on to
|
|
|
3619 actually mean `'.3~.4'', except when it's the left operand of a slat
|
|
|
3620 operator. So for instance, `DO .1 <- .2' would actually assign
|
|
|
3621 `'.3~.4'' to `.1'. Somewhat confusingly, this also works in the other
|
|
|
3622 direction; `DO .2 <- .1' would assign `.1' to `'.3~.4'', which would
|
|
|
3623 have the effect of changing the values of `.3' and `.4' so that
|
|
|
3624 `'.3~.4'' had the correct value, or throw an error if it couldn't
|
|
|
3625 manage this. (The general rule in this case is that any variable or
|
|
|
3626 constant in the expression that overloads the variable is at risk of
|
|
|
3627 being changed; this is known as a `reverse assignment'. Code like `DO
|
|
|
3628 .1 <- .1/#1' is entirely capable of changing the value of `#1',
|
|
|
3629 although to protect new INTERCAL users C-INTERCAL will refuse to carry
|
|
|
3630 out operations that change the value of constants unless a command-line
|
|
|
3631 switch (*note -v::) is used to give it permission. In C-INTERCAL,
|
|
|
3632 changing the value of a constant only changes meshes with that value,
|
|
|
3633 but in CLC-INTERCAL it can also change non-mesh uses of that constant,
|
|
|
3634 so doing so is not portable anyway.)
|
|
|
3635
|
|
|
3636 When multiple overloading rules are in effect, they are all applied;
|
|
|
3637 overloading `.1' to `'.2~.3'' and `.2' to `'.3$.4'' will cause `.1' to
|
|
|
3638 refer to `''.3$.4'~.3''. However, this expansion stops if this would
|
|
|
3639 cause a loop; to be precise, overloading is not expanded if the
|
|
|
3640 expansion is nested within the same expansion at a higher level (so
|
|
|
3641 `.1/.2' and `.2/.1' together cause `.1' to expand to `.2', which
|
|
|
3642 expands to `.1', which cannot expand any further). In C-INTERCAL, the
|
|
|
3643 expression on the right hand side of a slat is not evaluated and not
|
|
|
3644 expanded by operand overloading.
|
|
|
3645
|
|
|
3646 `STASHING' a variable causes its overloading information to be stashed
|
|
|
3647 too; `RETRIEVING' it causes its overload rule to also be retrieved from
|
|
|
3648 the stash (or any overload rule on the variable to be removed if there
|
|
|
3649 wasn't one when the variable was stashed).
|
|
|
3650
|
|
|
3651 Overloading a onespot variable to a twospot variable or vice versa is
|
|
|
3652 possible, but the results are unlikely to be predictable, especially if
|
|
|
3653 a onespot variable is used to handle a twospot value. Possible
|
|
|
3654 outcomes include truncating the value down to the right bitwidth,
|
|
|
3655 throwing an error if a value outside the onespot range is used, and
|
|
|
3656 even temporarily handling the entire twospot value as long as it
|
|
|
3657 doesn't end up eventually being assigned a value greater than twospot.
|
|
|
3658
|
|
|
3659 Note that reverse assignments can cause unpredictable behaviour if an
|
|
|
3660 attempt is made to reverse-assign the same variable twice in the same
|
|
|
3661 expression. In particular, sequences of commands like `DO .1 <-
|
|
|
3662 .2/'.3$.3' DO .2 <- #6' are liable to succeed assigning garbage to `.3'
|
|
|
3663 rather than failing as they ought to do, and likewise any situation
|
|
|
3664 where a variable is reverse-assigned twice in the same expression may
|
|
|
3665 assign garbage to it. This behaviour is seen as unsatisfactory,
|
|
|
3666 though, and plans exist to improve it for future versions.
|
|
|
3667
|
|
|
3668
|
|
|
3669 File: ick.info, Node: PIC-INTERCAL, Next: CREATE, Prev: Operand Overloading, Up: Top
|
|
|
3670
|
|
|
3671 12 PIC-INTERCAL
|
|
|
3672 ***************
|
|
|
3673
|
|
|
3674 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3675 ------------------------------------------------------------------------
|
|
|
3676 no version 0.26+ no no
|
|
|
3677
|
|
|
3678 PIC-INTERCAL is a simplified version of INTERCAL designed especially
|
|
|
3679 for embedded systems, designed to minimise code and data usage by
|
|
|
3680 INTERCAL programs so that they can fit on devices whose memory is
|
|
|
3681 measured in bytes rather than megabytes. (It is named after the first
|
|
|
3682 microcontroller for which code was successfully generated, and which
|
|
|
3683 influenced the choices of commands, the PIC16F628 manufactured by
|
|
|
3684 Microchip, and is most likely to be portable to other microcontrollers
|
|
|
3685 in the same range.) C-INTERCAL only compilers as far as C code when
|
|
|
3686 producing PIC-INTERCAL; it is up to the user to find the appropriate
|
|
|
3687 cross-compiler to translate this C into the relevant dialect of machine
|
|
|
3688 code. (Two header files in the distribution, `src/pick1.h' and
|
|
|
3689 `src/pick2.h', don't have any affect on the compiler but are referenced
|
|
|
3690 by the generated code, and the intent is for the user to change them to
|
|
|
3691 suit the behaviour of the PIC compiler used, because these are not as
|
|
|
3692 standardised as C compilers for everyday systems.)
|
|
|
3693
|
|
|
3694 There are several restrictions on PIC-INTERCAL programs:
|
|
|
3695
|
|
|
3696 * It's impossible to store more than one item in the STASH for any
|
|
|
3697 given variable.
|
|
|
3698
|
|
|
3699 * Many errors are not checked at runtime; it is the programmer's job
|
|
|
3700 to ensure that runtime errors are avoided. (The few errors that
|
|
|
3701 are detected will send the program into an infinite loop, as there
|
|
|
3702 is no sensible way to exit from a PIC program.)
|
|
|
3703
|
|
|
3704 * Double-oh-sevens are not randomised, but instead depend merely on
|
|
|
3705 whether the probability given is greater than 50% or not.
|
|
|
3706
|
|
|
3707 * The NEXT stack is limited to 16 entries rather than the usual 80.
|
|
|
3708
|
|
|
3709 * `ABSTAIN' and `REINSTATE' still work, but cannot be computed
|
|
|
3710 `ABSTAIN's, and will not necessarily work when used to affect the
|
|
|
3711 system library or calls to it.
|
|
|
3712
|
|
|
3713 * `READ OUT' and `WRITE IN' don't work. (See below for a
|
|
|
3714 replacement.)
|
|
|
3715
|
|
|
3716 * `COME FROM' and `NEXT FROM' must aim at a label, not an expression
|
|
|
3717 or gerund.
|
|
|
3718
|
|
|
3719 * Multithreading and TriINTERCAL cannot be used on PICs. (Operand
|
|
|
3720 overloading can be used, but only if your PIC cross-compiler
|
|
|
3721 supports function pointers; some don't.)
|
|
|
3722
|
|
|
3723
|
|
|
3724 In order to provide I/O capabilities, a new command `PIN' is available.
|
|
|
3725 It controls up to 16 I/O pins on the PIC or other embedded system; an
|
|
|
3726 I/O pin is capable of receiving or sending voltages to an electrical or
|
|
|
3727 electronic circuit. This explanation assumes that the device being
|
|
|
3728 controlled is a PIC16F628A, and therefore has its pins in two blocks of
|
|
|
3729 8 named `PORTA' and `PORTB'; for other microcontrollers, adapting the
|
|
|
3730 code in `src/pick1.h' is likely to be necessary to tell the compiler
|
|
|
3731 how to control the I/O pins, and the way in which this done will affect
|
|
|
3732 which I/O pins it is that the program will end up being able to
|
|
|
3733 communicate with.
|
|
|
3734
|
|
|
3735 The `PIN' command takes one twospot variable as its argument, like this:
|
|
|
3736
|
|
|
3737 DO PIN :2
|
|
|
3738
|
|
|
3739 The twospot variable is conceptually divided into 4 blocks of 8 bits.
|
|
|
3740 The highest two blocks control the directions of the pins in `PORTB'
|
|
|
3741 (most significant block) and `PORTA' (second most significant block); a
|
|
|
3742 1 on any bit means that the corresponding I/O pin should be set to send
|
|
|
3743 data, and a 0 means that it should be set to receive data. The lower
|
|
|
3744 two blocks control the values on the pins that are sending (and are
|
|
|
3745 ignored for receiving pins); the second least significant block
|
|
|
3746 controls `PORTB' and the least significant block controls `PORTA', with
|
|
|
3747 a 1 causing the program to set the output voltage to that of the
|
|
|
3748 microcontroller's negative voltage supply rail, and a 0 causing the
|
|
|
3749 program to set the output voltage to that of the microcontroller's
|
|
|
3750 positive voltage supply rail. (These voltages may vary on other
|
|
|
3751 systems; consult your system's datasheet and the changes you made to
|
|
|
3752 the header files.) After setting the pins, the `PIN' command then
|
|
|
3753 reads them as part of the same operation, this time setting the values
|
|
|
3754 of the lower blocks that are receiving, rather than setting the pins
|
|
|
3755 from the lower blocks that are sending. However, 1 and 0 bits on all
|
|
|
3756 bits of the twospot variable have the opposite meaning when doing this,
|
|
|
3757 so that 1 means receiving/positive voltage rail and 0 means
|
|
|
3758 sending/negative voltage rail. There is no way to input without
|
|
|
3759 output, or vice versa, but it's trivial to just send the same output
|
|
|
3760 again (which has no effect, because the voltage on sending pins is
|
|
|
3761 maintained at the same level until it is changed), or to ignore the
|
|
|
3762 input received.
|
|
|
3763
|
|
|
3764
|
|
|
3765 File: ick.info, Node: CREATE, Next: External Calls, Prev: PIC-INTERCAL, Up: Top
|
|
|
3766
|
|
|
3767 13 CREATE
|
|
|
3768 *********
|
|
|
3769
|
|
|
3770 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3771 ------------------------------------------------------------------------
|
|
|
3772 no version 0.28+ see text no
|
|
|
3773
|
|
|
3774 The `CREATE' command allows the creation of new syntax at runtime.
|
|
|
3775 CLC-INTERCAL has had such a command since 1.-94.-8, but its syntax is
|
|
|
3776 completely different and incompatible with the C-INTERCAL version, and
|
|
|
3777 so is not documented here (see the CLC-INTERCAL documentation for more
|
|
|
3778 details). The C-INTERCAL version is only defined if the `-a' option is
|
|
|
3779 used on the command line (and a runtime error E000 otherwise), because
|
|
|
3780 it forces the operand overloading code to be introduced and so slows
|
|
|
3781 down every variable access in the program.
|
|
|
3782
|
|
|
3783 The syntax of the `CREATE' command is to write `CREATE', then a line
|
|
|
3784 label, then anything. OK, well not quite anything; you're restricted
|
|
|
3785 to syntax that is supported by the `just-in-case' compiler that runs on
|
|
|
3786 comments at compile time just in case they gain a meaning later (see
|
|
|
3787 below). The anything provides an example statement to `CREATE';
|
|
|
3788 statements which look the same (but may differ in details) are created.
|
|
|
3789 Typical syntax for a `CREATE' statement would therefore look something
|
|
|
3790 like this:
|
|
|
3791
|
|
|
3792 DO CREATE (5) SWITCH .1 WITH .2
|
|
|
3793
|
|
|
3794 There is also computed `CREATE', working identically to ordinary
|
|
|
3795 `CREATE' except that the line number is taken from an expression and
|
|
|
3796 the created command must start with a letter (to avoid an ambiguity if
|
|
|
3797 the expression giving the line label happens to be an array reference),
|
|
|
3798 with a syntax like this:
|
|
|
3799
|
|
|
3800 DO CREATE .5 SWITCH .1 WITH .2
|
|
|
3801
|
|
|
3802 Here, a new `SWITCH WITH' statement (there is no such statement in
|
|
|
3803 INTERCAL normally) is being created. This command makes it possible to
|
|
|
3804 do this:
|
|
|
3805
|
|
|
3806 DO SWITCH .3 WITH .4
|
|
|
3807
|
|
|
3808 Normally that line would be an error (E000) due to being unrecognised,
|
|
|
3809 but having been `CREATE'd, it's now a real statement. (The gerund to
|
|
|
3810 affect created statements is `COMMENT', just like before they were
|
|
|
3811 created; the gerund to affect `CREATE' itself is `CREATION' (`CREATING'
|
|
|
3812 is also allowed, but not as elegant).) When the created statement is
|
|
|
3813 encountered, it `NEXT's to line (5), the line number specified in the
|
|
|
3814 `CREATE' statement. In order for the code there to be able to affect
|
|
|
3815 the variables mentioned in the statement, the variables `:1601' (for
|
|
|
3816 the first variable or expression mentioned), `:1602' (for the second
|
|
|
3817 variable or expression mentioned), and so on, are `STASH'ed and then
|
|
|
3818 overloaded to the respective expressions or variables mentioned in the
|
|
|
3819 created command; so `:1601' has been overloaded to mean `.3' and
|
|
|
3820 `:1602' has been overloaded to mean `.4' at this point. Then, the code
|
|
|
3821 at (5) runs; if it returns via a `RESUME #1', `:1601' and `:1602' will
|
|
|
3822 be `RETRIEVE'd automatically and the program will continue from after
|
|
|
3823 the created statement. (If you do not resume to that point, say if
|
|
|
3824 you're creating a flow control statement, you'll have to deal with the
|
|
|
3825 stashes for the 1600-range variables yourself.)
|
|
|
3826
|
|
|
3827 So what syntax is available in created statements? All the capital
|
|
|
3828 letters except `V' (which is an operator in INTERCAL) are available and
|
|
|
3829 can be used freely and as many times as desired; they match themselves
|
|
|
3830 literally. However, they are not allowed to spell an INTERCAL keyword
|
|
|
3831 at any point (so watch out for `DO' and `FROM', for instance).
|
|
|
3832 Whitespace is allowed, but is ignored (both in the `CREATE' template
|
|
|
3833 statement, and in the code being created; so `DO SW ITCH :8 WITH :50'
|
|
|
3834 will also have been created). Then, there are three groups of
|
|
|
3835 matchable data: scalar variables (onespot or twospot variables, as used
|
|
|
3836 in the examples above) match other scalar variables, array elements
|
|
|
3837 (like `,4 SUB '.5~.6'') match other array elements, and other
|
|
|
3838 expressions match other other expressions. Two matchable data may not
|
|
|
3839 appear consecutively in a created command, but must be separated by at
|
|
|
3840 least one capital letter (to prevent array-subscript-related
|
|
|
3841 ambiguities; remember that the just-in-case compiler has to compile
|
|
|
3842 these statements at compile time without knowing what they are). The
|
|
|
3843 actual expressions used in the `CREATE' statement don't matter; they're
|
|
|
3844 just examples for the runtime to match against.
|
|
|
3845
|
|
|
3846 It is also possible (from C-INTERCAL version 0.29 onwards) to create new
|
|
|
3847 operators. Such operators are always binary operators (that is, they
|
|
|
3848 take two arguments and parse like mingle or select), and always return
|
|
|
3849 32-bit results. There are three types of legal names for such
|
|
|
3850 operators, all of which are treated equivalently: lowercase letters,
|
|
|
3851 punctuation marks otherwise unused in INTERCAL, and overstrikes
|
|
|
3852 consisting of a character, a backspace, and another character (apart
|
|
|
3853 from overstrikes already used for built-in INTERCAL operators). The
|
|
|
3854 syntax for creating an operator looks like one of these:
|
|
|
3855
|
|
|
3856 DO CREATE (5) x
|
|
|
3857 DO CREATE .5 =
|
|
|
3858
|
|
|
3859 The arguments to the operator will be overloaded onto :1601 and :1602
|
|
|
3860 (which are, like with `CREATE'd statements, stashed before the
|
|
|
3861 overloading happens), and the return value is read from :1603 (which is
|
|
|
3862 stashed, then overloaded to itself). All these three variables are
|
|
|
3863 retrieved again after the operator finishes evaluating.
|
|
|
3864
|
|
|
3865 Note that it is a very unwise idea to use a `CREATE'd operator in the
|
|
|
3866 expression for a computed `COME FROM' or `NEXT FROM', because this
|
|
|
3867 always leads to an infinite regress; whenever any line label is reached
|
|
|
3868 (including the line label that the `CREATE' statement pointed at), the
|
|
|
3869 expression needs to be evaluated in order to determine whether to `COME
|
|
|
3870 FROM' that point, which in turn involves evaluating lines which have
|
|
|
3871 labels.
|
|
|
3872
|
|
|
3873 Some other points: a newer `CREATE' statement supercedes an older
|
|
|
3874 `CREATE' statement if they give equivalent templates, multiple `CREATE'
|
|
|
3875 statements may aim at the same line (this is the recommended technique
|
|
|
3876 for creating a statement that can handle expressions even if they're
|
|
|
3877 array elements or variables; you do this by specifying multiple
|
|
|
3878 templates in multiple `CREATE' statements), and strange things happen
|
|
|
3879 if a twospot variable in the 1600-range is used as an argument to a
|
|
|
3880 created statement itself (because of the stash/retrieve, such a
|
|
|
3881 variable can usually be read, but may not always be able to be written
|
|
|
3882 without the data being lost).
|
|
|
3883
|
|
|
3884
|
|
|
3885 File: ick.info, Node: External Calls, Next: Differences to Other Compilers, Prev: CREATE, Up: Top
|
|
|
3886
|
|
|
3887 14 External Calls
|
|
|
3888 *****************
|
|
|
3889
|
|
|
3890 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3891 ------------------------------------------------------------------------
|
|
|
3892 no version 0.28+ no no
|
|
|
3893
|
|
|
3894 C-INTERCAL has a feature allowing INTERCAL and non-INTERCAL code to be
|
|
|
3895 mixed. This is achieved by causing the non-INTERCAL programs to
|
|
|
3896 participate in the INTERCAL line-numbering model. The same feature
|
|
|
3897 allows expansion libraries to be linked into the code.
|
|
|
3898
|
|
|
3899 To create a combined program containing INTERCAL and non-INTERCAL code,
|
|
|
3900 use `ick' as the compiler as normal, but specify both the INTERCAL and
|
|
|
3901 non-INTERCAL source files on the command line, and use the `-e'
|
|
|
3902 command-line option. `ick' will invoke other compilers as necessary,
|
|
|
3903 after modifying the source files accordingly. At present, external
|
|
|
3904 calls are only supported to and from C.
|
|
|
3905
|
|
|
3906 In each case, it will be the INTERCAL program that is invoked first.
|
|
|
3907 (This means that it is impossible to link together more than one
|
|
|
3908 INTERCAL program, but you probably don't want to, because concatenating
|
|
|
3909 the programs is likely to have a similar effect.) You can get the
|
|
|
3910 INTERCAL program to `NEXT' to the non-INTERCAL program immediately, or
|
|
|
3911 the non-INTERCAL program to `COME FROM' or `NEXT FROM' the INTERCAL
|
|
|
3912 program immediately, to obtain the effect of running the non-INTERCAL
|
|
|
3913 program first.
|
|
|
3914
|
|
|
3915 Note that external calls are incompatible with PIC-INTERCAL and with
|
|
|
3916 multithreading; note also that you must use `gcc' as your compiler, and
|
|
|
3917 GNU cpp and ld, for them to work in the current version of C-INTERCAL.
|
|
|
3918
|
|
|
3919 * Menu:
|
|
|
3920
|
|
|
3921 * External Calls to C:: How to put INTERCAL calls in C.
|
|
|
3922 * External Calls to Funge-98:: Linking Befunge-98 and INTERCAL.
|
|
|
3923 * Miscellaneous External Calls:: Other things you can link in.
|
|
|
3924 * Using External Calls:: What happens when you use -e.
|
|
|
3925 * Expansion Libraries:: Expanding the compiler's capabilities.
|
|
|
3926
|
|
|
3927
|
|
|
3928 File: ick.info, Node: External Calls to C, Next: External Calls to Funge-98, Up: External Calls
|
|
|
3929
|
|
|
3930 14.1 External Calls to C
|
|
|
3931 ========================
|
|
|
3932
|
|
|
3933 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
3934 ------------------------------------------------------------------------
|
|
|
3935 no version 0.28+ no no
|
|
|
3936
|
|
|
3937 Linking C and INTERCAL programs is achieved by placing various
|
|
|
3938 constructs into the C programs that are equivalent to various INTERCAL
|
|
|
3939 constructs. It is possible to simulate a line with a label and a dummy
|
|
|
3940 command (which serves as a `COME FROM' suckpoint and `NEXT' target), a
|
|
|
3941 command with a line label, `NEXT', `RESUME', and `FORGET', and `COME
|
|
|
3942 FROM' and `NEXT FROM'. Onespot and twospot variables are accessible
|
|
|
3943 from inside the C program, where they can be read and written; however,
|
|
|
3944 the INTERCAL program cannot access any variables inside the C program
|
|
|
3945 that weren't part of the INTERCAL program originally.
|
|
|
3946
|
|
|
3947 To prevent various logical impossibilities, there are restrictions on
|
|
|
3948 where these can be used and what preparation is needed before they are
|
|
|
3949 used. Also, the semantics are not always exactly what you might expect
|
|
|
3950 for technical reasons.
|
|
|
3951
|
|
|
3952 It should be observed that the INTERCAL link intrudes on the user
|
|
|
3953 namespace. To prevent possible namespace clashes, no identifiers
|
|
|
3954 starting with `ick_' or `ICK_' should be used anywhere in the linked C
|
|
|
3955 program for any reason, except where specified in this manual.
|
|
|
3956
|
|
|
3957 * Menu:
|
|
|
3958
|
|
|
3959 * External C Call Infrastructure:: Enabling a C program for external calls
|
|
|
3960 * ick_startup:: Doing things at startup
|
|
|
3961 * ick_linelabel:: Labelling lines...
|
|
|
3962 * ick_labeledblock:: ...and labelling blocks
|
|
|
3963 * ick_comefrom and ick_nextfrom:: Stealing control from elsewhere
|
|
|
3964 * ick_next:: The INTERCAL answer to subroutine calls
|
|
|
3965 * ick_resume:: Going back to before a NEXT
|
|
|
3966 * ick_forget:: Discarding NEXT stack entries
|
|
|
3967 * ick_get/setone/twospot:: Accessing INTERCAL variables from C
|
|
|
3968 * ick_create:: CREATE statements via external calls
|
|
|
3969 * External Calls and auto:: Considerations for auto variables
|
|
|
3970
|
|
|
3971
|
|
|
3972 File: ick.info, Node: External C Call Infrastructure, Next: ick_startup, Up: External Calls to C
|
|
|
3973
|
|
|
3974 14.1.1 External C Call Infrastructure
|
|
|
3975 -------------------------------------
|
|
|
3976
|
|
|
3977 For a C program to be connected to an INTERCAL program, it needs to be
|
|
|
3978 marked with the correct header file, and needs to have functions marked
|
|
|
3979 for communication with the INTERCAL program.
|
|
|
3980
|
|
|
3981 `#include <ick_ec.h>'
|
|
|
3982 The header file `ick_ec.h' must be included using the preprocessor
|
|
|
3983 in any file which uses any of the INTERCAL external call
|
|
|
3984 functions, variables, or macros. (Note that this file may not
|
|
|
3985 necessarily exist, or exist in the usual place; `ick' will deal
|
|
|
3986 with making sure the correct header file is included.) This will
|
|
|
3987 include `stdint.h' (a standard C header file, which must exist on
|
|
|
3988 your system), so that you can access INTERCAL variables (the
|
|
|
3989 INTERCAL types onespot, twospot, tail, hybrid correspond to the C
|
|
|
3990 types uint16_t, uint32_t, uint16_t*, uint32_t* respectively);
|
|
|
3991 also, it will provide the prototypes for all the functions and
|
|
|
3992 definitions for all the macros needed to use the external calls
|
|
|
3993 system with C.
|
|
|
3994
|
|
|
3995 `ICK_EC_FUNC_START'
|
|
|
3996 `ICK_EC_FUNC_END'
|
|
|
3997 Many of the INTERCAL interface macros (`ick_linelabel',
|
|
|
3998 `ick_comefrom', and `ick_nextfrom') make it possible to jump from
|
|
|
3999 an INTERCAL program to a C program. Because C doesn't allow
|
|
|
4000 jumping into the middle of a function, there has to be some way to
|
|
|
4001 create a block of code which _can_ be jumped into. This is what
|
|
|
4002 these two macros achieve.
|
|
|
4003
|
|
|
4004 This declaration and definition:
|
|
|
4005
|
|
|
4006 ICK_EC_FUNC_START(identifier)
|
|
|
4007 {
|
|
|
4008 /* code goes here */
|
|
|
4009 }
|
|
|
4010 ICK_EC_FUNC_END
|
|
|
4011
|
|
|
4012 is equivalent to this:
|
|
|
4013
|
|
|
4014 void identifier(void)
|
|
|
4015 {
|
|
|
4016 /* code goes here */
|
|
|
4017 }
|
|
|
4018
|
|
|
4019 except that it is possible to jump from an INTERCAL program into
|
|
|
4020 the declared and defined program. (If you need to write a
|
|
|
4021 prototype for the function early, `void identifier(void);' is
|
|
|
4022 perfectly acceptable, but an early prototype is not required
|
|
|
4023 unless you call the function from earlier within the C code.) Of
|
|
|
4024 course, you can substitute any identifier that's legal as a
|
|
|
4025 function name for `identifier' (as long as it doesn't start with
|
|
|
4026 `ick_' or `ICK_'). The resulting function is a function (for
|
|
|
4027 instance, you can take its address or call it in the usual ways);
|
|
|
4028 the only differences are that it can be jumped into from INTERCAL
|
|
|
4029 code and that it is constrained to take no arguments and return no
|
|
|
4030 data. (It can still access global and INTERCAL variables.) If
|
|
|
4031 the function is jumped into from INTERCAL code, but then control
|
|
|
4032 flow reaches the end of the function, or the function `return;'s
|
|
|
4033 but was not called from C, the resulting behaviour is undefined;
|
|
|
4034 C-INTERCAL will attempt to continue by some means at that point,
|
|
|
4035 but may fail. If a function is unsure whether it gained control
|
|
|
4036 from C or from INTERCAL code, it may use `ick_return_or_resume'
|
|
|
4037 (described below).
|
|
|
4038
|
|
|
4039 Because you are not allowed to declare two C functions with the
|
|
|
4040 same name (even in different modules), all functions declared with
|
|
|
4041 `ICK_EC_FUNC_START' must have unique names across the entire
|
|
|
4042 compilation.
|
|
|
4043
|
|
|
4044
|
|
|
4045
|
|
|
4046 File: ick.info, Node: ick_startup, Next: ick_linelabel, Prev: External C Call Infrastructure, Up: External Calls to C
|
|
|
4047
|
|
|
4048 14.1.2 ick_startup
|
|
|
4049 ------------------
|
|
|
4050
|
|
|
4051 It is sometimes necessary for a C program to do its own initialisation
|
|
|
4052 before the INTERCAL program starts running. To do so, it can use the
|
|
|
4053 `ick_startup' macro inside a function declared with
|
|
|
4054 `ICK_EC_FUNC_START'; the syntax is `ick_startup(block)', where the
|
|
|
4055 argument is an expression, statement, or compound statement to run.
|
|
|
4056 The argument itself must not contain any ick_-prefixed macros or
|
|
|
4057 functions except possibly ick_create, may have side effects, and must
|
|
|
4058 fit the C preprocessor's idea of what a macro argument should look like
|
|
|
4059 (it's more used to parsing expressions than blocks; the general rule is
|
|
|
4060 to avoid commas except when they're directly or indirectly inside
|
|
|
4061 parentheses or strings).
|
|
|
4062
|
|
|
4063
|
|
|
4064 File: ick.info, Node: ick_linelabel, Next: ick_labeledblock, Prev: ick_startup, Up: External Calls to C
|
|
|
4065
|
|
|
4066 14.1.3 ick_linelabel
|
|
|
4067 --------------------
|
|
|
4068
|
|
|
4069 A line label is something that can be `NEXT'ed to and `COME FROM'.
|
|
|
4070 Unlike an INTERCAL line label, it does not label a statement, and
|
|
|
4071 therefore attempts to `ABSTAIN' or `REINSTATE' it may be errors, or may
|
|
|
4072 be ignored (it's unspecified which, which means that either may happen
|
|
|
4073 for any or no reason, but exactly one will happen in any given case,
|
|
|
4074 although the choice might not be consistent).
|
|
|
4075
|
|
|
4076 The macro `ick_linelabel(expression);' may appear anywhere a compound
|
|
|
4077 statement would normally be able to appear. (That is, it looks like a
|
|
|
4078 function call being used as a standalone expression, but in fact the
|
|
|
4079 places where it can appear are more limited.) In contrast to ordinary
|
|
|
4080 line labels, an expression can be used rather than just a constant;
|
|
|
4081 however, the behaviour is undefined if the expression has side-effects.
|
|
|
4082 Upon encountering the line label, any `COME FROM's or `NEXT FROM's
|
|
|
4083 aiming at the line label (including `ick_comefrom's and
|
|
|
4084 `ick_nextfrom's) will steal control from the program; `RESUMING' after
|
|
|
4085 a `NEXT FROM' will work, but suffers from the same caveats as
|
|
|
4086 setjmp/longjmp do (any auto variables that change their value between
|
|
|
4087 the `NEXT FROM' and `RESUME' will have their value clobbered (i.e.
|
|
|
4088 their value is no longer reliable and should not be accessed)). Note
|
|
|
4089 that the INTERCAL variables are immune to this problem. You can also
|
|
|
4090 avoid the problem by marking variables as `volatile' in the C program.
|
|
|
4091
|
|
|
4092 It is possible to `NEXT' or `ick_next' to a `ick_linelabel', which has
|
|
|
4093 the same effect as saving the `NEXT' stack, calling the function
|
|
|
4094 containing the `ick_linelabel' and then immediately doing a C `goto' to
|
|
|
4095 an imaginary label preceding it. Due to this possibility, an
|
|
|
4096 `ick_linelabel' is only allowed within a function defined with
|
|
|
4097 `ICK_EC_FUNC_START'.
|
|
|
4098
|
|
|
4099
|
|
|
4100 File: ick.info, Node: ick_labeledblock, Next: ick_comefrom and ick_nextfrom, Prev: ick_linelabel, Up: External Calls to C
|
|
|
4101
|
|
|
4102 14.1.4 ick_labeledblock
|
|
|
4103 -----------------------
|
|
|
4104
|
|
|
4105 In INTERCAL programs, labels don't stand on their own, but instead
|
|
|
4106 label a statement. The difference between a standalone line label and
|
|
|
4107 a line label that labels a statement is that `COME FROM's will come
|
|
|
4108 from the _label itself_ (which is before the next statement) when
|
|
|
4109 aiming at a standalone line label, but the _end of the statement_ when
|
|
|
4110 aiming at a labeled statement. To achieve the same effect in C, the
|
|
|
4111 macro `ick_labeledblock' is available; it can be used as
|
|
|
4112 `ick_labeledblock(expression,expression)' or
|
|
|
4113 `ick_labeledblock(expression,statement)'; the first argument is the
|
|
|
4114 label, and the second argument is an expression or statement to label
|
|
|
4115 (if an expression is labeled, it will be converted to a statement that
|
|
|
4116 evaluates it for its side effects and discards the result). It is even
|
|
|
4117 permitted to label a block statement in this way. Note, however, that
|
|
|
4118 you have to contend with the C preprocessor's ideas of where macro
|
|
|
4119 arguments begin and end when doing this. Other than the position of
|
|
|
4120 the `COME FROM' target created by the label, this behaves the same way
|
|
|
4121 as `ick_linelabel' (so for instance, computed line labels are allowed,
|
|
|
4122 but the expression that computes them must not have side effects, and
|
|
|
4123 it is only allowed within a function defined with `ICK_EC_FUNC_START').
|
|
|
4124
|
|
|
4125
|
|
|
4126 File: ick.info, Node: ick_comefrom and ick_nextfrom, Next: ick_next, Prev: ick_labeledblock, Up: External Calls to C
|
|
|
4127
|
|
|
4128 14.1.5 ick_comefrom and ick_nextfrom
|
|
|
4129 ------------------------------------
|
|
|
4130
|
|
|
4131 The `ick_comefrom' and `ick_nextfrom' macros are, like the other
|
|
|
4132 INTERCAL flow control macros (as opposed to functions), only allowed
|
|
|
4133 within a function defined with `ICK_EC_FUNC_START'. They act almost
|
|
|
4134 exactly like the INTERCAL statements of the same name (although note
|
|
|
4135 that C statements cannot be `ABSTAIN'ed `FROM' even if they act the
|
|
|
4136 same way as INTERCAL statements); they are written as
|
|
|
4137 `ick_comefrom(expression);' and `ick_nextfrom(expression);'
|
|
|
4138 respectively (note that they must be called as statements, and cannot
|
|
|
4139 be used as part of an expression). Whenever a standalone line label is
|
|
|
4140 encountered whose expression evaluates to the same number as the
|
|
|
4141 expression inside the `ick_comefrom' or `ick_nextfrom', and that number
|
|
|
4142 is at most 65535, then control will be transferred to the
|
|
|
4143 `ick_comefrom' or `ick_nextfrom', leaving a `NEXT' stack entry behind
|
|
|
4144 in the case of `ick_nextfrom'; likewise, if the end of a labeled
|
|
|
4145 statement, expression or block is reached and the label has the right
|
|
|
4146 number. Some caveats: the expression need not be constant, but must
|
|
|
4147 not have side effects, must not be negative, and must fit into the
|
|
|
4148 range of an `unsigned long' in the C program (and the statement will do
|
|
|
4149 nothing if the expression evaluates to a value larger than 65535). In
|
|
|
4150 keeping with the best C traditions, these caveats are not checked, but
|
|
|
4151 instead result in undefined behaviour if breached.
|
|
|
4152
|
|
|
4153 There are also versions `ick_comefromif' and `ick_nextfromif', which
|
|
|
4154 take a second parameter, which is a condition that specifies whether
|
|
|
4155 control is actually stolen from the target. The condition may have
|
|
|
4156 side effects, and is only run when the line numbers match; it should
|
|
|
4157 return 0 or NULL to leave control flow alone, or nonzero to steal
|
|
|
4158 control, and should be either an integral type or a pointer type.
|
|
|
4159 Although side effects are allowed, the condition must not look at or
|
|
|
4160 alter `auto' or `register' variables in the enclosing function, not
|
|
|
4161 even if they are also marked `volatile'. (Global and `static'
|
|
|
4162 variables are fine, though.)
|
|
|
4163
|
|
|
4164
|
|
|
4165 File: ick.info, Node: ick_next, Next: ick_resume, Prev: ick_comefrom and ick_nextfrom, Up: External Calls to C
|
|
|
4166
|
|
|
4167 14.1.6 ick_next
|
|
|
4168 ---------------
|
|
|
4169
|
|
|
4170 `ick_next' is a macro that acts like the INTERCAL statement `NEXT'.
|
|
|
4171 Contrary to the other INTERCAL-like macros, it can be used in any
|
|
|
4172 function regardless of whether it was defined with `ICK_EC_FUNC_START';
|
|
|
4173 however, it must still be used as a statement by itself, and a call to
|
|
|
4174 it looks like `ick_next(expression);'. The expression is the label to
|
|
|
4175 `NEXT' to, and works under the same rules as the expressions for
|
|
|
4176 `ick_comefrom'; it need not be constant (unlike in C-INTERCAL!), but
|
|
|
4177 must not have side effects, must not be negative, must fit into the
|
|
|
4178 range of an unsigned long, and is ignored if it is over 65535. If
|
|
|
4179 there happen to be multiple labels with the correct value at the time,
|
|
|
4180 the compiler will `NEXT' to one of them. Bear in mind that there is a
|
|
|
4181 limit of 80 entries to the `NEXT' stack, and that this limit is
|
|
|
4182 enforced.
|
|
|
4183
|
|
|
4184 If the resulting `NEXT' stack entry is `RESUME'd to, the program will
|
|
|
4185 continue after the `ick_next' as if via `setjmp', with all the usual
|
|
|
4186 restrictions that that entails; if the resulting `NEXT' stack entry is
|
|
|
4187 forgotten, then the `ick_next' call will never return. (Notice the 'as
|
|
|
4188 if via setjmp' condition allows you to preserve the vales of `auto' and
|
|
|
4189 `alloca'-allocated storage as long as its value has not changed since
|
|
|
4190 the `ick_next' was called, which is a significantly more lenient
|
|
|
4191 condition than that normally imposed on such variables (*note External
|
|
|
4192 Calls and auto::).
|
|
|
4193
|
|
|
4194
|
|
|
4195 File: ick.info, Node: ick_resume, Next: ick_forget, Prev: ick_next, Up: External Calls to C
|
|
|
4196
|
|
|
4197 14.1.7 ick_resume
|
|
|
4198 -----------------
|
|
|
4199
|
|
|
4200 `ick_resume' is a macro, but there are few restrictions on its use; it
|
|
|
4201 is permitted to use it inside an expression (but it returns void,
|
|
|
4202 making this not particularly useful), and acts like a function which
|
|
|
4203 takes an unsigned short argument, returns void, and has a prototype (but
|
|
|
4204 you cannot take its address; if you need to be able to do that, write a
|
|
|
4205 wrapper function for it). It can be used within any function regardless
|
|
|
4206 of how it was declared, and never returns; instead, it pops the
|
|
|
4207 specified number of `NEXT' stack entries and resumes execution at the
|
|
|
4208 last one popped, just as the INTERCAL statement does. This causes the
|
|
|
4209 same errors as the INTERCAL statement if the number of entries popped
|
|
|
4210 is zero or larger than the `NEXT' stack.
|
|
|
4211
|
|
|
4212 There is also a macro `ick_return_or_resume();'; it can only be used
|
|
|
4213 inside a function defined with `ICK_EC_FUNC_START', and is equivalent
|
|
|
4214 to `return;' if the function was called from C, or `ick_resume(1);' if
|
|
|
4215 the function was called from INTERCAL. It's therefore a safe way to
|
|
|
4216 return from such a C function if you don't know how control reached it
|
|
|
4217 in the first place.
|
|
|
4218
|
|
|
4219
|
|
|
4220 File: ick.info, Node: ick_forget, Next: ick_get/setone/twospot, Prev: ick_resume, Up: External Calls to C
|
|
|
4221
|
|
|
4222 14.1.8 ick_forget
|
|
|
4223 -----------------
|
|
|
4224
|
|
|
4225 The `ick_forget' macro removes `NEXT' stack entries, and the
|
|
|
4226 corresponding C stack entries. It must be called as a statement by
|
|
|
4227 itself, and its invocation looks like this: `ick_forget(expr);', where
|
|
|
4228 the expression is the number of `NEXT' stack entries to forget (all of
|
|
|
4229 them will be forgotten if the number is higher than the number of
|
|
|
4230 entries). The expression will be casted to an `unsigned short'.
|
|
|
4231
|
|
|
4232 `ick_forget' can only be used inside a function declared with
|
|
|
4233 `ICK_EC_FUNC_START'. As it is removing stack entries both in INTERCAL
|
|
|
4234 and in C, it will clobber the value of all `auto' variables created
|
|
|
4235 since the highest remaining `NEXT' stack entry came into being (or
|
|
|
4236 since the start of the program, if the `NEXT' stack is emptied by the
|
|
|
4237 command) and also deallocate all `alloca' storage allocated since then.
|
|
|
4238 It also causes the return address of the current function to become
|
|
|
4239 undefined, so that function must not return; control may leave it via
|
|
|
4240 `RESUME', or via `COME FROM', or via `NEXT' or `NEXT FROM' followed by
|
|
|
4241 the relevant `NEXT' stack entry being forgotten (the function is still
|
|
|
4242 'running' but suspended while the `NEXT' stack entry still exists).
|
|
|
4243 (Note that these restrictions are stronger than those on `RESUME'; this
|
|
|
4244 is because `RESUME' preserves most of the stack, but `FORGET' destroys
|
|
|
4245 parts of the stack and therefore cannot avoid destroying the data
|
|
|
4246 stored there. It could be much worse; a previous (never released)
|
|
|
4247 version of the code didn't remove those parts of the stack in many
|
|
|
4248 circumstances, leading to a stack leak that caused programs to segfault
|
|
|
4249 after a while.)
|
|
|
4250
|
|
|
4251
|
|
|
4252 File: ick.info, Node: ick_get/setone/twospot, Next: ick_create, Prev: ick_forget, Up: External Calls to C
|
|
|
4253
|
|
|
4254 14.1.9 ick_get/setone/twospot
|
|
|
4255 -----------------------------
|
|
|
4256
|
|
|
4257 This class of four functions make it possible to get and set INTERCAL
|
|
|
4258 scalar variables from C code. Their prototypes are as follows:
|
|
|
4259
|
|
|
4260 uint16_t ick_getonespot(unsigned short varnumber);
|
|
|
4261 void ick_setonespot(unsigned short varnumber, uint16_t newvalue);
|
|
|
4262 uint32_t ick_gettwospot(unsigned short varnumber);
|
|
|
4263 void ick_settwospot(unsigned short varnumber, uint32_t newvalue);
|
|
|
4264
|
|
|
4265 The program will error out with a fatal error (*note E200::) if the
|
|
|
4266 variable you request is mentioned nowhere in the INTERCAL program; if
|
|
|
4267 you attempt to set an `IGNORE'd variable, the attempt will silently
|
|
|
4268 fail (just as if you assigned to it in an INTERCAL program). The get
|
|
|
4269 functions are safe to use in a computed line label, so you can use them
|
|
|
4270 to produce computed line labels that depend on INTERCAL variables.
|
|
|
4271 (`uint16_t' and `uint32_t' are standard C data types; if your system
|
|
|
4272 doesn't provide them, get better system header files.)
|
|
|
4273
|
|
|
4274 If you care about speed, note that .1 is the fastest variable of all to
|
|
|
4275 access, and otherwise variables first mentioned near the top of the
|
|
|
4276 INTERCAL program will be faster to access than variables mentioned
|
|
|
4277 lower down.
|
|
|
4278
|
|
|
4279
|
|
|
4280 File: ick.info, Node: ick_create, Next: External Calls and auto, Prev: ick_get/setone/twospot, Up: External Calls to C
|
|
|
4281
|
|
|
4282 14.1.10 ick_create
|
|
|
4283 ------------------
|
|
|
4284
|
|
|
4285 The `ick_create' function (prototype: `void ick_create(char*, unsigned
|
|
|
4286 long)') allows the external calls system to be used to create new
|
|
|
4287 INTERCAL syntax; to do this, you give a `signature' representing the
|
|
|
4288 syntax you want to define and a line number to the function (which are
|
|
|
4289 its two arguments, respectively). The signature defines the syntax
|
|
|
4290 that you are defining; whenever that syntax is encountered within the
|
|
|
4291 INTERCAL program, it will `NEXT' to the line number you specify, which
|
|
|
4292 can do various clever things and then `RESUME' back to the INTERCAL
|
|
|
4293 program (or if you're defining a flow-control operation, you might want
|
|
|
4294 to leave the `NEXT' stack entry there and do other things). However,
|
|
|
4295 note that the overloading of `:1601', etc., will still take place as in
|
|
|
4296 the INTERCAL version of `CREATE' if the `-a' option is used (*note
|
|
|
4297 -a::), so care is needed when writing flow control statements that they
|
|
|
4298 work both with and without the option and don't cause `STASH' leaks
|
|
|
4299 (which means no `FORGET'ting the relevant `NEXT' stack entry, and no
|
|
|
4300 looking at 1600-range variables). This allows the external calls
|
|
|
4301 system to define whole new INTERCAL commands, with the same power as
|
|
|
4302 any other programming language.
|
|
|
4303
|
|
|
4304 There are various restrictions on what syntax you can `CREATE' with
|
|
|
4305 this method, which are best explained by an explanation of the relevant
|
|
|
4306 C-INTERCAL compiler internals. When an INTERCAL program is compiled by
|
|
|
4307 C-INTERCAL, any unrecognised statements it comes across are compiled by
|
|
|
4308 a `just-in-case' compiler that attempts to compile them anyway with no
|
|
|
4309 knowledge of their syntax, just in case the syntax becomes defined
|
|
|
4310 later. (E000 (*note E000::) will be thrown when such statements are
|
|
|
4311 encountered at runtime, unless the syntax has been `CREATE'd since to
|
|
|
4312 give a statement a meaning.) For the just-in-case compiler to run, the
|
|
|
4313 resulting statement must be completely unrecognised; this means that it
|
|
|
4314 may contain no keywords (not even a sequence of letters that forms a
|
|
|
4315 keyword, such as `FROM' or `DO'), it must consist only of variable
|
|
|
4316 names, expressions, and capital letters other than `V' (because `V' is
|
|
|
4317 a unary operator, so otherwise there would be ambiguity), and in which
|
|
|
4318 any two variable names or expressions are separated by at least one
|
|
|
4319 capital letter. The compiler will produce a `signature' for the
|
|
|
4320 unknown command that can be defined.
|
|
|
4321
|
|
|
4322 A signature consists of a sequence of characters (and is represented as
|
|
|
4323 a null-terminated string; the runtime makes a shallow copy of the
|
|
|
4324 string and keeps it until the end of the program, so arrangements must
|
|
|
4325 be made to ensure that the storage in which the string is allocated
|
|
|
4326 stays around that long, but this opens up interesting possibilities in
|
|
|
4327 which the signature that was actually `CREATE'd can be modified
|
|
|
4328 retroactively); whitespace is not allowed in a signature. Capital
|
|
|
4329 letters can be used (apart from `V'), and match the same capital
|
|
|
4330 letters literally in the INTERCAL syntax being created; also available
|
|
|
4331 are the special characters `.,;~', which match respectively a scalar
|
|
|
4332 variable (a onespot or twospot variable such as `:1'), an array
|
|
|
4333 variable (such as `;2'), an array element (such as `,3 SUB #4 #5'), and
|
|
|
4334 an expression that isn't a variable name and isn't an array element
|
|
|
4335 (such as `.4$.5'). If you want to be able to match other things (say,
|
|
|
4336 to be able to match all expressions), you will need to submit multiple
|
|
|
4337 signatures using multiple calls to `ick_create'; maybe you could write
|
|
|
4338 a library to do that automatically.
|
|
|
4339
|
|
|
4340 `CREATE'd operators also have signatures, but of quite a different
|
|
|
4341 form. The signature for a single-character operator is a lowercase u,
|
|
|
4342 followed by its character code in hexadecimal (no leading zeros, and in
|
|
|
4343 lowercase); the signature for an overstrike is a lowercase o, followed
|
|
|
4344 by the lower relevant character code in hexadecimal, followed by a
|
|
|
4345 lowercase x, followed by the higher relevant character code in
|
|
|
4346 hexadecimal.
|
|
|
4347
|
|
|
4348 The routine that is `NEXT'ed to will presumably want to be able to see
|
|
|
4349 what in the INTERCAL program was matched by the signature, so a range
|
|
|
4350 of function-like macros is provided to access that. They must be run
|
|
|
4351 from within the invocation of the function which was `NEXT'ed into by
|
|
|
4352 the created syntax (*note External Calls and auto:: for when a function
|
|
|
4353 invocation ends, which could be sooner than you think when the
|
|
|
4354 C-INTERCAL external calls system is used), and are undefined behaviour
|
|
|
4355 when that invocation did not gain control from a `CREATE'd statement.
|
|
|
4356 Here are their effective prototypes:
|
|
|
4357
|
|
|
4358 int ick_c_width(int);
|
|
|
4359 int ick_c_isarray(int);
|
|
|
4360 unsigned short ick_c_varnumber(int);
|
|
|
4361 uint32_t ick_c_value(int);
|
|
|
4362 /* These require -a to work */
|
|
|
4363 uint32_t ick_c_getvalue(int);
|
|
|
4364 void ick_c_setvalue(int, uint32_t);
|
|
|
4365
|
|
|
4366 The first argument to all these macros is the position of the match in
|
|
|
4367 the signature (0 for the first non-capital-letter match in the
|
|
|
4368 signature, 1 for the second, and so on until no more items are left in
|
|
|
4369 the signature to match); specifying a position that isn't in the
|
|
|
4370 signature is undefined behaviour.
|
|
|
4371
|
|
|
4372 `ick_c_width' returns the data type, as a width in bits, of the
|
|
|
4373 expression (or the width in bits of an element of the passed in array),
|
|
|
4374 and `ick_c_isarray' returns 1 if the argument was an array variable or
|
|
|
4375 0 if it was an expression (array elements and scalar variables are
|
|
|
4376 expressions). `ick_c_varnumber' returns the variable's number (for
|
|
|
4377 instance 123 for `.123'), or 0 if the corresponding argument was not a
|
|
|
4378 variable; in the cases where the argument was a variable, these three
|
|
|
4379 functions together provide enough information to figure out which
|
|
|
4380 variable (which is useful if you're writing an extension which takes a
|
|
|
4381 variable name as an argument).
|
|
|
4382
|
|
|
4383 `ick_c_value' returns the value of the corresponding expression at the
|
|
|
4384 time the `CREATE'd command was called; `ick_c_getvalue' is almost
|
|
|
4385 equivalent, but only works if the `-a' option (*note -a::) was used
|
|
|
4386 during compilation, and returns the value of the corresponding
|
|
|
4387 expression now. (The uint32_t return type is large enough to hold
|
|
|
4388 either a onespot or twospot value, and will be zero-extended if the
|
|
|
4389 corresponding expression had onespot type.) `ick_c_setvalue' also
|
|
|
4390 depends on `-a', and will assign to the corresponding expression (be
|
|
|
4391 careful not to provide a value that is too large for it!). In the case
|
|
|
4392 that the corresponding expression is not a variable, this will attempt
|
|
|
4393 to perform a reverse assignment to the expression, and can produce
|
|
|
4394 ordinary INTERCAL errors if it fails. It is not possible to
|
|
|
4395 redimension an array this way, as this is assignment, not a calculate
|
|
|
4396 operation.
|
|
|
4397
|
|
|
4398
|
|
|
4399 File: ick.info, Node: External Calls and auto, Prev: ick_create, Up: External Calls to C
|
|
|
4400
|
|
|
4401 14.1.11 External Calls and auto
|
|
|
4402 -------------------------------
|
|
|
4403
|
|
|
4404 Because the external calls system merges the INTERCAL `NEXT' stack with
|
|
|
4405 the C return value and data storage stack (note for pedants: the C
|
|
|
4406 standards nowhere mandate the existence of such a stack, or even mention
|
|
|
4407 one, but the restrictions stated in them imply that implementations have
|
|
|
4408 to act as if such a stack existed, because of the way the scoping rules
|
|
|
4409 and recursion work), the external calls system therefore has severe
|
|
|
4410 effects on data that happens to be stored there. (In INTERCAL terms,
|
|
|
4411 imagine what would happen if data could be stored on the `NEXT' stack;
|
|
|
4412 if C used the more sensible system of having a `STASH' for each
|
|
|
4413 variable, these problems would never occur in the first place, instead
|
|
|
4414 causing an entirely different set of problems.) Similar considerations
|
|
|
4415 apply to the common nonstandard C extension `alloca', which dynamically
|
|
|
4416 alters the size of the stack; also, in what goes below, `register'
|
|
|
4417 variables should be considered to be `auto', because the compiler may
|
|
|
4418 choose to allocate them on the stack. Theoretical considerations would
|
|
|
4419 lead one to conclude that variable-length arrays should obey most of
|
|
|
4420 the same restrictions; in practice, though, it's unwise to attempt to
|
|
|
4421 mix those with INTERCAL code at all, except by separating them into
|
|
|
4422 separate functions which aren't flagged with `ICK_EC_FUNC_START' and
|
|
|
4423 use no `ick_'-prefixed identifiers, even indirectly. (They may cause a
|
|
|
4424 compile to fail completely because they don't mix well with `goto'.)
|
|
|
4425
|
|
|
4426 In the description below, INTERCAL commands should be taken to include
|
|
|
4427 the equivalent C macros.
|
|
|
4428
|
|
|
4429 `NEXT'/`NEXT FROM' paired with `RESUME' have the least effect, and the
|
|
|
4430 most obvious effect, on `auto' variables in the function that was
|
|
|
4431 `NEXT'ed from, which is the same effect that the standard C function
|
|
|
4432 `longjmp' has. That is, `alloca' storage stays intact, and `auto'
|
|
|
4433 variables have their values `clobbered' (that is, their value is no
|
|
|
4434 longer reliable and should not be used) if they changed since the
|
|
|
4435 corresponding `NEXT' and are not marked as `volatile'. (This is a very
|
|
|
4436 easy restriction to get around, because changing the values of such
|
|
|
4437 variables is quite difficult without using statically-allocated
|
|
|
4438 pointers to point to them (a dubious practice in any case), and
|
|
|
4439 `volatile' is trivial to add to the declaration.)
|
|
|
4440
|
|
|
4441 `COME FROM' has more restrictions; it deallocates all `alloca' storage
|
|
|
4442 in the function that was `COME FROM', and functions that called it or
|
|
|
4443 that called functions that called it, etc., using C calls (as opposed
|
|
|
4444 to `NEXT'), and those invocations of the functions will cease to exist
|
|
|
4445 (thus destroying any `auto' variables in them), even in the case of
|
|
|
4446 `COMING FROM' a function into the same function. `auto' variables in
|
|
|
4447 the function that is come into will start uninitialised, even if
|
|
|
4448 initialisers are given in their declaration, and it will be a `new'
|
|
|
4449 invocation of that function. (It is quite possible that the
|
|
|
4450 uninitialised values in the `auto' variables will happen by chance to
|
|
|
4451 have the values they had in some previous invocation of the function,
|
|
|
4452 though, because they are likely to be stored in much the same region of
|
|
|
4453 memory; but it is highly unwise to rely on this.) Note that `volatile'
|
|
|
4454 will not help here. Observant or source-code-reading readers may note
|
|
|
4455 that there is a mention of an `ick_goto' in the source code to
|
|
|
4456 C-INTERCAL; this is undocumented and this manual does not officially
|
|
|
4457 claim that such a macro exists (after all, if it did, what in INTERCAL
|
|
|
4458 could it possibly correspond to?), but if such a macro does exist it
|
|
|
4459 obeys the same restrictions as `COME FROM'.
|
|
|
4460
|
|
|
4461 `FORGET' is the worst of all in terms of preserving data on the stack;
|
|
|
4462 it deallocates `alloca' data and clobbers or deletes `auto' variables
|
|
|
4463 in all function invocations that have come into existence since the
|
|
|
4464 `NEXT' that created the topmost remaining `NEXT' stack entry was
|
|
|
4465 called, or since the start of the program if the `NEXT' stack is
|
|
|
4466 emptied, and the current function will continue in a new invocation.
|
|
|
4467 `volatile' is useless in preventing this, because the relevant parts of
|
|
|
4468 the stack where the data were stored are deleted by the command (that's
|
|
|
4469 what `FORGET' does, remove stack). If any of these data are required,
|
|
|
4470 they have to be backed up into static storage (variables declared with
|
|
|
4471 `static' or global variables), or into heap storage (as in with
|
|
|
4472 `malloc'), or other types of storage (such as temporary files) which
|
|
|
4473 are not on the stack. (Incidentally, suddenly deleting parts of the
|
|
|
4474 stack is excellent at confusing C debuggers; but even `RESUME' and
|
|
|
4475 `COME FROM' tend to be sufficient to confuse such debuggers. More
|
|
|
4476 worrying is probably the fact that the C standard provides a portable
|
|
|
4477 method for deleting the stack like that, and in fact the external calls
|
|
|
4478 runtime library is written in standard freestanding-legal C89 (with the
|
|
|
4479 exception of `+printflow' debug output which requires a hosted
|
|
|
4480 implementation), meaning that in theory it would be possible to split
|
|
|
4481 it out to create an implementation of a C-plus-COME-FROM-and-NEXT
|
|
|
4482 language, and doing so would not be particularly difficult.)
|
|
|
4483
|
|
|
4484 Note that INTERCAL variables are not stored on the C stack, nor are any
|
|
|
4485 of the metadata surrounding them, and so are not affected unduly by
|
|
|
4486 control flow operations.
|
|
|
4487
|
|
|
4488
|
|
|
4489 File: ick.info, Node: External Calls to Funge-98, Next: Miscellaneous External Calls, Prev: External Calls to C, Up: External Calls
|
|
|
4490
|
|
|
4491 14.2 External Calls to Funge-98
|
|
|
4492 ===============================
|
|
|
4493
|
|
|
4494 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
4495 ------------------------------------------------------------------------
|
|
|
4496 no version 0.29+ no no
|
|
|
4497
|
|
|
4498 C-INTERCAL supports linking INTERCAL programs with Funge-98 programs
|
|
|
4499 (to be precise, only Befunge-98 programs are currently supported).
|
|
|
4500 However, it does not ship with a Funge-98 interpreter, and such an
|
|
|
4501 interpreter needs to be linked to the resulting program in order to run
|
|
|
4502 the Befunge program. Therefore, you need to convert a third-party
|
|
|
4503 Funge-98 interpreter to a library usable by C-INTERCAL before you can
|
|
|
4504 use this part of the external calls system (*note Creating the Funge-98
|
|
|
4505 Library::); however, this only has to be done once.
|
|
|
4506
|
|
|
4507 Once the library has been created, you can link an INTERCAL program
|
|
|
4508 with a Befunge-98 program by invoking `ick' like this:
|
|
|
4509
|
|
|
4510 ick -e intercalprogram.i befungeprogram.b98
|
|
|
4511
|
|
|
4512 You can link no more than one Befunge-98 program at once (just like you
|
|
|
4513 can link no more than one INTERCAL program at once). Also, the
|
|
|
4514 INTERCAL program must come first on the command line.
|
|
|
4515
|
|
|
4516 It is legal to link INTERCAL, C, and Befunge-98 simultaneously;
|
|
|
4517 however, the identifiers used in the third-party Funge-98 interpreter
|
|
|
4518 have not been mangled to avoid collisions, and therefore problems may
|
|
|
4519 be caused if the C program uses the same identifiers as the Funge-98
|
|
|
4520 interpreter.
|
|
|
4521
|
|
|
4522 * Menu:
|
|
|
4523
|
|
|
4524 * Creating the Funge-98 Library:: How to create the Funge-98 library.
|
|
|
4525 * The IFFI Fingerprint:: External calls from Funge's view.
|
|
|
4526
|
|
|
4527
|
|
|
4528 File: ick.info, Node: Creating the Funge-98 Library, Next: The IFFI Fingerprint, Up: External Calls to Funge-98
|
|
|
4529
|
|
|
4530 14.2.1 Creating the Funge-98 Library
|
|
|
4531 ------------------------------------
|
|
|
4532
|
|
|
4533 Before external calls to Funge-98 can be used, the relevant library
|
|
|
4534 must be compiled. (After the library has been compiled, then you will
|
|
|
4535 need to reinstall C-INTERCAL; however, you will not need to recompile
|
|
|
4536 C-INTERCAL.)
|
|
|
4537
|
|
|
4538 At present, only the cfunge Funge-98 interpreter can be converted into
|
|
|
4539 a library suitable for use by C-INTERCAL; also, doing this is only
|
|
|
4540 supported on POSIX systems (although if someone gets it to work on
|
|
|
4541 DOS/Windows, the author of this manual would be interested to hear
|
|
|
4542 about it.) Also, a source-code distribution (rather than a binary
|
|
|
4543 distribution) is needed. One way to obtain the latest cfunge sources
|
|
|
4544 is via the bzr version-control system, using the following command
|
|
|
4545 (correct as of the time of writing, but as always, links can become
|
|
|
4546 dead):
|
|
|
4547
|
|
|
4548 bzr branch http://rage.kuonet.org/~anmaster/bzr/cfunge
|
|
|
4549
|
|
|
4550 (As a licensing note, note that cfunge is licensed under the GNU
|
|
|
4551 General Public licence version 3, whereas C-INTERCAL is licensed under
|
|
|
4552 version 2 and all later versions of that licence; although these terms
|
|
|
4553 are obviously compatible with each other, you must ensure yourself that
|
|
|
4554 your program has appropriate licensing terms to allow a GPLv3 library
|
|
|
4555 to be linked to it.)
|
|
|
4556
|
|
|
4557 Once you have downloaded the cfunge sources, you need to compile them
|
|
|
4558 into a library suitable for use with C-INTERCAL (note that this is a
|
|
|
4559 somewhat different process to compiling them into a standalone Funge-98
|
|
|
4560 interpreter). There is a script provided in the C-INTERCAL
|
|
|
4561 distribution to do this, `etc/cftoec.sh'. It must be run in the `etc'
|
|
|
4562 subdirectory of the C-INTERCAL distribution (i.e. the directory the
|
|
|
4563 script itself is in), and must be given the path to the root directory
|
|
|
4564 of the cfunge source distribution (that is, the directory that contains
|
|
|
4565 the `src', `lib' and `tools' subdirectories of that distribution) as
|
|
|
4566 its only argument. Note that it may give some compiler warnings on
|
|
|
4567 compilation; my experience is that warnings about C99 inlining can be
|
|
|
4568 safely ignored (they reflect a deficiency in `gcc' itself that luckily
|
|
|
4569 seems to be irrelevant in this case), but other warnings may indicate
|
|
|
4570 problems in the exact versions of the sources that you downloaded (and
|
|
|
4571 errors definitely indicate such problems).
|
|
|
4572
|
|
|
4573 Once the library has been created, it will appear as the new file
|
|
|
4574 `lib/libick_ecto_b98.a' in the C-INTERCAL distribution (the cfunge
|
|
|
4575 distribution will be left unchanged); reinstalling C-INTERCAL will
|
|
|
4576 install this file to its proper location. (It is also in a valid
|
|
|
4577 location to be able to be run if you aren't installing C-INTERCAL but
|
|
|
4578 instead just running it from the distribution's directory.)
|
|
|
4579
|
|
|
4580
|
|
|
4581 File: ick.info, Node: The IFFI Fingerprint, Prev: Creating the Funge-98 Library, Up: External Calls to Funge-98
|
|
|
4582
|
|
|
4583 14.2.2 The IFFI Fingerprint
|
|
|
4584 ---------------------------
|
|
|
4585
|
|
|
4586 This section will not make much sense to a non-Funge programmer;
|
|
|
4587 therefore, if you are not used to Funge, you probably want to skip it.
|
|
|
4588
|
|
|
4589 To a Funge program, the external calls interface is accessed via a
|
|
|
4590 Funge-98 'fingerprint' defined by the interpreter. The name of the
|
|
|
4591 fingerprint is 0x49464649, or as text, `IFFI'.
|
|
|
4592
|
|
|
4593 When a program formed by linking INTERCAL and Befunge-98 is run, the
|
|
|
4594 first thing that happens is some internal INTERCAL initialisation which
|
|
|
4595 is not visible to either program, and then initialisation routines
|
|
|
4596 specified in the Befunge-98 program run (if an initialisation routine
|
|
|
4597 is also specified in a linked C program using ick_startup, it is
|
|
|
4598 unspecified whether the C or Befunge-98 initialisation happens first.)
|
|
|
4599 In the Befunge program, the initialisation routine consists of
|
|
|
4600 everything that happens until the `Y' command in the `IFFI' fingerprint
|
|
|
4601 is run; the author of the Funge-98 must load the `IFFI' fingerprint
|
|
|
4602 themselves during this initialisation to access that command. (This is
|
|
|
4603 so that the Befunge program ends up complying with the Funge-98
|
|
|
4604 standard; commands not defined in that standard cannot be used until a
|
|
|
4605 fingerprint is loaded.) During initialisation, no commands from the
|
|
|
4606 `IFFI' fingerprint may be used except `Y' and `A'. (If a different
|
|
|
4607 command is used, `C', `M', and `X' remove the arguments they would use
|
|
|
4608 from the stack (if any) but otherwise do nothing, and the other
|
|
|
4609 commands in the `IFFI' fingerprint reflect.)
|
|
|
4610
|
|
|
4611 After the `Y' command is called, the INTERCAL program starts running;
|
|
|
4612 in order for the Befunge program to regain control, it has to be
|
|
|
4613 `NEXT'ed to from the INTERCAL program, or `COME' or `NEXT FROM' the
|
|
|
4614 INTERCAL program, or contain the line label to which syntax in the
|
|
|
4615 INTERCAL program was `CREATE'd. (In other words, the normal INTERCAL
|
|
|
4616 ways of transferring information between parts of a program.) In order
|
|
|
4617 to do this, therefore, line labels and INTERCAL control flow statements
|
|
|
4618 must be placed into the Befunge program.
|
|
|
4619
|
|
|
4620 Code like `COME FROM (100)' is a single statement in INTERCAL, but
|
|
|
4621 several statements in Funge-98; therefore, some method of telling the
|
|
|
4622 interpreter where to start executing to look for `COME FROM's, `NEXT
|
|
|
4623 FROM's, and line labels is needed. The method used by C-INTERCAL is
|
|
|
4624 that of the 'marker'; a marker is represented by character 0xB7 (a
|
|
|
4625 mid-dot in Latin-1) in the input Funge-98 program, but is transformed
|
|
|
4626 to a capital `M' by `ick'. (The reason for using a special character
|
|
|
4627 for a marker and transforming it rather than just using `M' is to
|
|
|
4628 prevent occurences of `M' in comments and string literals, etc., having
|
|
|
4629 an effect on the control flow of the program.) Whenever a `NEXT' or
|
|
|
4630 line label is encountered (in the INTERCAL program, the Funge program
|
|
|
4631 or elsewhere), the Funge program is executed starting from each marker
|
|
|
4632 in each cardinal direction to look for line labels or `COME'/`NEXT
|
|
|
4633 FROM's respectively. Therefore, `COME FROM (100)' is written in
|
|
|
4634 Funge-98 as `Maa*C' (where the M is a marker in the source code), and
|
|
|
4635 likewise the line label `(100)' would be written as `Maa*L'. (This
|
|
|
4636 code can be written in any cardinal direction, that is left to right,
|
|
|
4637 top to bottom, right to left, or bottom to top, but not diagonally or
|
|
|
4638 flying.) There are likely to be unused directions from markers, which
|
|
|
4639 will be evaluated too; you can (and must) close these off by reflecting
|
|
|
4640 code execution back into that marker, another marker, or a non-marker
|
|
|
4641 `M'. Note also that a marker remains in Funge-space even if the `M' on
|
|
|
4642 the same square is deleted (the marker itself is not visible to the `g'
|
|
|
4643 command, though).
|
|
|
4644
|
|
|
4645 Here are the commands in the `IFFI' fingerprint:
|
|
|
4646 `A'
|
|
|
4647 This command pops a line number and then an 0"gnirts"-format string
|
|
|
4648 from the stack; they are used as the line number and signature to
|
|
|
4649 `CREATE' syntax in the INTERCAL program; for details of the format
|
|
|
4650 of the signature, see *note ick_create::. Although using this
|
|
|
4651 command during speculative execution works, doing so is not
|
|
|
4652 recommended; if the target line number for `CREATE'd syntax is
|
|
|
4653 changed during speculative execution to find the line that that
|
|
|
4654 syntax corresponds to, its effect is delayed until after the
|
|
|
4655 original line is found and execution continues from that point.
|
|
|
4656 (Side effects during speculative execution are never recommended,
|
|
|
4657 because they might or might not be optimised away.)
|
|
|
4658
|
|
|
4659 `C'
|
|
|
4660 During speculative execution to find `COME FROM's and `NEXT
|
|
|
4661 FROM's, pops a line label off the top of the stack and does a
|
|
|
4662 `COME FROM' that location. During speculative excution to find
|
|
|
4663 line labels, pops the top of the stack and ends that particular
|
|
|
4664 speculative execution as a failure. When not doing speculative
|
|
|
4665 execution, pops and discards the top element of the stack.
|
|
|
4666
|
|
|
4667 `D'
|
|
|
4668 This command must only be used when the Funge program is executing
|
|
|
4669 a `CREATE'd command, and allows access to the arguments that
|
|
|
4670 command has. It pops an integer off the top of the stack, and
|
|
|
4671 treats it as an argument position (0-based, so 0 refers to the
|
|
|
4672 first argument, 1 refers to the second, and so on). Note that
|
|
|
4673 providing an invalid argument number, or running this command when
|
|
|
4674 not implementing a `CREATE'd command, leads to undefined behaviour
|
|
|
4675 (possibly a reflection, possibly a segfault, possibly worse).
|
|
|
4676
|
|
|
4677 The command pushes information about the argument chosen onto the
|
|
|
4678 stack; the following information is pushed from bottom to top:
|
|
|
4679 * The data type of the argument, in bits (16 if the argument
|
|
|
4680 was a onespot variable or expression of onespot type, and 32
|
|
|
4681 if the argument was a twospot variable or expression of
|
|
|
4682 twospot type). Note that this is under the C-INTERCAL typing
|
|
|
4683 rules, rather than the INTERCAL-72 typing rules (that is,
|
|
|
4684 select's type is always that of its right argument no matter
|
|
|
4685 how many bits are actually selected).
|
|
|
4686
|
|
|
4687 * 1 if the argument is an array variable, 0 if it is a scalar
|
|
|
4688 value.
|
|
|
4689
|
|
|
4690 * 0 if the argument is not a variable, or the variable's number
|
|
|
4691 if it is (e.g. `.123' would push 123 here, but `.1~.2' would
|
|
|
4692 push 0).
|
|
|
4693
|
|
|
4694 * The argument's value at the time that the `CREATE'd
|
|
|
4695 instruction was called.
|
|
|
4696
|
|
|
4697 * The argument's value now, or alternatively a repeat of the
|
|
|
4698 previous stack element if `-a' (*note -a::) was not used.
|
|
|
4699 (Without `-a', the information needed to re-evaluate the
|
|
|
4700 expression is not available.)
|
|
|
4701
|
|
|
4702 `F'
|
|
|
4703 During speculative execution, this command reflects; otherwise,
|
|
|
4704 this command pops an integer from the top of stack, and `FORGET's
|
|
|
4705 that many `NEXT' stack entries (or all of them if the argument
|
|
|
4706 given is negative).
|
|
|
4707
|
|
|
4708 `G'
|
|
|
4709 This command pops an integer from the top of stack. If it is
|
|
|
4710 positive, the value of the onespot variable whose name is the
|
|
|
4711 popped integer is pushed onto the stack; if it is negative, the
|
|
|
4712 value of the twospot variable whose name is minus the popped
|
|
|
4713 integer is pushed onto the stack; and if it is zero, the command
|
|
|
4714 reflects. If the referenced variable is not in the INTERCAL
|
|
|
4715 program at all, this causes an INTERCAL error due to referencing a
|
|
|
4716 nonexistent variable.
|
|
|
4717
|
|
|
4718 `L'
|
|
|
4719 During speculative execution to find `COME FROM's and `NEXT
|
|
|
4720 FROM's, this command pops and discards the top stack element, then
|
|
|
4721 ends that speculative execution. During speculative execution to
|
|
|
4722 find a line label, this command pops an integer from the top of
|
|
|
4723 stack and succeeds with that integer as the line label (that is,
|
|
|
4724 it is possible to `NEXT' to an `L' in the Funge program if a
|
|
|
4725 marker, followed by code to push the correct line number onto the
|
|
|
4726 stack, precedes that `L'). When not doing speculative execution,
|
|
|
4727 the integer on the top of the stack is used as a line label
|
|
|
4728 (assuming it is in the range 1-65535, otherwise it is popped and
|
|
|
4729 discarded), and a search is made for `COME FROM's and `NEXT FROM's
|
|
|
4730 aiming for that line label (including in the INTERCAL program and
|
|
|
4731 the Befunge program itself, as well as programs in any other
|
|
|
4732 language which may be linked in). Note that just as in INTERCAL,
|
|
|
4733 it is possible to `NEXT' to a line label which has a `COME FROM'
|
|
|
4734 aiming for it, in which case the `COME FROM' will come from that
|
|
|
4735 line label as soon as the `NEXT' transfers control to it.
|
|
|
4736
|
|
|
4737 `M'
|
|
|
4738 Does nothing if not in speculative execution, or ends the current
|
|
|
4739 speculative execution with failure. (This is so that code like
|
|
|
4740 v
|
|
|
4741 >M5C
|
|
|
4742 ^
|
|
|
4743 does exactly the same thing as `COME FROM (5)', even when, for
|
|
|
4744 instance, it is entered from the left in the Funge program, rather
|
|
|
4745 than gaining control from the line label `(5)'.)
|
|
|
4746
|
|
|
4747 `N'
|
|
|
4748 During speculative execution, reflects. Otherwise, pops the top
|
|
|
4749 stack element, interprets it as a line label, and `NEXT's to that
|
|
|
4750 line label (this may start speculative execution to look for line
|
|
|
4751 labels, but might not if it isn't needed, for instance if the line
|
|
|
4752 label in question is in the INTERCAL program or in a C program
|
|
|
4753 linked to the Befunge program).
|
|
|
4754
|
|
|
4755 `R'
|
|
|
4756 During speculative execution, reflects. Otherwise, pops the top
|
|
|
4757 stack element, removes that many items from the `NEXT' stack, and
|
|
|
4758 `RESUME's at the last item removed. (If the top stack element was
|
|
|
4759 zero, negative, or too large, this will cause a fatal error in the
|
|
|
4760 INTERCAL program.)
|
|
|
4761
|
|
|
4762 `S'
|
|
|
4763 Pops a variable number (interpreted as onespot if positive, or
|
|
|
4764 minus the number of a twospot variable if negative) and an integer
|
|
|
4765 from the stack, and sets the referenced variable to the integer.
|
|
|
4766 This reflects if an attempt is made to set the nonexistent
|
|
|
4767 variable 0, causes a fatal error in the INTERCAL program if an
|
|
|
4768 attempt is made to set a variable that doesn't exist there, and
|
|
|
4769 does not set read-only variables (but pops the stack anyway). If
|
|
|
4770 the integer is too high for the variable it is being stored in,
|
|
|
4771 only the least significant 16 or 32 bits from it will be used; and
|
|
|
4772 likewise, if it is negative, it will be treated as the two's
|
|
|
4773 complement of the number given.
|
|
|
4774
|
|
|
4775 `V'
|
|
|
4776 Pops a `CREATE'd argument index and an integer from the top of
|
|
|
4777 stack. (This is undefined behaviour if not in the implementation
|
|
|
4778 of a `CREATE'd statement, or if the referenced argument does not
|
|
|
4779 exist; as with the `D' instruction, 0 refers to the first
|
|
|
4780 argument, 1 to the second, and so on.) If the `-a' option is not
|
|
|
4781 used, this command does nothing; otherwise, the value of the
|
|
|
4782 argument will be set to the integer. (This involves doing a
|
|
|
4783 reverse assignment if the argument is a non-variable expression,
|
|
|
4784 as usual, and causes a fatal error in the INTERCAL program if the
|
|
|
4785 reverse assignment is impossible or an attempt is made to assign a
|
|
|
4786 scalar to an array.)
|
|
|
4787
|
|
|
4788 `X'
|
|
|
4789 This is identical to `C', except that it does a `NEXT FROM' rather
|
|
|
4790 than a `COME FROM'.
|
|
|
4791
|
|
|
4792 As with external calls to C, terminating any program involved (whether
|
|
|
4793 the INTERCAL program with `GIVE UP', the Befunge program with `@' or
|
|
|
4794 `q', or a C program with `exit()') causes all programs involved to
|
|
|
4795 terminate, and likewise a fatal error will end all programs with an
|
|
|
4796 error.
|
|
|
4797
|
|
|
4798 One final point which is probably worth mentioning is that flow control
|
|
|
4799 instructions only record the IP's position and direction, nothing else;
|
|
|
4800 so for instance, if the stack is modified in one part of the code,
|
|
|
4801 those modifications will remain even after a `RESUME', for instance.
|
|
|
4802
|
|
|
4803
|
|
|
4804 File: ick.info, Node: Miscellaneous External Calls, Next: Using External Calls, Prev: External Calls to Funge-98, Up: External Calls
|
|
|
4805
|
|
|
4806 14.3 Miscellaneous External Calls
|
|
|
4807 =================================
|
|
|
4808
|
|
|
4809 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
4810 ------------------------------------------------------------------------
|
|
|
4811 no version 0.29+ no no
|
|
|
4812
|
|
|
4813 It is possible to specify other information to the external calls
|
|
|
4814 system by using the filename list after all the options are given. To
|
|
|
4815 be precise, certain filename patterns are recognised and used to change
|
|
|
4816 the options that are used to compile the externally-called files.
|
|
|
4817
|
|
|
4818 The `.c99' extension is treated identically to `.c', except that it
|
|
|
4819 causes the file with that extension to be preprocessed as C99 (the more
|
|
|
4820 modern version of the C standard, the older C89 is more common), and
|
|
|
4821 that all C files involved will be compiled and linked as C99. (This
|
|
|
4822 corresponds to `-std=c99' in `gcc'.)
|
|
|
4823
|
|
|
4824 The `.a' extension indicates that an object-code library should be
|
|
|
4825 linked in to the final program. This is most commonly used to link in
|
|
|
4826 the maths library `libm.a' and other such system libraries. If the
|
|
|
4827 filename is of the form `lib*.a', then the file will be searched for in
|
|
|
4828 the standard directories for libraries on your system, and also where
|
|
|
4829 the C-INTERCAL libraries are stored (which may be the same place);
|
|
|
4830 otherwise, the current directory will be searched. (Specifying
|
|
|
4831 `libm.a' on the command line corresponds to passing `-lm' to `gcc'.)
|
|
|
4832
|
|
|
4833
|
|
|
4834 File: ick.info, Node: Using External Calls, Next: Expansion Libraries, Prev: Miscellaneous External Calls, Up: External Calls
|
|
|
4835
|
|
|
4836 14.4 Using External Calls
|
|
|
4837 =========================
|
|
|
4838
|
|
|
4839 Whatever language your source files are written in, when `-e' is used
|
|
|
4840 (*note -e::), the compiler will go through much the same steps.
|
|
|
4841
|
|
|
4842 First, the INTERCAL program specified is compiled into a C program that
|
|
|
4843 uses the INTERCAL external call conventions for its control flow
|
|
|
4844 operations. The resulting `.c' file will be left behind in the same
|
|
|
4845 directory (even if `-g' isn't used); if you look at it, you'll see the
|
|
|
4846 `#include <ick_ec.h>' line, and the other hallmarks of an external call
|
|
|
4847 program (for instance, INTERCAL `NEXT's will translate into slightly
|
|
|
4848 modified `ick_next's; the modification is simply to allow the correct
|
|
|
4849 line number to be displayed in case of error).
|
|
|
4850
|
|
|
4851 After that, the resulting files are preprocessed twice. First, the C
|
|
|
4852 preprocessor is run on the files; then, a special C-INTERCAL
|
|
|
4853 `preprocessor' is run on the files. (`Preprocessor' is a bit of a
|
|
|
4854 misnomer here, as it's near the end of the compilation process;
|
|
|
4855 `postprocessor' would likely be more accurate, or maybe
|
|
|
4856 `interprocessor'.) Its job is to fix line labels between the gotos
|
|
|
4857 that are used to implement jumping into the middle of a C function, to
|
|
|
4858 assign unique numbers to things that need them, and to keep track of
|
|
|
4859 which functions need to be checked for line labels and for `COME FROM's
|
|
|
4860 and `NEXT FROM's. The resulting file will have the extension `.cio';
|
|
|
4861 it is almost human-readable, especially if you run it through a C code
|
|
|
4862 indenter, and consists of C code (or code in whatever language is being
|
|
|
4863 linked to the INTERCAL code, but so far only C is accepted) and
|
|
|
4864 instructions to `gcc'. The `.cio' file will be left behind for you to
|
|
|
4865 look at, if you like.
|
|
|
4866
|
|
|
4867 Once the `.cio' files have been produced, `gcc' is used to compile all
|
|
|
4868 the `.cio' files and link them together into an executable; the
|
|
|
4869 executable will have the same name as the INTERCAL source, minus any
|
|
|
4870 extension (and on DJGPP, assuming that its version of `gcc' could
|
|
|
4871 handle the resulting command line (not necessarily guaranteed), a
|
|
|
4872 `.exe' extension is added), and will consist of all the C files linked
|
|
|
4873 together with the INTERCAL. Any functions named `main' in the C files
|
|
|
4874 will be deleted; likewise, if there is a name clash between any two
|
|
|
4875 functions, the one in the file named earlier on the command line will
|
|
|
4876 be used. There is presumably some use for this feature, although I
|
|
|
4877 haven't figured out what it is yet.
|
|
|
4878
|
|
|
4879 Extending this to other compiled languages is mostly a problem of
|
|
|
4880 determining how they fit into the INTERCAL control structure, which is
|
|
|
4881 not a trivial task, and of figuring out how to link them to C code,
|
|
|
4882 which in some cases is trivial (especially if the language is one that
|
|
|
4883 `gcc' can compile!) and in other cases is very difficult. If anyone
|
|
|
4884 has any ideas of new languages that could be added to the external
|
|
|
4885 calls system, feel free to contact the current C-INTERCAL maintainer
|
|
|
4886 with suggestions or patches.
|
|
|
4887
|
|
|
4888
|
|
|
4889 File: ick.info, Node: Expansion Libraries, Prev: Using External Calls, Up: External Calls
|
|
|
4890
|
|
|
4891 14.5 Expansion Libraries
|
|
|
4892 ========================
|
|
|
4893
|
|
|
4894 INTERCAL-72 C-INTERCAL CLC-INTERCAL J-INTERCAL
|
|
|
4895 ------------------------------------------------------------------------
|
|
|
4896 no version 0.28+ no no
|
|
|
4897
|
|
|
4898 The C-INTERCAL distribution comes with libraries that can be used to
|
|
|
4899 extend its capabilities; they are implemented using the external call
|
|
|
4900 mechanism, and are in effect standard files to include using that
|
|
|
4901 mechanism. To use an expansion library, give the `-e' option to `ick'
|
|
|
4902 (note that this means you cannot use them with the debugger or
|
|
|
4903 profiler, nor with multithreaded or backtracking programs), and specify
|
|
|
4904 the expansion library's name at the end of the command line (or to be
|
|
|
4905 precise, anywhere after the initial INTERCAL file). The libraries
|
|
|
4906 themselves are written in C and have a `.c' extension, and are
|
|
|
4907 human-readable; C-INTERCAL will look for them in the same places as it
|
|
|
4908 looks for the system library (including in the current directory, so
|
|
|
4909 you can test your own expansion libraries without having to install
|
|
|
4910 them).
|
|
|
4911
|
|
|
4912 Expansion libraries use C identifiers which start with the string
|
|
|
4913 `ick_my_' (this is not used by the compiler, and is explicitly not
|
|
|
4914 affected by the prohibition on identifiers starting `ick_' when writing
|
|
|
4915 an expansion library), and use line labels in the range (1600) to
|
|
|
4916 (1699). (Most programs will be avoiding this range anyway, because
|
|
|
4917 it's inside the (1000) to (1999) range reserved for the system library,
|
|
|
4918 but the system library doesn't use it, in much the same way that the
|
|
|
4919 identifiers used are inside the range reserved for the compiler, but
|
|
|
4920 the compiler doesn't use them.)
|
|
|
4921
|
|
|
4922 Expansion libraries are available from C-INTERCAL version 0.28;
|
|
|
4923 CLC-INTERCAL has a similar concept (that of `preloads'), but
|
|
|
4924 implemented a completely different way.
|
|
|
4925
|
|
|
4926 syslibc
|
|
|
4927 -------
|
|
|
4928
|
|
|
4929 `syslibc' is an implementation of the base-2 INTERCAL system library in
|
|
|
4930 C (*note System Library::); using it in programs running in other bases
|
|
|
4931 is accepted by the compiler, but likely to produce unpredictable
|
|
|
4932 results. When using this expansion library, you also need to give the
|
|
|
4933 `-E' option (*note -E: -E+.) so that the main system library is not
|
|
|
4934 included, or it will be used in preference to the expansion library.
|
|
|
4935 All documented features of the INTERCAL base-2 system library are
|
|
|
4936 implemented, but most undocumented features are not, so INTERCAL
|
|
|
4937 programs which relied on them (dubious behaviour in any case) will not
|
|
|
4938 work with `syslibc'. The main reason to use this library is to
|
|
|
4939 increase the speed of an INTERCAL program; however, note that the speed
|
|
|
4940 gains in arithmetic will be accompanied by the performance penalty of
|
|
|
4941 using the external calls infrastructure, unless you were already using
|
|
|
4942 it.
|
|
|
4943
|
|
|
4944 compunex
|
|
|
4945 --------
|
|
|
4946
|
|
|
4947 As an example of using `ick_create', a very simple expansion library is
|
|
|
4948 provided to enable a computed NEXT capability, by defining a new
|
|
|
4949 command `COMPUNEX'. It is used as `DO .1 COMPUNEX' (allowing any
|
|
|
4950 expression in place of the .1), and is similar to an ordinary `NEXT',
|
|
|
4951 but has two limitations: it takes up two `NEXT' stack entries, and the
|
|
|
4952 top one should not be `RESUMEd' past or forgotten (thus it isn't a
|
|
|
4953 particularly useful command, except maybe to produce the equivalent of
|
|
|
4954 something like function pointers). By the way, note that C-INTERCAL
|
|
|
4955 avoids computed `NEXT' mainstream for much the same way that
|
|
|
4956 CLC-INTERCAL avoids `NEXT' altogether; it makes things too easy. This
|
|
|
4957 example is provided mostly just to demonstrate the syntax, and the care
|
|
|
4958 that needs to be taken with implementing flow control operators.
|
|
|
4959
|
|
|
4960 `compunex' is double-deprecated; an alternative is the following
|
|
|
4961 sequence of commands involving computed `CREATE':
|
|
|
4962
|
|
|
4963 DO CREATE .1 ABC
|
|
|
4964 DO ABC
|
|
|
4965
|
|
|
4966 This sequence emulates all features of `NEXT' (although it has
|
|
|
4967 different gerunds and is two statements, not one), making it much more
|
|
|
4968 useful for simulating computed `NEXT' than `COMPUNEX' is. (There's no
|
|
|
4969 need to avoid forgetting the return value; although this skips the
|
|
|
4970 `CREATE' cleanup, none is required because the created statement `ABC'
|
|
|
4971 (any other statement would do just as well) takes no arguments.)
|
|
|
4972
|
|
|
4973
|
|
|
4974 File: ick.info, Node: Differences to Other Compilers, Next: Character Sets, Prev: External Calls, Up: Top
|
|
|
4975
|
|
|
4976 15 Differences to Other Compilers
|
|
|
4977 *********************************
|
|
|
4978
|
|
|
4979 The C-INTERCAL compiler exists in a world of several other compilers.
|
|
|
4980
|
|
|
4981 Differences to the Princeton compiler
|
|
|
4982 -------------------------------------
|
|
|
4983
|
|
|
4984 The Princeton compiler was the first INTERCAL compiler available, and
|
|
|
4985 compiled INTERCAL-72. Using `convickt' (*note convickt::) to translate
|
|
|
4986 its programs from the original EBCDIC to Latin-1 or Atari-syntax ASCII
|
|
|
4987 is required to run them under the C-INTERCAL compiler, but apart from
|
|
|
4988 that there should be no problems; everything that that compiler can do
|
|
|
4989 can be reproduced by C-INTERCAL, even including some of its bugs. The
|
|
|
4990 only potential problems may be where constructs were nonportable or
|
|
|
4991 dubious to begin with (such as the `IGNORE'/`RETRIEVE' interaction), or
|
|
|
4992 where commands intended to be syntax errors were used in the program
|
|
|
4993 but have a meaning in C-INTERCAL. For extra portability, it's possible
|
|
|
4994 to use the `-t' compiler option to `ick' (*note -t::) to tell it to
|
|
|
4995 interpret the program as INTERCAL-72, but as C-INTERCAL's dialect of
|
|
|
4996 INTERCAL is basically backward-compatible anyway this mostly serves to
|
|
|
4997 check newer programs for compatibility with older compilers.
|
|
|
4998
|
|
|
4999 Differences to the Atari compiler
|
|
|
5000 ---------------------------------
|
|
|
5001
|
|
|
5002 The Atari compiler was another implementation of INTERCAL-72, which was
|
|
|
5003 basically identical to the Princeton compiler apart from its use of
|
|
|
5004 ASCII and Atari syntax. Everything said under the previous section
|
|
|
5005 applies, except that as it uses the same syntax as C-INTERCAL anyway
|
|
|
5006 (C-INTERCAL's syntax was based on the Atari compiler's), there is no
|
|
|
5007 need to use `convickt'.
|
|
|
5008
|
|
|
5009 Differences to J-INTERCAL
|
|
|
5010 -------------------------
|
|
|
5011
|
|
|
5012 The J-INTERCAL compiler is an implementation of INTERCAL written in Java
|
|
|
5013 that compiles INTERCAL into Java (and so has a similar relationship
|
|
|
5014 with Java to that of the C-INTERCAL compiler (which is written in C and
|
|
|
5015 compiles into C) with C). J-INTERCAL has much the same feature set as
|
|
|
5016 older versions of C-INTERCAL, with a few changes (such as the addition
|
|
|
5017 of Esperanto and error messages coming up in different situations).
|
|
|
5018 J-INTERCAL programs should run fine on C-INTERCAL without trouble (as
|
|
|
5019 it is also an Atari syntax compiler), except in nonportable cases such
|
|
|
5020 as `IGNORE'/`RETRIEVE' interaction.
|
|
|
5021
|
|
|
5022 Differences to CLC-INTERCAL
|
|
|
5023 ---------------------------
|
|
|
5024
|
|
|
5025 The CLC-INTERCAL compiler is the most modern INTERCAL compiler apart
|
|
|
5026 from C-INTERCAL (both compilers are maintained and updated every now
|
|
|
5027 and then as of the time of writing, so which is more modern is normally
|
|
|
5028 a matter of when you happen to check). Unlike the other three compilers
|
|
|
5029 mentioned above, it has a quite significant feature set, including many
|
|
|
5030 features not implemented or only partially implemented in C-INTERCAL,
|
|
|
5031 and is responsible for the origin of many of the features added in more
|
|
|
5032 recent versions of C-INTERCAL. Generally speaking, a CLC-INTERCAL
|
|
|
5033 program that uses its advanced features is unlikely to run on
|
|
|
5034 C-INTERCAL, or vice versa, whatever you do (apart from completely
|
|
|
5035 rewriting the more advanced parts of the program.)
|
|
|
5036
|
|
|
5037 However, there are certain steps that can be taken to transfer less
|
|
|
5038 advanced programs from one compiler to the other. First, translate the
|
|
|
5039 program to Latin-1 Princeton syntax (if translating from CLC-INTERCAL
|
|
|
5040 to C-INTERCAL) or Atari syntax (if translating from C-INTERCAL to
|
|
|
5041 CLC-INTERCAL), maybe using `convickt', if necessary. (Note that here
|
|
|
5042 the program is being translated to the syntax that is not default for
|
|
|
5043 the target compiler.) Then use command-line arguments to switch the
|
|
|
5044 compiler into the correct emulation mode for the other compiler;
|
|
|
5045 C-INTERCAL uses the options `-xX', and on CLC-INTERCAL this is done by
|
|
|
5046 selecting the appropriate preloads, or by changing the program's file
|
|
|
5047 extension to `.ci'. In each case other options may be needed to turn
|
|
|
5048 on various extensions (maybe `-m' or `-v' if translating to C-INTERCAL,
|
|
|
5049 maybe the preload for gerund-based `COME FROM' if translating to
|
|
|
5050 CLC-INTERCAL), and if translating to CLC-INTERCAL you need to append
|
|
|
5051 the system library to your program yourself because CLC-INTERCAL
|
|
|
5052 doesn't load it automatically.
|
|
|
5053
|
|
|
5054 In the case of very simple programs, or if you want to spend the effort
|
|
|
5055 in translating compiler-specific code from one compiler to another, you
|
|
|
5056 may be able to work without emulation options. (This is a good target
|
|
|
5057 to aim for, in any case.) In such a case, you would do nothing other
|
|
|
5058 than possibly edit the program to be more portable and a possible
|
|
|
5059 character set and syntax change using `convickt'. If you need
|
|
|
5060 compiler-specific code, you may be able to detect the compiler in the
|
|
|
5061 code itself and adapt accordingly; making use of the
|
|
|
5062 `IGNORE'/`RETRIEVE' interaction is one way to do this, as it differs
|
|
|
5063 between C-INTERCAL, J-INTERCAL, and CLC-INTERCAL. The other things to
|
|
|
5064 watch out for when doing this are that CLC-INTERCAL needs an explicit
|
|
|
5065 option to enable the use of `NEXT', that CLC-INTERCAL doesn't load the
|
|
|
5066 system library itself (you need to manually append it to the end of the
|
|
|
5067 program) and that you probably shouldn't number a line (666) unless you
|
|
|
5068 know what you're doing, because that line number has a special meaning
|
|
|
5069 in CLC-INTERCAL.
|
|
|
5070
|
|
|
5071
|
|
|
5072 File: ick.info, Node: Character Sets, Next: convickt, Prev: Differences to Other Compilers, Up: Top
|
|
|
5073
|
|
|
5074 Appendix A Character Sets
|
|
|
5075 *************************
|
|
|
5076
|
|
|
5077 The following table explains the equivalences between the various
|
|
|
5078 character sets used for INTERCAL: 7-bit ASCII Atari syntax, 5-bit
|
|
|
5079 Baudot Princeton syntax, 8-bit EBCDIC Princeton syntax, and 8-bit
|
|
|
5080 Latin-1 Princeton syntax. (The Baudot and EBCDIC are the CLC-INTERCAL
|
|
|
5081 versions, which are used by INTERCAL compilers but basically nowhere
|
|
|
5082 else.) The characters themselves are not shown in the table below,
|
|
|
5083 because they would have to be shown in some syntax, which would be
|
|
|
5084 misleading. (Atari syntax is used throughout this manual; you could
|
|
|
5085 convert from that, assuming you have an ASCII table handy.) You can
|
|
|
5086 also use the `convickt' command-line tool to translate INTERCAL
|
|
|
5087 programs from one format to another (*note convickt::). Note that
|
|
|
5088 Baudot has more than one 'shift state'; the shift state (1, 2, 3, or 4)
|
|
|
5089 is written before the hexadecimal code for each character, and *
|
|
|
5090 represents a character available in every shift state. To change from
|
|
|
5091 one shift state to another, use character 1f to change from shift
|
|
|
5092 states 3 or 4 to 1, or from 1 or 2 to 2, and character 1b to change
|
|
|
5093 from shift states 1 or 2 to 3, or from 3 or 4 to 4.
|
|
|
5094
|
|
|
5095 Atari Baudot EBCDIC Latin-1
|
|
|
5096 ------------------------------------
|
|
|
5097 09 N/A 09 09
|
|
|
5098 0a * 02 0a 0a
|
|
|
5099 0d * 08 0d 0d
|
|
|
5100 20 * 04 40 20
|
|
|
5101 21 3 0d 4f 21
|
|
|
5102 22 3 11 7f 22
|
|
|
5103 23 4 06 7b 23
|
|
|
5104 24 4 01 4a a2
|
|
|
5105 25 4 1c 6c 25
|
|
|
5106 26 3 1a 50 26
|
|
|
5107 27 3 0b 7d 27
|
|
|
5108 28 3 0f 4d 28
|
|
|
5109 29 3 12 5d 29
|
|
|
5110 2a 4 09 5c 2a
|
|
|
5111 2b 4 03 4e 2b
|
|
|
5112 2c 3 0c 6b 2c
|
|
|
5113 2d 3 03 60 2d
|
|
|
5114 2e 3 1c 4b 2e
|
|
|
5115 2f 3 1d 61 2f
|
|
|
5116 30 3 16 f0 30
|
|
|
5117 31 3 17 f1 31
|
|
|
5118 32 3 13 f2 32
|
|
|
5119 33 3 01 f3 33
|
|
|
5120 34 3 0a f4 34
|
|
|
5121 35 3 10 f5 35
|
|
|
5122 36 3 15 f6 36
|
|
|
5123 37 3 07 f7 37
|
|
|
5124 38 3 06 f8 38
|
|
|
5125 39 3 18 f9 39
|
|
|
5126 3a 3 0e 7a 3a
|
|
|
5127 3b 3 1e 5e 3b
|
|
|
5128 3c 4 0f 4c 3c
|
|
|
5129 3d 4 07 7e 3d
|
|
|
5130 3e 4 12 6e 3e
|
|
|
5131 3f 4 0c 65 a5
|
|
|
5132 40 3 19 6f 3f
|
|
|
5133 41 1 03 c1 41
|
|
|
5134 42 1 19 c2 42
|
|
|
5135 43 1 0e c3 43
|
|
|
5136 44 1 09 c4 44
|
|
|
5137 45 1 01 c5 45
|
|
|
5138 46 1 0d c6 46
|
|
|
5139 47 1 1a c7 47
|
|
|
5140 48 1 14 c8 48
|
|
|
5141 49 1 06 c9 49
|
|
|
5142 4a 1 0b d1 4a
|
|
|
5143 4b 1 0f d2 4b
|
|
|
5144 4c 1 13 d3 4c
|
|
|
5145 4d 1 1c d4 4d
|
|
|
5146 4e 1 0c d5 4e
|
|
|
5147 4f 1 18 d6 4f
|
|
|
5148 50 1 16 d7 50
|
|
|
5149 51 1 17 d8 51
|
|
|
5150 52 1 0a d9 52
|
|
|
5151 53 1 05 e2 53
|
|
|
5152 54 1 10 e3 54
|
|
|
5153 55 1 07 e4 55
|
|
|
5154 56 1 1e e5 56
|
|
|
5155 57 1 12 e6 57
|
|
|
5156 58 1 1d e7 58
|
|
|
5157 59 1 15 e8 59
|
|
|
5158 5a 1 11 e9 5a
|
|
|
5159 5b 4 10 9e 5b
|
|
|
5160 5c 4 05 N/A 5c
|
|
|
5161 5d 4 13 5a 5d
|
|
|
5162 5e 4 0d 6a 7c
|
|
|
5163 5f 4 15 7c 40
|
|
|
5164 60 N/A N/A 60
|
|
|
5165 61 2 03 81 61
|
|
|
5166 62 2 19 82 62
|
|
|
5167 63 2 0e 83 63
|
|
|
5168 64 2 09 84 64
|
|
|
5169 65 2 01 85 65
|
|
|
5170 66 2 0d 86 66
|
|
|
5171 67 2 1a 87 67
|
|
|
5172 68 2 14 88 68
|
|
|
5173 69 2 06 89 69
|
|
|
5174 6a 2 0b 91 6a
|
|
|
5175 6b 2 0f 92 6b
|
|
|
5176 6c 2 13 93 6c
|
|
|
5177 6d 2 1c 94 6d
|
|
|
5178 6e 2 0c 95 6e
|
|
|
5179 6f 2 18 96 6f
|
|
|
5180 70 2 16 97 70
|
|
|
5181 71 2 17 98 71
|
|
|
5182 72 2 0a 99 72
|
|
|
5183 73 2 05 a2 73
|
|
|
5184 74 2 10 a3 74
|
|
|
5185 75 2 07 a4 75
|
|
|
5186 76 2 1e a5 76
|
|
|
5187 77 2 12 a6 77
|
|
|
5188 78 2 1d a7 78
|
|
|
5189 79 2 15 a8 79
|
|
|
5190 7a 2 11 a9 7a
|
|
|
5191 7b 4 0a 9c 7b
|
|
|
5192 7c 4 1e fe N/A
|
|
|
5193 7d 4 11 dc 7d
|
|
|
5194 7e 4 0b a1 7e
|
|
|
5195
|
|
|
5196
|
|
|
5197 File: ick.info, Node: convickt, Next: Optimizer Idiom Language, Prev: Character Sets, Up: Top
|
|
|
5198
|
|
|
5199 Appendix B convickt
|
|
|
5200 *******************
|
|
|
5201
|
|
|
5202 A variety of character sets have historically been used to represent
|
|
|
5203 INTERCAL programs. Atari syntax was designed specifically for use with
|
|
|
5204 ASCII-7, and all Atari-syntax-based INTERCAL compilers accept that
|
|
|
5205 character set as possible input. (C-INTERCAL also accepts Latin-1 and
|
|
|
5206 UTF-8.) However, the story is more complicated with Princeton syntax;
|
|
|
5207 the original Princeton compiler was designed to work with EBCDIC, but
|
|
|
5208 because modern computers are often not designed to work with this
|
|
|
5209 character set other character sets are often used to represent it,
|
|
|
5210 particularly Latin-1. The CLC-INTERCAL compiler accepts Latin-1, a
|
|
|
5211 custom dialect of EBCDIC, Baudot, and a punched-card format as input;
|
|
|
5212 C-INTERCAL can cope with Latin-1 Princeton syntax, but for the other
|
|
|
5213 character sets, for other compilers, or just for getting something
|
|
|
5214 human-readable, it's useful to have a conversion program. `convickt'
|
|
|
5215 is an INTERCAL character set conversion program designed with these
|
|
|
5216 needs in mind.
|
|
|
5217
|
|
|
5218 The syntax for using `convickt' is
|
|
|
5219
|
|
|
5220 convickt INPUTSET OUTPUTSET [PADDING]
|
|
|
5221
|
|
|
5222 (that is, the input and output character sets are compulsory, but the
|
|
|
5223 parameter specifying what sort of padding to use is optional).
|
|
|
5224
|
|
|
5225 The following values for INPUTSET and OUTPUTSET are permissible:
|
|
|
5226
|
|
|
5227 `latin1'
|
|
|
5228 Latin-1, or to give it its official name ISO-8859-1, is the
|
|
|
5229 character set most commonly used for transmitting CLC-INTERCAL
|
|
|
5230 programs, and therefore nowadays the most popular character set
|
|
|
5231 for Princeton syntax programs. Because it is identical to ASCII-7
|
|
|
5232 in all codepoints that don't have the high bit set, most of the
|
|
|
5233 characters in it can be read by most modern editors and terminals.
|
|
|
5234 It is also far more likely to be supported by modern editors than
|
|
|
5235 EBCDIC, Baudot, or punched cards, all of which have fallen into
|
|
|
5236 relative disuse since 1972. It is also the only input character
|
|
|
5237 set that C-INTERCAL supports for Princeton syntax programs. It
|
|
|
5238 uses 8 bit characters.
|
|
|
5239
|
|
|
5240 `ebcdic'
|
|
|
5241 EBCDIC is an 8-bit character set that was an alternative to ASCII
|
|
|
5242 in 1972, and is the character set used by the original Princeton
|
|
|
5243 compiler. Unfortunately, there is no single standard version; the
|
|
|
5244 version of EBCDIC used by `convickt' is the one that CLC-INTERCAL
|
|
|
5245 uses. It is the default input character set that CLC-INTERCAL uses
|
|
|
5246 (although more recent versions of CLC-INTERCAL instead try to
|
|
|
5247 guess the input character set based on the input program.)
|
|
|
5248
|
|
|
5249 `baudot'
|
|
|
5250 Baudot is a 5-bit character set with shift codes; therefore when
|
|
|
5251 storing it in a file on an 8-bit computer, padding is needed to
|
|
|
5252 fill in the remaining three bits. The standard Baudot character
|
|
|
5253 set does not contain all the characters needed by INTERCAL;
|
|
|
5254 therefore, CLC-INTERCAL uses repeated shift codes to add two more
|
|
|
5255 sets of characters. `convickt' uses the CLC-INTERCAL version of
|
|
|
5256 Baudot, so as to be able to translate programs designed for that
|
|
|
5257 compiler; however, standard Baudot is also accepted in input if it
|
|
|
5258 contains no redundant shift codes, and if the input contains no
|
|
|
5259 characters not in standard Baudot, the output will be written so
|
|
|
5260 that it is both correct standard Baudot and correct CLC-INTERCAL
|
|
|
5261 Baudot for those characters.
|
|
|
5262
|
|
|
5263 `atari'
|
|
|
5264 This option causes `convickt' to attempt a limited conversion to
|
|
|
5265 or from Atari syntax; this uses ASCII-7 as the character set, but
|
|
|
5266 also tries to translate between Atari and Princeton syntax at the
|
|
|
5267 character level, which is sometimes but not always effective. For
|
|
|
5268 instance, `?' is translated from Atari to Princeton as a yen sign,
|
|
|
5269 and from Princeton to Atari as a whirlpool (`@'); this sort of
|
|
|
5270 behaviour is often capable of translating expressions
|
|
|
5271 automatically, but will fail when characters outside ASCII-7
|
|
|
5272 (Atari) or Latin-1 (Princeton) are used, and will not, for
|
|
|
5273 instance, translate a Princeton `V', backspace, `-' into Atari
|
|
|
5274 `?', but instead leave it untouched. ASCII-7 is a 7-bit character
|
|
|
5275 set, so on an 8 bit computer, there is one bit of padding that
|
|
|
5276 needs to be generated; note, however, that it is usual nowadays to
|
|
|
5277 clear the top bit when transmitting ASCII-7, which the `printable'
|
|
|
5278 and `zero' padding styles will do, but the `random' style may not
|
|
|
5279 do.
|
|
|
5280
|
|
|
5281
|
|
|
5282 When using a character set where not all bits in each byte are
|
|
|
5283 specified, a third argument can be given to specify what sort of
|
|
|
5284 padding to use for the top bits of each character. There are three
|
|
|
5285 options for this:
|
|
|
5286
|
|
|
5287 Option Meaning
|
|
|
5288 -----------------------------------------------------------------
|
|
|
5289 printable Keep the output in the range 32-126 where possible
|
|
|
5290 zero Zero the high bits in the output
|
|
|
5291 random Pad with random bits (avoiding all-zero bytes)
|
|
|
5292
|
|
|
5293 Note that not all conversions are possible. If a character cannot be
|
|
|
5294 converted, it will normally be converted to a NUL byte (which is
|
|
|
5295 invalid in every character set); note that this will prevent
|
|
|
5296 round-tripping, because NUL is interpreted as end-of-input if given in
|
|
|
5297 the input. There is one exception; if the character that could not be
|
|
|
5298 converted is a tab character, it will be converted to the other
|
|
|
5299 character set's representation of a space character, if possible,
|
|
|
5300 because the two characters have the same meaning in INTERCAL (the only
|
|
|
5301 difference is if the command is a syntax error that's printed as an
|
|
|
5302 error message). (The exception exists to make it possible to translate
|
|
|
5303 existing INTERCAL source code into Baudot.)
|
|
|
5304
|
|
|
5305
|
|
|
5306 File: ick.info, Node: Optimizer Idiom Language, Next: Copying, Prev: convickt, Up: Top
|
|
|
5307
|
|
|
5308 Appendix C Optimizer Idiom Language
|
|
|
5309 ***********************************
|
|
|
5310
|
|
|
5311 One file in the C-INTERCAL distribution (`src/idiotism.oil') is written
|
|
|
5312 in Optimizer Idiom Language, a programming language designed especially
|
|
|
5313 for expressing optimizer idioms for INTERCAL in an easily editable form
|
|
|
5314 (well, at least it's easier than the unmaintainable set of idioms
|
|
|
5315 hard-coded in C that were used in previous versions of the INTERCAL
|
|
|
5316 compiler).
|
|
|
5317
|
|
|
5318 * Menu:
|
|
|
5319
|
|
|
5320 * Basics: OIL Basics. The basics of how an OIL program works.
|
|
|
5321 * Syntax: OIL Syntax. How to write comments, idioms, and groups.
|
|
|
5322 * Expressions: OIL Expressions. Expressions are the basis of idioms.
|
|
|
5323 * Patterns: OIL Patterns. Filling in the left hand side of an idiom.
|
|
|
5324 * Replacements: OIL Replacements. Syntax for the right hand side.
|
|
|
5325 * Loops: OIL Loops. Simplifying and shortening programs.
|
|
|
5326 * Tips: OIL Tips. Some tips about using OIL.
|
|
|
5327 * Example: OIL Example. An example of how OIL can work.
|
|
|
5328
|
|
|
5329
|
|
|
5330 File: ick.info, Node: OIL Basics, Next: OIL Syntax, Up: Optimizer Idiom Language
|
|
|
5331
|
|
|
5332 C.1 OIL Basics
|
|
|
5333 ==============
|
|
|
5334
|
|
|
5335 The structure of an OIL file consists of a sequence of idioms. An
|
|
|
5336 optimizer idiom looks for a certain pattern in an expression (which
|
|
|
5337 could be an INTERCAL expression, or an expression that has already been
|
|
|
5338 partly optimized and therefore contains some non-INTERCAL operators),
|
|
|
5339 and replaces it with a replacement that's `simpler' in some sense (in
|
|
|
5340 the case of C-INTERCAL, `simpler' is interpreted to mean `compiles into
|
|
|
5341 a faster or smaller executable when run through a C compiler'). When an
|
|
|
5342 OIL program acts on an input INTERCAL file, it keeps on matching idioms
|
|
|
5343 to simplify expressions, until none of the idioms act any more (and if
|
|
|
5344 a situation occurs where idioms can keep matching indefinitely, the
|
|
|
5345 compiler goes into an infinite loop; so don't allow that to happen); at
|
|
|
5346 present, the idioms are tried from left to right, from the leaves of an
|
|
|
5347 expression to its root, and from the start of the OIL file to the end;
|
|
|
5348 but don't rely on that, because it's subject to change (and gets
|
|
|
5349 confusing when you think about what happens when the program actually
|
|
|
5350 does a replacement). Anyway, the point is that if an idiom can match
|
|
|
5351 an expression, and another idiom doesn't change it first, then the
|
|
|
5352 idiom will be matched against that part of the expression eventually,
|
|
|
5353 and the program won't end until there are no idioms that match the
|
|
|
5354 optimized expression.
|
|
|
5355
|
|
|
5356 At present, the only place that OIL is used in the C-INTERCAL compiler
|
|
|
5357 is when the `-O' option (*note -O: -O+.) is used in base 2. (Syntax is
|
|
|
5358 planned to extend OIL to higher bases, and some of this is documented
|
|
|
5359 and even implemented, but there's no way to use it.) The idioms are
|
|
|
5360 read from the file `src/idiotism.oil' during the compilation of the
|
|
|
5361 C-INTERCAL from sources; you can change the idioms, but you will then
|
|
|
5362 have to recompile the distribution (and if you are using the
|
|
|
5363 `config.sh' method, also reinstall, but that will be pretty fast.)
|
|
|
5364
|
|
|
5365
|
|
|
5366 File: ick.info, Node: OIL Syntax, Next: OIL Expressions, Prev: OIL Basics, Up: Optimizer Idiom Language
|
|
|
5367
|
|
|
5368 C.2 OIL Syntax
|
|
|
5369 ==============
|
|
|
5370
|
|
|
5371 An OIL file is encoded as an ASCII text file using no codepoints
|
|
|
5372 outside the range 0-127; using 10 for newline (as on a UNIX or Linux
|
|
|
5373 system) is always acceptable, but using 13 then 10 (as is common on
|
|
|
5374 Windows or DOS) for newline is acceptable only if your C compiler
|
|
|
5375 recognizes that as a newline. I have no idea what happens if you use
|
|
|
5376 just 13 on an Apple computer on which that is the common newline
|
|
|
5377 convention.
|
|
|
5378
|
|
|
5379 Comments can be given anywhere in the file by writing lines starting
|
|
|
5380 with semicolons (known as hybrids to INTERCAL programmers). It's also
|
|
|
5381 possible to write a semicolon after part of a line to comment out the
|
|
|
5382 rest of the line. Inside braced C expressions, comments can be given
|
|
|
5383 anywhere whitespace would be allowed by placing them between `/*' and
|
|
|
5384 `*/' (in such cases, the comments will be copied verbatim to the C
|
|
|
5385 temporary files used when building the C-INTERCAL compiler, where your
|
|
|
5386 C compiler will ignore them). Whitespace is ignored nearly everywhere;
|
|
|
5387 the only places it isn't ignored are in the middle of a decimal
|
|
|
5388 constant, inside square brackets, immediately after one of the
|
|
|
5389 characters `.:#_}', and anywhere that C doesn't allow it in quoted C
|
|
|
5390 code. (This means that you can even place it inside operators like &&
|
|
|
5391 if you like, as long as they're part of OIL code and not C code,
|
|
|
5392 although doing this is not recommended.) If you use whitespace in a
|
|
|
5393 situation where it isn't ignored, that's almost certainly an error.
|
|
|
5394
|
|
|
5395 Idioms are grouped into groups of idioms by placing an identifier in
|
|
|
5396 square brackets before the group; this follows the rules for C
|
|
|
5397 identifiers, except that there's a maximum length of 30 characters.
|
|
|
5398 This identifier is the `name' of the group, which has no effect except
|
|
|
5399 on optimizer debug output; for that matter, the only effect a group has
|
|
|
5400 is that all idioms in the group look the same in optimizer debug output,
|
|
|
5401 because they have the same name. It's recommended that idioms only have
|
|
|
5402 the same name if they are the same idiom, possibly written in several
|
|
|
5403 ways. For example, a shift by 0 has no effect and may as well be
|
|
|
5404 removed from the output; the way to express this in OIL is:
|
|
|
5405
|
|
|
5406 [nullshift]
|
|
|
5407 (_1 >> #0)->(_1)
|
|
|
5408 (_1 << #0)->(_1)
|
|
|
5409
|
|
|
5410 Here, nullshift is the name of the group of idioms, and two idioms are
|
|
|
5411 given; one which removes a null rightshift, and one which removes a null
|
|
|
5412 leftshift.
|
|
|
5413
|
|
|
5414 As the example above shows, the syntax of an idiom itself is
|
|
|
5415
|
|
|
5416 (pattern)->(replacement)
|
|
|
5417
|
|
|
5418 The parentheses here are actually part of the pattern and/or
|
|
|
5419 replacement, and as such sparks (apostrophes) or rabbit-ears (double
|
|
|
5420 quotes) can be used instead; they're shown in the syntax because the
|
|
|
5421 outer layer of parenthesising is always required. Both the pattern and
|
|
|
5422 replacement are OIL expressions, although they both have their own
|
|
|
5423 special syntax elements as well.
|
|
|
5424
|
|
|
5425
|
|
|
5426 File: ick.info, Node: OIL Expressions, Next: OIL Patterns, Prev: OIL Syntax, Up: Optimizer Idiom Language
|
|
|
5427
|
|
|
5428 C.3 OIL Expressions
|
|
|
5429 ===================
|
|
|
5430
|
|
|
5431 An OIL expression is built around subexpressions connected by infix
|
|
|
5432 binary operators and/or preceded by prefix unary operators, the same
|
|
|
5433 way as in C or INTERCAL (although unary operators must be entirely
|
|
|
5434 before their argument; the one character later position is not allowed.)
|
|
|
5435 As in INTERCAL, there is no operator precedence; expressions must be
|
|
|
5436 very fully bracketed to show unambiguously what the precedences must
|
|
|
5437 be, and then more so; for instance, bracketing marks must be placed
|
|
|
5438 around the argument of a unary operator in most circumstances.
|
|
|
5439 Bracketing of expressions can be done with parentheses, sparks
|
|
|
5440 (apostrophes) or rabbit-ears (double-quotes).
|
|
|
5441
|
|
|
5442 The following unary and binary operators are allowed in OIL expressions:
|
|
|
5443
|
|
|
5444 `$' INTERCAL mingle
|
|
|
5445 `~' INTERCAL select
|
|
|
5446 `&16' INTERCAL unary AND (16-bit)
|
|
|
5447 `V16' INTERCAL unary OR (16-bit)
|
|
|
5448 `?16' INTERCAL unary XOR (16-bit)
|
|
|
5449 `^16' INTERCAL unary sharkfin (16-bit)
|
|
|
5450 `@16' INTERCAL unary whirlpool (16-bit)
|
|
|
5451 `@216..@516' INTERCAL unary generalised whirlpool (16-bit)
|
|
|
5452 `&32' INTERCAL unary AND (32-bit)
|
|
|
5453 `V32' INTERCAL unary OR (32-bit)
|
|
|
5454 `?32' INTERCAL unary XOR (32-bit)
|
|
|
5455 `^32' INTERCAL unary sharkfin (32-bit)
|
|
|
5456 `@32' INTERCAL unary whirlpool (32-bit)
|
|
|
5457 `@232..@532' INTERCAL unary generalised whirlpool (32-bit)
|
|
|
5458 `&' C binary bitwise AND
|
|
|
5459 `|' C binary bitwise OR
|
|
|
5460 `^' C binary bitwise XOR
|
|
|
5461 `+' C addition
|
|
|
5462 `-' C subtraction
|
|
|
5463 `*' C multiplication
|
|
|
5464 `/' C integer division
|
|
|
5465 `%' C modulus
|
|
|
5466 `>' C greater than
|
|
|
5467 `<' C less than
|
|
|
5468 `~' C unary bitwise complement
|
|
|
5469 `!=' C not equals operator
|
|
|
5470 `==' C equals operator
|
|
|
5471 `&&' C logical AND
|
|
|
5472 `||' C logical OR
|
|
|
5473 `>>' C bitwise rightshift
|
|
|
5474 `<<' C bitwise leftshift
|
|
|
5475 `!' C unary logical NOT
|
|
|
5476
|
|
|
5477 (Note that in some cases two operators are expressed the same way, but
|
|
|
5478 that this doesn't matter because one is unary and the other is binary so
|
|
|
5479 that there can't be any ambiguity, only confusion. Also note that
|
|
|
5480 unlike INTERCAL unary logic operators, OIL unary logic operators must
|
|
|
5481 have a bitwidth stated.)
|
|
|
5482
|
|
|
5483 It hasn't yet been explained what operands these operators have to
|
|
|
5484 operate on; the syntax for those depends on whether it's a pattern or
|
|
|
5485 replacement that the expression is representing.
|
|
|
5486
|
|
|
5487
|
|
|
5488 File: ick.info, Node: OIL Patterns, Next: OIL Replacements, Prev: OIL Expressions, Up: Optimizer Idiom Language
|
|
|
5489
|
|
|
5490 C.4 OIL Patterns
|
|
|
5491 ================
|
|
|
5492
|
|
|
5493 Patterns are simply OIL expressions; the expressions match either
|
|
|
5494 original INTERCAL input or expressions produced by earlier idioms.
|
|
|
5495 Each operator must match the same operator in the (possibly
|
|
|
5496 partially-optimised) input; the operands themselves are pattern
|
|
|
5497 templates specifying what operands in the input they can match.
|
|
|
5498
|
|
|
5499 One special simple form of match is possible: `#NUMBER', where NUMBER
|
|
|
5500 is in decimal, matches a constant with that value. (Unlike in
|
|
|
5501 INTERCAL, this constant is not limited to being a onespot value; it is,
|
|
|
5502 however, limited to being at most twospot, as are all operands and
|
|
|
5503 intermediate values in OIL.)
|
|
|
5504
|
|
|
5505 Otherwise, an operand consists of the following parts, written in order:
|
|
|
5506
|
|
|
5507 1. A character to specify the data type of what's being matched.
|
|
|
5508 Usually, this will be `_' to specify that any data type can be
|
|
|
5509 matched. In a few cases, you may want to use `.' or `:' to
|
|
|
5510 specify that you only want to match a onespot or twospot value
|
|
|
5511 respectively (that is, 16- or 32-bit). You can also use `#'; this
|
|
|
5512 specifies a value that can be any width, but must be known to be a
|
|
|
5513 constant with a known value at optimize time (either because it
|
|
|
5514 was hardcoded as a constant originally or because a constant was
|
|
|
5515 produced there by the optimizer, for instance via a constant
|
|
|
5516 folding optimization).
|
|
|
5517
|
|
|
5518 2. Optionally, an expression in braces (`{' and `}'). This
|
|
|
5519 expression is written in C, not OIL (as are all expressions in
|
|
|
5520 braces), and puts an extra condition on whether the pattern
|
|
|
5521 matches. The exact meaning of this will be explained later.
|
|
|
5522
|
|
|
5523 3. A reference number, which must be one decimal digit long. A
|
|
|
5524 reference number of 0 causes the operand to be discarded
|
|
|
5525 immediately after matching; normally, you will want to specify a
|
|
|
5526 positive reference number. Two operands with the same reference
|
|
|
5527 number must be exactly the same for the pattern to match (for
|
|
|
5528 instance, both references to the same variable, or identical
|
|
|
5529 subexpressions). The reference number also allows the operand to
|
|
|
5530 be referenced by C expressions on other operands and by
|
|
|
5531 replacements. Reference numbers must be unique within the idiom
|
|
|
5532 (unless two or reference numbers are deliberately the same so that
|
|
|
5533 the operands they reference have to be identical to produce a
|
|
|
5534 match), and they are scoped only as far as the containing idiom;
|
|
|
5535 they don't carry from one idiom to another.
|
|
|
5536
|
|
|
5537
|
|
|
5538 Note that syntax like `#2' is ambiguous given what comes so far; the
|
|
|
5539 first interpretation is the one that is taken in practice, and if the
|
|
|
5540 second interpretation is wanted the operand should be expressed as
|
|
|
5541 `#{1}2', using a no-op braced expression to tell them apart. This
|
|
|
5542 particular no-op is recommended because it's detected and optimized by
|
|
|
5543 the `OIL' compiler.
|
|
|
5544
|
|
|
5545 Braced expressions, which must be written purely in C, add extra
|
|
|
5546 conditions; they must return nonzero to allow a possible match or zero
|
|
|
5547 to prevent one. They can reference the following variables and
|
|
|
5548 functions:
|
|
|
5549
|
|
|
5550 `c'
|
|
|
5551 `cNUMBER'
|
|
|
5552 This accesses a calculation made automatically by the compiled OIL
|
|
|
5553 program to identify which bits of the operand can possibly be set,
|
|
|
5554 and which ones cannot be. `c' by itself refers to the operand to
|
|
|
5555 which the braced expression is attached; if a number is given, it
|
|
|
5556 refers to another node (the number is interpreted as a reference
|
|
|
5557 number). The actual value of `c' is a 32-bit unsigned integer,
|
|
|
5558 each bit of which is true, or 1, if there is any chance that the
|
|
|
5559 corresponding bit of the operand might be 1, and false, or 0, if
|
|
|
5560 it's known for certain that the corresponding bit of the operand
|
|
|
5561 is 0.
|
|
|
5562
|
|
|
5563 For instance:
|
|
|
5564
|
|
|
5565 _{!(c&4294901760LU)}1
|
|
|
5566
|
|
|
5567 The constant given here is FFFF0000 when expressed in hexadecimal;
|
|
|
5568 the point is that the expression matches any operand that is known
|
|
|
5569 to have a value no greater than 65535. Unless the operand is the
|
|
|
5570 argument to a unary AND, this check generally makes more sense
|
|
|
5571 than explicitly specifying `.' rather than `_', because it will
|
|
|
5572 identify both 16- and 32-bit values as long as they're small
|
|
|
5573 enough to fit into a onespot variable. This code could, for
|
|
|
5574 instance, be used to check that an argument to a mingle must be
|
|
|
5575 small enough before optimising it (this is important because an
|
|
|
5576 optimisation shouldn't optimise an error - in this case, an
|
|
|
5577 overflowing mingle - into a non-error).
|
|
|
5578
|
|
|
5579 `x'
|
|
|
5580 `xNUMBER'
|
|
|
5581 `x' is like `c', and refers to operands in the same way, except
|
|
|
5582 that it can only refer to an operand marked with `#'. It holds
|
|
|
5583 the value of that constant (a 32-bit unsigned integer), which will
|
|
|
5584 be known to the optimizer at optimize time. One common use of
|
|
|
5585 this is to detect whether a constant happens to be a power of 2,
|
|
|
5586 although there are many other possibilities that may be useful.
|
|
|
5587
|
|
|
5588 `r'
|
|
|
5589 When inside a loop, `r' is the value of the loop counter. (It's
|
|
|
5590 almost certainly a mistake if you have a loop but don't reference
|
|
|
5591 the loop counter at least once, and usually at least twice, within
|
|
|
5592 the loop.) *Note OIL Loops::.
|
|
|
5593
|
|
|
5594 `and16'
|
|
|
5595 `and32'
|
|
|
5596 `or16'
|
|
|
5597 `or32'
|
|
|
5598 `xor16'
|
|
|
5599 `xor32'
|
|
|
5600 `iselect'
|
|
|
5601 `mingle'
|
|
|
5602 These are all functions with one argument (apart from iselect and
|
|
|
5603 mingle, which each take two arguments); they exist so that INTERCAL
|
|
|
5604 operators can be used by C expressions. They all take unsigned
|
|
|
5605 longs as input and output, even if they are onespot operators.
|
|
|
5606 Note that it's entirely possible for these to cause a compile-time
|
|
|
5607 error if used on invalid arguments (such as mingling with an
|
|
|
5608 operand over 65535), or to silently truncate an invalid argument
|
|
|
5609 down to the right number of bits; both of these should be avoided
|
|
|
5610 if possible, so the optimiser should check first to make sure that
|
|
|
5611 it doesn't use any of these functions on invalid arguments.
|
|
|
5612
|
|
|
5613 `xselx'
|
|
|
5614 This function returns its argument selected with itself; so
|
|
|
5615 `xselx(c)' is shorthand for `iselect(c,c)'. When the argument is
|
|
|
5616 very complicated, this can save a lot of space in the original OIL
|
|
|
5617 program.
|
|
|
5618
|
|
|
5619 `setbitcount'
|
|
|
5620 This function simply returns the number of bits with value 1 in its
|
|
|
5621 argument. This is sometimes useful with respect to various
|
|
|
5622 select-related optimisations, and can be a useful alternative to
|
|
|
5623 having to take logarithms in various situations.
|
|
|
5624
|
|
|
5625 `smudgeright'
|
|
|
5626 `smudgeleft'
|
|
|
5627 The `smudgeright' function returns its argument but with all the
|
|
|
5628 bits less significant than the most significant bit with value 1
|
|
|
5629 set to 1; likewise, `smudgeleft' returns its argument with all the
|
|
|
5630 bits more significant than the least significant bit with value 1
|
|
|
5631 set to 1.
|
|
|
5632
|
|
|
5633
|
|
|
5634 Note that all OIL character is done internally using unsigned 32-bit
|
|
|
5635 numbers, and C expressions you write should do the same. The practical
|
|
|
5636 upshot of this is that you should write `LU' after any constant you
|
|
|
5637 write in C code; if you don't do this, you are reasonably likely to get
|
|
|
5638 compiler warnings, and the resulting program may not work reliably,
|
|
|
5639 although the OIL compiler itself will not complain.
|
|
|
5640
|
|
|
5641 Here's a more complicated example of an optimizer operand:
|
|
|
5642
|
|
|
5643 #{!(x&2863311530LU)&&iselect(x,1431655765LU)==
|
|
|
5644 xselx(iselect(x,1431655765LU))}3
|
|
|
5645
|
|
|
5646 It helps to understand this if you know that 2863311530 in hexadecimal
|
|
|
5647 is AAAAAAAA and 1431655765 in hexadecimal is 55555555. (It's worth
|
|
|
5648 putting a comment with some frequently-used decimal constants in an OIL
|
|
|
5649 input file to help explain what these numbers mean and make the code
|
|
|
5650 more maintainable.) The operand matches any constant integer which has
|
|
|
5651 no bits in common with AAAAAAAA, and for which if any bit in common
|
|
|
5652 with 55555555 is set, all less significant bits in common with that
|
|
|
5653 number are also set.
|
|
|
5654
|
|
|
5655
|
|
|
5656 File: ick.info, Node: OIL Replacements, Next: OIL Loops, Prev: OIL Patterns, Up: Optimizer Idiom Language
|
|
|
5657
|
|
|
5658 C.5 OIL Replacements
|
|
|
5659 ====================
|
|
|
5660
|
|
|
5661 Replacements have much the same syntax as patterns. The expressions are
|
|
|
5662 parsed in much the same way; however, one peculiarity of replacements is
|
|
|
5663 that bitwidths must be specified. INTERCAL has a typecaster that
|
|
|
5664 figures out whether each expression is 16 bits or 32 bits wide, but it
|
|
|
5665 runs before the optimizer, and as the optimizer can produce expressions
|
|
|
5666 whose bitwidths don't obey INTERCAL's rules, this information needs to
|
|
|
5667 be inserted somehow in a replacement. In C-INTERCAL, it usually
|
|
|
5668 doesn't matter what the bitwidth is, and in cases where it doesn't
|
|
|
5669 matter the normal operators (`$', `~', and so on) can be used. (Note
|
|
|
5670 that the bit width of the entire replacement is always set to the same
|
|
|
5671 bit width as the bit width of the expression matched by the pattern; so
|
|
|
5672 you don't have to worry about the effect on unary logical operators
|
|
|
5673 that might be operating on the expression being optimized. This is an
|
|
|
5674 exception to the normal bitwidth rules for a replacement.) In cases
|
|
|
5675 where it does matter (due to C-INTERCAL's lenient interpretation of
|
|
|
5676 bitwidth on mingle inputs, the only place it matters is in the input to
|
|
|
5677 INTERCAL unary logical operators), both the bitwidth of the operator
|
|
|
5678 and the argument on which it operates must be explicitly given, and
|
|
|
5679 given as the same value; to set the bitwidth of an operator's result,
|
|
|
5680 simply write the bitwidth (16 or 32 for onespot and twospot
|
|
|
5681 respectively) immediately after the operator; for instance, `!=32' will
|
|
|
5682 generate a not-equals operation with a 32-bit bitwidth. If an
|
|
|
5683 operator's width is set to 16, and during the course of execution of
|
|
|
5684 the optimized program, a value that doesn't fit into 16 bits is
|
|
|
5685 encountered, that's undefined behaviour and anything might happen (most
|
|
|
5686 likely, though, the program will just act as though its width had been
|
|
|
5687 set to 32 bits instead); this error condition is not detected. Also
|
|
|
5688 note that operators like `&32' already have a bitwidth specified, so
|
|
|
5689 specifying `&3232' (or worse, `&3216') is not allowed.
|
|
|
5690
|
|
|
5691 Replacement operands are simpler than pattern operands, because there
|
|
|
5692 are only a few forms they can take.
|
|
|
5693
|
|
|
5694 `_NUMBER'
|
|
|
5695 `.NUMBER'
|
|
|
5696 `:NUMBER'
|
|
|
5697 This tells the optimiser to copy the operand or expression with
|
|
|
5698 reference number NUMBER to this point in the replacement used for
|
|
|
5699 the expression matched by the pattern. The three forms are
|
|
|
5700 identical; the last two are provided for aesthetic reasons (it can
|
|
|
5701 look better and be clearer to match `.1' in the pattern with `.1'
|
|
|
5702 in the replacement, for instance). You cannot use `#NUMBER' here
|
|
|
5703 to copy in a constant from the left-hand side, though, nor
|
|
|
5704 `#{1}NUMBER', because the first means something else and the
|
|
|
5705 second is undefined behaviour (that is, no behaviour for the second
|
|
|
5706 case has been specifically implemented in the compiler and
|
|
|
5707 therefore its behaviour is unpredictable and subject to change in
|
|
|
5708 future versions); use `_NUMBER' to copy over a constant with an
|
|
|
5709 unknown at optimizer compile time (but known at optimize time)
|
|
|
5710 value from the left hand side, as you can do with any other
|
|
|
5711 operand being copied.
|
|
|
5712
|
|
|
5713 `#NUMBER'
|
|
|
5714 Insert a constant with the literal value NUMBER here.
|
|
|
5715
|
|
|
5716 `#{EXPRESSION}0'
|
|
|
5717 Calculate the value of EXPRESSION (a C expression, which can
|
|
|
5718 reference the same variables and functions as a C expression in a
|
|
|
5719 pattern can; see *note C functions in OIL::) and insert a constant
|
|
|
5720 with the calculated value here. (That is, a value is calculated at
|
|
|
5721 optimise-time and the resulting value is therefore constant at
|
|
|
5722 runtime.)
|
|
|
5723
|
|
|
5724
|
|
|
5725 As an example, here's an idiom that moves C bitwise AND operations
|
|
|
5726 inside leftshifts. (This is useful because if the optimizer has
|
|
|
5727 generated a large sequence of mixed ANDs and bitshifts, moving all the
|
|
|
5728 ANDs to one end allows them to be clumped together and optimized down to
|
|
|
5729 one AND, whilst the shifts can all be combined into one large shift.)
|
|
|
5730
|
|
|
5731 ((_1 << #{1}2) & #{1}3)->((_1 & #{x3>>x2}0) << _2)
|
|
|
5732
|
|
|
5733
|
|
|
5734 File: ick.info, Node: OIL Loops, Next: OIL Tips, Prev: OIL Replacements, Up: Optimizer Idiom Language
|
|
|
5735
|
|
|
5736 C.6 OIL Loops
|
|
|
5737 =============
|
|
|
5738
|
|
|
5739 When writing idioms, sometimes instead of using very complicated
|
|
|
5740 expressions to try to match multiple situations at once it's easier to
|
|
|
5741 have a separate idiom for each possible situation; for instance, it's
|
|
|
5742 easier to write idioms for right-shift by 1, right-shift by 2,
|
|
|
5743 right-shift by 3, etc., rather than a general idiom to rightshift by any
|
|
|
5744 amount. When the idioms follow a pattern, as they will do in basically
|
|
|
5745 every case of this sort, it's possible to automatically generate them
|
|
|
5746 using a loop. For instance, idioms to optimize a one-bit rightshift
|
|
|
5747 and a two-bit rightshift are:
|
|
|
5748
|
|
|
5749 (_1~#{xselx(x)<<1==x&&x}2)->((_1&_2)>>#1)
|
|
|
5750 (_1~#{xselx(x)<<2==x&&x}2)->((_1&_2)>>#2)
|
|
|
5751
|
|
|
5752 Adding a loop to automatically generate the idioms, and placing a name
|
|
|
5753 for the group of idioms at the start, produces the following code:
|
|
|
5754
|
|
|
5755 [rshift]
|
|
|
5756 <#1-#31
|
|
|
5757 (_1~#{xselx(x)<<r==x&&x}2)->((_1&_2)>>#{r}0)
|
|
|
5758 >
|
|
|
5759
|
|
|
5760 That's 31 different idioms, generated with a loop. As the above example
|
|
|
5761 shows, a loop starts with `<#NUMBER-#NUMBER' and ends with `>'; a
|
|
|
5762 different idiom is generated for each possible value of the loop
|
|
|
5763 counter `r' in the range given by the opening line of the loop. Loops
|
|
|
5764 must be placed around idioms, but inside a group of idioms. Note the
|
|
|
5765 use of `#{r}0' to generate a constant whose value is equal to the value
|
|
|
5766 of the loop counter.
|
|
|
5767
|
|
|
5768
|
|
|
5769 File: ick.info, Node: OIL Tips, Next: OIL Example, Prev: OIL Loops, Up: Optimizer Idiom Language
|
|
|
5770
|
|
|
5771 C.7 OIL Tips
|
|
|
5772 ============
|
|
|
5773
|
|
|
5774 Here are some tips for the best use of OIL:
|
|
|
5775
|
|
|
5776 * The OIL compiler has a few deficiencies, such as error messages
|
|
|
5777 that don't give you much of an idea of what you did wrong (to
|
|
|
5778 compensate for this, it does give a reasonably accurate line and
|
|
|
5779 character number where the error happened), limits on things like
|
|
|
5780 how deep expressions can be nested and how many idioms are allowed
|
|
|
5781 (if you hit the first, you should really break it up into smaller
|
|
|
5782 idioms if possible, and if you hit the second, increase
|
|
|
5783 `MAXTOFREE' in oil.y; this isn't a limit on the number of idioms
|
|
|
5784 but on the number of strings that are allocated internally to
|
|
|
5785 process the idioms), and lack of error checking (invalid OIL may
|
|
|
5786 produce errors in the OIL compiler, or cause the output C code to
|
|
|
5787 contain errors or warnings, or may even appear to work).
|
|
|
5788
|
|
|
5789 * When you have symmetrical operators in an idiom (like C binary
|
|
|
5790 logical operators), you need to write the idiom both ways round
|
|
|
5791 (in the same group of idioms, preferably), or write another idiom
|
|
|
5792 to standardise the format first; the first method can get very
|
|
|
5793 tedious when there are many symmetrical operators in an idiom, and
|
|
|
5794 the second is prone to optimizer loops and subtle errors (both
|
|
|
5795 methods have been used in the provided `idiotism.oil' file.)
|
|
|
5796
|
|
|
5797 * Idioms should preferably be as general as possible, broken down
|
|
|
5798 into many separate idioms rather than all as one big idiom, and
|
|
|
5799 match the smallest part of the expression being optimized that is
|
|
|
5800 necessary for the idiom to be correct in all circumstances; all of
|
|
|
5801 these help to improve the performance of the optimizer in terms of
|
|
|
5802 what it can optimize.
|
|
|
5803
|
|
|
5804 * If a program's optimizing incorrectly, or you just want to see how
|
|
|
5805 the optimizer deals with a particular program, it's possible to
|
|
|
5806 debug the optimizer by giving the `-h', `-H', or `-hH' (*note
|
|
|
5807 -h::) switch to the C-INTERCAL compiler, which will cause debug
|
|
|
5808 information to be output on stderr. `-h' will show the initial
|
|
|
5809 and final expressions for each expression that was given as input
|
|
|
5810 to the optimizer, as well as a list of all optimizations used, in
|
|
|
5811 a language that's a sort of mix of C, INTERCAL, and OIL; `-H' will
|
|
|
5812 do the same, and also show the intermediate stages in the
|
|
|
5813 optimization. `-hH' is like `-H', but produces its output
|
|
|
5814 entirely in C, so that the various intermediate stages can be
|
|
|
5815 tried with a C compiler, or for people who are fed up of reading
|
|
|
5816 INTERCAL. `-H' can be a useful learning resource for people who
|
|
|
5817 want to understand how a particular INTERCAL expression works.
|
|
|
5818
|
|
|
5819 * Make sure that the optimizer doesn't change a statement from a
|
|
|
5820 run-time error into something that silently succeeds! Checking
|
|
|
5821 which bits can and can't be 1 is one good way to avoid this,
|
|
|
5822 especially with mingles. (At present, there are some idioms that
|
|
|
5823 can turn run-time errors into compile-time errors, such as with
|
|
|
5824 the expression `''#65535$#65535'$#0''; this could be avoided, but
|
|
|
5825 for the time being it isn't.)
|
|
|
5826
|
|
|
5827 * You can help! If you find an idiom that the optimizer isn't
|
|
|
5828 optimizing correctly, feel free to add it, or multiple idioms that
|
|
|
5829 come to the same thing, to `idiotism.oil'. In such a case, it
|
|
|
5830 would help other users if you would submit your new optimizer
|
|
|
5831 idiom to the project (*note Reporting Bugs::); this will help
|
|
|
5832 other users and future releases of INTERCAL, and also has a chance
|
|
|
5833 of allowing other users to check your new idioms to see if they
|
|
|
5834 cause problems or could be written better.
|
|
|
5835
|
|
|
5836
|
|
|
5837
|
|
|
5838 File: ick.info, Node: OIL Example, Prev: OIL Tips, Up: Optimizer Idiom Language
|
|
|
5839
|
|
|
5840 C.8 OIL Example
|
|
|
5841 ===============
|
|
|
5842
|
|
|
5843 To finish off this appendix, here's an example of the power of OIL;
|
|
|
5844 this is the optimization of an idiom from the INTERCAL-72 system
|
|
|
5845 library, as shown with `-H'; this should give a good idea of how OIL
|
|
|
5846 programs work. (All the relevant idioms are in `idiotism.oil' as of
|
|
|
5847 the time of writing.) Note how the expression is reduced one small
|
|
|
5848 step at a time; the smallness of the steps makes the optimizer more
|
|
|
5849 general, because if the original expression had been slightly
|
|
|
5850 different, the optimizer wouldn't have come to the same result but
|
|
|
5851 could have optimized it quite a bit of the way, up to the point where
|
|
|
5852 the optimizations were no longer valid; in an older version of
|
|
|
5853 INTERCAL, this idiom was simply hardcoded as a special case and so
|
|
|
5854 slight variations of it weren't optimized at all. If you look at the
|
|
|
5855 idioms themselves, it'll also be apparent how `c' (the record of which
|
|
|
5856 bits of an expression can be 1 and which bits can't be) is important
|
|
|
5857 information in being able to apply an optimization more aggressively.
|
|
|
5858
|
|
|
5859 .3 <- ((((((((.3 $ 0x0) ~ (0x7fff $ 0x1)) $ 0x0) ~ (0x7fff $ 0x1))
|
|
|
5860 $ 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5861 [minglefold]
|
|
|
5862 .3 <- ((((((((.3 $ 0x0) ~ 0x2aaaaaab) $ 0x0) ~ (0x7fff $ 0x1)) $
|
|
|
5863 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5864 [lshift16]
|
|
|
5865 .3 <- ((((((((((.3 >> 0x0) & 0x7fff) << 0x1) | 0x0) $ 0x0) ~
|
|
|
5866 (0x7fff $ 0x1)) $ 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5867 [noopor]
|
|
|
5868 .3 <- (((((((((.3 >> 0x0) & 0x7fff) << 0x1) $ 0x0) ~ (0x7fff $
|
|
|
5869 0x1)) $ 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5870 [minglefold]
|
|
|
5871 .3 <- (((((((((.3 >> 0x0) & 0x7fff) << 0x1) $ 0x0) ~ 0x2aaaaaab) $
|
|
|
5872 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5873 [lshift16]
|
|
|
5874 .3 <- (((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff) <<
|
|
|
5875 0x1) | 0x0) $ 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5876 [noopor]
|
|
|
5877 .3 <- ((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff) <<
|
|
|
5878 0x1) $ 0x0) ~ (0x3fff $ 0x3)) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5879 [minglefold]
|
|
|
5880 .3 <- ((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff) <<
|
|
|
5881 0x1) $ 0x0) ~ 0xaaaaaaf) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5882 [lshift16]
|
|
|
5883 .3 <- ((((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff)
|
|
|
5884 << 0x1) >> 0x1) & 0x1fff) << 0x3) | 0x0) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5885 [noopor]
|
|
|
5886 .3 <- (((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff) <<
|
|
|
5887 0x1) >> 0x1) & 0x1fff) << 0x3) $ 0x0) ~ (0xfff $ 0xf))
|
|
|
5888 [minglefold]
|
|
|
5889 .3 <- (((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff) <<
|
|
|
5890 0x1) >> 0x1) & 0x1fff) << 0x3) $ 0x0) ~ 0xaaaaff)
|
|
|
5891 [lshift16]
|
|
|
5892 .3 <- (((((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff)
|
|
|
5893 << 0x1) >> 0x1) & 0x1fff) << 0x3) >> 0x3) & 0x1ff) << 0x7) | 0x0)
|
|
|
5894 [noopor]
|
|
|
5895 .3 <- ((((((((((((.3 >> 0x0) & 0x7fff) << 0x1) >> 0x0) & 0x7fff)
|
|
|
5896 << 0x1) >> 0x1) & 0x1fff) << 0x3) >> 0x3) & 0x1ff) << 0x7)
|
|
|
5897 [nullshift]
|
|
|
5898 .3 <- (((((((((((.3 & 0x7fff) << 0x1) >> 0x0) & 0x7fff) << 0x1) >>
|
|
|
5899 0x1) & 0x1fff) << 0x3) >> 0x3) & 0x1ff) << 0x7)
|
|
|
5900 [combinelrshift]
|
|
|
5901 .3 <- ((((((((((.3 & 0x7fff) << 0x1) & 0x7fff) << 0x1) >> 0x1) &
|
|
|
5902 0x1fff) << 0x3) >> 0x3) & 0x1ff) << 0x7)
|
|
|
5903 [andintolshift]
|
|
|
5904 .3 <- ((((((((((.3 & 0x7fff) & 0x3fff) << 0x1) << 0x1) >> 0x1) &
|
|
|
5905 0x1fff) << 0x3) >> 0x3) & 0x1ff) << 0x7)
|
|
|
5906 [combinellshift]
|
|
|
5907 .3 <- (((((((((.3 & 0x7fff) & 0x3fff) << 0x2) >> 0x1) & 0x1fff) <<
|
|
|
5908 0x3) >> 0x3) & 0x1ff) << 0x7)
|
|
|
5909 [combinelrshift]
|
|
|
5910 .3 <- ((((((((.3 & 0x7fff) & 0x3fff) << 0x1) & 0x1fff) << 0x3) >>
|
|
|
5911 0x3) & 0x1ff) << 0x7)
|
|
|
5912 [andintolshift]
|
|
|
5913 .3 <- ((((((((.3 & 0x7fff) & 0x3fff) & 0xfff) << 0x1) << 0x3) >>
|
|
|
5914 0x3) & 0x1ff) << 0x7)
|
|
|
5915 [combinellshift]
|
|
|
5916 .3 <- (((((((.3 & 0x7fff) & 0x3fff) & 0xfff) << 0x4) >> 0x3) &
|
|
|
5917 0x1ff) << 0x7)
|
|
|
5918 [combinelrshift]
|
|
|
5919 .3 <- ((((((.3 & 0x7fff) & 0x3fff) & 0xfff) << 0x1) & 0x1ff) <<
|
|
|
5920 0x7)
|
|
|
5921 [andintolshift]
|
|
|
5922 .3 <- ((((((.3 & 0x7fff) & 0x3fff) & 0xfff) & 0xff) << 0x1) << 0x7)
|
|
|
5923 [combinellshift]
|
|
|
5924 .3 <- (((((.3 & 0x7fff) & 0x3fff) & 0xfff) & 0xff) << 0x8)
|
|
|
5925 [combineand]
|
|
|
5926 .3 <- ((((.3 & 0x3fff) & 0xfff) & 0xff) << 0x8)
|
|
|
5927 [combineand]
|
|
|
5928 .3 <- (((.3 & 0xfff) & 0xff) << 0x8)
|
|
|
5929 [combineand]
|
|
|
5930 .3 <- ((.3 & 0xff) << 0x8)
|
|
|
5931
|
|
|
5932
|
|
|
5933 File: ick.info, Node: Copying, Next: Main Index, Prev: Optimizer Idiom Language, Up: Top
|
|
|
5934
|
|
|
5935 Appendix D Copying
|
|
|
5936 ******************
|
|
|
5937
|
|
|
5938 The majority of the files in the C-INTERCAL distribution are licensed
|
|
|
5939 under the GNU General Public License (version 2 or later), but with
|
|
|
5940 some exceptions. The files `ick-wrap.c' and `pickwrap.c' are licensed
|
|
|
5941 under a license that allows them to be used for any purpose and
|
|
|
5942 redistributed at will, and are explicitly not GPL'd. This means that C
|
|
|
5943 source code generated by the compiler has the same copyright conditions
|
|
|
5944 as the original INTERCAL source. (Note that the libraries `libick.a'
|
|
|
5945 and `libickmt.a' are GPL, though, so you cannot redistribute an
|
|
|
5946 executable produced by `ick' or by linking a C file to either of those
|
|
|
5947 libraries unless the original INTERCAL source was GPL.) For similar
|
|
|
5948 reasons, the expansion libraries `syslibc.c' and `compunex.c'
|
|
|
5949 (currently the only ones in the distribution) is explicitly public
|
|
|
5950 domain. Also, this manual, and the files that are the source code for
|
|
|
5951 creating it, are licensed under the GNU Free Documentation License
|
|
|
5952 rather than the GPL, and the licenses themselves (`fdl-1-2.txi' and
|
|
|
5953 `COPYING.txt') are licensed under a license that allows verbatim
|
|
|
5954 redistribution but not creation of derivative works. All other files,
|
|
|
5955 though (including the `man' pages, which are not part of _this_
|
|
|
5956 manual), are licensed under the GPL. For the full text of the GPL, see
|
|
|
5957 the file `COPYING.txt' in the distribution.
|
|
|
5958
|
|
|
5959 * Menu:
|
|
|
5960
|
|
|
5961 * GNU Free Documentation License:: License for copying this manual.
|
|
|
5962
|
|
|
5963
|
|
|
5964
|
|
|
5965 Local Variables:
|
|
|
5966 coding: iso-8859-1
|
|
|
5967 End:
|
