C struct in 32 bits vs 64 bits VM

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

C struct in 32 bits vs 64 bits VM

SergeStinckwich
I try to understand differences between 32 bits and 64 bits FFI support for C structures.

I build a class called MyStruct subclass of FFIExternalStructure.
and define a layout for this structure like this one :

MyStruct class>>fieldsDesc
    "self rebuildFieldAccessors"

    ^ #(
        int index ;)

and then I generate automatically the field accessors.

If I use a 32 bit VM, the following method is generated to access the index field :

index
    "This method was automatically generated"
    ^handle signedLongAt: OFFSET_INDEX

and if I use a 64 bits VM, the same method is generated ...

I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 bits VM, they have different for 64 bits VM (sizeof(int) = 4 and sizeof(long) = 8).

Someone to explain me or this is a bug ?

​Thank you.​

--
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for machines to execute."
http://www.doesnotunderstand.org/
Reply | Threaded
Open this post in threaded view
|

Re: C struct in 32 bits vs 64 bits VM

SergeStinckwich


On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich <[hidden email]> wrote:
I try to understand differences between 32 bits and 64 bits FFI support for C structures.

I build a class called MyStruct subclass of FFIExternalStructure.
and define a layout for this structure like this one :

MyStruct class>>fieldsDesc
    "self rebuildFieldAccessors"

    ^ #(
        int index ;)

and then I generate automatically the field accessors.

If I use a 32 bit VM, the following method is generated to access the index field :

index
    "This method was automatically generated"
    ^handle signedLongAt: OFFSET_INDEX

and if I use a 64 bits VM, the same method is generated ...

I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 bits VM, they have different for 64 bits VM (sizeof(int) = 4 and sizeof(long) = 8).

Someone to explain me or this is a bug ?


​Ok I have understood ...

signedLongAt: method does not return a long as the name seems to indicate but in fact a 32 bits integer.
So it works in both 32 and 64 bits VM.

Maybe signedInt32At: would have been a better name :-) ​
 

--
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for machines to execute."
http://www.doesnotunderstand.org/
Reply | Threaded
Open this post in threaded view
|

Re: C struct in 32 bits vs 64 bits VM

Andres Valloud-4
The relevant spec does not state 'long' is of any particular size.

On 4/19/18 1:24 , Serge Stinckwich wrote:

>
>
> On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     I try to understand differences between 32 bits and 64 bits FFI
>     support for C structures.
>
>     I build a class called MyStruct subclass of FFIExternalStructure.
>     and define a layout for this structure like this one :
>
>     MyStruct class>>fieldsDesc
>         "self rebuildFieldAccessors"
>
>         ^ #(
>             int index ;)
>
>     and then I generate automatically the field accessors.
>
>     If I use a 32 bit VM, the following method is generated to access
>     the index field :
>
>     index
>         "This method was automatically generated"
>         ^handle signedLongAt: OFFSET_INDEX
>
>     and if I use a 64 bits VM, the same method is generated ...
>
>     I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32
>     bits VM, they have different for 64 bits VM (sizeof(int) = 4 and
>     sizeof(long) = 8).
>
>     Someone to explain me or this is a bug ?
>
>
> ​Ok I have understood ...
>
> signedLongAt: method does not return a long as the name seems to
> indicate but in fact a 32 bits integer.
> So it works in both 32 and 64 bits VM.
>
> Maybe signedInt32At: would have been a better name :-) ​
>
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (SU/IRD/UY1)
> "Programs must be written for people to read, and only incidentally for
> machines to execute."
>
> http://www.doesnotunderstand.org/

Reply | Threaded
Open this post in threaded view
|

Re: C struct in 32 bits vs 64 bits VM

Thierry Goubier
In reply to this post by SergeStinckwich


2018-04-19 10:24 GMT+02:00 Serge Stinckwich <[hidden email]>:


On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich <[hidden email]> wrote:
I try to understand differences between 32 bits and 64 bits FFI support for C structures.

I build a class called MyStruct subclass of FFIExternalStructure.
and define a layout for this structure like this one :

MyStruct class>>fieldsDesc
    "self rebuildFieldAccessors"

    ^ #(
        int index ;)

and then I generate automatically the field accessors.

If I use a 32 bit VM, the following method is generated to access the index field :

index
    "This method was automatically generated"
    ^handle signedLongAt: OFFSET_INDEX

and if I use a 64 bits VM, the same method is generated ...

I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 bits VM, they have different for 64 bits VM (sizeof(int) = 4 and sizeof(long) = 8).

Someone to explain me or this is a bug ?


​Ok I have understood ...

signedLongAt: method does not return a long as the name seems to indicate but in fact a 32 bits integer.
So it works in both 32 and 64 bits VM.

Maybe signedInt32At: would have been a better name :-) ​

Maybe this is because long in C does not guarantee 64bits, only long long does.

Thierry

 
 

--
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for machines to execute."
http://www.doesnotunderstand.org/

Reply | Threaded
Open this post in threaded view
|

Re: C struct in 32 bits vs 64 bits VM

SergeStinckwich
In reply to this post by Andres Valloud-4


On Thu, Apr 19, 2018 at 9:30 AM, Andres Valloud <[hidden email]> wrote:
The relevant spec does not state 'long' is of any particular size.


​yes I know this is why we have also a platformLongAt: method.

I was just wondering, why we have a signedLongAt: method that return always a 32 bits int.
Would be better to have be more explicit:

