[squeak-dev] FFI | Byte alignment

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri May 29 15:37:54 UTC 2020


Found a 32bits debian VM:

st at debi9:~$ gcc test_align.c
st at debi9:~$ ./a.out
size of x = 16
size of y = 16

So keep the code, just correct it!

Le ven. 29 mai 2020 à 17:01, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> a écrit :

> Try with this:
>
> cat > test_align.c <<END
> #include <stdio.h>
>
> struct foo1 {int a; long long b; int d;};
> struct foo2 {int a; double c; int d;};
>
> int main() {
> struct foo1 x;
> struct foo2 y;
> printf("size of x = %d\n",sizeof(x));
> printf("size of y = %d\n",sizeof(y));
> return 0;
> }
> END
> i686-w64-mingw32-gcc test_align.c
>  ./a.exe
>
> size of x = 24
> size of y = 24
>
> so at leat in windows (mingw) the alignment is 8 bytes for both long long
> and double.
> I have no 32bits linux handy, but it should be easy enough to pass the
> same test...
>
> Le ven. 29 mai 2020 à 16:45, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> a écrit :
>
>> Good catch!
>> Wikipedia page does not even agree on longlong... But it's not the
>> ultimate normative reference, better check by ourselves!
>> https://en.wikipedia.org/wiki/Data_structure_alignment
>>
>> Le ven. 29 mai 2020 à 15:53, Marcel Taeumel <marcel.taeumel at hpi.de> a
>> écrit :
>>
>>> Hi, there.
>>>
>>> In ExternalType class >> #initializeAtomicTypes, there is an interesting
>>> claim and a piece of dead code:
>>>
>>> "On 32 bits Windows and MacOS, double and long have an alignment of 8.
>>> But on Linux, their alignment is 4"
>>> (Smalltalk wordSize = 4 and: [Smalltalk platformName = 'unix']) ifTrue: [
>>> (#('double longlong ulonglong') includes: typeName) ifTrue: [
>>> byteAlignment := 4
>>> ]
>>> ].
>>>
>>> As you can see, there are single quotes missing and so will the path
>>> "byteAlignment  := 4" never be reached.
>>>
>>> I tried to figure out whether one should either fix the conditional or
>>> remove the entire passage. Maybe this got long fixed inside the FFI plugin?
>>>
>>> Best,
>>> Marcel
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200529/39b8fc1b/attachment.html>


More information about the Squeak-dev mailing list