<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Mika, I must disagree on one point -- that people with large problems have 64bit machines.<BR>
Large problem does not mean "large in memory" or large working set. It can mean "large on disk" and be combined with mostly sequential access to that disk. While 32bit is on the way out, we've had >2GB files for many years already, while 32bit was still very entrenched. You know -- disk costs vs. memory cost. It is memory beyond 4GB driving 64bit adoption, whereas disks went past 4GB long before at lower cost..<BR>
<BR>
<BR>
In your defense, I'll add "literals can be strings", something like:<BR>
<BR>
<BR>
INTERFACE Int64;<BR>
TYPE T = (* opaque! *) RECORD hi: INTEGER; low: Word.T; END; <BR>
PROCEDURE Add(a,b:T):T; <BR>
PROCEDURE Sub(a,b:T):T; <BR>
PROCEDURE LT(a,b:T):BOOLEAN; <BR>
PROCEDURE FromText(a:TEXT):T; <== <BR>
PROCEDURE FromInt(a:INTEGER):T; <BR>
PROCEDURE FromUInt64(a:UInt64.T):T RAISES{Overflow};<BR>
<BR>
<BR>
INTERFACE UInt64;<BR>
TYPE T = (* opaque! *) RECORD hi, low: Word.T; END; <BR>
PROCEDURE Add(a,b:T):T; <BR>
PROCEDURE Sub(a,b:T):T; <BR>
PROCEDURE LT(a,b:T):BOOLEAN; <BR>
PROCEDURE FromText(a:TEXT):T; <== <BR>
PROCEDURE FromInt(a:INTEGER):T; <BR>
PROCEDURE FromInt64(a:Int64.T):T RAISES{Overflow};<BR>
<BR>
<BR>
thus reducing the need.<BR>
<BR>
Does Modula-3 offer opaque types whose size is known to the client?<BR>
That is something I'd like, opacity without paying for heap allocation.<BR>
(Notice these interfaces are circularly dependent, seems reasonable, but I believe not allowed?)<BR>
<BR>
<BR>
?<BR>
<BR>
<BR>
I still say though, everyone prefers infix operators.<BR>
<BR>
<BR>
"Things change".<BR>
New needs are discovered.<BR>
Better ways of doing things.<BR>
Old restrictions fall away.<BR>
Sometimes progress is made.<BR>
Sometimes missteps are taken.<BR>
<BR>
<BR>
I believe we even had some proposals that didn't change the language, e.g. big subranges or big packed types?<BR>
TYPE INT64 = [-16_8000000000000000..16_7FFFFFFFFFFFFFFF] ?<BR>
or TYPE INT64 = BITS 64 FOR[-16_8000000000000000..16_7FFFFFFFFFFFFFFF] ?<BR>
<BR>
but that's maybe not so simple?<BR>Well, I recently found that the compiler does chose sizes based on ranges:<BR>
<BR>
VAR a:[0..255] is only a byte, even without saying BITS 8 (at least when in a record).<BR>
<BR>
<BR>
Do your language processing tools handle the notion that they are "cross compiling" to 64bit machines, where target integers don't fit in host integers?<BR>
<BR>
<BR>
- Jay<BR><BR>
<BR>> To: hosking@cs.purdue.edu<BR>> Date: Mon, 19 Apr 2010 10:23:13 -0700<BR>> From: mika@async.async.caltech.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] INTEGER<BR>> <BR>> <BR>> Well *my* problem is that I still use PM3 for a lot of things. Trying to<BR>> switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet.<BR>> <BR>> So I'm maintaining a significant amount of code that needs to compile <BR>> under both PM3 and CM3. Two problems crop up. <BR>> <BR>> 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or<BR>> the other version of m3tk/stubgen.<BR>> <BR>> 2. Some of the code I'm maintaining processes Modula-3 code as input.<BR>> It needs to be in two versions.<BR>> <BR>> In this kind of environment, programming languages don't really<BR>> evolve, since the system depends on their being both forward- and<BR>> backward-compatible. They "change" is more correct. The way Java<BR>> changes. <BR>> <BR>> More in general, though, Modula-3's designers were clearly well acquainted<BR>> with C, Fortran, and other languages that provide different-range<BR>> integers. They chose not to indulge. I even have a version of Modula-3<BR>> for a 16-bit machine that doesn't do it, even though on this machine the<BR>> need for a 32-bit integer is arguably greater than the need for 64-bit<BR>> integers on 32-bit machines. Now we indulge in this language complication<BR>> to solve what is clearly a temporary problem, since anyone who cares<BR>> about large problems is going to have 64-bit systems yesterday... and<BR>> meanwhile no one seems to have availed himself of the solution!<BR>> <BR>> My worst fear is that once the process gets started, the reason for<BR>> staying with the original Green-Book specification has now been defeated<BR>> and we will see more and more "evolution". Trying to actually build<BR>> systems that process Modula-3 like data becomes, at that point, like<BR>> trying to stand in quicksand.<BR>> <BR>> I'm not incredibly picky here... I just hope it doesn't go further.<BR>> I would personally support either sticking with the current status quo<BR>> or going back to the Green Book w.r.t. integers and characters.<BR>> <BR>> Saying that EWD wasn't renowned for his practicality is something he<BR>> would have taken as a great compliment, I'm sure.<BR>> <BR>> Mika<BR>> <BR>> Tony Hosking writes:<BR>> >Mika,<BR>> ><BR>> >First off, I'd be very interested to know what the issues are with =<BR>> >LONGINT and stubgen. We are building that every day in regression =<BR>> >testing. It would be really good to get some precise feedback.<BR>> ><BR>> >True, LONGINT is integrated with all of the language tools (same as =<BR>> >WIDECHAR).<BR>> ><BR>> >I suppose that is the price we pay for the language having evolved. =<BR>> >Nevertheless, CM3 should be totally backward compatible with the green =<BR>> >book. There is no reason it should not build packages from PM3 or SRC.<BR>> ><BR>> >Now, this is not to say that perhaps we haven't overreached with LONGINT =<BR>> >given that 64-bit is more prevalent. But then it is also useful to be =<BR>> >able to interoperate with C libraries. The previous interfacing was =<BR>> >pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but =<BR>> >then not propagating the double INTEGER value properly throughout the =<BR>> >Modula-3 libraries.<BR>> ><BR>> >I'm sorry to say that EWD was not particularly renowned for his =<BR>> >practicality; pedant more like. Nice to be high and mighty but we also =<BR>> >need to interact with the real world.<BR>> ><BR>> >We should be able to make this work. Is there a better alternative? =<BR>> >Revoke LONGINT, and WIDECHAR?<BR>> ><BR>> >On 18 Apr 2010, at 15:59, Mika Nystrom wrote:<BR>> ><BR>> >>=20<BR>> >> My problem is really just that it's ugly. LONGx is showing up as an =<BR>> >issue<BR>> >> in all sorts of low-level code, which is not surprising since Modula-3<BR>> >> with LONGx is not the same language as Modula-3 (maybe we should call<BR>> >> it Modula-3+?)=20<BR>> >>=20<BR>> >> The compiler bootstrapping process has gotten more complicated due to =<BR>> >it,<BR>> >> and when I cvs updated m3tk yesterday stubgen wouldn't compile because =<BR>> >there<BR>> >> was something "long" in it that wasn't there before. I have no idea =<BR>> >what<BR>> >> library or components I needed to update and recompile and didn't have =<BR>> >the<BR>> >> time to deal with the issue at the time.<BR>> >>=20<BR>> >> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or<BR>> >> SRC M3 since we're no longer using the language of the Green Book.<BR>> >> (Same comment goes for WIDECHAR, by the way.)<BR>> >>=20<BR>> >> One of the wonderful things about Modula-3 *used to be* that I could<BR>> >> grab some old package from DECSRC and just use it without changes =<BR>> >since<BR>> >> no one had messed with the language definition. This is still true as<BR>> >> far as programs that just use the tools go, but it's no longer true =<BR>> >for<BR>> >> programs that process Modula-3 code as input data. Of which there are<BR>> >> more than a few: many aspects of Modula-3 were specifically designed =<BR>> >to<BR>> >> make the language easy to process by program, as an intermediate =<BR>> >format<BR>> >> and whatnot.<BR>> >>=20<BR>> >> To quote E.W.D.:<BR>> >>=20<BR>> >> 'Unfathomed misunderstanding is further revealed by the term "software<BR>> >> maintenance", as a result of which many people continue to believe =<BR>> >that<BR>> >> programs and even programming languages themselves are subject to wear<BR>> >> and tear. Your car needs maintenance too, doesn't it? Famous is the =<BR>> >story<BR>> >> of the oil company that believed that its PASCAL programs did not last<BR>> >> as long as its FORTRAN programs "because PASCAL was not maintained".'<BR>> >>=20<BR>> >> LONGx is causing me to have to do "software maintenance" on Modula-3<BR>> >> programs... for a feature that no one appears to be using and is =<BR>> >quickly<BR>> >> becoming irrelevant.<BR>> >>=20<BR>> >> Mika<BR>> >>=20<BR>> >>=20<BR>> >> Tony Hosking writes:<BR>> >>> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D=<BR>> ><BR>> >>> defined to mean the same thing for all types.<BR>> >>> NUMBER does have an INTEGER value, as expected for subranges of =<BR>> >LONGINT =3D<BR>> >>> that are not too large.<BR>> >>> This is as it has always been for subranges of INTEGER that are not =<BR>> >too =3D<BR>> >>> large.<BR>> >>>=20<BR>> >>> Mika, I'm not sure I see any of the problems you are worrying about =<BR>> >in =3D<BR>> >>> the current definition of LONGINT/LONGCARD.<BR>> >>>=20<BR>> >>> On 18 Apr 2010, at 03:49, Mika Nystrom wrote:<BR>> >>>=20<BR>> >>>> =3D20<BR>> >>>> Jay I know most of this, and it doesn't really answer the question<BR>> >>>> "what is it for?"<BR>> >>>> =3D20<BR>> >>>> I think we've already established that LONGINT isn't useful for =3D<BR>> >>> counting<BR>> >>>> anything that might actually reside in the computer's memory: it =<BR>> >makes<BR>> >>>> no sense as an array index, for instance. INTEGER suffices for =<BR>> >that.<BR>> >>>> =3D20<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>> >>>> =3D20<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 =<BR>> >choice =3D<BR>> >>> for<BR>> >>>> people who want lots of snazzy infix operators. Modula-3 is =<BR>> >supposed =3D<BR>> >>> to<BR>> >>>> be a language with about as powerful semantics as C++ and an =<BR>> >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>> >>>> =3D20<BR>> >>>> so,<BR>> >>>> =3D20<BR>> >>>> NUMBER(a) and LAST(a) - FIRST(a) + 1<BR>> >>>> =3D20<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>> >>>> =3D20<BR>> >>>> Your comments about different parameter-passing techniques was what =<BR>> >I =3D<BR>> >>> was<BR>> >>>> trying to address with my suggestion to have a pragma for =<BR>> >this---just =3D<BR>> >>> to<BR>> >>>> match C (and Fortran?), of course. Name me a single Modula-3 =3D<BR>> >>> 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>> >>>> =3D20<BR>> >>>> And I am definitely in that school of thought that says that =3D<BR>> >>> programming<BR>> >>>> languages should not "evolve". Better to leave well enough alone.<BR>> >>>> =3D20<BR>> >>>> How much Modula-3 code has been written that uses LONGINT? Other =<BR>> >than<BR>> >>>> to talk to C? I've certainly never used it.<BR>> >>>> =3D20<BR>> >>>> Mika<BR>> >>>> =3D20<BR>> >>>> =3D20<BR>> >>>> =3D20<BR>> >>>> Jay K writes:<BR>> >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_<BR>> >>>>> Content-Type: text/plain; charset=3D3D"iso-8859-1"<BR>> >>>>> Content-Transfer-Encoding: quoted-printable<BR>> >>>>> =3D20<BR>> >>>>> =3D20<BR>> >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is =<BR>> >very =3D<BR>> >>> close to=3D3D<BR>> >>>>> LONGINT.<BR>> >>>>> =3D20<BR>> >>>>> Plus treating it opaquely and providing a bunch of functions to =3D<BR>> >>> operate on=3D3D<BR>> >>>>> it.<BR>> >>>>> =3D20<BR>> >>>>> Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see =<BR>> >=3D<BR>> >>> LARGE_INTE=3D3D<BR>> >>>>> GER and ULARGE_INTEGER in winnt.h)<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> Differences that come to mind:<BR>> >>>>> =3D20<BR>> >>>>> infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20<BR>> >>>>> =3D20<BR>> >>>>> possibly passed differently as a parameter<BR>> >>>>> =3D20<BR>> >>>>> or returned differently as a result<BR>> >>>>> =3D20<BR>> >>>>> ie. probably "directly compatible with" "long long"=3D3D2C passed =<BR>> >by =3D<BR>> >>> value (o=3D3D<BR>> >>>>> f course you could always pass by pointer and achieve =<BR>> >compatibilitity =3D<BR>> >>> trivi=3D3D<BR>> >>>>> ally)<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. =<BR>> >=3D<BR>> >>> Convenient =3D3D<BR>> >>>>> syntax.<BR>> >>>>> =3D20<BR>> >>>>> C++ is the best and some way worst of example of the general right =<BR>> >=3D<BR>> >>> way to d=3D3D<BR>> >>>>> o this -- you let programmers define types and their infix =<BR>> >operators. =3D<BR>> >>> Other=3D3D<BR>> >>>>> languages just come with a passle of special cases of types that =<BR>> >have =3D<BR>> >>> in-f=3D3D<BR>> >>>>> ix operators.<BR>> >>>>> =3D20<BR>> >>>>> A good example is that Java infix operator + on string=3D3D2C =<BR>> >besides =3D<BR>> >>> the vario=3D3D<BR>> >>>>> us integers=3D3D2C and nothing else.<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> I think C# lets you define operators=3D3D2C yet people don't =<BR>> >complain =3D<BR>> >>> that it i=3D3D<BR>> >>>>> s "a mess" as they do of C++.<BR>> >>>>> =3D20<BR>> >>>>> I think Python does now too.<BR>> >>>>> =3D20<BR>> >>>>> So it is feature growing in popularity among "mainstream" =3D<BR>> >>> languages=3D3D2C not =3D3D<BR>> >>>>> just C++.<BR>> >>>>> =3D20<BR>> >>>>> C++ of course is extremely mainstream=3D3D2C but also a favorite =3D<BR>> >>> target. (ht=3D3D<BR>> >>>>> tp://www.relisoft.com/tools/CppCritic.html)<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> We also have subranges of LONGINT.<BR>> >>>>> =3D20<BR>> >>>>> I'm not sure what the generalization of subranges are=3D3D2C =<BR>> >granted.<BR>> >>>>> =3D20<BR>> >>>>> Maybe some sort of C++ template that takes constants in the =<BR>> >template =3D<BR>> >>> and d=3D3D<BR>> >>>>> oes range checks at runtime. Yeah=3D3D2C maybe.<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> And as you point out=3D3D2C convenient literal syntax.<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> People reasonably argue for library extension in place of language =<BR>> >=3D<BR>> >>> extensio=3D3D<BR>> >>>>> n=3D3D2C but that requires a language which is flexible enough to =<BR>> >write =3D<BR>> >>> librari=3D3D<BR>> >>>>> es with the desired interface=3D3D2C and so many languages don't =<BR>> >let =3D<BR>> >>> infix oper=3D3D<BR>> >>>>> ators be in a user-written library.<BR>> >>>>> =3D20<BR>> >>>>> (There is a subtle but useless distinction here -- infix operators =<BR>> >=3D<BR>> >>> being in=3D3D<BR>> >>>>> libraries vs. "user-written" libraries. The infix set operations =<BR>> >for =3D<BR>> >>> examp=3D3D<BR>> >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C=<BR>> > the =3D<BR>> >>> compiler know=3D3D<BR>> >>>>> s about it.)<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>>> that would perhaps not match how C handles "long long" on the same<BR>> >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and =<BR>> >that =3D<BR>> >>> would require<BR>> >>>>> =3D20<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair =<BR>> >=3D<BR>> >>> edx:eax.<BR>> >>>>> =3D20<BR>> >>>>> edx is high=3D3D2C eax is low.<BR>> >>>>> =3D20<BR>> >>>>> When passed as a parameter to __stdcall or __cdecl is just passed =<BR>> >as =3D<BR>> >>> two 32=3D3D<BR>> >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C =<BR>> >hi=3D3D2C lo=3D3D2C =3D<BR>> >>> it's off to pu=3D3D<BR>> >>>> sh we go" is the Snow White-influenced mantra to remember how to =<BR>> >pass =3D<BR>> >>> them=3D3D<BR>> >>>>> =3D3D2C at least on little endian stack-growing-down machines =<BR>> >(which =3D<BR>> >>> includes x=3D3D<BR>> >>>>> 86). For __fastcall I'm not sure they are passed in registers or on =<BR>> >=3D<BR>> >>> the sta=3D3D<BR>> >>>>> ck.<BR>> >>>>> =3D20<BR>> >>>>> Passing and/or returning small structs also has special efficient =3D=<BR>> ><BR>> >>> handling =3D3D<BR>> >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small =<BR>> >=3D<BR>> >>> record. Not =3D3D<BR>> >>>>> that cm3 necessarily implements that "correctly" -- for interop =<BR>> >with =3D<BR>> >>> C=3D3D3B =3D3D<BR>> >>>>> for Modula-3 calling Modula-3 we can make up our own ABI so there =3D=<BR>> ><BR>> >>> isn't rea=3D3D<BR>> >>>>> lly an "incorrect" way. Notice the mingw problem I had passing a =3D<BR>> >>> Win32 poin=3D3D<BR>> >>>>> t struct by value=3D3D2C I cheated and passed it by VAR to a C =<BR>> >wrapper =3D<BR>> >>> to worka=3D3D<BR>> >>>>> round the gcc backend bug (which was mentioned a few times and =<BR>> >which =3D<BR>> >>> I look=3D3D<BR>> >>>>> ed into the code for=3D3D2C but took the easy route)<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> I don't know how long long works on other platforms but probably =3D<BR>> >>> similar.<BR>> >>>>> =3D20<BR>> >>>>> Probably a certain register pair for return values.<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>> =3D20<BR>> >>>>> - Jay<BR>> >>>>> =3D20<BR>> >>>>> =3D3D20<BR>> >>>>>> To: hosking@cs.purdue.edu<BR>> >>>>>> Date: Sat=3D3D2C 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>> >>>>>> =3D3D20<BR>> >>>>>> Tony Hosking writes:<BR>> >>>>>>> =3D20<BR>> >>>>>> ...<BR>> >>>>>>> =3D20<BR>> >>>>>>>> We need it to match 64-bit integers on 32-bit machines? That =<BR>> >seems =3D<BR>> >>> =3D3D3D<BR>> >>>>>>> like<BR>> >>>>>>>> a very weak rationale indeed=3D3D2C if the same functionality =<BR>> >could =3D<BR>> >>> be =3D3D3D<BR>> >>>>>>> provided<BR>> >>>>>>>> through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D<BR>> >>> INTEGER---even =3D3D<BR>> >>>>> =3D3D3D<BR>> >>>>>>> with<BR>> >>>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D<BR>> >>> compiler =3D3D<BR>> >>>>> =3D3D3D<BR>> >>>>>>> that<BR>> >>>>>>>> a special linkage convention is needed).<BR>> >>>>>>> =3D20<BR>> >>>>>>> There's no special linkage convention. Not sure what you mean =<BR>> >here.<BR>> >>>>>>> =3D20<BR>> >>>>>> =3D3D20<BR>> >>>>>> I just mean if we had<BR>> >>>>>> =3D3D20<BR>> >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER<BR>> >>>>>> =3D3D20<BR>> >>>>>> that would perhaps not match how C handles "long long" on the same<BR>> >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and =<BR>> >that =3D<BR>> >>> would require<BR>> >>>>>> special linkage tricks.<BR>> >>>>>> =3D3D20<BR>> >>>>>> But what would be lost? The ability to type literals.=3D3D20<BR>> >>>>>> =3D3D20<BR>> >>>>>> You could get the same code interface on 32- and 64-bit machine by<BR>> >>>>>> defining<BR>> >>>>>> =3D3D20<BR>> >>>>>> TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. =<BR>> >+16_7fffffff ]<BR>> >>>>>> =3D3D20<BR>> >>>>>> and using that.<BR>> >>>>>> =3D3D20<BR>> >>>>>> =3D3D20<BR>> >>>>>> Mika<BR>> >>>>> =3D3D<BR>> >>>>> =3D20<BR>> >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_<BR>> >>>>> Content-Type: text/html; charset=3D3D"iso-8859-1"<BR>> >>>>> Content-Transfer-Encoding: quoted-printable<BR>> >>>>> =3D20<BR>> >>>>> <html><BR>> >>>>> <head><BR>> >>>>> <style><!--<BR>> >>>>> .hmmessage P<BR>> >>>>> {<BR>> >>>>> margin:0px=3D3D3B<BR>> >>>>> padding:0px<BR>> >>>>> }<BR>> >>>>> body.hmmessage<BR>> >>>>> {<BR>> >>>>> font-size: 10pt=3D3D3B<BR>> >>>>> font-family:Verdana<BR>> >>>>> }<BR>> >>>>> --></style><BR>> >>>>> </head><BR>> >>>>> <body class=3D3D3D'hmmessage'><BR>> >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit =<BR>> >system =3D<BR>> >>> is very c=3D3D<BR>> >>>>> lose to LONGINT.<BR><BR>> >>>>>  =3D3D3BPlus treating it opaquely and providing a bunch of =3D<BR>> >>> functions to ope=3D3D<BR>> >>>>> rate on it.<BR><BR>> >>>>>  =3D3D3BJust as well therefore could be RECORD =<BR>> >hi=3D3D2Clo:LONGINT =3D<BR>> >>> END (see LAR=3D3D<BR>> >>>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>> Differences that come to mind:<BR><BR>> >>>>>  =3D3D3B =3D3D3Binfix operators =3D3D3B =<BR>> ><=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D<BR>> >>> <BR><BR>> >>>>>  =3D3D3B possibly passed differently =3D3D3Bas a =<BR>> >parameter<BR><BR>> >>>>>  =3D3D3B or returned differently as a result<BR><BR>> >>>>>  =3D3D3B ie. probably "directly compatible with" "long =<BR>> >long"=3D3D2C =3D<BR>> >>> passed by v=3D3D<BR>> >>>>> alue (of course you could always pass by pointer and achieve =3D<BR>> >>> compatibilitit=3D3D<BR>> >>>>> y trivially)<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. =<BR>> >=3D<BR>> >>> Convenient =3D3D<BR>> >>>>> syntax.<BR><BR>> >>>>> C++ is the best and some way worst of example of the general right =<BR>> >=3D<BR>> >>> way to d=3D3D<BR>> >>>>> o this -- you let programmers define types and their infix =<BR>> >operators. =3D<BR>> >>> Other=3D3D<BR>> >>>>> languages just come with a passle of special cases of types that =<BR>> >have =3D<BR>> >>> in-f=3D3D<BR>> >>>>> ix operators.<BR><BR>> >>>>> A good example is that Java infix operator + on string=3D3D2C =<BR>> >besides =3D<BR>> >>> the vario=3D3D<BR>> >>>>> us integers=3D3D2C and nothing else.<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>> I think C# lets you define operators=3D3D2C yet people don't =<BR>> >complain =3D<BR>> >>> that it i=3D3D<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" =3D<BR>> >>> languages=3D3D2C not =3D3D<BR>> >>>>> just C++.<BR><BR>> >>>>>  =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C=<BR>> > but =3D<BR>> >>> also a favori=3D3D<BR>> >>>>> te target. (<A =3D<BR>> >>> href=3D3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D3D<BR>> >>>>> /www.relisoft.com/tools/CppCritic.html</A>)<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>> We also have subranges of LONGINT.<BR><BR>> >>>>> I'm not sure what the generalization of subranges are=3D3D2C =3D<BR>> >>> granted.<BR><BR>> >>>>>  =3D3D3BMaybe some sort of C++ template that takes constants in =<BR>> >the =3D<BR>> >>> templat=3D3D<BR>> >>>>> e and does range checks at runtime. Yeah=3D3D2C maybe.<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>> And as you point out=3D3D2C convenient literal syntax.<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>> People reasonably argue for library extension in place of language =<BR>> >=3D<BR>> >>> extensio=3D3D<BR>> >>>>> n=3D3D2C but that requires a language which is flexible enough to =<BR>> >write =3D<BR>> >>> librari=3D3D<BR>> >>>>> es with the desired interface=3D3D2C and so many languages don't =<BR>> >let =3D<BR>> >>> infix oper=3D3D<BR>> >>>>> ators be in a user-written library.<BR><BR>> >>>>> (There is a subtle but useless distinction here -- infix operators =<BR>> >=3D<BR>> >>> being in=3D3D<BR>> >>>>> libraries vs. "user-written" libraries. The infix set operations =<BR>> >for =3D<BR>> >>> examp=3D3D<BR>> >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C=<BR>> > the =3D<BR>> >>> compiler know=3D3D<BR>> >>>>> s about it.)<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>> >=3D3D3B that would perhaps not match how C handles "long long" =<BR>> >on =3D<BR>> >>> the same<B=3D3D<BR>> >>>>> R>>=3D3D3B platform (which is how=3D3D2C come to think of =<BR>> >it?)=3D3D2C and =3D<BR>> >>> that would =3D3D<BR>> >>>>> require<BR><BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair =<BR>> >=3D<BR>> >>> edx:eax.<BR=3D3D<BR>> >>>>>> =3D20<BR>> >>>>> edx is high=3D3D2C eax is low.<BR><BR>> >>>>> When passed as a parameter to __stdcall or __cdecl is just passed =<BR>> >as =3D<BR>> >>> two 32=3D3D<BR>> >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C =<BR>> >hi=3D3D2C lo=3D3D2C =3D<BR>> >>> it's off to pu=3D3D<BR>> >>>>> sh we go" is the Snow White-influenced mantra to remember how to =<BR>> >pass =3D<BR>> >>> them=3D3D<BR>> >>>>> =3D3D2C at least on little endian stack-growing-down machines =<BR>> >(which =3D<BR>> >>> includes x=3D3D<BR>> >>>>> 86). For __fastcall I'm not sure they are passed in registers or on =<BR>> >=3D<BR>> >>> the sta=3D3D<BR>> >>>>> ck.<BR><BR>> >>>>> Passing and/or returning small structs also has special efficient =3D=<BR>> ><BR>> >>> handling =3D3D<BR>> >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small =<BR>> >=3D<BR>> >>> record. Not =3D3D<BR>> >>>>> that cm3 necessarily implements that "correctly" =3D3D3B -- for =<BR>> >=3D<BR>> >>> interop wit=3D3D<BR>> >>>>> h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI =<BR>> >so =3D<BR>> >>> there is=3D3D<BR>> >>>>> n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the =<BR>> >mingw =3D<BR>> >>> problem I had=3D3D<BR>> >>>>> passing a Win32 point struct by value=3D3D2C I cheated and passed =<BR>> >it by =3D<BR>> >>> VAR to=3D3D<BR>> >>>>> a =3D3D3BC wrapper to workaround the gcc backend bug (which was =<BR>> >=3D<BR>> >>> mentioned =3D3D<BR>> >>>>> a few times and which I looked into the code for=3D3D2C but took =<BR>> >the =3D<BR>> >>> easy route=3D3D<BR>> >>>>> )<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>> I don't know how long long works on other platforms but probably =3D<BR>> >>> similar.<B=3D3D<BR>> >>>>> R><BR>> >>>>> Probably a certain register pair for return values.<BR><BR>> >>>>>  =3D3D3B<BR><BR>> >>>>>  =3D3D3B- Jay<BR><BR> =3D3D3B<BR>>=3D3D3B To: =3D<BR>> >>> hosking@cs.purdue.edu<BR>>=3D3D3B=3D3D<BR>> >>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700<BR>>=3D3D3B From: =3D<BR>> >>> mika@async.async.c=3D3D<BR>> >>>>> altech.edu<BR>>=3D3D3B CC: m3devel@elegosoft.com<BR>>=3D3D3B =<BR>> >Subject: =3D<BR>> >>> Re: [M3de=3D3D<BR>> >>>>> vel] INTEGER<BR>>=3D3D3B <BR>>=3D3D3B Tony Hosking =<BR>> >writes:<BR>>=3D3D3B =3D<BR>> >>> >=3D3D3B<BR>=3D3D<BR>> >>>>> >=3D3D3B ...<BR>>=3D3D3B >=3D3D3B<BR>>=3D3D3B =<BR>> >>=3D3D3B>=3D3D3B We =3D<BR>> >>> need it to match 64-b=3D3D<BR>> >>>>> it integers on 32-bit machines? That seems =3D3D3D<BR>>=3D3D3B =3D<BR>> >>> >=3D3D3Blike<BR>>=3D3D<BR>> >>>>> =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if =<BR>> >the same =3D<BR>> >>> functionality =3D3D<BR>> >>>>> could be =3D3D3D<BR>>=3D3D3B >=3D3D3Bprovided<BR>>=3D3D3B =<BR>> >>=3D3D3B>=3D3D3=3D<BR>> >>> B through some o=3D3D<BR>> >>>>> ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D<BR>> >>> =3D3D3D<BR>>=3D3D3B >=3D3D3B=3D3D<BR>> >>>>> with<BR>>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D<BR>> >>> <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D<BR>> >>>>> s necessary to tell the compiler =3D3D3D<BR>>=3D3D3B =3D<BR>> >>> >=3D3D3Bthat<BR>>=3D3D3B >=3D3D3B&=3D3D<BR>> >>>>> gt=3D3D3B a special linkage convention is needed).<BR>>=3D3D3B =3D<BR>> >>> >=3D3D3B<BR>>=3D3D3B &=3D3D<BR>> >>>>> gt=3D3D3BThere's no special linkage convention. Not sure what you =<BR>> >mean =3D<BR>> >>> here.<BR=3D3D<BR>> >>>>>> >=3D3D3B >=3D3D3B<BR>>=3D3D3B <BR>>=3D3D3B I just mean if =<BR>> >we =3D<BR>> >>> had<BR>>=3D3D3B <BR>>=3D3D<BR>> >>>>> =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER<BR>>=3D3D3B =<BR>> >=3D<BR>> >>> <BR>>=3D3D3B that woul=3D3D<BR>> >>>>> d perhaps not match how C handles "long long" on the =<BR>> >same<BR>>=3D3D3B =3D<BR>> >>> platfor=3D3D<BR>> >>>>> m (which is how=3D3D2C come to think of it?)=3D3D2C and that would =<BR>> >=3D<BR>> >>> require<BR>>=3D3D<BR>> >>>>> =3D3D3B special linkage tricks.<BR>>=3D3D3B <BR>>=3D3D3B But =<BR>> >what would =3D<BR>> >>> be lost? Th=3D3D<BR>> >>>>> e ability to type literals. <BR>>=3D3D3B <BR>>=3D3D3B You could =<BR>> >get =3D<BR>> >>> the same co=3D3D<BR>> >>>>> de interface on 32- and 64-bit machine by<BR>>=3D3D3B =3D<BR>> >>> defining<BR>>=3D3D3B <BR>=3D3D<BR>> >>>>> >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. =<BR>> >=3D<BR>> >>> +16_7fffffff ]<B=3D3D<BR>> >>>>> R>>=3D3D3B <BR>>=3D3D3B and using that.<BR>>=3D3D3B =<BR>> ><BR>>=3D3D3B =3D<BR>> >>> <BR>>=3D3D3B Mika<BR=3D3D<BR>> >>>>>> </body><BR>> >>>>> </html>=3D3D<BR>> >>>>> =3D20<BR>> >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_--<BR> </body>
</html>