bug#14599: An option to make vector allocation aligned

[Jan Schukat <shookie@email.de>]

On 06/14/2013 03:33 AM, Daniel Hartwig wrote:
> On 13 June 2013 21:31, Ludovic Courtès <ludo@gnu.org> wrote:
>> Jan Schukat <shookie@email.de> skribis:
>>> The other question is the read syntax (one of the primary reasons I'm
>>> doing all this). If alignment is something that should be preserved in
>>> the permanent representation, you also need to store it in the flags,
>>> since the content pointer can be aligned by coincidence. I haven't
>>> looked at the compiling of bytevectors yet, to see if alignment can be
>>> handled easily there.
>> I agree that we’d need some sort of annotation to specify the alignment
>> of literals, but adding read syntax for that scares me somewhat.  What
>> do people think?
> I agree.  The read syntax for vector-ish types in guile is already
> large enough.  If alignment is important then use a procedural
> constructor and query.
>
> Alignment information not need to be printed with the default
> representation (read syntax), we dont also print the storage address,
> etc..
>
> Regards
  The more I think about it and hear what you have to say, the more I 
think alignment just needs to be tied to the type of the uniform array. 
Up to float and int 32 arrays nothing will change then. Double and int64 
arrays get one word of padding on 32 bit machines to make them 8 byte 
aligned. And then introduce new type flags m128 and m256 for for simd 
types that are 16 or 32 byte bit aligned, possibly the complex arrays 
too. Since you can interpret uniform arrays as all types of uniform 
array this should solve all alignment problems where needed. The simd 
type arrays must be able to accept and recognize int and float 
immediates though, and you must be able to group them. That's not really 
much new syntax, and won't interfere with the old syntax.

Also, now I lean more towards switching to 2.2 for myself and implement 
it on there, because as Ludovic said, the compiling will possibly 
preserve alignment there better.

Regards

Jan Schukat