<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Mika, I'm not sure what the answer is.<BR>
<BR>
<BR>
You might recall that Tony questioned the need for LONGINT, because it is "only" there to interface with C, and I've rewritten all the C interfacing, providing perhaps other means to solve that problem...I'm not sure what means Tony had in mind, but perhaps an array or record as you/I show.<BR>
<BR>
<BR>
Others spoke up about the need to work with files larger than 2GB.<BR>
Which isn't necessarily enabled by providing LONGINT, but it is a small convenient step ("convenient" to who? Not the compiler developer. :) )<BR>
<BR>
<BR>
A very small amount of code has been "fixed" to pass along large file sizes with complete fidelity.<BR>
The Rd/Wr interface continues to not work, or work well or easily, with streams beyond 2GB in size. I still that that should be dealt with. And I still suspect a 64bit size is near enough to infinity (for I/O purposes), that the interfaces don't need a significant redesign, merely a widening of INTEGER to LONGINT. Pass the problem up yet one more level. Granted, I vaguely recall that most/many/all rd/wr users require their data to fit into memory, so they'll fail with >2GB file sizes.<BR>
<BR>
<BR>
Recall that merely browsing to a directory with a large file with the normal Trestle GUI would hit a subrange fault and generally terminate the running program -- no need to try to open the file. That bug at least should now be fixed by LONGINT. Granted, it probably could have been fixed e.g. by lying and giving such files a size of LAST(INTEGER). ?<BR>
<BR>
<BR>
"Obviously" 64 is just one special spot on a range of integer sizes.<BR>
Realize however that a number of 64bit integer operations really can be very efficiently implemented on most 32bit processors. Though not all operations -- add, subtract, compare are reasonable, multiply, divide less so.<BR>
However arbitrary precision arithmetic, not just double precision, can be done about as efficiently -- the critical piece is "exposing the carry flag efficiently", if it exists, and we don't actually do that.<BR>
<BR>
<BR>
Another opinion is that 64bit platforms already work..and perhaps 32bit platforms won't be around much longer anyway.<BR>
This feature is 10-20 years too late and its impact therefore won't be significant. ?<BR>
(<A href="http://yarchive.net/comp/longlong.html">http://yarchive.net/comp/longlong.html</A> dates "long long" to circa 18 years ago.)<BR>
<BR>
<BR>
Again, I don't have an anwer.<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> To: jay.krell@cornell.edu<BR>> Date: Sun, 18 Apr 2010 00:49:27 -0700<BR>> From: mika@async.async.caltech.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] INTEGER<BR>> <BR>> <BR>> Jay I know most of this, and it doesn't really answer the question<BR>> "what is it for?"<BR>> <BR>> I think we've already established that LONGINT isn't useful for counting<BR>> anything that might actually reside in the computer's memory: it makes<BR>> no sense as an array index, for instance. INTEGER suffices for that.<BR>> <BR>> I thought that the only real reason for LONGINT was to match C's<BR>> declaration of various seek-related routines on 32-bit machines.<BR>> That's not a very good reason.<BR>> <BR>> C++ succeeds because it does very well in the area(s) it is good at.<BR>> People who want to program in C++ will clearly program in C++, not<BR>> Modula-3. Modula-3 is never, ever going to be the language of choice for<BR>> people who want lots of snazzy infix operators. Modula-3 is supposed to<BR>> be a language with about as powerful semantics as C++ and an extremely<BR>> simple syntax and definition---snazzy infix is one of the things you<BR>> give up for that. I don't see how LONGINT fits into this picture.<BR>> Now we have LONGCARD too? And it's infected the definitions<BR>> of FIRST and LAST? But not NUMBER... argh!<BR>> <BR>> so,<BR>> <BR>> NUMBER(a) and LAST(a) - FIRST(a) + 1<BR>> <BR>> no longer mean the same thing? Are we going to see lots of comments<BR>> in generics in the future where it says T may not be an open array<BR>> type nor an array type indexed on LONGINT or a subrange thereof?<BR>> <BR>> Your comments about different parameter-passing techniques was what I was<BR>> trying to address with my suggestion to have a pragma for this---just to<BR>> match C (and Fortran?), of course. Name me a single Modula-3 programmer<BR>> who cares in what order the bits in his parameters are pushed on the<BR>> stack in a Modula-3-to-Modula-3 call.<BR>> <BR>> And I am definitely in that school of thought that says that programming<BR>> languages should not "evolve". Better to leave well enough alone.<BR>> <BR>> How much Modula-3 code has been written that uses LONGINT? Other than<BR>> to talk to C? I've certainly never used it.<BR>> <BR>> Mika<BR>> <BR>> <BR>> <BR>> Jay K writes:<BR>> >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_<BR>> >Content-Type: text/plain; charset="iso-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>> ><BR>> ><BR>> >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a 32bit system is very close to=<BR>> > LONGINT.<BR>> ><BR>> > Plus treating it opaquely and providing a bunch of functions to operate on=<BR>> > it.<BR>> ><BR>> > Just as well therefore could be RECORD hi=2Clo:LONGINT END (see LARGE_INTE=<BR>> >GER and ULARGE_INTEGER in winnt.h)<BR>> ><BR>> >=20<BR>> ><BR>> >Differences that come to mind:<BR>> ><BR>> > infix operators <=3D=3D=3D=20<BR>> ><BR>> > possibly passed differently as a parameter<BR>> ><BR>> > or returned differently as a result<BR>> ><BR>> > ie. probably "directly compatible with" "long long"=2C passed by value (o=<BR>> >f course you could always pass by pointer and achieve compatibilitity trivi=<BR>> >ally)<BR>> ><BR>> >=20<BR>> ><BR>> >=20<BR>> ><BR>> >I have to say though=2C the biggest reason is in-fix operators. Convenient =<BR>> >syntax.<BR>> ><BR>> >C++ is the best and some way worst of example of the general right way to d=<BR>> >o this -- you let programmers define types and their infix operators. Other=<BR>> > languages just come with a passle of special cases of types that have in-f=<BR>> >ix operators.<BR>> ><BR>> >A good example is that Java infix operator + on string=2C besides the vario=<BR>> >us integers=2C and nothing else.<BR>> ><BR>> >=20<BR>> ><BR>> >=20<BR>> ><BR>> >I think C# lets you define operators=2C yet people don't complain that it i=<BR>> >s "a mess" as they do of C++.<BR>> ><BR>> >I think Python does now too.<BR>> ><BR>> >So it is feature growing in popularity among "mainstream" languages=2C not =<BR>> >just C++.<BR>> ><BR>> > C++ of course is extremely mainstream=2C but also a favorite target. (ht=<BR>> >tp://www.relisoft.com/tools/CppCritic.html)<BR>> ><BR>> >=20<BR>> ><BR>> >=20<BR>> ><BR>> >We also have subranges of LONGINT.<BR>> ><BR>> >I'm not sure what the generalization of subranges are=2C granted.<BR>> ><BR>> > Maybe some sort of C++ template that takes constants in the template and d=<BR>> >oes range checks at runtime. Yeah=2C maybe.<BR>> ><BR>> >=20<BR>> ><BR>> >=20<BR>> ><BR>> >And as you point out=2C convenient literal syntax.<BR>> ><BR>> >=20<BR>> ><BR>> >=20<BR>> ><BR>> >People reasonably argue for library extension in place of language extensio=<BR>> >n=2C but that requires a language which is flexible enough to write librari=<BR>> >es with the desired interface=2C and so many languages don't let infix oper=<BR>> >ators be in a user-written library.<BR>> ><BR>> >(There is a subtle but useless distinction here -- infix operators being in=<BR>> > libraries vs. "user-written" libraries. The infix set operations for examp=<BR>> >le are in a library=2C but not user-written=2C special=2C the compiler know=<BR>> >s about it.)<BR>> ><BR>> >=20<BR>> ><BR>> >> that would perhaps not match how C handles "long long" on the same<BR>> >> platform (which is how=2C come to think of it?)=2C and that would require<BR>> ><BR>> ><BR>> >=20<BR>> ><BR>> >On NT/x86=2C __int64/long long is returned in the register pair edx:eax.<BR>> ><BR>> >edx is high=2C eax is low.<BR>> ><BR>> >When passed as a parameter to __stdcall or __cdecl is just passed as two 32=<BR>> >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu=<BR>> >sh we go" is the Snow White-influenced mantra to remember how to pass them=<BR>> >=2C at least on little endian stack-growing-down machines (which includes x=<BR>> >86). For __fastcall I'm not sure they are passed in registers or on the sta=<BR>> >ck.<BR>> ><BR>> >Passing and/or returning small structs also has special efficient handling =<BR>> >in the ABI=2C so __int64 really might be equivalent to a small record. Not =<BR>> >that cm3 necessarily implements that "correctly" -- for interop with C=3B =<BR>> >for Modula-3 calling Modula-3 we can make up our own ABI so there isn't rea=<BR>> >lly an "incorrect" way. Notice the mingw problem I had passing a Win32 poin=<BR>> >t struct by value=2C I cheated and passed it by VAR to a C wrapper to worka=<BR>> >round the gcc backend bug (which was mentioned a few times and which I look=<BR>> >ed into the code for=2C but took the easy route)<BR>> ><BR>> >=20<BR>> ><BR>> >=20<BR>> ><BR>> >I don't know how long long works on other platforms but probably similar.<BR>> ><BR>> >Probably a certain register pair for return values.<BR>> ><BR>> >=20<BR>> ><BR>> > - Jay<BR>> ><BR>> >=20<BR>> >> To: hosking@cs.purdue.edu<BR>> >> Date: Sat=2C 17 Apr 2010 19:47:03 -0700<BR>> >> From: mika@async.async.caltech.edu<BR>> >> CC: m3devel@elegosoft.com<BR>> >> Subject: Re: [M3devel] INTEGER<BR>> >>=20<BR>> >> Tony Hosking writes:<BR>> >> ><BR>> >> ...<BR>> >> ><BR>> >> >> We need it to match 64-bit integers on 32-bit machines? That seems =3D<BR>> >> >like<BR>> >> >> a very weak rationale indeed=2C if the same functionality could be =3D<BR>> >> >provided<BR>> >> >> through some other mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even =<BR>> >=3D<BR>> >> >with<BR>> >> >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler =<BR>> >=3D<BR>> >> >that<BR>> >> >> a special linkage convention is needed).<BR>> >> ><BR>> >> >There's no special linkage convention. Not sure what you mean here.<BR>> >> ><BR>> >>=20<BR>> >> I just mean if we had<BR>> >>=20<BR>> >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER<BR>> >>=20<BR>> >> that would perhaps not match how C handles "long long" on the same<BR>> >> platform (which is how=2C come to think of it?)=2C and that would require<BR>> >> special linkage tricks.<BR>> >>=20<BR>> >> But what would be lost? The ability to type literals.=20<BR>> >>=20<BR>> >> You could get the same code interface on 32- and 64-bit machine by<BR>> >> defining<BR>> >>=20<BR>> >> TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ]<BR>> >>=20<BR>> >> and using that.<BR>> >>=20<BR>> >>=20<BR>> >> Mika<BR>> > =<BR>> ><BR>> >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_<BR>> >Content-Type: text/html; charset="iso-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>> ><BR>> ><html><BR>> ><head><BR>> ><style><!--<BR>> >.hmmessage P<BR>> >{<BR>> >margin:0px=3B<BR>> >padding:0px<BR>> >}<BR>> >body.hmmessage<BR>> >{<BR>> >font-size: 10pt=3B<BR>> >font-family:Verdana<BR>> >}<BR>> >--></style><BR>> ></head><BR>> ><body class=3D'hmmessage'><BR>> >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a =3B32bit system is very c=<BR>> >lose to LONGINT.<BR><BR>> > =3BPlus treating it opaquely and providing a bunch of functions to ope=<BR>> >rate on it.<BR><BR>> > =3BJust as well therefore could be RECORD hi=2Clo:LONGINT END (see LAR=<BR>> >GE_INTEGER and ULARGE_INTEGER in winnt.h)<BR><BR>> > =3B<BR><BR>> >Differences that come to mind:<BR><BR>> > =3B =3Binfix operators =3B <=3B=3D=3D=3D <BR><BR>> > =3B possibly passed differently =3Bas a parameter<BR><BR>> > =3B or returned differently as a result<BR><BR>> > =3B ie. probably "directly compatible with" "long long"=2C passed by v=<BR>> >alue (of course you could always pass by pointer and achieve compatibilitit=<BR>> >y trivially)<BR><BR>> > =3B<BR><BR>> > =3B<BR><BR>> >I have to say though=2C the biggest reason is in-fix operators. Convenient =<BR>> >syntax.<BR><BR>> >C++ is the best and some way worst of example of the general right way to d=<BR>> >o this -- you let programmers define types and their infix operators. Other=<BR>> > languages just come with a passle of special cases of types that have in-f=<BR>> >ix operators.<BR><BR>> >A good example is that Java infix operator + on string=2C besides the vario=<BR>> >us integers=2C and nothing else.<BR><BR>> > =3B<BR><BR>> > =3B<BR><BR>> >I think C# lets you define operators=2C yet people don't complain that it i=<BR>> >s "a mess" as they do of C++.<BR><BR>> >I think Python does now too.<BR><BR>> >So it is feature growing in popularity among "mainstream" languages=2C not =<BR>> >just C++.<BR><BR>> > =3B =3B C++ of course is extremely mainstream=2C but also a favori=<BR>> >te target. (<A href=3D"http://www.relisoft.com/tools/CppCritic.html">http:/=<BR>> >/www.relisoft.com/tools/CppCritic.html</A>)<BR><BR>> > =3B<BR><BR>> > =3B<BR><BR>> >We also have subranges of LONGINT.<BR><BR>> >I'm not sure what the generalization of subranges are=2C granted.<BR><BR>> > =3BMaybe some sort of C++ template that takes constants in the templat=<BR>> >e and does range checks at runtime. Yeah=2C maybe.<BR><BR>> > =3B<BR><BR>> > =3B<BR><BR>> >And as you point out=2C convenient literal syntax.<BR><BR>> > =3B<BR><BR>> > =3B<BR><BR>> >People reasonably argue for library extension in place of language extensio=<BR>> >n=2C but that requires a language which is flexible enough to write librari=<BR>> >es with the desired interface=2C and so many languages don't let infix oper=<BR>> >ators be in a user-written library.<BR><BR>> >(There is a subtle but useless distinction here -- infix operators being in=<BR>> > libraries vs. "user-written" libraries. The infix set operations for examp=<BR>> >le are in a library=2C but not user-written=2C special=2C the compiler know=<BR>> >s about it.)<BR><BR>> > =3B<BR><BR>> >>=3B that would perhaps not match how C handles "long long" on the same<B=<BR>> >R>>=3B platform (which is how=2C come to think of it?)=2C and that would =<BR>> >require<BR><BR><BR>> > =3B<BR><BR>> >On NT/x86=2C __int64/long long is returned in the register pair edx:eax.<BR=<BR>> >><BR>> >edx is high=2C eax is low.<BR><BR>> >When passed as a parameter to __stdcall or __cdecl is just passed as two 32=<BR>> >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu=<BR>> >sh we go" is the Snow White-influenced mantra to remember how to pass them=<BR>> >=2C at least on little endian stack-growing-down machines (which includes x=<BR>> >86). For __fastcall I'm not sure they are passed in registers or on the sta=<BR>> >ck.<BR><BR>> >Passing and/or returning small structs also has special efficient handling =<BR>> >in the ABI=2C so __int64 really might be equivalent to a small record. Not =<BR>> >that cm3 necessarily implements that "correctly" =3B -- for interop wit=<BR>> >h C=3B for Modula-3 calling Modula-3 we can make up our own ABI so there is=<BR>> >n't =3Breally an "incorrect" way. =3BNotice the mingw problem I had=<BR>> > passing a Win32 point struct by value=2C I cheated and passed it by VAR to=<BR>> > a =3BC wrapper to workaround the gcc backend bug (which was mentioned =<BR>> >a few times and which I looked into the code for=2C but took the easy route=<BR>> >)<BR><BR>> > =3B<BR><BR>> > =3B<BR><BR>> >I don't know how long long works on other platforms but probably similar.<B=<BR>> >R><BR>> >Probably a certain register pair for return values.<BR><BR>> > =3B<BR><BR>> > =3B- Jay<BR><BR> =3B<BR>>=3B To: hosking@cs.purdue.edu<BR>>=3B=<BR>> > Date: Sat=2C 17 Apr 2010 19:47:03 -0700<BR>>=3B From: mika@async.async.c=<BR>> >altech.edu<BR>>=3B CC: m3devel@elegosoft.com<BR>>=3B Subject: Re: [M3de=<BR>> >vel] INTEGER<BR>>=3B <BR>>=3B Tony Hosking writes:<BR>>=3B >=3B<BR>=<BR>> >>=3B ...<BR>>=3B >=3B<BR>>=3B >=3B>=3B We need it to match 64-b=<BR>> >it integers on 32-bit machines? That seems =3D<BR>>=3B >=3Blike<BR>>=<BR>> >=3B >=3B>=3B a very weak rationale indeed=2C if the same functionality =<BR>> >could be =3D<BR>>=3B >=3Bprovided<BR>>=3B >=3B>=3B through some o=<BR>> >ther mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even =3D<BR>>=3B >=3B=<BR>> >with<BR>>=3B >=3B>=3B a pragma e.g. <=3B*CLONGLONG*>=3B.. if it i=<BR>> >s necessary to tell the compiler =3D<BR>>=3B >=3Bthat<BR>>=3B >=3B&=<BR>> >gt=3B a special linkage convention is needed).<BR>>=3B >=3B<BR>>=3B &=<BR>> >gt=3BThere's no special linkage convention. Not sure what you mean here.<BR=<BR>> >>>=3B >=3B<BR>>=3B <BR>>=3B I just mean if we had<BR>>=3B <BR>>=<BR>> >=3B TYPE LONGINT =3D ARRAY [0..1] OF INTEGER<BR>>=3B <BR>>=3B that woul=<BR>> >d perhaps not match how C handles "long long" on the same<BR>>=3B platfor=<BR>> >m (which is how=2C come to think of it?)=2C and that would require<BR>>=<BR>> >=3B special linkage tricks.<BR>>=3B <BR>>=3B But what would be lost? Th=<BR>> >e ability to type literals. <BR>>=3B <BR>>=3B You could get the same co=<BR>> >de interface on 32- and 64-bit machine by<BR>>=3B defining<BR>>=3B <BR>=<BR>> >>=3B TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ]<B=<BR>> >R>>=3B <BR>>=3B and using that.<BR>>=3B <BR>>=3B <BR>>=3B Mika<BR=<BR>> >> </body><BR>> ></html>=<BR>> ><BR>> >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_--<BR> </body>
</html>