<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Peter, Huh? Of course not.<BR>
<BR>
"long long" is always exactly 64 bits, except on systems where it doesn't exist at all.<BR>
<BR>
There isn't really any 128 bit integer type in widespread use, aside from multi precision arithmetic libraries and such.<BR>
<BR>
long on Windows is always 32bits, as I said.<BR>
<BR>
The pointer sized types are: size_t, ptrdiff_t, ssize_t, INTEGER, and any pointer<BR>
<BR>
Surely sizeof(long) == sizeof(void*) was considered for Win64, but rejected due to the wider spread source incompatibility it would have caused. Yes, I know, every other 64 bit system took a different route -- Alpha, AIX, Solaris, IRIX, Darwin -- but they all probably had far less code to deal with.<BR>
<BR>
I have also programmed with a 16bit int, but nobody seems to care about portability to that these days/decades/centuries. If folks here want to imagine Modula-3 is portable to such a system, with 16 bit INTEGER, I am willing to entertain discussion and maybe even code as to the ramifications..maybe..<BR>
<BR>
- Jay<BR><BR><BR>> Date: Fri, 2 Jan 2009 22:52:26 -0800<BR>> From: eiserlohpp@<BR>> To: m3devel@<BR>> Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer?<BR>> <BR>> Jay,<BR>> <BR>> Please don't make size_t 128 bits in size. In "C" a<BR>> long is specified by the language spec to be an integral <BR>> type big enough to hold a pointer. Longs in "C" may be<BR>> bigger than a pointer, but they must be at least that size. <BR>> <BR>> NOTE: an int (integer) does not have that guarantee.<BR>> <BR>> In fact, I once programed on a platform (Amiga) that had<BR>> two different compilers one used 16-bits and other 32 for<BR>> their integers. You can imagine the difficulties.<BR>> <BR>> Windows machines, as you have been using, give an address<BR>> space of 32 bits to user space. This is regardless of how<BR>> much RAM it may actually have. I would expect that on a<BR>> Win64 platform, pointers are 64 bits, and "long" is also <BR>> 64 bits.<BR>> <BR>> On my AMD64_LINUX box, pointers are 64 bits, and therefore<BR>> a long is 64, and a long long is 128. The system type<BR>> size_t is 64 bits. If you attempt to map Cstddef.size_t<BR>> to 128 bits it will not only break the syscall interfaces<BR>> to the kernel, but also be a waste of space.<BR>> <BR>> From that standpoint the type definitions<BR>> size_t = Ctypes.unsigned_long;<BR>> ..., etc.<BR>> <BR>> are correct.<BR>> <BR>> Please don't define <BR>> size_t = Ctypes.unsigned_long_long;<BR>> <BR>> <BR>> The "C" include files<BR>> /usr/includes/bits/types.h<BR>> /usr/includes/bits/typesizes.h<BR>> <BR>> play preprocessor games to ensure that the ssize_t are<BR>> defined to use the "natural" word size. <BR>> <BR>> Other types get defined to fixed sizes (ie, _int32 must<BR>> always be 32 bits) otherwise external interfaces (file<BR>> formats, inodes, ..., etc) would be corrupted. For that<BR>> reason explicitly sized types need to be defined.<BR>> <BR>> Actually, GNU/Modula-2 recently defined explictly sized<BR>> types.<BR>> <BR>> <BR>> Peter Eiserloh.<BR>> <BR>> <BR>> <BR>> Date: Fri, 2 Jan 2009 23:05:24 +0000<BR>> From: Jay <jay.krell@cornell.edu><BR>> Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer?<BR>> To: m3devel <m3devel@elegosoft.com>, Tony <hosking@cs.purdue.edu><BR>> Message-ID: <COL101-W1612F9835414ED341527DBE6E20@phx.gbl><BR>> Content-Type: text/plain; charset="iso-8859-1"<BR>> <BR>> <BR>> I'd like to avoid using "long" and "ulong" anywhere.<BR>> On Unix, they are always pointer sized.<BR>> On Windows, they are always 32 bits.<BR>> <BR>> This divergence of meaning I think it renders it useless.<BR>> <BR>> I believe for pointer-sized integers, the right types are any of:<BR>> unsigned: size_t, Word.T<BR>> signed: INTEGER, ssize_t, ptrdiff_t<BR>> For 32bit integers: int32_t and uint32_t, perhaps int.<BR>> <BR>> There is arguably some ambiguity if you consider 16bit platforms.<BR>> <BR>> Now, I noticed we have:<BR>> INTERFACE Cstddef;<BR>> <BR>> size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long;<BR>> <BR>> I would like to change this, either to:<BR>> <BR>> 32bits:<BR>> size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int;<BR>> <BR>> 64bits:<BR>> size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long;<BR>> <BR>> or portable:<BR>> size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER;<BR>> but, my question then is, why isn't the portable version already in use?<BR>> Especially for the signed types.<BR>> <BR>> I mean, you know, we have:<BR>> <BR>> 32bits/BasicCtypes:<BR>> <BR>> INTERFACE BasicCtypes;<BR>> IMPORT Word, Long;<BR>> TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff];<BR>> question is, why aren't int and long_int INTEGER?<BR>> <BR>> 64bits/BasicCtypes:<BR>> <BR>> long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];<BR>> <BR>> why not INTEGER?<BR>> <BR>> <BR>> <BR>> +--------------------------------------------------------+<BR>> | Peter P. Eiserloh |<BR>> +--------------------------------------------------------+<BR>> <BR>> <BR>> <BR><BR></body>
</html>