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

On Tue, Sep 1, 2009 at 12:12 AM, BGB / cr88192<cr88192@hotmail.com> wrote:
>>> more recently, my project has taken a very different approach:
>>> both the VM and native code are C.
>> <snip />
>>> however, all this effort does have a payoff:
>>> plain C to plain C integration.
>>
>> If I understand you correctly, it seems that this interface wouldn't
>> be portable to other VMs, and that the standard libraries could not be
>> shared with another implementation which did not use a C virtual
>> machine?
>
> another VM could use a similar strategy, but granted, to use plain C<->C
> interfacing, the VM in question would need to be able to support C.
>
> the great problem is that this quickly rules out most simple /
> language-specific VMs...
>
> basically, to handle both a dynamic language, and C, the VM would need a
> similar level of complexity to that of .NET ...




But only if you need to 'handle' C in your VM. I am at a loss as to
why this might be useful. To make a dynamic VM, with a useful FFI, you
don't need to handle C in any meaningful way, except:
  - it might be useful to parse some C subset to generate glue coode
(if using the idea's I outlined in my first mail)
  - to link to C libraries, which isn't hard (no dynamic linking requirements).


  You certainly don't need a JIT, an 'unsafe' environment, to process C
as bytecode (does .NET even do this?) or any of the rest of the
complexity of .NET.






> 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.






> 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.


Paul
--
Paul Biggar
paul.biggar@gmail.com

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