[M3devel] cm3 regression

[Jay]

Right.
Win64 will be:
  INTEGER = 64 bits
  LONGINT = 64 bits
  Word.T = INTEGER (should be common to all platforms) 
  LongWord.T = LONGINT (should be common to all platforms)
  BasicCtypes.int = 32 bits (should be common to all platforms?) 
  BasicCtypes.long = 32 bits (the difference) 
  BasicCtypes.longlong = 64 bits if this even exists
> mess since you have both LLP64 (Windows) and LP64 (everyone else, for > good reason -- see http://www.unix.org/version2/whatsnew/ > lp64_wp.html). In any case, yes, I expect there will need to be a 
I think everyone else had the advantage of:
 1) doing it earlier 
 2) and with much less code 
 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.
 
Hey, good redirect, want to name the directories: 
   ILP32 (aka 32 bits) 
   LP64  (aka 64 bits except Windows) 
   LLP64  (aka 64 bit Windows)
?
 
Too cryptic?
 
While I don't want a bunch of "Win64" directories, maybe put in some selectively, and have:
  32bit (same as today) 
  64bit (same as today) 
  Win64 
 
Anyway, this is still getting a bit ahead of things.
 - Jay



> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> To: mika at async.caltech.edu> Subject: Re: [M3devel] cm3 regression> Date: Mon, 14 Apr 2008 14:42:07 -0400> > I think Modula-3 has it exactly right in that the base types INTEGER > and Word.T use the natural word size of the machine, and that there > are no guarantees about BITSIZE on those. If you want a specific bit > size you use BITS FOR or simply a subrange type, both of which pack > down in memory to just the number of bytes needed. C is generally a > mess since you have both LLP64 (Windows) and LP64 (everyone else, for > good reason -- see http://www.unix.org/version2/whatsnew/ > lp64_wp.html). In any case, yes, I expect there will need to be a > fork of BasicCTypes along the lines of ILP32, LP64, and LLP64. > Currently, we have the strangeness that NT386 = ILP32/LL32 (because > the integrated backend can't grok LL64), but this is an anomaly. > Ideally, this would go to LLP64 (IL32) to match the Win64 world. > Remember, this is only for *C types*. On all 64-bit platforms, we > should aim for 64-bit INTEGER and 64-bit Word.T as the native Modula-3 > types. How C types fall out depends on the native C expectations of > the platform, and really are just about interfacing to C APIs.> > On Apr 14, 2008, at 1:18 PM, Mika Nystrom wrote:> > > Jay writes:> >> --_50e47a65-f79d-472b-8eaf-fbcc30b6410e_> >> Content-Type: text/plain; charset="iso-8859-1"> >> Content-Transfer-Encoding: quoted-printable> >>> >> new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", > >> line 18=> >> : illegal based LONGINT literal, zero used"..\src\C\32BITS > >> \BasicCtypes.i3",=> >> line 18: illegal based LONGINT literal, zero used> >> long_long =3D [-16_7fffffffffffffffL-1L .. > >> 16_7fffffffffffffffL]=> >> ;> >> =20> >> Why isn't this LONGINT? So that NT386 can limp along? And it'd be > >> correct f=> >> or the rest, eh?> >> I'll try it and see..> >> =20> >> The underlying system (the compiler) has (U)Int[8,16,32,64]> >> They should just be used here imho..> >> =20> >> Also, what should "long" be on 64bit?> >> On Windows it is 32 bits always.> >> On 32 bit systems it is 32 bits.> >> I think the 64bits directory is going to be forked for AMD64_NT_*.> >> The Windows decision imho has successfully been applied to more > >> code and mo=> >> re users so therefore is better by practical success, even if the > >> whole iss=> >> ue is problematic almost no matter what. Clearly the C and Modula-3 > >> notions=> >> of integers are pretty poor..> >> > I have to re-code my program to use Int64 if I want it to use the> > natural INTEGER size on 64 bit machines? No thanks.> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080414/9d71f322/attachment-0002.html>