Hi there,

While adding support for handling keyboard events to the SDL bindings
(see the attached patch; it's not for applying, as the documentation is
lacking and the interface exposes too many details), I discovered that
the alignment of members within a struct matters quite a bit.

That is, to make the keyed struct work correctly, I had to add extra
bytes of padding in the appropriate places.  This works, at least on my
platform, but I'm not sure how portable it is.

If you have the SDL headers installed on your system, I'm trying to make
the Parrot equivalent of an SDL_Event, the mess that it is.  In
particular, I added one byte of padding before keysym and three bytes
before keysym.sym.

Is this indeed unportable?  If so, is there a way to work around this
without writing C code for every afflicted structure?  Is it a case of
making the struct PMCs smarter?  Or have I fixed it with my nasty
workaround?

-- c

sdl_key_events.patch 4K Download

        set layout['member'], .DATATYPE_INT
        push layout, 0
        push layout, 0
        set layout['alignedmember'], .DATATYPE_UINT16
        push layout, 0
        push layout, 'align'

Maybe that's not the right interface, but I'd like something nearly that
simple.

Is this one for the TODO list, or did I catch a pumpking in good
humours?

-- c

Its basically an one-liner in unmanagedstruct.pmc:205

 if (offs == 0 && toff % data_size)
  advance (offs, toff) to data_size alignment

        typedef struct {
                Uint8 type; /* SDL_KEYDOWN or SDL_KEYUP */
                Uint8 which;    /* The keyboard device index */
                Uint8 state;    /* SDL_PRESSED or SDL_RELEASED */
                SDL_keysym keysym;
        } SDL_KeyboardEvent;

SDL_keysym itself is a struct:

        typedef struct {
                Uint8 scancode;         /* hardware specific */
                SDLKey sym;         /* SDL virtual keysym */
                SDLMod mod;         /* current key modifiers */
                Uint16 unicode;         /* translated character */
        } SDL_keysym;

SDLKey and SDLMod are both enums.

