*@ Igor*
> As i understand, in general, the problem that you described is in
> following:
> - you want to pass an address of your buffer contents, but started not from
> very first element of your buffer, but somewhere inside a buffer.
Yes ! Exactly that. I'm bad at explaining things :(
Unfortunately, this is the only way how we could implement such, lets say
> 'ElementPointer' safely. Which then can be used to pass to C function(s),
> converting object reference + offset into simple address just before
> invoking a function (and sure thing, knowing that there's no chance
> triggering GC, else it will turn into pointer to wrong place, but that's
> general problem of passing pointers on object memory heap, not just
> exclusively for 'element pointer' and such).
>
Alright, thank you very much for your explanations ! By the way, is there a
way to disable the GC for a short period of time and then re-enable it ?
*@ Henrik*
I am not sure I understand every bit of your code right now but I will
definitely study it because it looks awesome.
Moreover, performance is quite important for me so your solution is very
attractive and I'll try to use it. Thanks a lot !
I find it both fun and amazing what you can do with Pharo. I never thought
I would do assembly inside Pharo !
Again, a big thanks to both of you,
Cheers,
Matthieu
2015-06-09 17:43 GMT+02:00 Igor Stasenko <siguc...@gmail.com>:
> As i understand, in general, the problem that you described is in
> following:
> - you want to pass an address of your buffer contents, but started not from
> very first element of your buffer, but somewhere inside a buffer.
>
> In smalltalk you cannot reference an element of array,
> only the object (array in that case) as a whole.
>
> The reason why it like so, because VM moves objects around, and you cannot
> control directly when that happens,
> and also VM responsible for updating all pointers (references) to moved
> object(s)
> for all interested parties (which could be other objects, stack etc) ,
> making sure all references remain consistent upon such move.
> So, with such constraints, the only way to validly point to an element
> inside array
> would be to store two values separately:
> - a reference to an object, that represent your buffer (which VM would
> update at will)
> - an index (or offset) in that object, pointing to element in your buffer
>
> Unfortunately, this is the only way how we could implement such, lets say
> 'ElementPointer' safely. Which then can be used to pass to C function(s),
> converting object reference + offset into simple address just before
> invoking a function (and sure thing, knowing that there's no chance
> triggering GC, else it will turn into pointer to wrong place, but that's
> general problem of passing pointers on object memory heap, not just
> exclusively for 'element pointer' and such).
>
> For buffers allocated externally, e.g. outside heap governed by VM,
> there's nothing prevents you from having an address that pointing inside
> some buffer (or even outside it :)
>
> For NBExternalAddress:
>
> addr := self allocate: somespace.
>
> newAddr := NBExternalAddress value: addr value + someoffset.
>
> or
>
> newAddr := addr copy value: addr value + someoffset
>
> sure, it is up to you then, how to calculate offsets and buffer size(s) as
> well as allocating/deallocating memory for buffers you using.
>
>
> On 8 June 2015 at 16:41, Matthieu Lacaton <matthieu.laca...@gmail.com>
> wrote:
>
>> Hello everyone,
>>
>> I have a small question about NativeBoost : How does the "+" operator
>> when applied to a pointer translates into NativeBoost code ?
>>
>> To give a bit of context, what I want to do is to reallocate some
>> non-contiguous bytes in memory to a buffer. Basically, I have an array of
>> integers in a buffer and I want to copy some chunks of it in another
>> buffer. The chunks are always the same size and the offset between each
>> chunk is always the same too.
>>
>> Because a bit of actual code is easier to understand here is what I'd
>> like to do in Pharo :
>>
>> ...
>>
>> int i, j;
>> int *data = malloc(1000*sizeof(int));
>> int *newData = malloc(50*sizeof(int));
>>
>> // Allocate initial data
>> for (i = 0 ; i < 1000, i++) {
>> data[i] = i;
>> }
>>
>> //Copy desired chunks into new buffer
>> for (i = 0; i < 5; i++ ) {
>> memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int));
>> j++;
>> }
>>
>> free(data);
>>
>> ...
>>
>> Here basically I'll get in my buffer chunks of 10 integers starting at
>> 200 with an offset of 30 between chunks, and this 5 times. (200 201 202 ...
>> 208 209 230 231 ... 238 239 260 ... 328 329).
>>
>> I am okay with the malloc, memcpy and free but I don't know how to handle
>> the "+" operator in my memcpy function.
>>
>> Thank you,
>>
>> Matthieu
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
