[M3devel] Compiler and language problems with packed types

[Rodney M. Bates]

There are a number of cases where the compiler crashes with messages like:

** INTERNAL CG ERROR *** unable to find integer type?  type=Word.64  size/offset/align=64/20/32

In working on these, I also find cases where the compiler does not crash but
is out of compliance with the language, and/or the language is not clear.

2.2.5 Packed Types clearly says (concerning BITS n FOR Base):

"variables of type T *that occur in records, objects, or arrays*
  will occupy exactly n bits and be packed adjacent to the preceding
  field or element."

So for scalar variables, the BITS n FOR should have no effect on
allocated size or alignment.  For scalar local variables and formal
parameters, the compiler complies.  For global variables, it does not.
For example, for BITS 15 FOR CHAR, it rounds n up to 16 and allocates
that.

In all cases, scalar, global, even record fields, BITSIZE always
reports n, regardless whether this agrees with actual allocated space.
BYTESIZE always reports BITSIZE rounded up and converted to bytes.

ADR crashes the compiler on non-byte-aligned fields.

The language doesn't define the 3 sizes nor ADR for non-byte-aligned,
packed variables, scalar or otherwise.

Aside from fixing the crashes, I propose the following:

1) Fix the compiler to allocate global scalars unpacked, per the language.

2) For scalar variables, make BITSIZE, BYTESIZE, and ADRSIZE
    report according to the actual allocation, not the ignored
    packed size. This is both a language clarification and a
    compiler fix.

3) Applied to types, make BITSIZE report according the n, in
    other words, as if the type were used for a field or element.
    This is already happening in the compiler, but is not defined
    by the language.

4) Applied to types, make BYTESIZE and ADRSIZE round up to whole bytes.
    This is what is happening now, but is not defined by the language.
    Or would it be better to make a static error if the address is not
    statically known to be a byte multiple?

5) For ADR, make it a static error if the address is not statically
    known to be a byte multiple.

2), 3), 4), and 5) entail adding better definition to the language.

1), 2), 5), and the 2nd alternative in 4) entail compiler changes.
5), however would only change a compiler crash to a static error.

It is possible there is existing code that would be sensitive to some
of the compiler changes.  I have seen a lot of low-level bit twiddling
code that appears to have been written on the assumption that BITS n
FOR also affects allocation of scalars, although I am not sure how
much of it actually depends on this.  Only global scalars would be
affected.

Any thoughts?


-- 
Rodney Bates
rodney.m.bates at acm.org