[Vm-dev] Simulating FFI Calls [was Re: VMMaker simulation - strlen, strcpy, getenv and FakeStdinStream]

[Alistair Grant]

Hi Eliot,


On Mon, 15 Oct 2018 at 18:55, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> On Mon, Oct 15, 2018 at 9:48 AM Alistair Grant <akgrant0710 at gmail.com> wrote:
>>
>> On Mon, 15 Oct 2018 at 16:46, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> >
>> > By “derived” I mean a pointer to some point inside an object, not a pointer to the start of an object.  When one passes eg a ByteArray through the FFI to a reference parameter  the marshaling code ends up passing a pointer to the start of the object.  That won’t work if what we want to do is simulate passing a pointer to the start of a simulation object that actually lives at an offset inside the large ByteArray that constitutes the entire heap in the simulation.  So we need to be able to express a ByteArray, offset pair and pass that through the FFI to a reference parameter and have the marshaling code end up passing the derived a pointer that is the start of the ByteArray plus the offset, and hence end up passing a pointer to the start of the simulation object in the large ByteArray that constitutes the entire heap.
>>
>> As a first step to get things going, couldn't we just copy the
>> ByteArray's to and from the simulation memory?  It would obviously be
>> much less efficient, but would reduce the number of pre-requisites to
>> get started.
>
> Maybe, but I expect it is a very small change to marshaling to spurt this and has high value to the FFI in general

Cool.  My assumption from the way you originally wrote this was that
it would be relatively expensive to develop.


> (think of trying to pass a field embedded in a struct; that's not yet possible; with derived pointers it is; the facility is generally useful).  IME if one can find a simple more general solution to a problem than some other, then pursue that, even if its initial cost maybe higher because it will pay off better in the long run.

I didn't mean to imply that it wouldn't be done, just that it may not
be the first thing done (based on my incorrect assumption that it
would be expensive to develop).

Cheers,
Alistair