Re: C interpreter

N. D. Culver wrote:
>
> EiC has been updated ...
>
> <snip>
>
> I read the somewhat obtrusive license for this product and wonder if
> anyone really really wants an interpreting C compiler.


EiC is also interactive and pointer-safe. This in my opinion
makes a huge difference.


> If so, there is a version of oxcc at:
> <ftp://ftp.simtel.net/pub/simtelnet/msdos/c/oxcc1434.zip> which you
> can examine. It compiles to bytecodes and also interprets full C,
> almost all of the GCC extensions and setjmp,longjmp,alloca etc. It has
> a dynamic linker and will link the interpreted code with hard code or
> byte coded libraries.


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, but what I really want is a nice
way of linking to builtin code.


The way EiC calls builtin functions is via interface routines. All
interface routines have the same form and each builtin function must
have an interface routine if you want to have access to it from the
interpreter. For example, the interface routine to the maths function
`pow' is:


#include <math.h>
#include "eic.h"
val_t eic_pow(void)
{
        val_t v;
        v.dval = pow(arg(0,getargs(),double),
                                  arg(1,getargs(),double));
        return v;
}


where val_t specifies a union that holds all allowed data types. The
EiC `arg' facility comes in several forms, and are defined in eic.h:


#define arg_list AR_t *
#define getargc() ARGC
#define getargs() AR[2]
#define nextarg(x,type) (*((type*)&(--x)->v))
#define arg(i,x,type) (*((type*)&x[-(i+1)].v))


They provide direct access to EiC's runtime interpreter stack `AR[2]'.


Next, the interface routine must be added to EiC's symbol table, and
this
is done via the function call:


                add_builtinfunc("pow",eic_pow);


where `pow' is the name of the function the interpreter will see, but
`eic_pow' is the function it will actually call. From EiC's virtual
machine, this is done via:


case call: /* call a builtin function */
                ARGC = STK[ToP].v.ival; /* number of arguments being passed */
                AR[2] = &env->LAR[env->lsp];
                STK[ToP - 1].v = (*STK[ToP - 1].v.vfunc) (); /* call the
function */
                env->lsp -= STK[ToP].v.ival;
                ToP--;
                break;


As EiC is type safe, and before EiC will call `pow' the function must
be prototyped and this is done via usually including the appropriate
header, and in this case it is <math.h>:


                double pow(double a, double b);


Safe-pointers adds another layer of complexity to all of this.




> In the last 3 years I've received less than 10 emails about oxcc and
> most were complaining that they couldn't generate .exe files.


I have not received a lot direct emails, but a lot of people have
visited EiC's web page and about 50 people have downloaded it.


Cheers,


Ed.
--

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