In previous chapters several compilers for very small languages have been designed, but none of these languages were suitable for writing their own compilers. In this chapter several self-compiling compilers are described. The later ones were bootstrapped from the earlier ones.
This section describes some of the general notions of self-compilations, and some language specific background.
Compilers for large languages can be formidable, especially if they are to generate efficient code for a language that is conceptually very different from the machine for which instructions are to be generated. On the other hand, compilers for small languages can be very small indeed, especially if they are to produce code for a machine that has precisely the sort of operations which the language requires. This occurs for example when compiling code for a virtual machine, where this virtual code is either interpreted by a software interpreter, or further compiled into some actual machine code.
Almost any large universal language is suitable for reading strings of input characters, manipulating various tables, and writing either strings of output characters or sequences of instructions for some target machine. Hence almost any such language will be suitable for writing compilers. The ease with which this can be done depends on how well the complexities of the two languages are matched: the simpler the language that is to be compiled, the easier it is to write a compiler for it in a given language; the simpler the language in which the compiler is to be written, the harder it is to write a compiler in it for a given language.
If a language is suitable for writing compilers, then it becomes possible to write a compiler for the language in the language itself. In that case the compiler will be as large as the language it compiles. None of the languages that we compiled in earlier chapters were suitable for writing their own compilers. Even the largest compiler mentioned in the reading of Chapter~14, Wirth's Pascal-S, cannot compile itself. The smallest self-compiling Pascal compiler is the P-code compiler that has been used to bootstrap most of the early Pascal compilers. But because Pascal is fairly large, any Pascal compiler will be quite large.
But a self-compiling compiler need not be large at all. If the language that it compiles is minimally adequate to describe its own syntax and semantics, then the compiler itself can be very small indeed. This chapter describes a sequence of self-compiling compilers taking character string inputs and producing character string outputs. As presented here, the compilers produce code for the DEC editor TECO; but it would be easy to change the target language. Both the source and the target forms of the compilers are included in the text.
The remainder of this chapter contains a description of a family of quite simple string languages, HITECO~1, HITECO~2, HITECO~3 and HITECO~4 and their self-compiling compilers. They are not compatible, but they are evolutionary steps. The four files containing both the source and their target forms of the compilers are respectively 7, 12, 17 and 26 blocks (of 512 bytes) long.
This section describes some common features of all the HITECO source languages and some general features of the TECO target language.
The first source language HITECO 1 was chosen so as to be as small as possible, to the extent that this was compatible with self-compilation. Obviously a fast parsing algorithm was wanted, so a deterministic parser was required. In turn, this implied the LL1 condition: that all alternatives begin with distinct keywords.
The later languages evolved in a natural way: First new features were seen to be desirable, so the features were added to the existing compiler. At this point the compiler could compile a somewhat larger language, but it did not itself use the new features. Second the new compiler was rewritten so that it now used the new features and could still compile itself. Sometimes, in a third step, earlier features were removed because they were no longer needed, or because they had been replaced by better ones. This bootstrapping process is described in more general terms in a later section.
The source languages were to a large extent influenced by the initial target language TECO, a utility supplied by Digital Equipment Corporation. TECO began its life a mere interactive editor, but it has evolved into a powerful string processing language. Interactive usage requires brief commands, so, because of its origins, TECO programs are very compact. As a result, longer programs tend to be difficult to decipher a week after they have been written. All this means that TECO can be seen as a barely legible machine language for a powerful string processing machine; it needs a high level version which would be easier to read.
The remainder of this section should be skipped by readers who are only interested in HITECO as a source language.
TECO supports the types integer, character and strings of characters. There is a distinguished string, the editing buffer, and most operations apply to it, including input and output to files. In addition, there are a number of registers containing single integers or single characters, or strings of characters.
Among the operations applicable to the editing buffer are anchored searches. These are a special kind of search which requires the search string to be matched beginning at the current pointer position. If there is a successful match, then the pointer moves and the search returns success which can be used in a conditional. If there is no immediate match, then the pointer is not moved. Anchored searches are an ideal mechanism for LL1 parsing; and for that reason all versions of HITECO require the source language program to reside in the editing buffer. Strings can be inserted anywhere in the editing buffer, and they can be appended to registers. But compilation requires an alternation of inspecting source language program and generating target language program. If the editing buffer were used to hold the code that is generated, then the editing pointer would have to alternate between pointing to a position in the source and pointing to a position in the target. So it is simpler to generate code by appending it to registers.
When a compiler is compiling itself it is
executing procedures which are located somewhere,
and it generates code for its own procedures.
If it were placing its generated code directly
into the positions in memory that are executing,
then it would be adding code to the registers that are
supposed to be executing at the time.
So any code that is generated has to be placed elsewhere
(and TECO's register 9 was chosen arbitrarily for this purpose).
It is not strictly true that executable code
is generated by HITECO,
instead it is a program which, when executed,
will distribute real code to where it is needed.
So the compiler really generates code for a crude absolute loader
(the code is compiled into TECO's register 9;
the loading is then done by TECO itself,
by the command M9).
The first generation in the HITECO family consists of very small string to string translator written in itself and producing TECO code. Some of the design decisions are discussed, and both the HITECO and the TECO versions of the translator are given. HITECO 1 is adequate for expressing simple grammmatical constructions for a language in which the terminals are symbols. It does not have conventional flow of control, nor does it have data structures, and it cannot manipulate characters except by treating them as short symbols.
This first version of HITECO
was designed in such a way that the parser does not even know
whether it is reading a stream of characters or a stream of symbols.
The initial version of HITECO was designed with
the target machine in mind.
Even extended BNF is not ideally suited for
simple deterministic parsing
which does not know about single characters.
HITECO contains the same kinds of constructions as BNF,
except that a sequence of alternatives is signalled by CHOICE,
each alternative is preceded by WHEN
and has to be followed by a quoted terminal and then a statement,
the sequence is terminated by OTHERWISE and an error message,
inside a concatenation a compulsory quoted terminal
is flanked by CHECK and an error message,
the indefinite repetition is signalled by REP
which has to be followed by a quoted terminal and then a statement,
and there is an explicit concatenation operator ;,
and round parentheses may be used for grouping.
The grammar uses only one non-terminal STATEMENT.
In the extended BNF which is used below,
quotations denote their content,
juxtaposition denotes concatenation,
the vertical bar denotes alternation,
and the square brackets denote indefinite repetition of what they enclose.
As may be seen from the above,
a statement is either one of the five single terminals
STATEMENT, VARIABLE, QUOTE,
CODE, CODE or MESSAGE,
or is the terminal PUT followed by code,
or it is the terminal CHECK followed by a quote and a message,
or it is the terminal REP followed by a quote and then a statement,
or it is the terminal LET followed by a variable,
then the terminal = and then a statement,
or it is the terminal ( followed by one or more statements
separated by the terminal ; and terminated by the terminal ),
or it is the terminal CHOICE
followed by zero or more sequences consisting of the
terminal WHEN, then a quote and then a statement,
followed by the terminal OTHERWISE and a message.
(Note that STATEMENT is a non-terminal,
whereas STATEMENT is a terminal.)
The HITECO 1 source code consists of one page of text.
It is a single LET statement which places a single
CHOICE statement into register A.
There are 11 WHEN clauses corresponding to the 11
alternatives in the grammar.
Each WHEN clause consists of a head and a body.
The head consists of a source quote: PUT, (,
CHECK, REP etc., and the bodies consist of simple
statements or of compound statements enclosed
in parentheses.
Simple statements occur for PUT, STATEMENT,
VARIABLE,
compound statements occur for (, CHECK,
REP, LET etc.
Most of the statements are simple PUT statements
which generate code.
Of the remainder,
the simple ones are either recursive calls to STATEMENT,
or calls to procedures in the run time support:
QUOTE, CODE, MESSAGE and VARIABLE.
The composite statements are REP or CHECK constructions,
or they are compound statements enclosed in parentheses.
The CHOICE statement and the LET statement are composite too.
To enhance readability,
all PUT statements have been placed towards the right,
by ignoring them and only reading what is on the left
one gets the syntax of HITECO without the messy code
that has to be generated.
TECO is just about an ideal processor for HITECO; this is not surprising since HITECO was designed for that purpose. Nevertheless it was found convenient to augment TECO with five small procedures which act as run-time support:
The first one handles quotes, codes and messages:
essentially it remembers the first printing character which initiates the item
and served as a quote,
and then steps through the content of the item
copying characters to the code until it sees the matching character
which terminates the item.
The next one is a simple scanner which skips blanks,
tabs and newlines.
The next one handles errors: it writes the current line
up to the current parsing position,
then it writes ==HERE=>, then it writes the rest of the line.
The next procedure is used solely for formatting the target code
by writing a newline without the need for the newline character
in the source (which would spoil its appearance).
The last procedure checks that the character at the current
parsing position is a letter,
otherwise it calls the error procedure and writes a message.
Since the runtime support does not involve any recursive calls,
it would have been possible to unfold such calls
in the PUT statements inside the principal procedure A
which compiles statements.
This was not done because unfolding the many calls
to these procedures would have made the compiler so much longer.
However, since such a "pure" compiler would be of some
interest, it is worth contemplating.
This section is specific to the TECO implementation
of HITECO.
Readers who are not familiar with TECO may well wish to
skip this section.
The TECO object code constitutes the first half
of the file which is presented in the next section.
It is assumed that the entire code will be executed;
one way to do it is to put it into any arbitrary Q-register
(say Q-register 9), and then call it (by M9).
The effect will be to load portions of it into other
Q-registers, as follows:
The bulk of the code, for STATEMENT will be loaded
into Q-register A.
The remaining short portions constitute the run-time
environment, they are loaded into the Q-registers
as indicated.
The file contains several control-A characters
which are not printed by the line printer.
For that reason the file is reproduced here in the form
TECO would type it out.
Any control-A characters are reproduced as two characters: ^A,
up-arrow and A.
In all other respects the file is exactly as shown here.
For all self-compiling compilers, the first compilation has to be done by hand, so that the compiler writer has to write both the source version and the target version. Then the target version can be used to machine compile the source version, to produce a second copy of the target version. If all went well, the two target versions should be identical. >From then on everything is done by bootstrapping. This section gives a general description of the process of bootstrapping compilers --- using an early form of a compiler to help produce a better form, and a specific description of bootstrapping HITECO.
A compiler which compiles itself can be used to compile any programs in the language it compiles, and these programs need not have anything to do with compilation. But if the language is small, designed for self-compilation and little else, then one would be hard pressed to write anything but compilers in it. One major use of a self-compiling compiler is as a so-called bootstrapping device for writing a better compiler. Here better can mean several things. In the first place, if the language it compiles is the same as the original, then it can mean any one of: 1) prettier formatting of the target code, making it easier to read, or 2) greater efficiency during the compilation process, or 3) greater efficiency of the code that is produced. Note that for a compiler that is not written in itself, 2) and 3) are quite distinct aspects of efficiency, and that for a self-compiling compiler the way to achieve 2) is to achieve 3). On the other hand, better can also mean a different source language which is 4) easier to read, or 5) makes the writing of the compiler easier, or 6) has more useable features. The way to achieve 4) and 5) is to achieve 6).
The bootstrapping process consists of repeatedly applying the following steps. Assume that version(i) of the compiler exists in two forms, the source form source(i), and the target form target(i). First the current source form of the compiler is edited to become source(i+1). This new source still has to be written in the language which target(i) can compile, but it can differ either in the code generation or in the language which it can compile. The new source is compiled by target(i) to produce a new compiler, target(i+1). This can now be used in the next repetition. If the editing changes merely concerned improved compilation, then target(i+1) will produce better code, but it will not be faster at compiling because its code was generated by target(i). To obtain a better compiler, the bootstrap loop has to be repeated again, using source(i+1) as the input to target(i+1) to produce target(i+2) which will now be the improved version. If the code concerned modifications to the code that will be generated during compilation, then the process has to be repeated a further time so that the improvements eventually reach target(i+3). On the other hand, if the editing changes concern the source language, then the new compiler will be able to compile a new language. But so far nothing has been written in this new language, and one way to do so is to edit source(i+1) so that it is now written in the new language. At this point we have a new compiler source(i+2) for a new language, written in itself, and we have an executable form target(i+1) whose source was still written in the previous language. Another compilation produces target(i+2), and the bootstrap is complete.
A very useful check to make is the seemingly pointless self-compilation: use target(i) to compile source(i) producing target(i+1). If the compiler is stable now, then target(i+1) will be identical to target(i). If the compilation is not stable yet, then it may take another self-compilation to reach this point. But it can also happen that after one or two self-compilations the resultant target(i+1) or target(i+2) does not work at all; in that case an error has occurred earlier. In this way self-compilation is an important internal check.
The first generation in the HITECO family consists of a very small string to string translator written in itself and producing TECO code. The second generation has its run-time support written in itself. Some of the design decisions are discussed, and both the HITECO and the TECO versions of the translator are given. The run time support for HITECO 1 required features which could not be written in HITECO 1 itself. The principal objective of HITECO 2 was to make it possible to write this runtime support in HITECO 2 itself.
HITECO is adequate for expressing grammmatical constructions for a language in which the terminals are symbols. It does not have conventional flow of control, and it cannot manipulate characters. But both of these are required in the run time support. So, these features were added to HITECO2.
HITECO2 can be described by a grammar with three nonterminals:
STATEMENT, CONDITION and EXPRESSION.
The compiler for HITECO1 consists of just one procedure,
and a single PUT statement for generating the runtime support.
For HITECO2 the source code consists of a total of eight
procedures written entirely in HITECO2.
Each procedure is defined by a LET statement.
The procedures for parsing the three non-terminals
STATEMENT, CONDITION and EXPRESSION
are located in the alphabetic registers A, B and C,
respectively.
A grammar for HITECO2 is easily reconstructed from the source
by reading LET A = .. as STATEMENT ::= ..,
LET B = .. as CONDITION ::= .., and
LET C = .. as EXPRESSION ::= ...
The bodies of the three rules should be easy enough to
reconstruct by ignoring the right half of the page with
the code generation.
The run-time support for HITECO2 is almost identical to that of HITECO1, except that it is now written in HITECO2 itself. There are five procedures in the run-time support, and their code is located in registers 3, 4, 5, 6 and 7.
The largest and most important compiling procedure is for STATEMENT,
and it is essentially an enriched version of the single
compiling procedure for HITECO1.
Some of the inbuilt atomic statements correspond to non-terminals,
including STATEMENT itself.
The execution of such atoms generates code.
An entirely new atomic statement is the assignment statement,
which had to be made of the form MOVE e TO v,
where e is an expression and v is a variable name consisting
of a single letter or digit.
The new flow of control statements include a conventional IF_THEN
statement with an optional ELSE part,
and a new LOOP statement with EXITs.
The condition of the IF part of a conditional is handled by a separate
compiling procedure;
conditions consist of a numeric expression followed either by one of
three comparison operators and then another expression,
or by one of three postfix predicates which are true
if the value of the expression is an ASCII code for a letter,
a digit, or either of the two.
The last is needed because the compiler cannot handle more general
disjunctions.
An expression is either a number, recognised by its initial leading digit,
or the value of the inbuilt special variable CH
representing the numeric ASCII value of the currently visible character
as seen by the scanner,
or a variable whose value is in a REGISTER,
or a parameter of a procedure.
The procedure which the LET statement
puts into register 7 is invoked in STATEMENT
by QUOTE, CODE and MESSAGE.
It takes a parameter which is either 0 or 1 or 2,
and the value of that parameter determines whether
the quotation symbol of the source
is used for the code or not:
As may be seen in STATEMENT,
CODE uses parameter 0,
and in this case the quotation symbols are stripped off,
QUOTE uses parameter 1,
and in this case the quotation symbols are retained,
and MESSAGE uses parameter 2,
and in this case ^A (control-A) is used as the quotation symbol.
The procedure which the LET statement
puts into register 6 is the scanner which
uses the inbuilt procedure GETCH to skip
one character for spaces and tabs, and two characters
for carriage returns --- the other character skipped
is the line feed.
The conditional is in a loop,
the inbuilt procedure RESTART sends control back
to the beginning of the loop,
and the inbuilt procedure EXIT sends control
beyond the end of the loop.
The procedure which the LET statement
puts into register 5 is the error
reporter; it writes a new line to the terminal,
the beginning of the current line being parsed,
an arrow to the current parsing position,
and the remainder of the current line.
The procedure which the LET statement
puts into register 4 merely writes
a new line to the object code.
The procedure which the LET statement
puts into register 3 checks that the
current character being scanned is
a symbol constituent --- essentially a letter or a digit.
The following is the HITECO2 compiler written in HITECO2 itself. The target form of HITECO2 written in TECO is not given here because it is just an enriched form of the target form of HITECO1 written in TECO.
One of the principal shortcomings of HITECO2
was the fact that procedures only had single character names.
Hence the compiling procedures for STATEMENT, CONDITION
and EXPRESSION were actually called A, B and C.
Inside STATEMENT, there were three special purpose statements
namely STATEMENT, CONDITION and EXPRESSION,
which generated code to generate code to call A, B and C,
but they did not actually call A, B and C themselves.
So, HITECO2 looked deceptively like a recursive descent compiler,
but it was really something else.
To obtain a normal recursive descent compiler,
the nonterminals of the grammar should correspond to
compiling procedures.
Except for very simple grammars, recursive descent parsers have to satisfy quite strict visibility requirements. One way of satisfying such requirements is the use of block structure, as we have done in several earlier parsers and translators. Another way is to give forward declarations (as we did for ver and fal in the model generator of Chapter~14). This is a generally useful method, and HITECO3 uses it. A program has to begin with forward declarations for all procedures. The purpose of the forward declarations is to put the names of the declarations into a symbol table, and, depending on the target language, associate code information with the names. In the case of TECO target code, the required code information is the single letter name of the Q-register which contains the code for the procedure. After the forward declarations follow the declarations of the bodies of the procedures. The translated code for these bodies has to be placed into the Q-registers which were assigned to the names of the procedures during the forward declarations. In detail, since the translator produces code for a loader, the translator has to look up the symbol table in order to tell the loader into which Q-register to place the code which the translator is about to produce when it is translating a body. In the same way, if the body contains calls to procedures, the translator has to look up the symbol table in order to produce code for a call of TECO code in the right Q-register. Apart from the change just described, the language was left fairly unchanged.
The same process of bootstrapping was applied to HITECO2 to obtain
a new self-compiling compiler for a language HITECO3.
But this language was still inelegant.
In particular,
the WHEN before the individual choices
and the CHECK before required symbols
did not seem necessary from a logical point of view,
although they had been operationally necessary
for the simple parser that could be written in the language.
To make the input language look more like BNF,
WHEN and CHECK were eliminated
in the next version, as described in detail in the next section.
The fourth generation of HITECO adds several new features. Some of the design decisions are discussed, and both the HITECO and the TECO versions of the translator are given.
A program begins with forward declarations of all procedures, this is necessary because nesting of procedures is not possible and there is mutual recursion for which the calling procedure has to know where the code for the called procedure is located. The HITECO4 compiler begins with forward declarations of 18 procedures.
The first compiling procedure is for the non-terminal program.
Its body consists of a statement sequence,
essentially for compiling the forward declarations
of the procedure names
and then the bodies of procedure declarations.
Note that in the body of procedure program
everything having to do with code generation has
again been shifted to the
right part of the page.
This leaves the left half containing a relatively pure
description of the input language.
For example, the part for the procedure declarations says that until the
current printing character is a period,
the word PROCEDURE is required,
and if it is not there then an error message is given which is
constructed from the missing word and the string program which follows.
The error message then will be:
'PROCEDURE' expected in program.
After the word PROCEDURE a procedure name is expected;
this is handled by a separate compiling procedure.
Following that, = is required,
otherwise the error message '=' expected in program is given.
As may be seen from these two examples,
required symbols are written in double quotes,
followed by another quotation containing another part of the
error message.
After the = a statement is expected, as described next.
The long compiling procedure for the non-terminal statement
has as its body a single CHOICE statement.
Note that the various choices all begin with a quoted string,
which may be the currently visible symbol;
if it is, then the body of the particular choice is entered.
So a CHOICE statement is somewhat similar to a CASE statement.
The first few choices are inbuilt atomic statements,
mostly having to do with code generation.
The next few take parameters, but they are still atomic statements ---
they do not have further statements as parts.
The first non-atomic statement type is the LOOP statement,
consisting of the keyword LOOP followed by another statement.
Typically the other statement will be a compound statement,
consisting of several statement separated by semicolons
and the whole enclosed in parentheses,
typically at least one of these other statements will be
an EXIT statement or at least contain one.
In the compiling procedure for statement,
following the LOOP statement is the compound statement: (
followed by a SEQuence of statements SEParated by ;,
followed by ) --- otherwise the error
'=' expected in compound statement is given.
SEQ-statements are explained a little further down,
as consisting of SEQ followed by a statement followed by SEP
and then a quote --- the separator, such as ; above.
The next kind of statement is the CHOICE statement,
consisting of CHOICE, a list of choices that are handled by
a separate compiling procedure,
then a compulsory OTHERWISE
and a final statement.
Note that this particular part of the compiling procedure
for statement describes the structure of the statement
which is the body of the compiling procedure.
The remaining compound statements are mostly self-explanatory,
except perhaps the TO statement, which is like a FOR statement
of Pascal without the FOR part --- the expression is evaluated
and its value is the number of times the DO part will be executed.
If a statement does not start with any of the explicit keyword choices,
then the OTHERWISE part of the compiling procedure for statement is
activated.
If the current character is a double quote,
then the characters up to the closing quote are taken
as a required terminal --- such as ), THEN, DO etc.,
and if they are not present,
then the required terminal together with the following
explanatory MESSAGE are combined to report an error.
If the current character is a lower case letter,
then the ensuing characters are read and used to lookup the
table that was produced by the forward declarations.
Following the procedure name,
a (possibly empty) parameter list is parsed next.
If the current character is an uppercase letter,
then it is the name of a variable in an assignment statement,
for which := and an expression are expected next.
The next compiling procedure is for the non-terminal CONDITION.
A condition consists either of the keyword MATCH
followed by a quotation to be matched at the current parsing position,
or of an expression followed by a predicate.
(The first line of the body of this procedure is
typical of the problems with self-compiling compilers:
The first MATCH is already compiled, the quoted "MATCH"
is what the next generation will require.)
The next compiling procedure is for expression,
not in an ideal syntax but forced by the limited recursion facility
of the target language TECO.
The keyword expressions correspond mainly to
the ASCII codes of special characters,
or parenthesised expressions containing infix operators.
Other expressions can be single upper case letters for variables,
or digit strings which evaluate to numbers.
The procedure infix compiles those parts of expressions
beginning with arithmetic infix operators;
the procedure predicate deals with either
postfix predicates or comparison operators followed by expressions.
There are a few more compiling procedures for parameter lists
(which the compiler does not check),
and for three other kinds of lists ---
those in CHOICE, OPCODE and CASE statements.
The target code consists of a number of procedure bodies which are stored in Q-registers:
ME
has to be given.
The following is the source:
The TECO target code is given here for completeness, most readers will want to skip the following three pages.
The HITECO project as described here took about 6 man weeks to implement; this figure is for writing source and target codes and endless self-compilations and bootstrapping steps, but excluding documentation. The result has been an implementation of a readable string processing language. Further work should now concentrate on making available to the HITECO user those features of TECO which the HITECO compiler does not use itself.
TECO is a powerful language,
and it has numerous features that would not normally
be used in interactive text editing.
But there were some deficiencies:
The most annoying problem was the absurdly small
recursion stack of the old version of TECO ---
in the manual[!] it is said to be about 10.
Several intermediate versions of HITECO failed because
they required recursion just slightly deeper than TECO
will tolerate.
There are a number of things which ---
with the wisdom of hindsight ---
I would have liked to have done differently.
It would have been nice to have organised the versions in such a way
that each one can compile itself and its immediate successor.
During the development of the sequence
such versions did sometimes exist,
but there were too many of them to be kept.
With more careful design it would have been possible
to keep the number of generations quite low.
Perhaps somebody will be inspired to start again
by augmenting version 1.
It was probably a waste of time to generate pretty-printed
TECO code in the early versions.
Another mistake was to use the form @^A/text/ is used now).
As far as the implementation in TECO is concerned,
it might have been beneficial to produce code that
does not rely on the limited recursion stack of TECO,
but uses the very generous Q-register push-down list instead.
Such a change would best be done by modifying version 4,
but the price might be a dramatic loss of efficiency.
It is worth noting that the limitation on the size of the recursion stack has been removed in the 1990 version of VAX TECO.
Modifying the source language:
You have an offer from a Polish software agent who
wants to buy a HITECO1 compiler,
but he wants the key words to be in Polish.
Assume that the English words STATEMENT,
VARIABLE, QUOTE etc.
have the Polish equivalent STATEMENTSKY,
VARIABLESKY, QUOTESKY etc.
Describe the steps needed to change the English version of HITECO1
to a Polish version.
All changes are to be made to the source,
editing the target is not allowed
(only Philistines do that).
The final product to be delivered is to consist of a source version
and a target version.
Modifying the target language: Two of my students have used version 1 as a starting point to write tiny self-compiling compilers which use C or Pascal as the target language. One of them volunteered the information that it was fun, the other one did not say anything.
Use version 4 as a starting point to write a self-compiling compiler which uses C or Pascal or any other language as the target. This could be done by bootstrapping, by changing those parts in the HITECO4 source which generate TECO code. Then the old TECO version would be used to compile this changed source to a target version in the new language. Then the target version can be used to compile the changed source again, and if all went well then the resulting second copy of the target should be identical to the first. Alternatively, if you do not have TECO to run a HITECO compiler use the source as an aid in designing a new self-compiling compiler.
Reading: A very comprehensive general account of self-compilation and bootstrapping can be found in Lecarme and Pellissier Gart (1986).