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

Paul Biggar <paul.biggar@gmail.com>
Wed, 2 Sep 2009 15:34:40 +0100

          From comp.compilers

Related articles
[8 earlier articles]
Re: Languages with well-integrated Foreign Function Interface to learn paul.biggar@gmail.com (Paul Biggar) (2009-07-28)
Re: Languages with well-integrated Foreign Function Interface to learn cr88192@hotmail.com (BGB / cr88192) (2009-08-24)
Re: Languages with well-integrated Foreign Function Interface to learn cr88192@hotmail.com (BGB / cr88192) (2009-08-30)
Re: Languages with well-integrated Foreign Function Interface to learn paul.biggar@gmail.com (Paul Biggar) (2009-08-31)
Re: Languages with well-integrated Foreign Function Interface to learn cr88192@hotmail.com (BGB / cr88192) (2009-08-31)
Re: Languages with well-integrated Foreign Function Interface to learn DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-09-02)
Re: Languages with well-integrated Foreign Function Interface to learn paul.biggar@gmail.com (Paul Biggar) (2009-09-02)
Re: Languages with well-integrated Foreign Function Interface to learn cr88192@hotmail.com (BGB) (2009-09-02)
Re: Languages with well-integrated Foreign Function Interface to learn paul.biggar@gmail.com (Paul Biggar) (2009-09-03)
Re: Languages with well-integrated Foreign Function Interface to learn cr88192@hotmail.com (BGB / cr88192) (2009-09-03)
Re: Languages with well-integrated Foreign Function Interface to learn cr88192@hotmail.com (BGB) (2009-09-03)
| List of all articles for this month |

From: Paul Biggar <paul.biggar@gmail.com>
Newsgroups: comp.compilers
Date: Wed, 2 Sep 2009 15:34:40 +0100
Organization: Compilers Central
References: 09-07-074 09-07-095 09-07-105 09-08-050 09-08-056 09-09-005
Keywords: code
Posted-Date: 02 Sep 2009 23:41:03 EDT

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



Post a followup to this message

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