<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This problem is artifical one. <div><br></div><div>Unpacked field going in RECORD/OBJECT after packed field is automatically aligned by type/CPU rules. Only packed field is not aligned.</div><div><br><div><div><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Divided by a common language</div><div><br></div><div>Dragiša Durić</div><div><a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a></div><div><br></div></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br><div><div>On Sep 5, 2012, at 5:36 PM, Antony Hosking wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>As I recall you were having trouble with alignment, right?<br><br>In which case, why not pad your record type out to a reasonably aligned value? As in:<br><br>CONST PadRange = Word.LeftShift(1, BITSIZE(ADDRESS) - BITSIZE(TypeUID)) - 1;<br>RECORD<br> t: TypeUID;<br> pad: BITS BITSIZE(ADDRESS) - 32 FOR [0..PadRange];<br>END;<br><br><br><br>On Sep 5, 2012, at 11:18 AM, Antony Hosking <<a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a>> wrote:<br><br><blockquote type="cite">Remind me again why you can’t use TypeUID as is?<br></blockquote><blockquote type="cite">There is nothing in the language spec that prohibits packed types in records.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Sep 5, 2012, at 10:50 AM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">This seems quite wrong from a simple engineering/design/factoring/abstraction point of view.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Imagine I have a few of these things. They are subranges or enums. That fit in a smaller size.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Wouldn't it be nice, to just use the type directly and get the space savings? Opportunistically?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">What if the type is a REAL or a LONGINT?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I want the type to be opaque/abstract where that is easy and cheap and this certainly seems like an easy/cheap place to have slightly valuable opacity.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Isn't it really good, more than "just nice" to let the type change and have a lot of code work just as well?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Because they didn't copy around knowledge of what the type is?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">What if the type changes?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Anyone just copying it around by exact restated typename is unaffected.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Anyone who looked at and decided to restate the definition might type might be broken.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">And again, really -- you want to sacrifice both performance and abstraction when both are easily kept better?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">That is, I'm all for range checks to keep things "safe", safety is important, but in this case you can easily preserve safety w/o adding range checks.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">We do have enums at this layer.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Would you suggest I take the ORD of all of those and store them in INTEGERs too?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I am really surprised.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> - Jay<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">From: <a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Date: Wed, 5 Sep 2012 10:33:58 -0400<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">To: <a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a>; <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Subject: Re: [M3devel] M3CG<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Precisely.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On Sep 5, 2012, at 3:40 AM, Dragiša Durić <<a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a>> wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Why holding/passing of this value in INTEGER would be a problem? As long as range checks are passed on "assignment boundaries", it is all well.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">It is how Modula-3 does things. <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Divided by a common language<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Dragiša Durić<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On Sep 4, 2012, at 10:47 PM, Jay K wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">RECORD HoldsTypeUID:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> typeuid: [FIRST(TypeUID)..LAST(TypeUID)];<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">END?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">But what if I'm really just a holder/passer of this thing,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and I never interpret it. Now TypeUID can't be changed<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to LONGREAL or somesuch. Ideally some code wouldn't care<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and still be correct.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The idea is to hold the thing, pass it on, without knowing<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">what it is. I want a field with the same type.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Why does it matter if TypeUID is representable in 32 bits?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Isn't the range the interface?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If it wasn't for readability of all the F's, I think<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">TypeUID = [-16_7FFFFFFF - 1 .. 16_7FFFFFFF]; is best.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Do we really care about few or many bits that occupies?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cstdint.int32_t I agree is a bit lazy.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Maybe something like Word.Shift(1, 31) .. Word.Not(Word.Shift(1, 31)) ?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">A bit wordy but ok.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Maybe not correct. Not clear the start is negative.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Maybe needs to be more like:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">(-Word.Not(Word.Shift(1, 31))) - 1 .. Word.Not(Word.Shift(1, 31)) <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">But these bit twiddlings might then confuse people.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">So maybe having to count F's is better.. :(<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">You know, what about being 32bits in size would be part of an interface?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I don't think much/anything, but maybe.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Do we do/allow things like bit operations on it? Index into it a certain number<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">of bits? Take the address and assume BYTESIZE == 4?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I could see those maybe occuring. Maybe.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">But I'm pretty sure they values are fairly abstract/opaque and the best anyone can do<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is format them as strings and compare them for e.g. sorting purposes, but must<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">assume they are fairly sparse.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Btw, whenever the matter of "portability to signed-magnitude" or one's complement<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">comes up, I admit I get a bit confused. Two's complement is very ingrained<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">in my world view.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I agree TInt.T suffices.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Just like CARDINAL isn't needed, INTEGER suffices.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cardinal.T just disallows negative numbers earlier, or at lower level, etc.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If we had to use TInt.T and add checks in a few places that it >= 0, ok.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">It seems a little nice to put the checking in.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> - Jay<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Subject: Re: M3CG<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">From: <a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Date: Tue, 4 Sep 2012 13:05:34 -0400<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Sep 4, 2012, at 12:09 PM, Jay <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">"BITS" seems to not provide any useful value. It only makes it so you can't put the type into a portable unpacked record, which is what I was doing. I either have to pack my record somehow (counting target-dependent bits??) or lay out the fields carefully in some way that all targets allow. The problem was that some targets didn't like the layout.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">For M3CG.TypeUID the BITS 32 enforces that it is always representable in 32 bits. This is a fundamental invariant of the compiler and run-time system. Removing it might allow bug creep. You don't need to pack your record. You just need a field sufficiently large to hold the value of a type id. In this instance an INTEGER field would suffice, or you can use the same subrange.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Given the stated range, that you'll get enough bits to store it, what is the point in giving the size too? Isn't providing just the range and no particular size, sufficient & more abstract? Granted, I went the other way.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Only if an implementation chooses to store a subrange in as few bits as necessary. Yes, CM3 does this, but it is not guaranteed by the language spec. Here the size is the critical invariant.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I don't remember but guessing:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Cardinal.T would be, like CARDINAL vs. INTEGER: only slightly subtley useful: same as TInt.T, but disallows negative numbers.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">But for what purpose. The target does not have CARDINAL. It only has a target integer.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Most likely I ran into places where a host integer/cardinal did not necessarily suffice, and so a target type was called for.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I know we have places that need to use target types but don't yet. Specifically for the sizes of things like records & arrays. Otherwise we have hacks where 64bit systems declare 32bit limits.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Again, TInt.T suffices for all of these.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">- Jay (briefly/pocket-sized-computer-aka-phone)<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Sep 4, 2012, at 7:11 AM, Antony Hosking <<a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a>> wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Jay,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I've been looking over some of your changes to M3CG interfaces. You'll notice that I removed your import of Cstdlib.int into M3CG_Ops.i3. It does not belong there. The type as declared:<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">TypeUID = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">is correct as is. It is a 32 bit value that encodes a particular subrange, REGARDLESS of target machine. It is improper to change that definition to rely on some C type.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I also have some other questions. Why did you add the type Cardinal.T? This seems entirely unnecessary, since targets don't have a Cardinal type. The only type they have is a target integer. All other Modula-3 ordinal types should be simulated in the compiler using TInt.T. I would advise that it be removed. Also, I don't understand why you changed descriptions of the primitive types to use this Cardinal.T instead of the original CARDINAL to hold information about the bit size, alignment, and byte size. There is no situation in which a host will need to emulate the behavior of CARDINAL for these values (all can be represented using CARDINAL no matter what the host).<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I am concerned that these changes reflect a desire on your part to change the world to fit your specific needs (whether justified or not). The interfaces defined in M3CG were carefully designed and inherit from a long code-chain going back to the 1980's and have not see huge changes since then. I strongly advise against making changes unless you have good reason, because there are a number of tools that rely on M3CG (not just those in the public sources).<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I am going to do a pass to revert some of your changes, since they are causing a number of my systems to fail to build. (cf. Niagara on tinderbox).<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I strongly advise that you try to use a private branch when developing new functionality. We as a community can then go through a revision process to vet substantive changes before merging them into the trunk.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">- Tony<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><br></div></blockquote></div><br></div></div></div></body></html>