Re: Languages with well-integrated Foreign Function Interface to learn from?
- From: Paul Biggar <paul.biggar@xxxxxxxxx>
- Date: Thu, 3 Sep 2009 08:48:31 +0100
one major advantage:
you can run C in the VM.
C is a very useful language to be able to run as a scripting language, since
it is a fairly powerful language.
Nothing against C, JITs, etc. I was just suggesting good practice for
designing portable FFIs. I think if you follow the design you've
outlined, it will be nearly impossible for a reimplementation to use
your FFI without copying your VM design.
I can already more-or-less glue dynamic typing to C-style data
representations, ...
Maybe, but why would you want to? In my opinion, all you do here is
prevent people from reimplementing your language, which is the same
mistake that all existing scripting languages have made.
the main advantage is that it allows many places to internally use static
typing, which allows for greater performance in many cases...
another advantage is that it can save memory...
I don't think there is anything in the FFI proposal I laid out that
prevents implementing as much of your run-time or library as you
choose in C. You don't need to support C code in your VM to achieve
this.
for example, typical dynamic typesystems use pointer-sized values for every
possible value, and gives extra performance-eating costs (such as the need
for fiddling with type-tags in the pointer bits, deal with ranges or
displacements for another tagging scheme, ...).
Again, if you determine that these can be statically typed, you do not
need to support C in your VM to optimize this.
thus, my ideas for how to do JS in my present framework...
if done well, JS "should" be able to achieve close to 1:1 performance
with C
(if compiled to statically-typed native code via lots of internal
trickery...).
I wouldn't assume this for a second. You can't statically compile
Javascript to native code at all, primarily because of the existence
of AJAX, which fetches code at run-time from the server, and eval()s
it. In the absence of this, and other means of run-time code
generation, Jensen's work (http://www.cs.au.dk/~amoeller/papers/tajs/)
shows that, yes, JS is very statically type-able. But the application
is not compilation - none of the recent Javascript implementations
(squirellfish, V8 and tracemonkey) are statically compiled, nor could
they be if they wanted to process real-life Javascript.
who ever said anything about statically compiling the JS?...
I simply said it would be compiled to statically-typed native code.
Indeed. I misread your previous mail.
this means:
A, it is compiled to dynamically typed bytecode;
B, the JIT does all the trickery to lower it to static typing.
You should of course support a low-level IR in your JIT, for all the
reasons you outlined above. At the risk of repeating myself, I don't
believe you've given a good reason for supporting the full generality
of C (except that its a cool hack, perhaps :))
the main complexity with JIT and JS is part of the typesystem:
there is no clear distinction between integer and real types;
nearly all overflows are defined of automatically going to double;
There isn't a huge distinction between strings and numbers either,
AIUI. You might have come across Gal's PLDI 2009 paper
(people.mozilla.org/~dmandelin/tracemonkey-pldi-09.pdf) with their
nice solution. V8 has a nice 100% compiled solution too
(http://code.google.com/apis/v8/design.html).
--
Paul Biggar
paul.biggar@xxxxxxxxx
.
- References:
- Re: Languages with well-integrated Foreign Function Interface to learn from?
- From: BGB / cr88192
- Re: Languages with well-integrated Foreign Function Interface to learn from?
- Prev by Date: Re: Deterministic Finite Automata: Sub-element captures
- Next by Date: A novice in compiler construction wants feedback
- Previous by thread: Re: Languages with well-integrated Foreign Function Interface to learn from?
- Next by thread: Re: Languages with well-integrated Foreign Function Interface to learn from?
- Index(es):
Relevant Pages
|
