<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Right.<BR>
Win64 will be:<BR>
INTEGER = 64 bits<BR>
LONGINT = 64 bits<BR>
Word.T = INTEGER (should be common to all platforms) <BR>
LongWord.T = LONGINT (should be common to all platforms)<BR>
BasicCtypes.int = 32 bits (should be common to all platforms?) <BR>
<STRONG> BasicCtypes.long = 32 bits (the difference) </STRONG><BR>
BasicCtypes.longlong = 64 bits if this even exists<BR>
<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><BR>
I think everyone else had the advantage of:<BR>
1) doing it earlier <BR>
2) and with much less code <BR>
3) no 16 bit legacy that pushed stuff to "long" earlier, thereby taking it away as an option, whereas I GUESS on Unix int was more common, or more "care" had already been taken more often given an earlier "variety" of systems, but again #1 and #2.<BR>
<BR>
Hey, good redirect, want to name the directories: <BR>
ILP32 (aka 32 bits) <BR>
LP64 (aka 64 bits except Windows) <BR>
LLP64 (aka 64 bit Windows)<BR>
?<BR>
<BR>
Too cryptic?<BR>
<BR>
While I don't want a bunch of "Win64" directories, maybe put in some selectively, and have:<BR>
32bit (same as today) <BR>
64bit (same as today) <BR>
Win64 <BR>
<BR>
Anyway, this is still getting a bit ahead of things.<BR>
<BR> - Jay<BR><BR><BR><BR>
<HR id=stopSpelling>
<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><BR></body>
</html>