[M3commit] CVS Update: cm3 (64 bit integers...)

[j k]

I think fixing NT386 should be easy enough given just a /bit/more time.I've been poking through it a bit..
 
> No way. INTEGER is intended to be abstract -- as defined in the > language spec.I'll have to read it to see what characteristics are guaranteed. Assuming you can have "very large" arrays, approaching the address space, or at least half of it, you are generally stuck with either INTEGER being the size of a pointer, or some "complicated" representation, like with varying precision, or heck even floating point.> This leads us into the swamp, full of nightmares and dragons.
I really tend to think "my way" is the clear simple way. (Not "my way", but the way of a LOT of code, some of it very high quality, some of it not). Yeah I am colored by "where I live", in the swamp perhaps.
It all seems to work quite well. Granted there is a need sometimes for floating point and very high precision, but the types I list, plus bit fields of any size 1 to 64, satisfy nearly all needs very well and very clearly. You do have to declare that assigning a larger precision integer to a smaller precision integer is a checked operation that can fail. Or some way to turn on/off the checks, though, really.. if you look at the "runtime checks" that Visual C++ offers, if you really want silent truncation, you can & with the appropriate value, e.g. UINT32 b; UINT16 a = (b & 0xffff) will not fail. There is the matter of assuming two's complement or not. Do people still work under the notion that there might be one's complement or arbitrary other representations of fixed small precision integers? Again I'll have to read the spec to see what abstraction INTEGER provides.
 
> You only get the compiler error for NT386, for which LONGINT is 32- 
Understood.
 
 - Jay
 



> From: hosking at cs.purdue.edu> Date: Sun, 26 Aug 2007 11:28:49 -0400> To: jay.krell at cornell.edu> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3 (64 bit integers...)> > > On Aug 26, 2007, at 8:08 AM, j k wrote:> > > Here is the change:> >> > < TYPE T = BITS 64 FOR [ -16_7fffffffffffffffL-1L .. > > 16_7fffffffffffffffL ];> >> > > (*TYPE T = BITS 64 FOR [ -16_7fffffffffffffffL-1L .. > > 16_7fffffffffffffffL ];*)> > > TYPE T = BITS BITSIZE(LONGINT) FOR [ FIRST(LONGINT) .. LAST > > (LONGINT) ];> > This should be OK.> > > Otherwise you get a compile error when the constants overflow at > > compile time.> > You only get the compiler error for NT386, for which LONGINT is 32- > bits because the non-gcc backend can handle only 32-bit integers. > What we really need is for NT386 to use a back-end that is capable of > 64 bits. NT386GNU may be the easiest route to this.> > > I still think all this stuff is a little wierd. Can we write off > > ALPHA_OSF, assert that INTEGER is 32 bits, and introduce a new type > > that is the same size as a pointer?> > No way. INTEGER is intended to be abstract -- as defined in the > language spec.> > > Again I think the types you want are:> > INT8, INT16, INT32, INT64 -- signed types with exact sizes, the > > same on all platforms (INT64 yet missing on Win32)> > UINT8, UINT16, UINT32, UINT64 -- unsigned types with exact > > sizes, the same on all platforms (UINT64 yet missing on Win32)> > SIZE_T, ?SSIZE_T? or ?PTRDIFF_T?-- unsigned and signed types for > > storing addresses, or sizes of arrays, or array indices, or the > > differences thereof, PERHAPS guaranteed to be 32 bits or 64 bits> > INTEGER -- same as SSIZE_T ?or? INT32??> > What's the pickle story? Are pickles interchangable beteen > > Alpha and non-Alpha?> > Should probably be equiv to SSIZE_T. That's what Alpha has.> > LONGINT -- same as INT64> > This leads us into the swamp, full of nightmares and dragons.> > >> > - Jay> >> >> > > Date: Sun, 26 Aug 2007 13:43:01 +0000> > > To: m3commit at elegosoft.com> > > From: jkrell at elego.de> > > Subject: [M3commit] CVS Update: cm3> > >> > > CVSROOT: /usr/cvs> > > Changes by: jkrell at birch. 07/08/26 13:43:01> > >> > > Modified files:> > > cm3/m3-libs/libm3/src/types/: Int64.i3> > >> > > Log message:> > > Fix it to compile for Win32's temporary 32 bit Int64.> > > Is this correct? I think so.> > >> >> > Messenger Café — open for fun 24/7. Hot games, cool activities > > served daily. Visit now.> 
_________________________________________________________________
Recharge--play some free games. Win cool prizes too!
http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20070827/4cb65d5f/attachment-0005.html>