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

>> 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 ...
>
> Where do you see such a requirement?
>


personal experience...


having the VM run a scripting language is one thing;
having the VM run C is another.


trying to do both at the same time, with the same VM, well, this "opens a
whole new can of worms".


granted, one could take a shortcut and use dynamic typing for implementing
C, but why not ignore this possibility, and instead assume that the VM core
is statically typed. similarly, I can exclude the shortcut of building an
interpreter on top of the VM (this was an option I personally rejected).




after faced with a lot of this, one realizes 2 things:
in the grand scope of things, the .NET VM is not "that" complicated by
comparrison;
OTOH, one finds that all of this stuff is a horrible PITA...


(I am not claiming one needs all of .NETs runtimes/libraries, rather, I am
focusing on the core of the VM itself...).




it is generality which is the hard part, and it is surprising how simple
each "step" may seem along the way, or, at least, until one attempts to
actually do them.




it is a similar issue to how, when compiling C, one may find it surprisingly
difficult to make their compiler be fast. one can easily get near instant
compilation with a scripting language, but not so with C. it has its ways of
eating up time.




> IMO the VM only must support the C calling convention and data types
> (ABI) - not different from interfacing any other "language".
>


to run C, or to interface with it?...


I was concerning myself with running it in this context.


interfacing is an easier task, after all...




granted, yes, one can implement C on a VM which does not internally use
static typing, which could save some work, but I had excluded this (partly,
I don't know of any real way to do so without somewhat hurting
performance...).

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