bug#14599: An option to make vector allocation aligned

[Jan Schukat]

Hello again :)


On 06/12/2013 10:37 PM, Andy Wingo wrote:
> On Wed 12 Jun 2013 15:37, Jan Schukat <address@hidden> writes:
>
> > If you want to access native uniform vectors from c, sometimes you
> > really want guarantees about the alignment.
> 16 bytes I guess?  Guile's uniforms are 8-byte-aligned by default, as
> you probably know.

Yes, 16 bytes. But more could be useful too. And as I have stated in my 
previous mail, the first element of the vector is guaranteed to be 4 
byte aligned on 32 bit machines, because it starts directly after the 3 
word header, which is allocated at 8 byte boundaries. And yes, I have 
tested this, but should be obvious from the code too.



> Just wondering if there is a better default.
>
> > +#ifdef SCM_VECTOR_ALIGN
> > +      contents = scm_gc_malloc_pointerless (SCM_BYTEVECTOR_HEADER_BYTES
> > + c_len + SCM_VECTOR_ALIGN,
> > +                        SCM_GC_BYTEVECTOR);
> > +      ret = PTR2SCM (contents);
> > +      contents += SCM_BYTEVECTOR_HEADER_BYTES;
> > +      contents += (addr + (SCM_VECTOR_ALIGN - 1)) & -SCM_VECTOR_ALIGN;
> > +#else
> >         contents = scm_gc_malloc_pointerless (SCM_BYTEVECTOR_HEADER_BYTES
> > + c_len,
> >                           SCM_GC_BYTEVECTOR);
> >         ret = PTR2SCM (contents);
> >         contents += SCM_BYTEVECTOR_HEADER_BYTES;
> > +#endif
> This is somewhat dangerous, as you could lose the pointer to the start,
> and then the contents get collected.
>
> I guess this can be fixed in master, if you set the "holder" field on a
> bytevector to the actual memory that you allocate.

Don't really understand the danger here, isn't this allocated as a whole 
block and only collected as a whole block too? What am I missing?

Having the arrays aligned according to their type by default could be a 
nice option, i.e. a word of padding for long and doubles on 32 bit 
machines, and then also introducing a new 16byte simd128 and 32 byte 
simd256 type id and their respective creation functions.


Regards

Jan Schukat