[M3devel] INTEGER

[Jay K]

Mika I think your point, which I missed for a while is that:

  Just because some hardware has an efficient 64bit integer called INTEGER, does not justify giving other (32bit) hardware a somewhat efficient 64bit integer called LONGINT. ?

  The analogy I missed is, just because EXTENDED ought to be 80 bits on x86, it should still be 64bits on most other systems. A "maximum" of 3 floating point types are provided names, but systems that don't want that many can equate some of them.

 

 In fact..one might argue... 64bit hardware has very efficient 32bit integer and very efficient 64bit integer, you almost want:

  32bit: INTEGER = LONGINT = 32bits

  64bit: INTEGER = 32bits, LONGINT = 64bits

 

While I doubt that's is where we are heading, it is in fact what all current C environments do, with one exception, if you map "int" = "INTEGER", "long" = "LONGINT".

(The exception is Win64.)

 

But Modula-3 has subranges and packed types, so I guess:
INT32 = BITS 32 for [16_80000000..16_7FFFFFFF];

 

suffices?

 

 

 - Jay

 
> To: hosking at cs.purdue.edu
> Date: Tue, 20 Apr 2010 11:07:15 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER
> 
> Tony Hosking writes:
> >On 20 Apr 2010, at 13:12, Mika Nystrom wrote:
> ...
> >> easy access to the hardware in their own machines, not really so that =
> >IBM
> >> programmers could have an extra format for VAX compatibility. Note =
> >that
> >> I don't believe that it was intended that EXTENDED would be emulated =
> >by
> >> the compiler either: the point was really to give programmers access =
> >to
> >> the formats provided efficiently by their hardware.
> >
> >In the current implementation EXTENDED=3DLONGREAL.
> 
> Ok, but EXTENDED is still something that is efficiently provided by
> my hardware. Not something efficiently provided by someone else's
> hardware!
> 
> >> 4. I still haven't seen any really convincing use cases. What's it =
> >for?
> >> The lack of LONGINT was an obstacle to what, precisely?
> >
> >I think the only one we have is file sizes...
> >
> >> 5. Finally, is it the intention that LONGINT be fixed at 64 bits
> >> forevermore? (See point 2.) This seems to completely fly in the face
> >> of M3's philosophy. (See Hendrik's arguments.)
> >
> >The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER).
> 
> I am not so sure here.
> 
> Rodney's argument has in fact convinced me that the current version of
> LONGINT is wrong and perhaps evil. It should either go away completely
> or be replaced by Hendrik's suggestion.
> 
> Here's why. The argument is that if I have an N-bit machine, for N<M,
> out there in the world there is an M-bit machine that for some reason
> matters a great deal to me. For some reason I need to be able to write
> code that manipulates M-bit integers---because of the existence of this
> M-bit machine (or machines)! (Normally we're dealing with the situation
> that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to
> reason that if the M-bit machine (which I do not own and upon which my
> program does not run) is important to me, it is also important to other
> Modula-3 programmers. Hence all other implementations of Modula-3 will
> *also* provide M-bit integers. 
> 
> The M-bit machine of the previous paragraph is of course, in the real
> world, a machine with the 64-bit version of the Intel x86 instruction set,
> "amd64". How long is it from here to the point where we have programmers
> who write code that depends on the fact that M=64, always?
> 
> Mika
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100420/39e21549/attachment-0002.html>