dgl (05/12/83)
I'm looking for a good C interpreter. Hopefully, it will 1) be written in C 2) include structures, floating point and memory allocation 3) be reasonably isomorphic with Portable C 4) have the sources available The target system is a VAX, so neither size nor efficiency are so much of a concern as correctness of implementation. Thanks, Gareth Loy
kurt@fluke.UUCP (Kurt Guntheroth) (08/14/84)
People have begun to ask me why I don't think C could be interpreted.
Specifically, why not preprocess first and then interpret.
Well..., it kind of defeats the purpose of an interpreter, which is to allow
you to make easy alteration of the source lines. Imagine a program which
makes reasonable use of the preprocessor. Constants are symbolic, some
parts of the program are conditionally included, files are included. In
short, the source program changes by a significant amount when preprocessed.
Now, you could just not write programs that need preprocessing and what you
wrote would be what you saw in the interpreter buffer. That would be ok
but you would never be able to run normal C code which relies on the pre-
processor.
You could preprocess first. But then the code you interpreted wouldn't
much resemble the code you wrote. Sure it executes fine (albeit
slowly), but if you want to change something (interpreters are supposed
to make debugging easy), the line of the error may not look much like
anything you wrote. The lines of text the interpreter works on will
not be referenced to the lines of your source, the text will look
different (and often very strange...look at preprocessed code containing
calls to the stdio 'functions' if you want to see just how wierd things
look.) Files will be included... Not a good choice.
OK, so don't debug the code with the interpreter, or make the debugging
facilities resemble sdb or dbx. That's no good either. PCC is pretty fast
and so is ld. The time it took to (1) preprocess, (2) load the interpreter
and (3) run your program would probably more than equal the time to compile
the affected module over again and relink things. So why bother.
That leaves expanding macros each time by the line or keeping two versions
of the program around with a data structure relating one to the other. This
works I suppose, but it would be slow if not carefully done, and even if
carefully done, would be memory-wasteful and fiendishly complex. Maybe the
developers of this interpreter have a way to do this, I don't know?
--
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurtcmm@pixadv.UUCP (cmm) (08/17/84)
C preprocessing resembles LISP character macros. Different interpreters
have different approaches, but surely some model could be found here.
The main difference between normal LISP macros, and the C preprocessor,
is that mostly LISP macros replace a syntactic unit (S-expression), with
another syntactic unit. C macros frequently include fragments of syntax
in their expansions.
--
____________________________________________________________________________
cmm (carl m mikkelsen) | (617)657-8720x2310
Pixel Computer Incorporated |
260 Fordham Road | {allegra|ihnp4|cbosgd|ima|genrad|amd|harvard}\
Wilmington, Ma. 01887 | !wjh12!pixel!pixadv!cmm