<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
[tangential...]<br><br>I think the definition of INTEGER is OK, but it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't have to provide them themselves. (CARDINAL I don't think is what I want.)<br>Add them somewhere in m3core?<br>MODULE Integers; ?<br><br>Unfortunately, actually, I want more than this, and then coming up with names is hard.<br><br>I want "safe" integers that raise exceptions or something upon overflow.<br>I want "unsafe" integers that silently "wrap around".<br>And maybe "arbitrary precision" integers that grow to accomodate, but also are smart and shrink to throw away trailing zeros.<br><br>I know you can often push stuff out of the language and into a library. As long as the language allows the library writer to provide a "nice enough" interface. For example the use of the plus sign on user defined types.. You know..like C++... but less complicated and easier to implement and fully understand...<br><br>In C, "officially", unsigned integers are unsafe and wrap around silently, and overflow on signed integers is undefined, however in reality, they are also silent, and I suspect, but am not sure, that I want both versions..maybe only for compat with existing code.<br><br>Which reminds me -- am I correct that the Modula-3 language defines overflow as raising an exception but nobody implements it that way? I can check. Are folks interested in fixing that?<br><br> - Jay<br><br><br>> CC: jayk123@hotmail.com; m3devel@elegosoft.com<br>> From: hosking@cs.purdue.edu<br>> To: mika@async.caltech.edu<br>> Subject: Re: [M3devel] cm3 regression<br>> Date: Mon, 14 Apr 2008 14:42:07 -0400<br>> <br>> I think Modula-3 has it exactly right in that the base types INTEGER <br>> and Word.T use the natural word size of the machine, and that there <br>> are no guarantees about BITSIZE on those. If you want a specific bit <br>> size you use BITS FOR or simply a subrange type, both of which pack <br>> down in memory to just the number of bytes needed. C is generally a <br>> mess since you have both LLP64 (Windows) and LP64 (everyone else, for <br>> good reason -- see http://www.unix.org/version2/whatsnew/ <br>> lp64_wp.html). In any case, yes, I expect there will need to be a <br>> fork of BasicCTypes along the lines of ILP32, LP64, and LLP64. <br>> Currently, we have the strangeness that NT386 = ILP32/LL32 (because <br>> the integrated backend can't grok LL64), but this is an anomaly. <br>> Ideally, this would go to LLP64 (IL32) to match the Win64 world. <br>> Remember, this is only for *C types*. On all 64-bit platforms, we <br>> should aim for 64-bit INTEGER and 64-bit Word.T as the native Modula-3 <br>> types. How C types fall out depends on the native C expectations of <br>> the platform, and really are just about interfacing to C APIs.<br>> <br>> On Apr 14, 2008, at 1:18 PM, Mika Nystrom wrote:<br>> <br>> > Jay writes:<br>> >> --_50e47a65-f79d-472b-8eaf-fbcc30b6410e_<br>> >> Content-Type: text/plain; charset="iso-8859-1"<br>> >> Content-Transfer-Encoding: quoted-printable<br>> >><br>> >> new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", <br>> >> line 18=<br>> >> : illegal based LONGINT literal, zero used"..\src\C\32BITS <br>> >> \BasicCtypes.i3",=<br>> >> line 18: illegal based LONGINT literal, zero used<br>> >> long_long =3D [-16_7fffffffffffffffL-1L .. <br>> >> 16_7fffffffffffffffL]=<br>> >> ;<br>> >> =20<br>> >> Why isn't this LONGINT? So that NT386 can limp along? And it'd be <br>> >> correct f=<br>> >> or the rest, eh?<br>> >> I'll try it and see..<br>> >> =20<br>> >> The underlying system (the compiler) has (U)Int[8,16,32,64]<br>> >> They should just be used here imho..<br>> >> =20<br>> >> Also, what should "long" be on 64bit?<br>> >> On Windows it is 32 bits always.<br>> >> On 32 bit systems it is 32 bits.<br>> >> I think the 64bits directory is going to be forked for AMD64_NT_*.<br>> >> The Windows decision imho has successfully been applied to more <br>> >> code and mo=<br>> >> re users so therefore is better by practical success, even if the <br>> >> whole iss=<br>> >> ue is problematic almost no matter what. Clearly the C and Modula-3 <br>> >> notions=<br>> >> of integers are pretty poor..<br>> ><br>> > I have to re-code my program to use Int64 if I want it to use the<br>> > natural INTEGER size on 64 bit machines? No thanks.<br>> <br></body>
</html>