Bitfields

ASIL's version of the old fashioned C bitfield are fairly simple. A bitfield in ASIL can be a member of any structure, but not a class. They're a variation of the type-less named structs discussed in [Nested type-less named structs]. However, many bitfields don't need an identifier for the bitfield itself.

Bitfields start with the bitfield keyword. Each member is either an unsigned integer or a boolean. Each field uses the syntax (public|protected|private) var length% [boolean] identifier where length% is the number of bits needed for that field. If the "boolean" portion is present, the field is a boolean. Otherwise, the field is an unsigned int based on the word type.

:::text
struct MyStruct1
  bitfield identifier
    public 1 boolean bMyBool ' A boolean that's just a single bit long
    public 3 iMyInt ' An unsigned integer 3 bits long
    ~ ' Add this to the end to cause the compiler to pad the bitfield out to use whole words

struct MyStruct2
  bitfield
    public 1 boolean bMyBool ' A boolean that's just a single bit long
    public 3 iMyInt ' An unsigned integer 3 bits long
    ~ ' Add this to the end to cause the compiler to pad the bitfield out to use whole words

With the first declaration, you access the fields inside it using identifier.field. However, fields inside MyStruct2 can be accessed directly.

:::text
var MyStruct1 firstInstance = new MyStruct1
var MyStruct2 secondInstance = new MyStruct2

firstInstance.identifier.bMyBool = false
secondInstance.bMyBool = true

[Will Pittenger]

Should bitfields allow signed fields? I could use feedback here. The problem is the number of different ways to represent a signed integer.