Re: f95 interpreter

glen herrmannsfeldt <>
21 Oct 2004 22:19:06 -0400

          From comp.compilers

Related articles
Re: f95 interpreter (glen herrmannsfeldt) (2004-10-21)
Re: f95 interpreter (Gene Wirchenko) (2004-10-23)
Re: f95 interpreter (glen herrmannsfeldt) (2004-10-24)
| List of all articles for this month |

From: glen herrmannsfeldt <>
Newsgroups: comp.lang.fortran,comp.compilers
Date: 21 Oct 2004 22:19:06 -0400
Organization: Comcast Online
References: <Pine.LNX.4.60.0410161511130.2756@janus>
Keywords: Fortran, interpreter
Posted-Date: 21 Oct 2004 22:19:06 EDT

(comp.compilers added)
Jason Nielsen wrote:

> I was wondering if there is a good reason why an f95 interpreter
> doesn't exist (or at least I'm not aware of one). I recently had to
> work on a project using OCaml and was quite impressed with the fact
> that it has an interpreter and can be compiled to pretty good native
> code (i.e. runs reasonably fast). I have gotten used to having
> either one or the other.. but not both. The debug-devel time
> without the compile-debug cycle was quite enjoyable and got me to
> thinking about this question.


There are very few true interpreters for programming languages. (Not
counting command languages such as unix csh, sh, and DOS/Windows .BAT

Most are closer to incremental compilers, where at minimum each
statement is compiled to an intermediate form, converting language
tokens (keywords) to an internal form, and possibly user symbols
(variable names) also. Most BASIC systems work like that, many
compiling each line when it is entered. On the continuum between
compilers and interpreters, it is most of the way toward interpreters.

As for Fortran, there was WATFIV (successor to WATFOR) both very high
speed, in core compilers. Compiled code is generated directly in
core, and not written out as an object file. Fixing up branch targets
is easy, it can be done much faster than compilers that do write an
object file, but the code is really compiled.

An interpreter or incremental compiler usually requires a search for
branch targets (GOTO destination, or structured programing constructs)
which may search through much of the program searching for the target.
Compiled code will have the address already known.

-- glen
[Back in the early 1970s, IBM had two PL/I compilers, the X compiler
which generated optimized machine code and the CK (checkout) compiler
which generated bytecodes and interpreted them. They used the same
front end and accepted the same input language. The CK compiler
offered all of the nice debugging stuff you'd expect from an
intepreter, full range checks, bogus pointers, type mismatches, all
that. You could even tell CK to generate code with call stubs so you
could run a mix of X and CK code if you wanted. Of course, high
quality debugging support like that is now obsolete. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.