[M3devel] more packed questions

[Rodney M. Bates]

Jay K wrote:
> T = BITS 2 FOR [0..3]; makes sense to me
> 
> 
> T = BITS 10 FOR [0..3];
> What does that do?
> It is legal, and allocates 10 bits, and uses a certain 2 of them?

Yes, but only for an array element or field of a record or object.

> Which 2?

The least significant 2.  Actually, the value would be treated as
occupying all 10, but the bounds rules of the language would ensure
that only values in 0..3 are ever stored therein.  Same as just [0..3],
the compiler can allocate whatever number of bits it wants (but at
least 2) but ensure stored values are in the range.

> Probably, it depends on endian and read the code, and it is meant
> to mean the same thing in C, if embedded in a struct, as
> a 10 bit bitfield that only happens to contain values 0..3?
> 
> 
> TYPE T1 = RECORD a:INTEGER END;
> TYPE T2 = BITS 64 FOR T1;
>  legal?
>  Sticks 0 or 32 bits after T1/a?

First, it doesn't do anything unless T2 is used as an array element
or a field.  If so, then that element/field occupies 64 bits itself.
Where within those bits the compiler puts the T1 record is not specified
by the language, and this case is not as obvious as INTEGER or [0..3].
I would expect a compiler would, on a 32-bit machine, put the T1
within the 64 bits of the T2 the same way it would allocate fields in a
record, i.e., the lowest-numbered 4 bytes of the 8.   This would effectively
do what you speculated.

>  
>  
>  My goal is to generate accurate type information in parse.c.
>  Debugging in stock gdb should work.
>  And then furthermore try converting offset loads/stores
>  to component/array_refs.
>  And then furthermore, let all of -O3 work.
>  
>  
>   - Jay