<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Alistair,<div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 15, 2018 at 10:37 AM Alistair Grant <<a href="mailto:akgrant0710@gmail.com">akgrant0710@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Hi Eliot,<br><br>
On Mon, 15 Oct 2018 at 18:55, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
> On Mon, Oct 15, 2018 at 9:48 AM Alistair Grant <<a href="mailto:akgrant0710@gmail.com" target="_blank">akgrant0710@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, 15 Oct 2018 at 16:46, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
>> ><br>
>> > 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.<br>
>><br>
>> As a first step to get things going, couldn't we just copy the<br>
>> ByteArray's to and from the simulation memory? It would obviously be<br>
>> much less efficient, but would reduce the number of pre-requisites to<br>
>> get started.<br>
><br>
> Maybe, but I expect it is a very small change to marshaling to spurt this and has high value to the FFI in general<br>
<br>
Cool. My assumption from the way you originally wrote this was that<br>
it would be relatively expensive to develop.<br></blockquote><div><br></div><div>Taking a superficial look at the code I see this in ffiAtomicArgByReference:Class:in:</div><div><br></div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>(atomicType = FFITypeVoid or:[(atomicType >> 1) = (FFITypeSignedByte >> 1)]) ifTrue:</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>"byte* -- see comment on string above"</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>[(isString or: [oopClass = interpreterProxy classByteArray]) ifTrue: "String/Symbol/ByteArray"</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>[^self ffiPushPointer: (interpreterProxy firstIndexableField: oop) in: calloutState].</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>(oopClass = interpreterProxy classExternalAddress) ifTrue: </div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>[^self ffiPushPointer: (self longAt: oop + interpreterProxy baseHeaderSize) in: calloutState].</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>isAlien ifTrue:</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>[^self ffiPushPointer: (self pointerForOop: (self startOfData: oop)) in: calloutState].</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>atomicType = FFITypeVoid ifFalse:</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>[^FFIErrorCoercionFailed]].</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>"note: type void falls through"</div></div><div><br></div><div>which could be extended, crudely, with</div><div><br></div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>(oopClass = interpreterProxy classArray</div><div><span style="white-space:pre"> and: [(</span>interpreterProxy slotSizeOf: oop) = 2</div><span style="white-space:pre"> and: [(</span>interpreterProxy isWordsOrBytes: (obj := interpreterProxy fetchPointer: 0 ofObject: oop))<div><span style="white-space:pre"> and: [(</span>interpreterProxy isInteger: (offset := interpreterProxy fetchPointer: 1 ofObject: oop))</div><div><span style="white-space:pre"> and: [(offset := </span>interpreterProxy integerValueOf: offset) between: 0 and: (interpreterProxy byteSizeOf: obj)]]]<span style="white-space:pre">]</span>) ifTrue: </div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>[^self ffiPushPointer: (interpreterProxy firstIndexableFieldOf: obj) + offset in: calloutState].</div></div><div><br></div><div>and something analogous could be done in ffiPushPointerContentsOf:in:, which is sent via ffiAtomicStructByReference:Class:in:. But simply passing a derived pointer as a tuple of object, offset might be a poor design. We might want to add a specific class to the FFI, DerivedPointerArgument or some such. So I think the implementation is extremely cheap; it is the design that vexes (HHGTTG: You haven't even invented the wheel yet! Well, no. Maybe you can tell us. What color should it be?)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> (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.<br>
<br>
I didn't mean to imply that it wouldn't be done, just that it may not<br>
be the first thing done (based on my incorrect assumption that it<br>
would be expensive to develop).<br>
<br>
Cheers,<br>
Alistair<br>
</blockquote></div><div><br></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>