Next: Character Sets, Previous: External Calls, Up: Top [Index]
The C-INTERCAL compiler exists in a world of several other compilers.
The Princeton compiler was the first INTERCAL
compiler available, and compiled INTERCAL-72. Using
convickt
(see convickt) to translate its programs from
the original EBCDIC to Latin-1 or Atari-syntax ASCII is required to run
them under the C-INTERCAL compiler, but apart from that
there should be no problems; everything that that compiler can do can
be reproduced by C-INTERCAL, even including some of its
bugs. The only potential problems may be where constructs were
nonportable or dubious to begin with (such as the
IGNORE
/RETRIEVE
interaction), or where
commands intended to be syntax errors were used in the program but have
a meaning in C-INTERCAL. For extra portability, it’s
possible to use the -t
compiler option to ick
(see -t) to tell it to interpret
the program as INTERCAL-72, but as
C-INTERCAL’s dialect of INTERCAL
is basically backward-compatible anyway this mostly serves to check
newer programs for compatibility with older compilers.
The Atari compiler was an uncompleted implementation of
INTERCAL-72, optimistically pre-described in some 1982
additions to the original INTERCAL-72 manual. Despite the
implementation’s never actually existing, the documentation of
the syntax provided a model for C-INTERCAL. If any Atari
800 INTERCAL source code actually existed, there would be no need to
use convickt
on it.
The J-INTERCAL compiler is an implementation of
INTERCAL written in Java that compiles
INTERCAL into Java (and so has a similar
relationship with Java to that of the C-INTERCAL compiler
(which is written in C and compiles into C) with C).
J-INTERCAL has much the same feature set as older versions
of C-INTERCAL, with a few changes (such as the addition of
Esperanto and error messages coming up in different situations).
J-INTERCAL programs should run fine on
C-INTERCAL without trouble (as it is also an Atari syntax
compiler), except in nonportable cases such as
IGNORE
/RETRIEVE
interaction.
The CLC-INTERCAL compiler is the most modern INTERCAL compiler apart from C-INTERCAL (both compilers are maintained and updated every now and then as of the time of writing, so which is more modern is normally a matter of when you happen to check). Unlike the other three compilers mentioned above, it has a quite significant feature set, including many features not implemented or only partially implemented in C-INTERCAL, and is responsible for the origin of many of the features added in more recent versions of C-INTERCAL. Generally speaking, a CLC-INTERCAL program that uses its advanced features is unlikely to run on C-INTERCAL, or vice versa, whatever you do (apart from completely rewriting the more advanced parts of the program).
However, there are certain steps that can be taken to transfer less
advanced programs from one compiler to the other. First, translate the
program to Latin-1 Princeton syntax (if translating from
CLC-INTERCAL to C-INTERCAL) or Atari syntax
(if translating from C-INTERCAL to
CLC-INTERCAL), maybe using convickt
, if
necessary. (Note that here the program is being translated to the
syntax that is not default for the target compiler.) Then use
command-line arguments to switch the compiler into the correct
emulation mode for the other compiler; C-INTERCAL uses the
options -xX, and on CLC-INTERCAL this is done
by selecting the appropriate preloads, or by changing the
program’s file extension to ‘.ci’. In
each case other options may be needed to turn on various extensions
(maybe -m or -v if translating to
C-INTERCAL, maybe the preload for gerund-based COME
FROM
if translating to CLC-INTERCAL), and if
translating to CLC-INTERCAL you need to append the system
library to your program yourself because CLC-INTERCAL
doesn’t load it automatically.
In the case of very simple programs, or if you want to spend the effort
in translating compiler-specific code from one compiler to another, you
may be able to work without emulation options. (This is a good target
to aim for, in any case.) In such a case, you would do nothing other
than possibly edit the program to be more portable and a possible
character set and syntax change using convickt
. If you
need compiler-specific code, you may be able to detect the compiler in
the code itself and adapt accordingly; making use of the
IGNORE
/RETRIEVE
interaction is one way to do
this, as it differs between C-INTERCAL,
J-INTERCAL, and CLC-INTERCAL. The other
things to watch out for when doing this are that
CLC-INTERCAL needs an explicit option to enable the use of
NEXT
, that CLC-INTERCAL doesn’t load
the system library itself (you need to manually append it to the end of
the program) and that you probably shouldn’t number a line (666)
unless you know what you’re doing, because that line number has a
special meaning in CLC-INTERCAL.
Next: Character Sets, Previous: External Calls, Up: Top [Index]