Re: C-like interpreted language WITH pointers

have you looked into the likes of 'ch' and 'tinycc'?...


http://en.wikipedia.org/wiki/Ch_interpreter
http://en.wikipedia.org/wiki/TinyCC


LLVM/clang may also be worth looking into.




well, going off the question itself:


now, granted in my case, I wrote my own dynamic C compiler, but I will not
personally endorse it at present (or, at least, not unless one feels so
inclined on working on the compiler itself, since there may well be many
remaining bugs, as well as known incomplete features...). my effort is then,
more of a personal experimental thing (sadly, most of my code is like this,
where I write things but for practical concerns still need to more endorse
existing projects, but oh well...).


my reasons?... well, they are my reasons. I can at least have the specific
features I want (primarily stuff borrowed from 'dynamic' languages), and
experiment with stuff (for example, recently beating together a
small/incomplete JavaScript/ECMAScript VM, and working with improving
integration between JS and C).




I still face many issues though, for example:


ECMA-262 specifies that reals have full double precision, which is a bit of
a problem given I am using a conservative collector and dynamically-typed
doubles need to be stored on the heap. the current in-pointer flonums have
far less than double precision (previously, I had just been using these, but
these are in violation of the standard, beyond just having sub-float
precision).
partial solutions exist (namely, adding a cheaper way to allocate and
collect small atomic heap objects, namely via a non-graph-tracing mark/sweep
process, which should be faster than a full graph-trace but is more likely
to retain garbage).


misc:
the small atomic heap will probably use 8 byte cells and sideband info
(probably 16 bits/cell, with embedded size and type), where items are
atomic, but will fall back to the main heap for objects larger than (24 or
32 bytes), where the main heap uses 16-byte cells, in-object headers, and
has 8 bits sideband/cell (note that objects >= 6KiB go off again to a
different 'large object' heap);


cons cells also exist, and have their own area as well (cell size is 8 bytes
on x86, but 16 on x86-64).


combine this with making the beast concurrent, and it is a big complicated
mess...




actually, my stuff makes fairly heavy internal use of conses, but officially
JS does not use them.
I am left in many cases torn between strict conformance and performance
concerns.




oh well, luckily at least I can do scripting in C as well, and get non-crap
performance...
as a cost though, my current C/JS interface machinery is not exactly cheap
(in particular, recursive calls between C and JS code is likely to be a
horrible case, creating a new interpreter context for each call into JS
land, ...). so, had been considering the possibility of making fancy use of
trampolines and similar to deal with this case, as well as reusing the same
context for each iteration.


an alternative would involve somewhat restructuring the JS VM (making the
interpreter function more like a kind of "false co-processor"), but this
could hurt raw performance when dealing with unmixed code, or possibly even
defeat the interpreters' ability to do tail-call optimization, ... but, as a
positive point, could simplify re-adding JIT support (the existing VM had
handled JIT'ed code via trampolines, and I had removed JIT in some of the
recent rewriting effort, and trying to force it into implementing JS rather
than my own scripting language...).




but, recent progress is very slow, given a lot more of my time is going into
doing homework and similar...




"Legrandin" <spougsazag@farifluset.mailexpire.com> wrote in message
news:08-09-097@comp.compilers...
> Hi,
>
> Not sure if this is the most appropriate ng...
>
> I am looking for a simple, fast, small, intepreted, C-like imperative
> language, with support for pointers and memory aliasing.
>
> * it should be compilable in bytecode and executed by a small VM
> * it does not need to be safe (NULL dereference may crash the system :-))
> * I will use for some releatively intensive numeric manipulation, but
> floating point arithmetic or even division are not needed.

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