<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Mika I think your point, which I missed for a while is that:<BR>
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. ?<BR>
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.<BR>
<BR>
In fact..one might argue... 64bit hardware has very efficient 32bit integer and very efficient 64bit integer, you almost want:<BR>
32bit: INTEGER = LONGINT = 32bits<BR>
64bit: INTEGER = 32bits, LONGINT = 64bits<BR>
<BR>
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".<BR>
(The exception is Win64.)<BR>
<BR>
But Modula-3 has subranges and packed types, so I guess:<BR>INT32 = BITS 32 for [16_80000000..16_7FFFFFFF];<BR>
<BR>
suffices?<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> To: hosking@cs.purdue.edu<BR>> Date: Tue, 20 Apr 2010 11:07:15 -0700<BR>> From: mika@async.async.caltech.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] INTEGER<BR>> <BR>> Tony Hosking writes:<BR>> >On 20 Apr 2010, at 13:12, Mika Nystrom wrote:<BR>> ...<BR>> >> easy access to the hardware in their own machines, not really so that =<BR>> >IBM<BR>> >> programmers could have an extra format for VAX compatibility. Note =<BR>> >that<BR>> >> I don't believe that it was intended that EXTENDED would be emulated =<BR>> >by<BR>> >> the compiler either: the point was really to give programmers access =<BR>> >to<BR>> >> the formats provided efficiently by their hardware.<BR>> ><BR>> >In the current implementation EXTENDED=3DLONGREAL.<BR>> <BR>> Ok, but EXTENDED is still something that is efficiently provided by<BR>> my hardware. Not something efficiently provided by someone else's<BR>> hardware!<BR>> <BR>> >> 4. I still haven't seen any really convincing use cases. What's it =<BR>> >for?<BR>> >> The lack of LONGINT was an obstacle to what, precisely?<BR>> ><BR>> >I think the only one we have is file sizes...<BR>> ><BR>> >> 5. Finally, is it the intention that LONGINT be fixed at 64 bits<BR>> >> forevermore? (See point 2.) This seems to completely fly in the face<BR>> >> of M3's philosophy. (See Hendrik's arguments.)<BR>> ><BR>> >The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER).<BR>> <BR>> I am not so sure here.<BR>> <BR>> Rodney's argument has in fact convinced me that the current version of<BR>> LONGINT is wrong and perhaps evil. It should either go away completely<BR>> or be replaced by Hendrik's suggestion.<BR>> <BR>> Here's why. The argument is that if I have an N-bit machine, for N<M,<BR>> out there in the world there is an M-bit machine that for some reason<BR>> matters a great deal to me. For some reason I need to be able to write<BR>> code that manipulates M-bit integers---because of the existence of this<BR>> M-bit machine (or machines)! (Normally we're dealing with the situation<BR>> that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to<BR>> reason that if the M-bit machine (which I do not own and upon which my<BR>> program does not run) is important to me, it is also important to other<BR>> Modula-3 programmers. Hence all other implementations of Modula-3 will<BR>> *also* provide M-bit integers. <BR>> <BR>> The M-bit machine of the previous paragraph is of course, in the real<BR>> world, a machine with the 64-bit version of the Intel x86 instruction set,<BR>> "amd64". How long is it from here to the point where we have programmers<BR>> who write code that depends on the fact that M=64, always?<BR>> <BR>> Mika<BR>> <BR> </body>
</html>