<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
TYPE LONGINT = ARRAY [0..1] OF INTEGER on a 32bit system is very close to LONGINT.<BR>
Plus treating it opaquely and providing a bunch of functions to operate on it.<BR>
Just as well therefore could be RECORD hi,lo:LONGINT END (see LARGE_INTEGER and ULARGE_INTEGER in winnt.h)<BR>
<BR>
Differences that come to mind:<BR>
infix operators <=== <BR>
possibly passed differently as a parameter<BR>
or returned differently as a result<BR>
ie. probably "directly compatible with" "long long", passed by value (of course you could always pass by pointer and achieve compatibilitity trivially)<BR>
<BR>
<BR>
I have to say though, the biggest reason is in-fix operators. Convenient syntax.<BR>
C++ is the best and some way worst of example of the general right way to do this -- you let programmers define types and their infix operators. Other languages just come with a passle of special cases of types that have in-fix operators.<BR>
A good example is that Java infix operator + on string, besides the various integers, and nothing else.<BR>
<BR>
<BR>
I think C# lets you define operators, yet people don't complain that it is "a mess" as they do of C++.<BR>
I think Python does now too.<BR>
So it is feature growing in popularity among "mainstream" languages, not just C++.<BR>
C++ of course is extremely mainstream, but also a favorite target. (<A href="http://www.relisoft.com/tools/CppCritic.html">http://www.relisoft.com/tools/CppCritic.html</A>)<BR>
<BR>
<BR>
We also have subranges of LONGINT.<BR>
I'm not sure what the generalization of subranges are, granted.<BR>
Maybe some sort of C++ template that takes constants in the template and does range checks at runtime. Yeah, maybe.<BR>
<BR>
<BR>
And as you point out, convenient literal syntax.<BR>
<BR>
<BR>
People reasonably argue for library extension in place of language extension, but that requires a language which is flexible enough to write libraries with the desired interface, and so many languages don't let infix operators be in a user-written library.<BR>
(There is a subtle but useless distinction here -- infix operators being in libraries vs. "user-written" libraries. The infix set operations for example are in a library, but not user-written, special, the compiler knows about it.)<BR>
<BR>
> that would perhaps not match how C handles "long long" on the same<BR>> platform (which is how, come to think of it?), and that would require<BR><BR>
<BR>
On NT/x86, __int64/long long is returned in the register pair edx:eax.<BR>
edx is high, eax is low.<BR>
When passed as a parameter to __stdcall or __cdecl is just passed as two 32bit values adjacent on the stack, "hi, lo, hi, lo, it's off to push we go" is the Snow White-influenced mantra to remember how to pass them, at least on little endian stack-growing-down machines (which includes x86). For __fastcall I'm not sure they are passed in registers or on the stack.<BR>
Passing and/or returning small structs also has special efficient handling in the ABI, so __int64 really might be equivalent to a small record. Not that cm3 necessarily implements that "correctly" -- for interop with C; for Modula-3 calling Modula-3 we can make up our own ABI so there isn't really an "incorrect" way. Notice the mingw problem I had passing a Win32 point struct by value, I cheated and passed it by VAR to a C wrapper to workaround the gcc backend bug (which was mentioned a few times and which I looked into the code for, but took the easy route)<BR>
<BR>
<BR>
I don't know how long long works on other platforms but probably similar.<BR>
Probably a certain register pair for return values.<BR>
<BR>
- Jay<BR><BR> <BR>> To: hosking@cs.purdue.edu<BR>> Date: Sat, 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>> <BR>> Tony Hosking writes:<BR>> ><BR>> ...<BR>> ><BR>> >> We need it to match 64-bit integers on 32-bit machines? That seems =<BR>> >like<BR>> >> a very weak rationale indeed, if the same functionality could be =<BR>> >provided<BR>> >> through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even =<BR>> >with<BR>> >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler =<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>> <BR>> I just mean if we had<BR>> <BR>> TYPE LONGINT = ARRAY [0..1] OF INTEGER<BR>> <BR>> that would perhaps not match how C handles "long long" on the same<BR>> platform (which is how, come to think of it?), and that would require<BR>> special linkage tricks.<BR>> <BR>> But what would be lost? The ability to type literals. <BR>> <BR>> You could get the same code interface on 32- and 64-bit machine by<BR>> defining<BR>> <BR>> TYPE FileOffset = ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ]<BR>> <BR>> and using that.<BR>> <BR>> <BR>> Mika<BR> </body>
</html>