Re: Languages with well-integrated Foreign Function Interface to learn from?

> 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@gmail.com

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