|Re: f95 interpreter firstname.lastname@example.org (glen herrmannsfeldt) (2004-10-21)|
|Re: f95 interpreter email@example.com (Gene Wirchenko) (2004-10-23)|
|Re: f95 interpreter firstname.lastname@example.org (glen herrmannsfeldt) (2004-10-24)|
|From:||glen herrmannsfeldt <email@example.com>|
|Date:||21 Oct 2004 22:19:06 -0400|
|Posted-Date:||21 Oct 2004 22:19:06 EDT|
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.
[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]
Return to the
Search the comp.compilers archives again.