bug#14599: An option to make vector allocation aligned

[Jan Schukat]

Hello,

If you want to access native uniform vectors from c, sometimes you 
really want guarantees about the alignment.

Fortunately the the (byte)vector format and allocation makes that pretty 
easy to implement: just add a little padding between the header and the 
actual data.

So for my own project, this is what I'm doing, and there shouldn't be 
much of a memory impact unless there are tons of small vectors used, 
which isn't very lispy anyway.

This isn't necessarily true for vectors created from pre-existing 
buffers (the take_*vector functions), but there you have control over 
the pointer you pass, so you can make it true if needed.

So if there is interest, maybe this could be integrated into the build 
system as a configuration like this:


--- libguile/bytevectors.c    2013-04-11 02:16:30.000000000 +0200
+++ bytevectors.c    2013-06-12 14:45:16.000000000 +0200
@@ -223,10 +223,18 @@

       c_len = len * (scm_i_array_element_type_sizes[element_type] / 8);

+#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

       SCM_BYTEVECTOR_SET_LENGTH (ret, c_len);
       SCM_BYTEVECTOR_SET_CONTENTS (ret, contents);


It could even be possible to make the alignment a run-time decision, but 
for that the api and read syntax for vectors need to be extended. Which 
could be worthwhile ...

Apart from that, I see there are issues with the native mingw builds 
again, which I haven't noticed earlier since I primarily develop on 
linux, but I can reproduce the problem shown in #14361.


Regards

Jan Schukat