[M3devel] Compiler and language problems with packed types

[Darko Volaric]

ADR should only be able to return a valid address for the architecture,
allowing any byte aligned address may be too permissive. Either way this
should be defined to be implementation dependent since there may be
performance considerations. It should be a static error to take the address
of something that doesn't produce a valid address and one that actually
points or can point to the data in question.

I think that that BITSIZE should report the declared number of bits (the
minimum number of bits allocated) with BYTESIZE reporting the actual
allocated size of the field or variable (eg: after alignment). Both are
valuable information. What is the point of BYTESIZE if it can simply be
derived from BITSIZE?


If we're interfacing with say C, and a global there is defined to be 16
bits, how do we define that in M3? Do we make a subrange and assume the
compiler will do the right thing? How can we be sure that we're not
overwriting adjacent data in that global data space in the C code?


On Wed, Jan 24, 2018 at 10:38 PM, Rodney M. Bates <rodney_bates at lcwb.coop>
wrote:

> 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
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20180126/bf5002eb/attachment-0001.html>