platformIntAt:
platformLongAt:
int32At:
int64At:

and same for unsigned versions.

--
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for machines to execute."
http://www.doesnotunderstand.org/
Reply | Threaded
Open this post in threaded view
|

Re: C struct in 32 bits vs 64 bits VM

Thierry Goubier
In reply to this post by Andres Valloud-4
signed long is now specified as:

 Capable of containing at least the [−2,147,483,647, +2,147,483,647] range;

so at least 32 bits;

and signed long long

Capable of containing at least the [−9,223,372,036,854,775,807,
+9,223,372,036,854,775,807] range [C99]

so at least 64 bits;

and long long size >= long size

So a 32 bits long is legal, as well as a 64bits long, and as well as a
256bits long :)

2018-04-19 10:30 GMT+02:00 Andres Valloud <[hidden email]>:

> The relevant spec does not state 'long' is of any particular size.
>
> On 4/19/18 1:24 , Serge Stinckwich wrote:
>>
>>
>>
>> On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     I try to understand differences between 32 bits and 64 bits FFI
>>     support for C structures.
>>
>>     I build a class called MyStruct subclass of FFIExternalStructure.
>>     and define a layout for this structure like this one :
>>
>>     MyStruct class>>fieldsDesc
>>         "self rebuildFieldAccessors"
>>
>>         ^ #(
>>             int index ;)
>>
>>     and then I generate automatically the field accessors.
>>
>>     If I use a 32 bit VM, the following method is generated to access
>>     the index field :
>>
>>     index
>>         "This method was automatically generated"
>>         ^handle signedLongAt: OFFSET_INDEX
>>
>>     and if I use a 64 bits VM, the same method is generated ...
>>
>>     I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32
>>     bits VM, they have different for 64 bits VM (sizeof(int) = 4 and
>>     sizeof(long) = 8).
>>
>>     Someone to explain me or this is a bug ?
>>
>>
>> Ok I have understood ...
>>
>> signedLongAt: method does not return a long as the name seems to
>> indicate but in fact a 32 bits integer.
>> So it works in both 32 and 64 bits VM.
>>
>> Maybe signedInt32At: would have been a better name :-)
>>
>>
>> --
>> Serge Stinckwich
>> UMI UMMISCO 209 (SU/IRD/UY1)
>> "Programs must be written for people to read, and only incidentally for
>> machines to execute."
>>
>> http://www.doesnotunderstand.org/
>
>

Reply | Threaded
Open this post in threaded view
|

Re: C struct in 32 bits vs 64 bits VM

philippeback
In reply to this post by Thierry Goubier


On Thu, Apr 19, 2018 at 10:32 AM, Thierry Goubier <[hidden email]> wrote:


2018-04-19 10:24 GMT+02:00 Serge Stinckwich <[hidden email]>:


On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich <[hidden email]> wrote:
I try to understand differences between 32 bits and 64 bits FFI support for C structures.

I build a class called MyStruct subclass of FFIExternalStructure.
and define a layout for this structure like this one :

MyStruct class>>fieldsDesc
    "self rebuildFieldAccessors"

    ^ #(
        int index ;)

and then I generate automatically the field accessors.

If I use a 32 bit VM, the following method is generated to access the index field :

index
    "This method was automatically generated"
    ^handle signedLongAt: OFFSET_INDEX

and if I use a 64 bits VM, the same method is generated ...

I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 bits VM, they have different for 64 bits VM (sizeof(int) = 4 and sizeof(long) = 8).

Someone to explain me or this is a bug ?


​Ok I have understood ...

signedLongAt: method does not return a long as the name seems to indicate but in fact a 32 bits integer.
So it works in both 32 and 64 bits VM.

Maybe signedInt32At: would have been a better name :-) ​

Maybe this is because long in C does not guarantee 64bits, only long long does.

Thierry

 
 

--
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for machines to execute."
http://www.doesnotunderstand.org/


Reply | Threaded
Open this post in threaded view
|

Re: C struct in 32 bits vs 64 bits VM

philippeback
In reply to this post by Andres Valloud-4
A C long is guaranteed to be at least 32 bits in size.

long long is guaranteed to be 64 bits.

int depends on the platform.

Phil

On Thu, Apr 19, 2018 at 10:30 AM, Andres Valloud <[hidden email]> wrote:
The relevant spec does not state 'long' is of any particular size.

On 4/19/18 1:24 , Serge Stinckwich wrote:


On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich
<[hidden email] <mailto:[hidden email]>> wrote:

    I try to understand differences between 32 bits and 64 bits FFI
    support for C structures.

    I build a class called MyStruct subclass of FFIExternalStructure.
    and define a layout for this structure like this one :

    MyStruct class>>fieldsDesc
        "self rebuildFieldAccessors"

        ^ #(
            int index ;)

    and then I generate automatically the field accessors.

    If I use a 32 bit VM, the following method is generated to access
    the index field :

    index
        "This method was automatically generated"
        ^handle signedLongAt: OFFSET_INDEX

    and if I use a 64 bits VM, the same method is generated ...

    I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32
    bits VM, they have different for 64 bits VM (sizeof(int) = 4 and
    sizeof(long) = 8).

    Someone to explain me or this is a bug ?


​Ok I have understood ...

signedLongAt: method does not return a long as the name seems to
indicate but in fact a 32 bits integer.
So it works in both 32 and 64 bits VM.

Maybe signedInt32At: would have been a better name :-) ​


--
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."

http://www.doesnotunderstand.org/