Re: [Gm2] translating C bit fields

[Gaius Mulley]

SiTex Graphics <address@hidden> writes:

> Gaius and Andreas,
>
> Thanks for your replies.  I'll try sets for now.
>
> Native gm2 support for bit fields would of course be very convenient.
> Perhaps gm2 could support the BITFIELDS extension used by the
> Stonybrook compiler.  I've copied the relevant docs below.
>
> -Scott
>
> <snip>
> Bit fields can be declared anywhere in a record. Bit fields are
> declared within a bit field block which starts with the BITFIELDS
> keyword and ending with the END keyword.
>
> BITFIELDS
>    BitFieldList
> END
>
> BitFieldList is
>
> identifier {,identifier}: TypeSpecification BY Bits
>
> where Bits is a compile time constant designating the number of bits
> to use for storing the field.
>
> where TypeSpecification can be any ordinal type.
>
>    TYPE BITREC =
>         RECORD
>         before : CARDINAL;
>
>         BITFIELDS
>         bitField1 : CARDINAL BY 3;
>         bitField2 : INTEGER BY 3;
>         END;
>
>         after : CARDINAL;
>         END;
>
>
> Signed types have a minimum bit size of 2, and unsigned types can
> occupy a single bit. Bit fields are grouped and packed via an
> algorithm compatible with most C compilers. Therefore, translating a C
> structure containing bit fields is straightforward.
>
> Bit-fields obey the same size and alignment rules as other record
> fields. Each bit-field exists within an aligned storage entity of the
> type declared for the field. All bits of a bit-field must exist within
> a single aligned entity. Padding bits and/or bytes will be added to
> accomplish this. The bit-field aligned load entity can overlap with
> any previous field and/or bit-field. On little endian processors bits
> are allocated from low to high. On big endian processors bits are
> allocated from high to low. In both cases this means that bit-fields
> are allocated from lowest memory address to highest memory address
> within the record.
> </snip>

Hi Scott,

I wonder whether a more pragmatic approach might be to mirror the C
semantics for bit fields but with Modula-2 syntax of course.  So for
example:


   type = RECORD
             foo: INTEGER BY 2;
             bar: CARDINAL BY 4;
          END ;


The reasons for this approach are:

  (i)   in many cases users will wish to map Modula-2 data structures
        onto C counterparts.  This will provide a 1:1 match for any
        architecture.
  (ii)  reduce the amount of complexity.  The Stonybrook approach does
        seem quite complex and would make the mapping between C and
        Modula-2 tricky especially when wanting code to be portable
        across big/little endian architectures.
  (iii) it is very easy to implement in gm2 :-), we just pass the
        constexpression in the relevant Tree to the gcc middle end.
  (iv)  it provides a straightforward extension for those users using
        the gnu compiler collection.  Same mechanism for C/C++/M2
        and which is similar(ish) to the issue of conditional
        compilation (via the C preprocessor) which is used by
        C/C++/Fortran and M2.

would this be acceptable?

regards,
Gaius