FFI: FFI-Kernel-mt.113.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

FFI: FFI-Kernel-mt.113.mcz

commits-2
Marcel Taeumel uploaded a new version of FFI-Kernel to project FFI:
http://source.squeak.org/FFI/FFI-Kernel-mt.113.mcz

==================== Summary ====================

Name: FFI-Kernel-mt.113
Author: mt
Time: 18 June 2020, 2:40:14.824118 pm
UUID: 556bf79d-15a2-f340-9586-a0333f091288
Ancestors: FFI-Kernel-mt.112

Avoid copying external structs that are part of other structs from external memory into object memory.

=============== Diff against FFI-Kernel-mt.112 ===============

Item was added:
+ ----- Method: ExternalAddress>>structAt:length: (in category 'accessing') -----
+ structAt: byteOffset length: length
+ "Return the external address of the struct's first field. Ignore length."
+ ^ self + byteOffset!

Item was added:
+ ----- Method: ExternalAddress>>structAt:put:length: (in category 'accessing') -----
+ structAt: byteOffset put: externalAddress length: length
+ "Read length bytes from externalAddress and write it at this external address (plus byteOffset)."
+
+ | start |
+ start := self + byteOffset.
+ 1 to: length do: [:targetOffset |
+ start
+ byteAt: targetOffset
+ put: (externalAddress byteAt: targetOffset)].!


Reply | Threaded
Open this post in threaded view
|

Re: FFI: FFI-Kernel-mt.113.mcz

Nicolas Cellier
ignored length does make me think of it...
IMO, we should manipulate bounded pointers when possible.
That is, address + byteLength.
Most of the time, we know the length (when we allocated ourselves, when we have a pointer to scalar, etc...).

Le jeu. 18 juin 2020 à 14:45, <[hidden email]> a écrit :
Marcel Taeumel uploaded a new version of FFI-Kernel to project FFI:
http://source.squeak.org/FFI/FFI-Kernel-mt.113.mcz

==================== Summary ====================

Name: FFI-Kernel-mt.113
Author: mt
Time: 18 June 2020, 2:40:14.824118 pm
UUID: 556bf79d-15a2-f340-9586-a0333f091288
Ancestors: FFI-Kernel-mt.112

Avoid copying external structs that are part of other structs from external memory into object memory.

=============== Diff against FFI-Kernel-mt.112 ===============

Item was added:
+ ----- Method: ExternalAddress>>structAt:length: (in category 'accessing') -----
+ structAt: byteOffset length: length
+       "Return the external address of the struct's first field. Ignore length."
+       ^ self + byteOffset!

Item was added:
+ ----- Method: ExternalAddress>>structAt:put:length: (in category 'accessing') -----
+ structAt: byteOffset put: externalAddress length: length
+       "Read length bytes from externalAddress and write it at this external address (plus byteOffset)."
+       
+       | start |
+       start := self + byteOffset.
+       1 to: length do: [:targetOffset |
+               start
+                       byteAt: targetOffset
+                       put: (externalAddress byteAt: targetOffset)].!




Reply | Threaded
Open this post in threaded view
|

Re: FFI: FFI-Kernel-mt.113.mcz

marcel.taeumel
Hi Nicolas!

IMO, we should manipulate bounded pointers when possible.

That's what this change enables now when navigating through fields of external structs that sit in external memory.

We could add such pointer arithmetic to ExternalData, too, to extract "sub arrays". SequenceableCollection has #copyFrom:to: ... maybe that would return a copy in Squeak's object memory. ... and #from:to: would just give us more limited access to external data. Like this:

someInts := ExternalData
    fromHandle: externalAddress
    type: ExternalType int asPointerType.

someInts  size: 100. "Suppose we know that from somewhere"

subset := someInts from: 5 to: 40. "answer a new ExternalData object with size = 36"
subsetCopy .= someInts copyFrom: 5 to: 40. "answer ExternalData with ByteArray as handle, i.e., a copy"

... maybe such copies could directly answer RawBitsArray instances ...

Best,
Marcel

Am 18.06.2020 15:00:48 schrieb Nicolas Cellier <[hidden email]>:

ignored length does make me think of it...
IMO, we should manipulate bounded pointers when possible.
That is, address + byteLength.
Most of the time, we know the length (when we allocated ourselves, when we have a pointer to scalar, etc...).

Le jeu. 18 juin 2020 à 14:45, <[hidden email]> a écrit :
Marcel Taeumel uploaded a new version of FFI-Kernel to project FFI:
http://source.squeak.org/FFI/FFI-Kernel-mt.113.mcz

==================== Summary ====================

Name: FFI-Kernel-mt.113
Author: mt
Time: 18 June 2020, 2:40:14.824118 pm
UUID: 556bf79d-15a2-f340-9586-a0333f091288
Ancestors: FFI-Kernel-mt.112

Avoid copying external structs that are part of other structs from external memory into object memory.

=============== Diff against FFI-Kernel-mt.112 ===============

Item was added:
+ ----- Method: ExternalAddress>>structAt:length: (in category 'accessing') -----
+ structAt: byteOffset length: length
+       "Return the external address of the struct's first field. Ignore length."
+       ^ self + byteOffset!

Item was added:
+ ----- Method: ExternalAddress>>structAt:put:length: (in category 'accessing') -----
+ structAt: byteOffset put: externalAddress length: length
+       "Read length bytes from externalAddress and write it at this external address (plus byteOffset)."
+       
+       | start |
+       start := self + byteOffset.
+       1 to: length do: [:targetOffset |
+               start
+                       byteAt: targetOffset
+                       put: (externalAddress byteAt: targetOffset)].!