[M3devel] cm3 regression

[Jay]

[tangential...]

I think the definition of INTEGER is OK, but it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't have to provide them themselves. (CARDINAL I don't think is what I want.)
Add them somewhere in m3core?
MODULE Integers; ?

Unfortunately, actually, I want more than this, and then coming up with names is hard.

I want "safe" integers that raise exceptions or something upon overflow.
I want "unsafe" integers that silently "wrap around".
And maybe "arbitrary precision" integers that grow to accomodate, but also are smart and shrink to throw away trailing zeros.

I know you can often push stuff out of the language and into a library. As long as the language allows the library writer to provide a "nice enough" interface. For example the use of the plus sign on user defined types.. You know..like C++... but less complicated and easier to implement and fully understand...

In C, "officially", unsigned integers are unsafe and wrap around silently, and overflow on signed integers is undefined, however in reality, they are also silent, and I suspect, but am not sure, that I want both versions..maybe only for compat with existing code.

Which reminds me -- am I correct that the Modula-3 language defines overflow as raising an exception but nobody implements it that way? I can check. Are folks interested in fixing that?

 - 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/20080416/16f5a026/attachment-0002.html>