[M3devel] long vs. INTEGER? ranges vs. word/integer?

[Jay]

Peter, Huh? Of course not.
 
"long long" is always exactly 64 bits, except on systems where it doesn't exist at all.
 
There isn't really any 128 bit integer type in widespread use, aside from multi precision arithmetic libraries and such.
 
long on Windows is always 32bits, as I said.
 
The pointer sized types are: size_t, ptrdiff_t, ssize_t, INTEGER, and any pointer
 
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.
 
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..
 
 - Jay> Date: Fri, 2 Jan 2009 22:52:26 -0800> From: eiserlohpp@> To: m3devel@> Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer?> > Jay,> > Please don't make size_t 128 bits in size. In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. > > NOTE: an int (integer) does not have that guarantee.> > In fact, I once programed on a platform (Amiga) that had> two different compilers one used 16-bits and other 32 for> their integers. You can imagine the difficulties.> > Windows machines, as you have been using, give an address> space of 32 bits to user space. This is regardless of how> much RAM it may actually have. I would expect that on a> Win64 platform, pointers are 64 bits, and "long" is also > 64 bits.> > On my AMD64_LINUX box, pointers are 64 bits, and therefore> a long is 64, and a long long is 128. The system type> size_t is 64 bits. If you attempt to map Cstddef.size_t> to 128 bits it will not only break the syscall interfaces> to the kernel, but also be a waste of space.> > From that standpoint the type definitions> size_t = Ctypes.unsigned_long;> ..., etc.> > are correct.> > Please don't define > size_t = Ctypes.unsigned_long_long;> > > The "C" include files> /usr/includes/bits/types.h> /usr/includes/bits/typesizes.h> > play preprocessor games to ensure that the ssize_t are> defined to use the "natural" word size. > > Other types get defined to fixed sizes (ie, _int32 must> always be 32 bits) otherwise external interfaces (file> formats, inodes, ..., etc) would be corrupted. For that> reason explicitly sized types need to be defined.> > Actually, GNU/Modula-2 recently defined explictly sized> types.> > > Peter Eiserloh.> > > > Date: Fri, 2 Jan 2009 23:05:24 +0000> From: Jay <jay.krell at cornell.edu>> Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer?> To: m3devel <m3devel at elegosoft.com>, Tony <hosking at cs.purdue.edu>> Message-ID: <COL101-W1612F9835414ED341527DBE6E20 at phx.gbl>> Content-Type: text/plain; charset="iso-8859-1"> > > I'd like to avoid using "long" and "ulong" anywhere.> On Unix, they are always pointer sized.> On Windows, they are always 32 bits.> > This divergence of meaning I think it renders it useless.> > I believe for pointer-sized integers, the right types are any of:> unsigned: size_t, Word.T> signed: INTEGER, ssize_t, ptrdiff_t> For 32bit integers: int32_t and uint32_t, perhaps int.> > There is arguably some ambiguity if you consider 16bit platforms.> > Now, I noticed we have:> INTERFACE Cstddef;> > size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long;> > I would like to change this, either to:> > 32bits:> size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int;> > 64bits:> size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long;> > or portable:> size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER;> but, my question then is, why isn't the portable version already in use?> Especially for the signed types.> > I mean, you know, we have:> > 32bits/BasicCtypes:> > INTERFACE BasicCtypes;> IMPORT Word, Long;> 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];> question is, why aren't int and long_int INTEGER?> > 64bits/BasicCtypes:> > long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];> > why not INTEGER?> > > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090103/0a67de8a/attachment-0002.html>