Browse Prior Art Database

Incremental Compilation for Interpretative Language Translator

IP.com Disclosure Number: IPCOM000106856D
Original Publication Date: 1993-Dec-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 4 page(s) / 191K

Publishing Venue

IBM

Related People

Temple, AC: AUTHOR

Abstract

Disclosed is a mechanism that allows compiler technology to be implemented for an interpretative language (such as the Application System Language) on a staged basis. As a result interpreter performance can be improved significantly by providing an equivalent compiler. Defined is a programming solution for staging the introduction of such a compile capability.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 34% of the total text.

Incremental Compilation for Interpretative Language Translator

      Disclosed is a mechanism that allows compiler technology to be
implemented for an interpretative language (such as the Application
System Language) on a staged basis.  As a result interpreter
performance can be improved significantly by providing an equivalent
compiler.  Defined is a programming solution for staging the
introduction of such a compile capability.

      A number of programming languages have been implemented using
interpreters, rather than compilers.  This approach has been used for
a number of reasons.  Interpreters are less complex to implement;
they are more portable across different hardware and operating
systems.  Also it is easier to provide powerful debug and support
facilities and the language may contain dynamic semantics that make
compilation difficult.  While interpreters have advantages over
compilers, they generally suffer a performance penalty.  Some
languages, for example BASIC and REXX, were initially implemented
using an interpreter but are now complemented by a compiler.  The
standard approach has been to develop the compiler separately from
the interpreter, posing an all or nothing decision, often hard to
justify.  This disclosure proposes a solution.

      Interpreters normally translate the external source statements
into an internal form that simplifies execution and so aids execution
performance.  The internal form consists of tables that contain the
various elements of the original statement.  For example an
assignment such as:

     LET A = B + 10

May be held after translation as a set of table entries:

      Here each component of the assignment statement has been
separated out into successive entries (tokens) in a two column table.
The first column specifies an operation to be performed and the
second column provides the associated parameter.  The Add and Store
entries don't require a parameter since they use the results of the
previous entries.  This arrangement closely follows the structure of
machine instruction, such that it is a simple task to perform
execution against the target hardware.  Naturally the operation code
and associated parameters are held in a compact internal form that
trades off memory for execution speed.  The internal representation
may well present a simplification of the situation.  In the above
example, there would be little complexity if the variables A and B
were both integers.  If one was decimal, then either the addition or
the store would require a format conversion prior to its execution.
Compilers handle these situations by generating additional machine
instructions at the appropriate points.  Interpreters have to detect
the situation during execution and take the necessary additional
steps.  This type of problem seems straightforward to deal with but
it becomes more complex if the language allows variables to contain
more than one type of data.  For example...