On Tue, 05 Jan 2010 22:13:28 +0200, Andreas Raab <andreas.raab at gmx.de>  
wrote:

> vagy wrote:
>> Thanx for the tip. I saw your code, though i was thinking more
>> along the lines of having a standard DoubleArray implementation in the  
>> image
>> as we have for 32bit Floats. I just saw that FloatArray is implemented  
>> in
>> terms of variableWordSubclass but there is no variableDoubleWordSubclass
>> which, at first glance, may make the whole issue of having a standard
>> DoubleArray non trivial. I think we need the opinion of a VM expert  
>> here.
>> In any way, what do you think about having a standard DoubleArray?
>
> You're right it's nontrivial, at least for the current object model.  
> Many platforms have 8 byte alignment requirements for doubles and our  
> oops are only 4 byte aligned. This is the main reason why there isn't a  
> double array - since garbage collector will move objects around there is  
> absolutely no guarantee that the double array will be 8 byte aligned.  
> And having a double array that the code in the VM needs to shift to  
> align properly would completely defeat the purpose of having it in the  
> first place. This may change with the move to 64 bit or perhaps with  
> some of Eliot's ideas about changing the object format, but it's nothing  
> that is going to happen in the short term.
>
> Cheers,
>    - Andreas

I see, thanx for the info. Well then i'll put DoubleArrays on hold for now
and craft something special for my project's use case.
Did you take a look at the other issues i raised about FFI? (i can't paste  
a
link to the relevant message at the moment because the message archive  
server
is down). But I would definitely like a word from you before going on with  
it.
In a nutshell:
- Being able to change single values (and not only the values contained in  
Arrays)
   when passed down to C through pointer arguments
   (for instance if you pass down an Integer through a long* argument, FFI  
tells
   you that you cant treat an Integer like a pointer, when the intended  
usage is
   treating it like in C, i.e. change the value of the pointed memory)
- Have FFI helper functions (that a C client can link against) that create
   whatever Smalltalk Arrays FFI is able to handle (this is inspired from  
Java's JNI)
- Expose interpreterProxy through FFI for advanced uses (sic!) :-)
   (Though i don't completely understand the consequences of that and it  
feels a little
   bit dangerous)

Cheers
  - Vagelis