<div dir="ltr"><div>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.</div><div><br></div><div>I think that that <span style="font-size:12.8px">BITSIZE</span> should report the declared number of bits (the minimum number of bits allocated) with <span style="font-size:12.8px">BYTESIZE</span> 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?</div><div><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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?</span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 24, 2018 at 10:38 PM, Rodney M. Bates <span dir="ltr"><<a href="mailto:rodney_bates@lcwb.coop" target="_blank">rodney_bates@lcwb.coop</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are a number of cases where the compiler crashes with messages like:<br>
<br>
** INTERNAL CG ERROR *** unable to find integer type?  type=Word.64  size/offset/align=64/20/32<br>
<br>
In working on these, I also find cases where the compiler does not crash but<br>
is out of compliance with the language, and/or the language is not clear.<br>
<br>
2.2.5 Packed Types clearly says (concerning BITS n FOR Base):<br>
<br>
"variables of type T *that occur in records, objects, or arrays*<br>
 will occupy exactly n bits and be packed adjacent to the preceding<br>
 field or element."<br>
<br>
So for scalar variables, the BITS n FOR should have no effect on<br>
allocated size or alignment.  For scalar local variables and formal<br>
parameters, the compiler complies.  For global variables, it does not.<br>
For example, for BITS 15 FOR CHAR, it rounds n up to 16 and allocates<br>
that.<br>
<br>
In all cases, scalar, global, even record fields, BITSIZE always<br>
reports n, regardless whether this agrees with actual allocated space.<br>
BYTESIZE always reports BITSIZE rounded up and converted to bytes.<br>
<br>
ADR crashes the compiler on non-byte-aligned fields.<br>
<br>
The language doesn't define the 3 sizes nor ADR for non-byte-aligned,<br>
packed variables, scalar or otherwise.<br>
<br>
Aside from fixing the crashes, I propose the following:<br>
<br>
1) Fix the compiler to allocate global scalars unpacked, per the language.<br>
<br>
2) For scalar variables, make BITSIZE, BYTESIZE, and ADRSIZE<br>
   report according to the actual allocation, not the ignored<br>
   packed size. This is both a language clarification and a<br>
   compiler fix.<br>
<br>
3) Applied to types, make BITSIZE report according the n, in<br>
   other words, as if the type were used for a field or element.<br>
   This is already happening in the compiler, but is not defined<br>
   by the language.<br>
<br>
4) Applied to types, make BYTESIZE and ADRSIZE round up to whole bytes.<br>
   This is what is happening now, but is not defined by the language.<br>
   Or would it be better to make a static error if the address is not<br>
   statically known to be a byte multiple?<br>
<br>
5) For ADR, make it a static error if the address is not statically<br>
   known to be a byte multiple.<br>
<br>
2), 3), 4), and 5) entail adding better definition to the language.<br>
<br>
1), 2), 5), and the 2nd alternative in 4) entail compiler changes.<br>
5), however would only change a compiler crash to a static error.<br>
<br>
It is possible there is existing code that would be sensitive to some<br>
of the compiler changes.  I have seen a lot of low-level bit twiddling<br>
code that appears to have been written on the assumption that BITS n<br>
FOR also affects allocation of scalars, although I am not sure how<br>
much of it actually depends on this.  Only global scalars would be<br>
affected.<br>
<br>
Any thoughts?<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-- <br>
Rodney Bates<br>
<a href="mailto:rodney.m.bates@acm.org" target="_blank">rodney.m.bates@acm.org</a><br>
______________________________<wbr>_________________<br>
M3devel mailing list<br>
<a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a><br>
<a href="https://m3lists.elegosoft.com/mailman/listinfo/m3devel" rel="noreferrer" target="_blank">https://m3lists.elegosoft.com/<wbr>mailman/listinfo/m3devel</a><br>
</font></span></blockquote></div><br></div>