<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
These would be "base" types and people would have to pick and chose their own typedefs to suit their needs.<BR>
<BR>
<BR>
Imho the idea of a "natural" size is a nice theory but it turns out that "we" (in the larger software world) are stuck with the exact sizes as they happen to have been for a while. C int will always be 32 bits. Growing it will break too much code. Even if processors get natural 128 bit integers, they will still always have to deal efficiently with 32 bit integers because 32 bit integers won't go away. Ditto now 64bit integers.<BR>
<BR>
<BR>
As well natural is great for a local variable, but as soon as you start allocating things in large numbers, you start wanting the size to not be much larger than is needed and you consider the range you'll actually need..sometimes it is obviously small, sometimes not. If it isn't obviously small then you can err toward a larger type like or int or size_t. If it is obviously a small range and allocated in large number then you'll more seriously consider UINT8 or UINT16. If the range is unavoidably huge then you'll consider floating point or a multiple precision option.<BR>
<BR>
<BR>
Granted, Modula-3 does have "BITS FOR" and subranges.<BR>
I'm not used to having those.<BR>
So maybe these types aren't needed since you can build them.<BR>
The compiler does certainly have these exact types internally though.<BR>
And the processors generally all have instructions that operate on them (with varying efficiency though).<BR>
<BR>
<BR>
If you consider C, people often have int, long, long long.<BR>
This is as I said dumb because what will 128 integers be called, "long long long"?<BR>
"byte", "short", "long" these are just funny informal names.<BR>
A more mechanical system is INT8, INT16, INT32 or PTRDIFF_T.<BR>
I grant that there is base integer type with the size of a pointer, that doesn't have the exact number of bits encoded.<BR>
<BR>
Perhaps Modula-3 doesn't have such a bad legacy codebase?<BR>Perhaps growing INTEGER to 64bits didn't break anything and growing it to 128 won't either?<BR>
Perhaps persistance is generally pickles and they deal better with this stuff, and not like direct blitting?<BR>
<BR>
Anyway,<BR>
- Jay<BR><BR> <BR>
<HR id=stopSpelling>
From: hosking@cs.purdue.edu<BR>Date: Wed, 16 Dec 2009 20:10:14 -0500<BR>To: jay.krell@cornell.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] Oops, forgot to ask<BR><BR><BASE>
<DIV><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span>
<DIV style="WORD-WRAP: break-word"><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span>
<DIV><SPAN style="FONT-SIZE: medium" class=ecxApple-style-span>On 16 Dec 2009, at 19:52, Jay K wrote:</SPAN></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></SPAN></DIV>
<DIV><BR class=ecxApple-interchange-newline>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxhmmessage>"0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER?<BR> <BR> <BR>See..LONGINT is only useful in this brief period where we still have 32bit INTEGER.<BR>(Actually it would have been useful long ago.)<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>LONGINT could be 128 bits for all its definition cares. It is just something usually (not always) bigger than an INTEGER.</DIV><BR>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxhmmessage> I really think "long" is a dumb name..<BR>There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t..<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Now these are dumb names because they wire in the size of the value.</DIV>
<DIV><BR></DIV>
<DIV>In Modula-3 INTEGER is a natural (i.e., word-size) value.</DIV>
<DIV><BR></DIV>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxhmmessage> <BR> <BR> - Jay<BR><BR> <BR>> Date: Wed, 16 Dec 2009 16:56:55 -0600<BR>> From:<SPAN class=ecxApple-converted-space> </SPAN><A href="mailto:rodney_bates@lcwb.coop">rodney_bates@lcwb.coop</A><BR>> To:<SPAN class=ecxApple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>> Subject: Re: [M3devel] Oops, forgot to ask<BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>> Tony Hosking wrote:<BR>> > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote:<BR>> ><BR>> ><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> Hi Gang,<BR>> >><BR>> >> 0 - CARDINALs are an integral type defined by the language<BR>> >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently,<BR>> >> a change was made to CM3 to extend the language it recognizes<BR>> >> beyond the original language spec (SPWM3), now CM3 understands<BR>> >> a LONGINT.<SPAN class=ecxApple-converted-space> </SPAN><BR>> >><BR>> >> Was there a corresponding LONGCARD defined?<BR>> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> ><BR>> > No. But you can write:<BR>> ><BR>> > [0L..LAST(LONGINT)]<BR>> ><BR>> > just as<BR>> ><BR>> > CARDINAL=[0..LAST(INTEGER)]<BR>> ><SPAN class=ecxApple-converted-space> </SPAN><BR>> Actually, the line above was once true, long long ago, when dinosaurs<BR>> roamed unfettered. CARDINAL was changed to be "just like"<BR>> (but not equal to) [0..LAST(INTEGER)]. This would have been<BR>> maybe early 1990s.<SPAN class=ecxApple-converted-space> </SPAN><BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>> It took me years to figure out what this actually meant, and more<BR>> years to figure out why, but I believe I now know. CARDINAL is not an<BR>> equal type to [0..LAST(INTEGER)], but otherwise has all the same<BR>> properties. This makes the two mutually assignable, which is close<BR>> enough to equal to not matter in most contexts. The exact consequences<BR>> follow from other language rules.<SPAN class=ecxApple-converted-space> </SPAN><BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>> The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not<BR>> equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of<BR>> machines with different values of LAST(INTEGER)), because the numeric<BR>> value of LAST(INTEGER) is part of the expanded type. The one place this<BR>> matters is if you use pickles to transfer data between machines of different<BR>> word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash<BR>> of the complete, expanded type definition) is different on the two machines,<BR>> and values of or containing this type cannot be transferred. Exact type<BR>> signature matches are used in pickles to find corresponding types when<BR>> reading.<SPAN class=ecxApple-converted-space> </SPAN><BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>> But pickles handle different sized INTEGER values fine, expanding/shortening<BR>> as needed. Being a leaf in a type definition, INTEGER is always the same<BR>> type on any machine. So CARDINAL was changed to be its own unique<BR>> type too, so it would be possible also to transfer CARDINAL values in<SPAN class=ecxApple-converted-space> </SPAN><BR>> pickles<BR>> between different word sizes.<SPAN class=ecxApple-converted-space> </SPAN><BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>> So, we really should have a LONGCARD, parallel to CARDINAL.<BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>> Note that this also affects network objects, which use pickles to transfer<BR>> values of the objects.<BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>> ><BR>> ><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> Can is use all 64-bits, or is it restricted to 63, like<BR>> >> the CARDINAL is only 31-bits.<BR>> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> ><BR>> > 63 bits, since its underlying base type is LONGINT.<BR>> ><BR>> ><BR>> ><SPAN class=ecxApple-converted-space> </SPAN><BR>> >><BR>> >><BR>> >><BR>> >> +--------------------------------------------------------+<BR>> >> | Peter P. Eiserloh |<BR>> >> +--------------------------------------------------------+<BR>> >><BR>> >><BR>> >><BR>> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> ><BR>> ><BR>> ><SPAN class=ecxApple-converted-space> </SPAN><BR>><SPAN class=ecxApple-converted-space> </SPAN><BR></DIV></SPAN></BLOCKQUOTE></DIV><BR> </body>
</html>