[Vm-dev] [Pharo-dev] [NB] Trying to implement a ReadStream on NBExternalAddress

[Nicolas Cellier]

Alignment apart, one thing that could be useful is the ability to pass the
address of a byte array, offsetted at will.
For example, I have an array of unboxed double complex
(real0,imaginary0,real1,imaginary1,...)
And I want to copy the imaginary part only in another location.
Blas provides enough methods for that, I just need to pass
- ByteArray adress+8 bytes (+1 sizeof double)
- half array length
- and a stride of 16 bytes (2 size of double).
In most Smalltalk dialects, this is currently only possible with External
Heap, but not with Smalltalk managed memory...
OK, some guru will tell me to do it with BitBlt, but ther must be something
easier...

I feel like this would open many possibilities for interpreting low level
languages
(like invoking some primitives on emulated memory blob).


2013/9/25 Eliot Miranda <eliot.miranda at gmail.com>

>
> Hi Tim, Hi All,
>
> On Wed, Sep 25, 2013 at 12:46 PM, tim Rowledge <tim at rowledge.org> wrote:
>
>>
>>
>> On 25-09-2013, at 11:36 AM, Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>>
>> > On Wed, Sep 25, 2013 at 10:39 AM, tim Rowledge <tim at rowledge.org>
>> wrote:
>> >
>> >
>> > On 25-09-2013, at 9:30 AM, Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>> >
>> > >  Off the top of my head it may need the memory manager to add a
>> "sliver" object type, an 8-byte header with no fields, that is collected by
>> coallescing with adjacent free blocks, that can fill in the 8-byte gaps
>> aligning pinned objects on 16 byte boundaries would create.  I'll think
>> about this.
>> > >
>> >
>> > Wild-ass suggestion; would it work to allocate the relevant object
>> (which I'm assuming here is essentially an UninterpretedBytes) with an
>> 'extra' 8 bytes and then store the 'real' bits at the right place to have
>> the 16byte boundary? Yes, there would have to be magic to signify where the
>>  real start of data is. Yes, it would potentially change on scavenge, but
>> since these are largely pinned, not such a big issue maybe?
>> >
>> > In general that's a bad idea because it loads the frequent path
>> (accessing the object) with the work, unloading the infrequent path
>> (pinning the object).  It can't happen during scavenge because by
>> definition pinned objects are not in new space.  hence I think the time to
>> take the hit is on pinning (an infrequent operation).  Make sense?
>>
>> Almost always. But it's worth throwing wild ideas around occasionally
>> just to see if they stick to the blanket.
>>
>
> Yes!!  I was almost going to post something on just this point.  Thanks
> for the prompt.  I want to encourage everyone to throw ideas out there
> without fear of their being proved wrong.  Discussing the ideas has great
> value whether or not they;re right.  The other day Clement had a good idea
> about become.  I'd not thought about the issue he brought up before, and
> his suggestion, even though I don't think it'll work, made me think about
> the issue and helped clarify my thinking.  So yes, please keep throwing out
> those ideas.  And don't get discouraged by critical responses.
>
>
>> How about two subclasses - one for each possible 8byte alignment? The FFI
>> code only gets a ptr to the right place anyway, so it won't care. Accessor
>> methods would be minimally different for the two subclasses and handle the
>> offset for ST code. Compacting, if it ever touched instances, would swap
>> the class if required. How's that for adaptive optimisation ;-)
>>
>
> That could work, but offends my sense of the separation between the system
> and the VM.  So I don't feel like going there :-)
>
>
>> Or how about simply not allocating the actual memory in object space? I
>> know it can be a pain but perhaps it's less of a pain in the end.
>>
>
> That one can always do.  The FFI will always provide some sort of
> interface to malloc and/or valloc (even if it is as primitive as actually
> calling those functions).  But the question for Spur is what facilities it
> should provide and I want to provide something much easier to use (i.e.
> pinned ByteArrays and the like).
>
> --
> cheers,
> Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130925/c4b00feb/attachment.htm