As I understand it (and correct me if I'm wrong), SDL_keysym needs a
byte of padding on my architecture within SDL_KeyboardEvent.  I can add
that padding manually, but I'm not convinced that'll be portable to
different architectures.

That's the kind of padding I'd like unmanagedstruct.pmc to be able to do
for me.

-- c

But I'd say that there are four adjacent Uint8 taking one word, then is
another word (SDLkey sym). Or a structure starts aligned ...

We don't have a notion of nested structures. They could go just inline,
i.e. without extra syntax. Pointers to structures are of course missing
too, that's a different thingy.

#include <stdio.h>
#include <stdlib.h>
#include <SDL/SDL_events.h>

int main ()
{
    SDL_KeyboardEvent kbevent;
    printf( "0x%08X event\n", &kbevent );
    printf( "0x%08X event.type\n", &kbevent.type );
    printf( "0x%08X event.which\n", &kbevent.which );
    printf( "0x%08X event.state\n", &kbevent.state );
    printf( "0x%08X event.keysym.scancode\n", &kbevent.keysym.scancode
);
    printf( "0x%08X event.keysym.sym\n", &kbevent.keysym.sym );
    printf( "0x%08X event.keysym.mod\n", &kbevent.keysym.mod );
    printf( "0x%08X event.keysym.unicode\n", &kbevent.keysym.unicode );
    return(0);

0x7FFFF7E8 event
0x7FFFF7E8 event.type
0x7FFFF7E9 event.which
0x7FFFF7EA event.state
0x7FFFF7EC event.keysym.scancode
0x7FFFF7F0 event.keysym.sym
0x7FFFF7F4 event.keysym.mod
0x7FFFF7F8 event.keysym.unicode

-- c

i recall an old trick i learned to get offsets into structs which would
be easier to read than hex addresses:

  c> int main ()
  c> {
  c>     SDL_KeyboardEvent kbevent;
  c>     printf( "0x%08X event\n", &kbevent );
  c>     printf( "0x%08X event.type\n", &kbevent.type );

<untested>

        printf( "%d event.type\n", (char *)&kbevent.type ) - (char *)&kbevent ;

it can be made into a macro IIRC for ease of use.

that could be done with a perl script for any structure and it could
generate an offset map for the given environment. that map could be used
by parrot to access members in a portable way.

so the script would parse a structure, generate a set of those prints
(with the right format output) and compile it with the same tools as
parrot. run that little c program and save the output in a file. parrot
reads that file and uses it as a name to offset map for that structure.

want me to hack up this little script and c generation stuff? the hard
part is parsing the struct so i would have to assume some simple format
and not full c for the moment. the only thing needed by the parser is
all the member names.

uri

--
Uri Guttman  ------  u...@stemsystems.com  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

is used inside parrot/jit/*

I thought of that too. A Perl script that takes a C struct and emits an
*ManagedStruct initializer. WRT align: as such struct initializers are
in library code and used by different machines, I'd rather have the
alignment calculation inside the unmanagedstruct.pmc.

But as a last resort this script could regenerate the offsets for a
particular machine.

## &gen_struct()
#  struct event_t {
#     char x;      /* optional comment */
#     char y;
#     int  flags;
#  };
## &end_gen

## autogenerated from above template
## don't modifiy - rerun gen_struct $file
   .local pmc event_t_struct_init
   .include "datatypes.pasm"
   event_t_struct_init = new .OrderedHash
   event_t_struct_init["x"] = .DATATYPE_CHAR  # optional comment
   event_t_struct_init[1] = 0    # no array of items
   event_t_struct_init[2] = 0    # automatic offset
   event_t_struct_init["y"] = .DATATYPE_CHAR
   event_t_struct_init[4] = 0    # no array of items
   event_t_struct_init[5] = 0    # automatic offset
   event_t_struct_init["flags"] = .DATATYPE_INT
   event_t_struct_init[7] = 0    # no array of items
   event_t_struct_init[8] = 0    # automatic offset _or_ 4/8
## end autogen

  gen_struct --force-align file.imc

could fill in the correct offset in the last line.
Running gen_struct the first time should produce the autogenerated part.

For PASM only, it could look like:

## &gen_struct(P23)
...
   new P23, .OrderedHash
   set P23["x"],  ...

You might have a look at F<runtime/parrot/include/datatypes.pasm> which
is autogenerated too. *Struct.pmc doesn't yet handle all types, but this
will be fixed.

Nested structs are ugly. The alignment of the first item seems to depend
on the biggest item in the struct.

   struct {
     char          // 0
     struct {
       char        // 1
     }
     char          // 2
   }

   struct {
     char          // 0
     struct {
       char        // 4
       int         // 8
     }
   }

So we need some notion of nested structs or a hint for correct
alignment. I've checked in basic alignment handling for "normal"
cases, but not the second one above.

Below is a test program to experiment with that stuff.

leo

#include <stdlib.h>
#include <stddef.h>
#include <stdio.h>

// offsetof expands to ((size_t) &(( struct xt  *)0)->  x )

struct xt {
        char x;
        struct yt {
                char i;
                int  j;   // use different items here
        } _y;
        char z;

The problem is nested structs, s. classes/unmanagedstruct.pmc for some
comments and the test program in another f'up in this thread.

$gcc-source/stor-layout.c seems to deal with that, but its a bit
unreadable :)

leo

leo

Tim.

  LT> Nested structs are ugly. The alignment of the first item seems to depend
  LT> on the biggest item in the struct.

that is a known rule for alignment of nested structs. since larger items
usually have strict alignment requirements on many platforms (misaligned
accesses either fail with bus faults or pay a massive penalty as on the
alpha), the compiler has to align the whole struct so that item will be
aligned. it can't just pad internally since that could vary. a char
followed by a 32 bit item could need 1,2, or 3 bytes of padding
depending on where the struct starts. so cc will force that struct to 32
bit alignement and pad 3 bytes after the char to keep the 32 bit item
aligned.

  LT> So we need some notion of nested structs or a hint for correct
  LT> alignment. I've checked in basic alignment handling for "normal"
  LT> cases, but not the second one above.

you just need to do the same thing in offsetof but do it for the nested
struct elements. it won't necessarily be the same as when that struct is
top level so you can't cheat there.

it sounds like between the PIR solution and the cpan module that i don't
need to do my own hack. or should i still work on it? it would be an
external perl5/c solution that would be able to generate some form of
table of item offsets.

uri

--
Uri Guttman  ------  u...@stemsystems.com  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

Pointers to nested structs and function pointers as struct items are
already in CVS (at least, when returned from the external C lib) - I'll
update the docs/pmc/struct.pod tommorrow, including nested structures.

<normally i would never comment on your english which is usually very
good but util(ity) is pronounced with a hard 'u' as in 'you'. so that
should be 'a' and not an>.

  LT> initializer - as outlined in the previous posting - would be great
  LT> though.

i am playing with ExtUtil::XSParser now and i have some problems with
it. i will be writing the author. does anyone on this list use it now? i
can send in what i have done. it seems to be more a work in progress
than something useable but i could be wrong. at least one method i need
to override (find_includes) was not described properly in the docs and i
had to scan the source to make it work. also the P:RD parser doesn't seem
to return a parse tree but some ok (1) values. any help would be
appreciated. i mainly need the c struct parser to give me a tree and i
can do the rest.

thanx,

uri

--
Uri Guttman  ------  u...@stemsystems.com  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

  >> i am playing with ExtUtil::XSParser now

  LT> ... but I hope that people out there are speaking Perl and can help with
  LT> that issue.

mitchell charity pointed me to a much better module
Convert::Binary::C. it looks perfect and seems robust and it is very
well documented. i just installed (10747 tests!) it and will play with
it soon. if it does what it claims, it will be trivial to generate
anything we need. all it needs is a couple of calls to parse any c
source and one method will return a list of all the structs with a fully
broken out parse tree with offsets!  i will hack up something basic
using it and we can tweak the output to whatever parrot needs.

uri

--
Uri Guttman  ------  u...@stemsystems.com  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

boy, was this easy with this module. all we need to do is mess around
with the output to get whatever leo needs.

with this struct (from leo with some minor changes):

struct xt {
        char x;
        struct yt {
                char i,k;
                int  j;
        } Y;
        char z;

#!/usr/local/bin/perl -w

use strict ;

use Data::Dumper ;
use Convert::Binary::C ;

my $cbc = Convert::Binary::C->new() ;

$cbc->parse_file( @ARGV ) ;

#print Dumper $cbc->compound() ;

my @structs = $cbc->compound() ;

foreach my $struct ( @structs ) {

        print "$struct->{'type'} $struct->{'identifier'}\n" ;

        foreach my $declaration ( @{$struct->{'declarations'}} ) {

                my $type = $declaration->{'type'} ;

                foreach my $declarator ( @{$declaration->{'declarators'}} ) {

                        my $decl_name = $declarator->{'declarator'} ;
                        my $offset = $declarator->{'offset'} ;

                        print "\t$type $decl_name : offset $offset\n" ;
                }
        }

struct yt
        char i : offset 0
        char k : offset 1
        int j : offset 2
struct xt
        char x : offset 0
        struct yt Y : offset 1
        char z : offset 7

this was part of the structure parse tree (via Dumper):

$VAR2 = {
          'context' => 'xyz.h(3)',
          'declarations' => [
                              {
                                'declarators' => [
                                                   {
                                                     'declarator' => 'x',
                                                     'offset' => 0,
                                                     'size' => 1
                                                   }
                                                 ],
                                'type' => 'char'
                              },
                              {
                                'declarators' => [
                                                   {
                                                     'declarator' => 'Y',
                                                     'offset' => 1,
                                                     'size' => 5
                                                   }
                                                 ],
                                'type' => 'struct yt'
                              },
                              {
                                'declarators' => [
                                                   {
                                                     'declarator' => 'z',
                                                     'offset' => 6,
                                                     'size' => 1
                                                   }
                                                 ],
                                'type' => 'char'
                              }
                            ],
          'pack' => 0,
          'align' => 1,
          'size' => 7,
          'identifier' => 'xt',
          'type' => 'struct'
        };

BTW, this was on a sparc/solaris box.

so what output formats do we need?

the structures parse tree (from the compound method) has everything you
could want and is very simple to navigate. this is one amazing module
and it should get more publicity for sure.

uri

--
Uri Guttman  ------  u...@stemsystems.com  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

struct { char; struct { char; char; char; } }
is at +0, +1, +2, +3

But: struct { char; struct { char; char; short; } }
is at +0, +2, +3, +4

And: struct { char; struct { char; short; char; } }
is at +0, +2, +4, +6

        x : 0
        i : 4
        j : 8
        z : 12

—

Gordon Henriksen
malic...@mac.com

  .DATATYPE_STRUCT
  .DATATYPE_STRUCT_PTR

are already in CVS.

leo

struct yt (size=8, alignment=4)
        char i : offset 0
        char k : offset 1
        int j : offset 4

struct xt (size=16, alignment=4)
        char x : offset 0
        struct yt Y : offset 4
        char z : offset 12

lupus

--
-----------------------------------------------------------------
lu...@debian.org                                     debian/rules
lu...@ximian.com                             Monkeys do it better

1) some script e.g. gen_struct (struct2pasm ...) located in tools/dev or
build_tools.

2) options:

   --gen-pasm, -p    (default, *if* src file =~ /\.pasm$/
   --pmc=Px          (for --gen-pasm only, default P15)
   --gen-pir         (default)
   --named-initializer=0,1   (1)
   --named-accessor=0,1      (0)
   --out-file, -o=file (default: change input in place unless stdin)

3) Operation

3a) Take a C structure, spit out initializer
3b) take a commented C structure, add or change initializer
    3b) is for source-files that may contain multiple C structures
        like in my original posting WRT this util or like below

## begin autogeneratedd bla bla

4) The output
4a) initializer name / P-register  => $init_pmc

   new P20, .OrderedHash       # .PerlArray if --no-named-initializer

 or
   .local pmc struct_xt_init   # --gen-pir
   struct_xt_init = new OrderedHash

 and

   .include "datatypes.pasm"  # for DATATYPE_ consts below

4b) data type of item

   push $init_pmc, .DATATYPE_$type  # --no-named-init...

 or

   set $init_pmc["$var"], .DATATYPE_$type  # --name-init..

 If item is a nested struct or a pointer to nested struct please
 consult docs/pmc/struct.pod

4c) item count = 0, or N for array of items

   push $init_pmc, $item_count

4d) offset - always 0 for now

   push $init_pmc, 0

4e) nice to have: preserve C comments (put these after '#')

S. also t/pmc/nci.t for examples of initializers and src/nci_test.c for
the referenced C structs.

I hope above outline is somewhat clear else please just ask.