Channels ▼

Andrew Koenig

Dr. Dobb's Bloggers

More Dirty Tricks in SPITBOL

December 21, 2011

This post continues the discussion ([1], [2]) about dirty tricks in the SPITBOL compiler. This time I'd like to talk about a technique that I mentioned briefly in passing: Looking at the generated code during execution to find where statements begin. It turns out that SPITBOL's runtime support examined the program's code while it was running in several contexts. In fact, it even changed the program's code from time to time.

The most important reason for the program to change its own code was the unusual way in which SNOBOL4 does I/O. Instead of having I/O statements or library functions, it allows the programmer to designate specific variables as being attached to files. For example, the variable named INPUT reads a line from the standard input stream each time its value is accessed, and the variable named OUTPUT writes its contents, followed by a newline, to the standard output stream each time it is given a new value. Accordingly, the statement

OUTPUT = INPUT

reads a line from the standard input and copies that line to the standard output.

If you want to read from a file, rather than from the standard input stream, you execute a statement such as

INPUT("in", "myfile")

Here, we are calling the library function named INPUT (which is distinct from the variable named INPUT) and giving it two arguments. The first argument is the name of a variable that we wish to associate with an input file, the name of which we supply as the second argument. There is a corresponding library function named OUTPUT for output files.

Because we can use a string to name the variable(s) that we intend to use for input/output, it is not possible in general to know until the INPUT or OUTPUT function is executed what the name of that variable will be. Accordingly, when the compiler generates a load or store instruction that accesses any variable at all, it is possible that that instruction will wind up doing input or output. It should be obvious that the overhead involved in testing every variable access for possible I/O operations would slow down programs substantially.

SPITBOL avoided this overhead by a technique that was as effective as it was sneaky: When a program calls INPUT or OUTPUT, the runtime library now knows the name of the variable that is to be used for the purpose. It has a symbol table sitting around at runtime, so it can figure out that variable's address. It then looks through the machine code that it generated for the entire program, finding every instruction that accessed that variable. It replaces each such instruction by a call to the library.

In other words, the call to INPUT above replaces every instruction that accesses the variable in by a call to the library that asks it to read from myfile into in.

Obviously, this technique is not one that we would recommend in general. In the case of SPITBOL, however, it was yet one more technique that users of the compiler did not have to worry about, and that contributed to the blazing speed of programs that the compiler compiled.

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video