Re: C interpreter

"N. D. Culver" <>
30 Mar 1998 21:39:52 -0500

          From comp.compilers

Related articles
[3 earlier articles]
C interpreter (1989-10-02)
C interpreter Ed.Breen@"CMIS" (Ed Breen) (1998-03-18)
Re: C interpreter (N. D. Culver) (1998-03-22)
Re: C interpreter (Joachim Durchholz) (1998-03-24)
Re: C interpreter (N. D. Culver) (1998-03-30)
Re: C interpreter (Ed Breen) (1998-03-30)
Re: C interpreter (N. D. Culver) (1998-03-30)
| List of all articles for this month |

From: "N. D. Culver" <>
Newsgroups: comp.compilers
Date: 30 Mar 1998 21:39:52 -0500
Organization: Atlantic Biomedical Engineering
References: 98-03-166 98-03-213 <>
Keywords: C, interpreter

Ed Breen wrote:
> EiC is also interactive and pointer-safe. This in my opinion
> makes a huge difference.

Oxcc is not interactive but it is pointer-safe. It has to be because
it can regenerate source after evaluating outer declarations or
interpreting the program. For instance pointers can be cast as ints
and stored in arrays, when they come out of hiding the system knows

> This sounds really nice, but can hard code call interpreter functions?
> And how difficult is it to link the interpreter to new libraries
> of C code. For example EiC links to almost the entire standard
> C library and a portion of the POSIX.1 library,

This is really two questions because the compiler interprets the AST
and the VM interprets byte codes. The compiler automatically builds
hard-code or soft-code callback thunks whenever the address of a
function is passed as an argument. It doesn't automatically build a
thunk for every global function although I see no reason why it
couldn't. I might be wrong here, maybe it DOES build the thunks for
all interpreted global functions, or at least the ones that might be
'taken by suprise' by hard-coded library routines. There are some
interactions between the compiler and dynamic linker that escape my
memory at this time.

The byte code VM automatically links everything up. Version 1434 of
the compiler will link to any djgpp or oxcc compiled a.out library or
a.out file residing on the OS filesystem or in the .cff archive. More
recent versions can handle COFF, ELF and PE formats. If memory serves,
the library looker upper does a fairly good job all by itself but you
can also give it a library path on the command line.

> but what I really want is a nice way of linking to builtin code.

Oxcc has a few builtins but the overhead for calling builtins is no
higher that that for calling hard-coded library functions so I see
no need to provide the user a way to add more builtins. The VM
source code has several examples of builtins, take a look at bterp.c.

Norm Culver

Post a followup to this message

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