<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>RECORD HoldsTypeUID:<br> typeuid: [FIRST(TypeUID)..LAST(TypeUID)];<br>END?<BR><br> <BR>But what if I'm really just a holder/passer of this thing,<br>and I never interpret it. Now TypeUID can't be changed<br>to LONGREAL or somesuch. Ideally some code wouldn't care<br>and still be correct.<BR><br> <BR>The idea is to hold the thing, pass it on, without knowing<br>what it is. I want a field with the same type.<BR><br> <BR>Why does it matter if TypeUID is representable in 32 bits?<br>Isn't the range the interface?<br>If it wasn't for readability of all the F's, I think<br>TypeUID = [-16_7FFFFFFF - 1 .. 16_7FFFFFFF]; is best.<BR> <BR><br>Do we really care about few or many bits that occupies?<BR> <BR><br>Cstdint.int32_t I agree is a bit lazy.<br>Maybe something like Word.Shift(1, 31) .. Word.Not(Word.Shift(1, 31)) ?<br>A bit wordy but ok.<BR>Maybe not correct. Not clear the start is negative.<BR>Maybe needs to be more like:<BR> <BR>(-Word.Not(Word.Shift(1, 31))) - 1 .. Word.Not(Word.Shift(1, 31)) <BR> <BR> <BR>But these bit twiddlings might then confuse people.<BR>So maybe having to count F's is better.. :(<BR> <BR> <BR>You know, what about being 32bits in size would be part of an interface?<br>I don't think much/anything, but maybe.<BR> <BR><br>Do we do/allow things like bit operations on it? Index into it a certain number<br>of bits? Take the address and assume BYTESIZE == 4?<br>I could see those maybe occuring. Maybe.<BR><br> <BR>But I'm pretty sure they values are fairly abstract/opaque and the best anyone can do<br>is format them as strings and compare them for e.g. sorting purposes, but must<br>assume they are fairly sparse.<BR> <BR> <BR>Btw, whenever the matter of "portability to signed-magnitude" or one's complement<br>comes up, I admit I get a bit confused. Two's complement is very ingrained<br>in my world view.<BR> <BR> <BR>I agree TInt.T suffices.<br>Just like CARDINAL isn't needed, INTEGER suffices.<br>Cardinal.T just disallows negative numbers earlier, or at lower level, etc.<br>If we had to use TInt.T and add checks in a few places that it >= 0, ok.<br>It seems a little nice to put the checking in.<BR> <BR> <BR> - Jay<br><br><br><br> <BR><div><div id="SkyDrivePlaceholder"></div>> Subject: Re: M3CG<br>> From: hosking@cs.purdue.edu<br>> Date: Tue, 4 Sep 2012 13:05:34 -0400<br>> CC: m3devel@elegosoft.com<br>> To: jay.krell@cornell.edu<br>> <br>> On Sep 4, 2012, at 12:09 PM, Jay <jay.krell@cornell.edu> wrote:<br>> <br>> > "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>> <br>> 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>> <br>> > 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>> <br>> 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>> <br>> > I don't remember but guessing:<br>> > <br>> > <br>> > Cardinal.T would be, like CARDINAL vs. INTEGER: only slightly subtley useful: same as TInt.T, but disallows negative numbers.<br>> <br>> But for what purpose. The target does not have CARDINAL. It only has a target integer.<br>> <br>> > Most likely I ran into places where a host integer/cardinal did not necessarily suffice, and so a target type was called for.<br>> > <br>> > <br>> > 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>> <br>> Again, TInt.T suffices for all of these.<br>> <br>> > <br>> > <br>> > - Jay (briefly/pocket-sized-computer-aka-phone)<br>> > <br>> > On Sep 4, 2012, at 7:11 AM, Antony Hosking <hosking@cs.purdue.edu> wrote:<br>> > <br>> >> Jay,<br>> >> <br>> >> 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>> >> <br>> >> TypeUID = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];<br>> >> <br>> >> 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>> >> <br>> >> 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>> >> <br>> >> 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>> >> <br>> >> 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>> >> <br>> >> 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>> >> <br>> >> — Tony<br>> >> <br>> <br></div> </div></body>
</html>