CStruct ABI and packed structs

Hi again,

I had some time to browse through the CStruct code and I think it is
really nice. There are two issues for my intended usecase and I wanted
to ask what to do about it.

1.) The alignment rules of the type are inside the type itself, but in
general this is coming from the ABI. E.g. one case (it might not apply
to smalltalk) is that 64 bit types have a 8 byte alignment on ARM EABI
and 4 byte on the old ABI...

2.) The structs I showed are all packed and should not follow the
alignment rules...


I would like to move the alignof out of the type classes and into an ABI
class and at first step contain the alignment rules we have right now,
the second thing would be to create a CPackedStruct subclass which will
ignore the alignment rules. I would change the CStruct to make
subclassing more easy.

does this make sense?
        z.

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/06/2010 10:48 AM, Holger Hans Peter Freyther wrote:

>
> 2.) The structs I showed are all packed and should not follow the
> alignment rules...

This also creates the need for the #value selector to deal with
unaligned memory access... for architectures that need it.

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/06/2010 04:56 AM, Holger Hans Peter Freyther wrote:
> On 06/06/2010 10:48 AM, Holger Hans Peter Freyther wrote:
>
>>
>> 2.) The structs I showed are all packed and should not follow the
>> alignment rules...
>
> This also creates the need for the #value selector to deal with
> unaligned memory access... for architectures that need it.

Apart from this, the packed struct class would simply be

^L
CCompound subclass: CPackedStruct [

     <shape: #word>
     <category: 'Language-C interface'>
     <comment: nil>

     CPackedStruct class >> declaration: array [
         "Compile methods that implement the declaration in array."

         <category: 'subclass creation'>
         self
             declaration: array
             inject: self superclass sizeof
             into: [:oldOffset :alignment | oldOffset]
     ]
]



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/06/2010 04:48 AM, Holger Hans Peter Freyther wrote:
Replying to this more extensively.  The abstract class you're looking
for is probably already there -- CCompound.

I'll look into making a primitive for unaligned accesses.  Right now I
prefer to stick to bugfixes only for the git repository (and I would
like to have all 3.2.x images run on 3.2.y, so no new primitives), but I
can queue it for 3.3.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/07/2010 01:23 AM, Paolo Bonzini wrote:

>
> Replying to this more extensively.  The abstract class you're looking
> for is probably already there -- CCompound.
>
> I'll look into making a primitive for unaligned accesses.  Right now I
> prefer to stick to bugfixes only for the git repository (and I would
> like to have all 3.2.x images run on 3.2.y, so no new primitives), but I
> can queue it for 3.3.

Hi Paolo,

thanks for your both replies. At this point I only looked for guidance
of doing the right thing.

So my plan right now:
        - Test the new class you posted
        - Add stdint.h types to cint.h enum and code
        - Add these to CObject.st
        - Attempt to add bitfields
        - Maybe start on the CPP/C Parser and see if what is missing to
          parse our header files.

does this make sense? I know it is not a lot, the two problems I have
are time and still not being a smalltalk expert.

thanks
        z.

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/07/2010 03:30 AM, Holger Hans Peter Freyther wrote:
> - Add stdint.h types to cint.h enum and code
 > - Add these to CObject.st

It shouldn't be necessary to add all of stdint.h.  You just need to add
long long (i.e. hardcoded 64-bit) values.  Then, all values except
#long/#ulong trivially map to one intXX_t/uintXX_t and you just need to
cut/paste classes and CDATA_* values.

You can even do this last, since it would only take some
search-and-replace to change your header file parser

> - Attempt to add bitfields

This is not hard if you do it entirely in CStruct.  It may require some
small refactoring, but nothing incredibly difficult.  For the syntax I
suggest:

     #( ....
        ((#bitfield1  3)
         (#bitfield2  4)
         (#bitfield3  1)) #uint)

since in non-packed structs the type will give you the alignment.

Feel free to add methods like

Integer extend [
     truncateToBits: n [
         "Keep the lowest N bits of the receiver."
         ^self bitAnd: (1 bitShift: n) - 1
     ]

     signExtendToBits: n [
         "Keep the lowest N bits of the receiver and sign extend them
          using two's complement."
         | mask |
         mask := 1 bitShift: n - 1.
         ^(self bitAnd: mask - 1) - (self bitAnd: mask)
     ]
]

> - Maybe start on the CPP/C Parser and see if what is missing to
>            parse our header files.

The C parser is a bit hard mostly because there is no documentation on
its state (I found none in 1.1.5).  I think it's simpler to try to whip
out a simple converter in Perl or awk, like it was done for the GTK+
bindings.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/06/2010 09:35 AM, Paolo Bonzini wrote:

      compileSize: size align: alignment [
          super compileSize: size align: 1
      ]

> ]


is there a place for CPackedStruct in the GST Kernel? Somewhere else?

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 10/15/2010 05:55 PM, Holger Hans Peter Freyther wrote:
>
> is there a place for CPackedStruct in the GST Kernel? Somewhere else?

There is; however, it's a bit more tricky than this, because access to
unaligned members will trap on some architectures.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 10/15/2010 06:14 PM, Paolo Bonzini wrote:
> On 10/15/2010 05:55 PM, Holger Hans Peter Freyther wrote:
>>
>> is there a place for CPackedStruct in the GST Kernel? Somewhere else?
>
> There is; however, it's a bit more tricky than this, because access to
> unaligned members will trap on some architectures.

Sure, would you want to patch it in the 'value' implementations? or somewhere
in the C code? Would you want to introduce 'parallel' types that can handle
unaligned access? CArray -> CArrayUnaligned?



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 10/15/2010 06:17 PM, Holger Hans Peter Freyther wrote:
Not really CArrayUnaligned, because those are compound types.  But yes,
CIntUnaligned and friends would be needed so that the right alignment is
also propagated to the fields (you want "packedStruct field alignof ==
1" always).

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk