[M3devel] Oops, forgot to ask

Thu Dec 17 02:55:15 CET 2009

These would be "base" types and people would have to pick and chose their own typedefs to suit their needs.

Imho the idea of a "natural" size is a nice theory but it turns out that "we" (in the larger software world) are stuck with the exact sizes as they happen to have been for a while. C int will always be 32 bits. Growing it will break too much code. Even if processors get natural 128 bit integers, they will still always have to deal efficiently with 32 bit integers because 32 bit integers won't go away. Ditto now 64bit integers.

As well natural is great for a local variable, but as soon as you start allocating things in large numbers, you start wanting the size to not be much larger than is needed and you consider the range you'll actually need..sometimes it is obviously small, sometimes not. If it isn't obviously small then you can err toward a larger type like or int or size_t. If it is obviously a small range and allocated in large number then you'll more seriously consider UINT8 or UINT16. If the range is unavoidably huge then you'll consider floating point or a multiple precision option.

Granted, Modula-3 does have "BITS FOR" and subranges.

I'm not used to having those.

So maybe these types aren't needed since you can build them.

The compiler does certainly have these exact types internally though.

And the processors generally all have instructions that operate on them (with varying efficiency though).

If you consider C, people often have int, long, long long.

This is as I said dumb because what will 128 integers be called, "long long long"?

"byte", "short", "long" these are just funny informal names.

A more mechanical system is INT8, INT16, INT32 or PTRDIFF_T.

 I grant that there is base integer type with the size of a pointer, that doesn't have the exact number of bits encoded.

Perhaps Modula-3 doesn't have such a bad legacy codebase?
Perhaps growing INTEGER to 64bits didn't break anything and growing it to 128 won't either?

Perhaps persistance is generally pickles and they deal better with this stuff, and not like direct blitting?

Anyway,

 - Jay

From: hosking at cs.purdue.edu
Date: Wed, 16 Dec 2009 20:10:14 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Oops, forgot to ask

On 16 Dec 2009, at 19:52, Jay K wrote:

"0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER?

See..LONGINT is only useful in this brief period where we still have 32bit INTEGER.
(Actually it would have been useful long ago.)

LONGINT could be 128 bits for all its definition cares.  It is just something usually (not always) bigger than an INTEGER.

 I really think "long" is a dumb name..
There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t..

Now these are dumb names because they wire in the size of the value.

In Modula-3 INTEGER is a natural (i.e., word-size) value.

 - Jay

> Date: Wed, 16 Dec 2009 16:56:55 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Oops, forgot to ask
> 
> Tony Hosking wrote:
> > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote:
> >
> > 
> >> Hi Gang,
> >>
> >> 0 - CARDINALs are an integral type defined by the language
> >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently,
> >> a change was made to CM3 to extend the language it recognizes
> >> beyond the original language spec (SPWM3), now CM3 understands
> >> a LONGINT. 
> >>
> >> Was there a corresponding LONGCARD defined?
> >> 
> >
> > No. But you can write:
> >
> > [0L..LAST(LONGINT)]
> >
> > just as
> >
> > CARDINAL=[0..LAST(INTEGER)]
> > 
> Actually, the line above was once true, long long ago, when dinosaurs
> roamed unfettered. CARDINAL was changed to be "just like"
> (but not equal to) [0..LAST(INTEGER)]. This would have been
> maybe early 1990s. 
> 
> It took me years to figure out what this actually meant, and more
> years to figure out why, but I believe I now know. CARDINAL is not an
> equal type to [0..LAST(INTEGER)], but otherwise has all the same
> properties. This makes the two mutually assignable, which is close
> enough to equal to not matter in most contexts. The exact consequences
> follow from other language rules. 
> 
> The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not
> equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of
> machines with different values of LAST(INTEGER)), because the numeric
> value of LAST(INTEGER) is part of the expanded type. The one place this
> matters is if you use pickles to transfer data between machines of different
> word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash
> of the complete, expanded type definition) is different on the two machines,
> and values of or containing this type cannot be transferred. Exact type
> signature matches are used in pickles to find corresponding types when
> reading. 
> 
> But pickles handle different sized INTEGER values fine, expanding/shortening
> as needed. Being a leaf in a type definition, INTEGER is always the same
> type on any machine. So CARDINAL was changed to be its own unique
> type too, so it would be possible also to transfer CARDINAL values in 
> pickles
> between different word sizes. 
> 
> So, we really should have a LONGCARD, parallel to CARDINAL.
> 
> Note that this also affects network objects, which use pickles to transfer
> values of the objects.
> 
> 
> 
> >
> > 
> >> Can is use all 64-bits, or is it restricted to 63, like
> >> the CARDINAL is only 31-bits.
> >> 
> >
> > 63 bits, since its underlying base type is LONGINT.
> >
> >
> > 
> >>
> >>
> >>
> >> +--------------------------------------------------------+
> >> | Peter P. Eiserloh |
> >> +--------------------------------------------------------+
> >>
> >>
> >>
> >> 
> >
> >
> > 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091217/fc998a3f/attachment-0002.html>