<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
I believe the 128bit and 256bit types are implemented with compiler extensions but not language extensions.<BR>
They declare records and "functions", but the compilers implement the "functions" inline (roughly one instruction each).<BR>
This is akin to interface Word and generic interface Atomic.<BR>
They are "just" libraries from a language point of view, but the compiler knows about them and inlines them.<BR>
<BR>
<BR>
Well, at least the "packed" types.<BR>
There are larger "scalar" types coming? That support infix operators?<BR>
<BR>
<BR>
Again, so far as we have all figured out (I'm guessing and building on a hint Mika provided), it is mostly just about literals and infix notation. And if that is the case, it really shows that a language ought to be a bit more flexible in the first place (user defined infix operators on user defined types), and then it won't need as much extending later on.<BR>
<BR>
<BR>
Nobody really prefers "Word.Plus(a, b)" over "a + b"...<BR>
<BR>
<BR>
- Jay<BR> <BR>> Date: Mon, 19 Apr 2010 04:47:14 +0000<BR>> From: dabenavidesd@yahoo.es<BR>> To: hosking@cs.purdue.edu; mika@async.async.caltech.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] INTEGER<BR>> <BR>> Hi:<BR>> I think the irrelevant point is arguable as there are SIMD instructions of 128-bit and later will be 256-bit packed types registers so the point of becoming irrelevant could be worrisome in time, probably not now. As packed types weren't to traumatic but are more needed now by this fact. <BR>> If you wish more generality, a language change will be needed, not an extension, language extensions are easily doable with enough knowledge but right now you would need to do it or it will become harder and harder to reconstruct your own code. If you need backward compatibility why don't host cm3 with pm3, that is old cm3 can't compile cm3 but its negative inverse is true and it is old known old cm3 can build pm3 and src m3 (current cm3 built itself as I saw with RC5 on AMD64_LINUX). Still you want to host other older environments look for doing it with CM3, I think it wouldn't be so much traumatic, wouldn't it? You would compile and have two different runtime but you could do what you want to do, as I guess you were doing for other reasons and it wouldn't be so much effort to do it, maybe the ugly parts would be system dependent things as I think.<BR>> I think there are many other options as to be backwards compatible like drop new features or build against other specific libraries, but again is not that the purpose you are looking for, then is simpler if you think the above intention in some sense to you?<BR>> It's just an idea, hope it helps something.<BR>> <BR>> --- El dom, 18/4/10, Mika Nystrom <mika@async.async.caltech.edu> escribió:<BR>> <BR>> > De: Mika Nystrom <mika@async.async.caltech.edu><BR>> > Asunto: Re: [M3devel] INTEGER<BR>> > Para: "Tony Hosking" <hosking@cs.purdue.edu><BR>> > CC: m3devel@elegosoft.com<BR>> > Fecha: domingo, 18 de abril, 2010 14:59<BR>> > <BR>> > My problem is really just that it's ugly. LONGx is<BR>> > showing up as an issue<BR>> > in all sorts of low-level code, which is not surprising<BR>> > since Modula-3<BR>> > with LONGx is not the same language as Modula-3 (maybe we<BR>> > should call<BR>> > it Modula-3+?) <BR>> > <BR>> > The compiler bootstrapping process has gotten more<BR>> > complicated due to it,<BR>> > and when I cvs updated m3tk yesterday stubgen wouldn't<BR>> > compile because there<BR>> > was something "long" in it that wasn't there before. <BR>> > I have no idea what<BR>> > library or components I needed to update and recompile and<BR>> > didn't have the<BR>> > time to deal with the issue at the time.<BR>> > <BR>> > And the new m3tk, stubgen, and compiler(?) won't compile<BR>> > using PM3 or<BR>> > SRC M3 since we're no longer using the language of the<BR>> > Green Book.<BR>> > (Same comment goes for WIDECHAR, by the way.)<BR>> > <BR>> > One of the wonderful things about Modula-3 *used to be*<BR>> > that I could<BR>> > grab some old package from DECSRC and just use it without<BR>> > changes since<BR>> > no one had messed with the language definition. This<BR>> > is still true as<BR>> > far as programs that just use the tools go, but it's no<BR>> > longer true for<BR>> > programs that process Modula-3 code as input data. Of<BR>> > which there are<BR>> > more than a few: many aspects of Modula-3 were specifically<BR>> > designed to<BR>> > make the language easy to process by program, as an<BR>> > intermediate format<BR>> > and whatnot.<BR>> > <BR>> > To quote E.W.D.:<BR>> > <BR>> > 'Unfathomed misunderstanding is further revealed by the<BR>> > term "software<BR>> > maintenance", as a result of which many people continue to<BR>> > believe that<BR>> > programs and even programming languages themselves are<BR>> > subject to wear<BR>> > and tear. Your car needs maintenance too, doesn't it?<BR>> > Famous is the story<BR>> > of the oil company that believed that its PASCAL programs<BR>> > did not last<BR>> > as long as its FORTRAN programs "because PASCAL was not<BR>> > maintained".'<BR>> > <BR>> > LONGx is causing me to have to do "software maintenance" on<BR>> > Modula-3<BR>> > programs... for a feature that no one appears to be using<BR>> > and is quickly<BR>> > becoming irrelevant.<BR>> > <BR>> > Mika<BR>> > <BR>> > <BR>> > Tony Hosking writes:<BR>> > >In the language spec NUMBER(a) and LAST(a) - FIRST(a) +<BR>> > 1 are *not* =<BR>> > >defined to mean the same thing for all types.<BR>> > >NUMBER does have an INTEGER value, as expected for<BR>> > subranges of LONGINT =<BR>> > >that are not too large.<BR>> > >This is as it has always been for subranges of INTEGER<BR>> > that are not too =<BR>> > >large.<BR>> > ><BR>> > >Mika, I'm not sure I see any of the problems you are<BR>> > worrying about in =<BR>> > >the current definition of LONGINT/LONGCARD.<BR>> > ><BR>> > >On 18 Apr 2010, at 03:49, Mika Nystrom wrote:<BR>> > ><BR>> > >>=20<BR>> > >> Jay I know most of this, and it doesn't really<BR>> > answer the question<BR>> > >> "what is it for?"<BR>> > >>=20<BR>> > >> I think we've already established that LONGINT<BR>> > isn't useful for =<BR>> > >counting<BR>> > >> anything that might actually reside in the<BR>> > computer's memory: it makes<BR>> > >> no sense as an array index, for instance. <BR>> > INTEGER suffices for that.<BR>> > >>=20<BR>> > >> I thought that the only real reason for LONGINT<BR>> > was to match C's<BR>> > >> declaration of various seek-related routines on<BR>> > 32-bit machines.<BR>> > >> That's not a very good reason.<BR>> > >>=20<BR>> > >> C++ succeeds because it does very well in the<BR>> > area(s) it is good at.<BR>> > >> People who want to program in C++ will clearly<BR>> > program in C++, not<BR>> > >> Modula-3. Modula-3 is never, ever going to<BR>> > be the language of choice =<BR>> > >for<BR>> > >> people who want lots of snazzy infix<BR>> > operators. Modula-3 is supposed =<BR>> > >to<BR>> > >> be a language with about as powerful semantics as<BR>> > C++ and an extremely<BR>> > >> simple syntax and definition---snazzy infix is one<BR>> > of the things you<BR>> > >> give up for that. I don't see how LONGINT<BR>> > fits into this picture.<BR>> > >> Now we have LONGCARD too? And it's infected<BR>> > the definitions<BR>> > >> of FIRST and LAST? But not NUMBER... argh!<BR>> > >>=20<BR>> > >> so,<BR>> > >>=20<BR>> > >> NUMBER(a) and LAST(a) - FIRST(a) + 1<BR>> > >>=20<BR>> > >> no longer mean the same thing? Are we going<BR>> > to see lots of comments<BR>> > >> in generics in the future where it says T may not<BR>> > be an open array<BR>> > >> type nor an array type indexed on LONGINT or a<BR>> > subrange thereof?<BR>> > >>=20<BR>> > >> Your comments about different parameter-passing<BR>> > techniques was what I =<BR>> > >was<BR>> > >> trying to address with my suggestion to have a<BR>> > pragma for this---just =<BR>> > >to<BR>> > >> match C (and Fortran?), of course. Name me a<BR>> > single Modula-3 =<BR>> > >programmer<BR>> > >> who cares in what order the bits in his parameters<BR>> > are pushed on the<BR>> > >> stack in a Modula-3-to-Modula-3 call.<BR>> > >>=20<BR>> > >> And I am definitely in that school of thought that<BR>> > says that =<BR>> > >programming<BR>> > >> languages should not "evolve". Better to<BR>> > leave well enough alone.<BR>> > >>=20<BR>> > >> How much Modula-3 code has been written that uses<BR>> > LONGINT? Other than<BR>> > >> to talk to C? I've certainly never used it.<BR>> > >>=20<BR>> > >> Mika<BR>> > >>=20<BR>> > >>=20<BR>> > >>=20<BR>> > >> Jay K writes:<BR>> > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_<BR>> > >>> Content-Type: text/plain;<BR>> > charset=3D"iso-8859-1"<BR>> > >>> Content-Transfer-Encoding: quoted-printable<BR>> > >>>=20<BR>> > >>>=20<BR>> > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on<BR>> > a 32bit system is very =<BR>> > >close to=3D<BR>> > >>> LONGINT.<BR>> > >>>=20<BR>> > >>> Plus treating it opaquely and providing a<BR>> > bunch of functions to =<BR>> > >operate on=3D<BR>> > >>> it.<BR>> > >>>=20<BR>> > >>> Just as well therefore could be RECORD<BR>> > hi=3D2Clo:LONGINT END (see =<BR>> > >LARGE_INTE=3D<BR>> > >>> GER and ULARGE_INTEGER in winnt.h)<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> Differences that come to mind:<BR>> > >>>=20<BR>> > >>> infix operators <BR>> > <=3D3D=3D3D=3D3D=3D20<BR>> > >>>=20<BR>> > >>> possibly passed differently as a parameter<BR>> > >>>=20<BR>> > >>> or returned differently as a result<BR>> > >>>=20<BR>> > >>> ie. probably "directly compatible with" "long<BR>> > long"=3D2C passed by =<BR>> > >value (o=3D<BR>> > >>> f course you could always pass by pointer and<BR>> > achieve compatibilitity =<BR>> > >trivi=3D<BR>> > >>> ally)<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> I have to say though=3D2C the biggest reason<BR>> > is in-fix operators. =<BR>> > >Convenient =3D<BR>> > >>> syntax.<BR>> > >>>=20<BR>> > >>> C++ is the best and some way worst of example<BR>> > of the general right =<BR>> > >way to d=3D<BR>> > >>> o this -- you let programmers define types and<BR>> > their infix operators. =<BR>> > >Other=3D<BR>> > >>> languages just come with a passle of special<BR>> > cases of types that have =<BR>> > >in-f=3D<BR>> > >>> ix operators.<BR>> > >>>=20<BR>> > >>> A good example is that Java infix operator +<BR>> > on string=3D2C besides =<BR>> > >the vario=3D<BR>> > >>> us integers=3D2C and nothing else.<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> I think C# lets you define operators=3D2C yet<BR>> > people don't complain =<BR>> > >that it i=3D<BR>> > >>> s "a mess" as they do of C++.<BR>> > >>>=20<BR>> > >>> I think Python does now too.<BR>> > >>>=20<BR>> > >>> So it is feature growing in popularity among<BR>> > "mainstream" =<BR>> > >languages=3D2C not =3D<BR>> > >>> just C++.<BR>> > >>>=20<BR>> > >>> C++ of course is extremely<BR>> > mainstream=3D2C but also a favorite =<BR>> > >target. (ht=3D<BR>> > >>> tp://www.relisoft.com/tools/CppCritic.html)<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> We also have subranges of LONGINT.<BR>> > >>>=20<BR>> > >>> I'm not sure what the generalization of<BR>> > subranges are=3D2C granted.<BR>> > >>>=20<BR>> > >>> Maybe some sort of C++ template that takes<BR>> > constants in the template =<BR>> > >and d=3D<BR>> > >>> oes range checks at runtime. Yeah=3D2C maybe.<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> And as you point out=3D2C convenient literal<BR>> > syntax.<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> People reasonably argue for library extension<BR>> > in place of language =<BR>> > >extensio=3D<BR>> > >>> n=3D2C but that requires a language which is<BR>> > flexible enough to write =<BR>> > >librari=3D<BR>> > >>> es with the desired interface=3D2C and so many<BR>> > languages don't let =<BR>> > >infix oper=3D<BR>> > >>> ators be in a user-written library.<BR>> > >>>=20<BR>> > >>> (There is a subtle but useless distinction<BR>> > here -- infix operators =<BR>> > >being in=3D<BR>> > >>> libraries vs. "user-written" libraries. The<BR>> > infix set operations for =<BR>> > >examp=3D<BR>> > >>> le are in a library=3D2C but not<BR>> > user-written=3D2C special=3D2C the =<BR>> > >compiler know=3D<BR>> > >>> s about it.)<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>>> that would perhaps not match how C handles<BR>> > "long long" on the same<BR>> > >>>> platform (which is how=3D2C come to think<BR>> > of it?)=3D2C and that =<BR>> > >would require<BR>> > >>>=20<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> On NT/x86=3D2C __int64/long long is returned<BR>> > in the register pair =<BR>> > >edx:eax.<BR>> > >>>=20<BR>> > >>> edx is high=3D2C eax is low.<BR>> > >>>=20<BR>> > >>> When passed as a parameter to __stdcall or<BR>> > __cdecl is just passed as =<BR>> > >two 32=3D<BR>> > >>> bit values adjacent on the stack=3D2C "hi=3D2C<BR>> > lo=3D2C hi=3D2C lo=3D2C =<BR>> > >it's off to pu=3D<BR>> > >> sh we go" is the Snow White-influenced mantra to<BR>> > remember how to pass =<BR>> > >them=3D<BR>> > >>> =3D2C at least on little endian<BR>> > stack-growing-down machines (which =<BR>> > >includes x=3D<BR>> > >>> 86). For __fastcall I'm not sure they are<BR>> > passed in registers or on =<BR>> > >the sta=3D<BR>> > >>> ck.<BR>> > >>>=20<BR>> > >>> Passing and/or returning small structs also<BR>> > has special efficient =<BR>> > >handling =3D<BR>> > >>> in the ABI=3D2C so __int64 really might be<BR>> > equivalent to a small =<BR>> > >record. Not =3D<BR>> > >>> that cm3 necessarily implements that<BR>> > "correctly" -- for interop with =<BR>> > >C=3D3B =3D<BR>> > >>> for Modula-3 calling Modula-3 we can make up<BR>> > our own ABI so there =<BR>> > >isn't rea=3D<BR>> > >>> lly an "incorrect" way. Notice the mingw<BR>> > problem I had passing a =<BR>> > >Win32 poin=3D<BR>> > >>> t struct by value=3D2C I cheated and passed it<BR>> > by VAR to a C wrapper =<BR>> > >to worka=3D<BR>> > >>> round the gcc backend bug (which was mentioned<BR>> > a few times and which =<BR>> > >I look=3D<BR>> > >>> ed into the code for=3D2C but took the easy<BR>> > route)<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> I don't know how long long works on other<BR>> > platforms but probably =<BR>> > >similar.<BR>> > >>>=20<BR>> > >>> Probably a certain register pair for return<BR>> > values.<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>=20<BR>> > >>> - Jay<BR>> > >>>=20<BR>> > >>> =3D20<BR>> > >>>> To: hosking@cs.purdue.edu<BR>> > >>>> Date: Sat=3D2C 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>> > >>>> =3D20<BR>> > >>>> Tony Hosking writes:<BR>> > >>>>>=20<BR>> > >>>> ...<BR>> > >>>>>=20<BR>> > >>>>>> We need it to match 64-bit<BR>> > integers on 32-bit machines? That seems =<BR>> > >=3D3D<BR>> > >>>>> like<BR>> > >>>>>> a very weak rationale indeed=3D2C<BR>> > if the same functionality could =<BR>> > >be =3D3D<BR>> > >>>>> provided<BR>> > >>>>>> through some other mechanism<BR>> > (e.g.=3D2C ARRAY [0..1] OF =<BR>> > >INTEGER---even =3D<BR>> > >>> =3D3D<BR>> > >>>>> with<BR>> > >>>>>> a pragma e.g.<BR>> > <*CLONGLONG*>.. if it is necessary to tell the =<BR>> > >compiler =3D<BR>> > >>> =3D3D<BR>> > >>>>> that<BR>> > >>>>>> a special linkage convention is<BR>> > needed).<BR>> > >>>>>=20<BR>> > >>>>> There's no special linkage convention.<BR>> > Not sure what you mean here.<BR>> > >>>>>=20<BR>> > >>>> =3D20<BR>> > >>>> I just mean if we had<BR>> > >>>> =3D20<BR>> > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF<BR>> > INTEGER<BR>> > >>>> =3D20<BR>> > >>>> that would perhaps not match how C handles<BR>> > "long long" on the same<BR>> > >>>> platform (which is how=3D2C come to think<BR>> > of it?)=3D2C and that =<BR>> > >would require<BR>> > >>>> special linkage tricks.<BR>> > >>>> =3D20<BR>> > >>>> But what would be lost? The ability to<BR>> > type literals.=3D20<BR>> > >>>> =3D20<BR>> > >>>> You could get the same code interface on<BR>> > 32- and 64-bit machine by<BR>> > >>>> defining<BR>> > >>>> =3D20<BR>> > >>>> TYPE FileOffset =3D3D ARRAY[0..1] OF<BR>> > [-16_80000000 .. +16_7fffffff ]<BR>> > >>>> =3D20<BR>> > >>>> and using that.<BR>> > >>>> =3D20<BR>> > >>>> =3D20<BR>> > >>>> Mika<BR>> > >>> <BR>> > <BR>> > <BR>> > =3D<BR>> > >>>=20<BR>> > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_<BR>> > >>> Content-Type: text/html;<BR>> > charset=3D"iso-8859-1"<BR>> > >>> Content-Transfer-Encoding: quoted-printable<BR>> > >>>=20<BR>> > >>> <html><BR>> > >>> <head><BR>> > >>> <style><!--<BR>> > >>> .hmmessage P<BR>> > >>> {<BR>> > >>> margin:0px=3D3B<BR>> > >>> padding:0px<BR>> > >>> }<BR>> > >>> body.hmmessage<BR>> > >>> {<BR>> > >>> font-size: 10pt=3D3B<BR>> > >>> font-family:Verdana<BR>> > >>> }<BR>> > >>> --></style><BR>> > >>> </head><BR>> > >>> <body class=3D3D'hmmessage'><BR>> > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on<BR>> > a =3D3B32bit system =<BR>> > >is very c=3D<BR>> > >>> lose to LONGINT.<BR><BR>> > >>>  =3D3BPlus treating it opaquely and<BR>> > providing a bunch of =<BR>> > >functions to ope=3D<BR>> > >>> rate on it.<BR><BR>> > >>>  =3D3BJust as well therefore could be<BR>> > RECORD hi=3D2Clo:LONGINT =<BR>> > >END (see LAR=3D<BR>> > >>> GE_INTEGER and ULARGE_INTEGER in<BR>> > winnt.h)<BR><BR>> > >>>  =3D3B<BR><BR>> > >>> Differences that come to mind:<BR><BR>> > >>>  =3D3B =3D3Binfix<BR>> > operators =3D3B <=3D3B=3D3D=3D3D=3D3D =<BR>> > ><BR><BR>> > >>>  =3D3B possibly passed<BR>> > differently =3D3Bas a parameter<BR><BR>> > >>>  =3D3B or returned differently as a<BR>> > result<BR><BR>> > >>>  =3D3B ie. probably "directly<BR>> > compatible with" "long long"=3D2C =<BR>> > >passed by v=3D<BR>> > >>> alue (of course you could always pass by<BR>> > pointer and achieve =<BR>> > >compatibilitit=3D<BR>> > >>> y trivially)<BR><BR>> > >>>  =3D3B<BR><BR>> > >>>  =3D3B<BR><BR>> > >>> I have to say though=3D2C the biggest reason<BR>> > is in-fix operators. =<BR>> > >Convenient =3D<BR>> > >>> syntax.<BR><BR>> > >>> C++ is the best and some way worst of example<BR>> > of the general right =<BR>> > >way to d=3D<BR>> > >>> o this -- you let programmers define types and<BR>> > their infix operators. =<BR>> > >Other=3D<BR>> > >>> languages just come with a passle of special<BR>> > cases of types that have =<BR>> > >in-f=3D<BR>> > >>> ix operators.<BR><BR>> > >>> A good example is that Java infix operator +<BR>> > on string=3D2C besides =<BR>> > >the vario=3D<BR>> > >>> us integers=3D2C and nothing else.<BR><BR>> > >>>  =3D3B<BR><BR>> > >>>  =3D3B<BR><BR>> > >>> I think C# lets you define operators=3D2C yet<BR>> > people don't complain =<BR>> > >that it i=3D<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<BR>> > "mainstream" =<BR>> > >languages=3D2C not =3D<BR>> > >>> just C++.<BR><BR>> > >>>  =3D3B =3D3B C++ of course is<BR>> > extremely mainstream=3D2C but =<BR>> > >also a favori=3D<BR>> > >>> te target. (<A =<BR>> > >href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D<BR>> > >>><BR>> > /www.relisoft.com/tools/CppCritic.html</A>)<BR><BR>> > >>>  =3D3B<BR><BR>> > >>>  =3D3B<BR><BR>> > >>> We also have subranges of LONGINT.<BR><BR>> > >>> I'm not sure what the generalization of<BR>> > subranges are=3D2C =<BR>> > >granted.<BR><BR>> > >>>  =3D3BMaybe some sort of C++ template<BR>> > that takes constants in the =<BR>> > >templat=3D<BR>> > >>> e and does range checks at runtime. Yeah=3D2C<BR>> > maybe.<BR><BR>> > >>>  =3D3B<BR><BR>> > >>>  =3D3B<BR><BR>> > >>> And as you point out=3D2C convenient literal<BR>> > syntax.<BR><BR>> > >>>  =3D3B<BR><BR>> > >>>  =3D3B<BR><BR>> > >>> People reasonably argue for library extension<BR>> > in place of language =<BR>> > >extensio=3D<BR>> > >>> n=3D2C but that requires a language which is<BR>> > flexible enough to write =<BR>> > >librari=3D<BR>> > >>> es with the desired interface=3D2C and so many<BR>> > languages don't let =<BR>> > >infix oper=3D<BR>> > >>> ators be in a user-written library.<BR><BR>> > >>> (There is a subtle but useless distinction<BR>> > here -- infix operators =<BR>> > >being in=3D<BR>> > >>> libraries vs. "user-written" libraries. The<BR>> > infix set operations for =<BR>> > >examp=3D<BR>> > >>> le are in a library=3D2C but not<BR>> > user-written=3D2C special=3D2C the =<BR>> > >compiler know=3D<BR>> > >>> s about it.)<BR><BR>> > >>>  =3D3B<BR><BR>> > >>> >=3D3B that would perhaps not match how<BR>> > C handles "long long" on =<BR>> > >the same<B=3D<BR>> > >>> R>>=3D3B platform (which is how=3D2C<BR>> > come to think of it?)=3D2C and =<BR>> > >that would =3D<BR>> > >>> require<BR><BR><BR>> > >>>  =3D3B<BR><BR>> > >>> On NT/x86=3D2C __int64/long long is returned<BR>> > in the register pair =<BR>> > >edx:eax.<BR=3D<BR>> > >>>>=20<BR>> > >>> edx is high=3D2C eax is low.<BR><BR>> > >>> When passed as a parameter to __stdcall or<BR>> > __cdecl is just passed as =<BR>> > >two 32=3D<BR>> > >>> bit values adjacent on the stack=3D2C "hi=3D2C<BR>> > lo=3D2C hi=3D2C lo=3D2C =<BR>> > >it's off to pu=3D<BR>> > >>> sh we go" is the Snow White-influenced mantra<BR>> > to remember how to pass =<BR>> > >them=3D<BR>> > >>> =3D2C at least on little endian<BR>> > stack-growing-down machines (which =<BR>> > >includes x=3D<BR>> > >>> 86). For __fastcall I'm not sure they are<BR>> > passed in registers or on =<BR>> > >the sta=3D<BR>> > >>> ck.<BR><BR>> > >>> Passing and/or returning small structs also<BR>> > has special efficient =<BR>> > >handling =3D<BR>> > >>> in the ABI=3D2C so __int64 really might be<BR>> > equivalent to a small =<BR>> > >record. Not =3D<BR>> > >>> that cm3 necessarily implements that<BR>> > "correctly" =3D3B -- for =<BR>> > >interop wit=3D<BR>> > >>> h C=3D3B for Modula-3 calling Modula-3 we can<BR>> > make up our own ABI so =<BR>> > >there is=3D<BR>> > >>> n't =3D3Breally an "incorrect"<BR>> > way. =3D3BNotice the mingw =<BR>> > >problem I had=3D<BR>> > >>> passing a Win32 point struct by value=3D2C I<BR>> > cheated and passed it by =<BR>> > >VAR to=3D<BR>> > >>> a =3D3BC wrapper to workaround the gcc<BR>> > backend bug (which was =<BR>> > >mentioned =3D<BR>> > >>> a few times and which I looked into the code<BR>> > for=3D2C but took the =<BR>> > >easy route=3D<BR>> > >>> )<BR><BR>> > >>>  =3D3B<BR><BR>> > >>>  =3D3B<BR><BR>> > >>> I don't know how long long works on other<BR>> > platforms but probably =<BR>> > >similar.<B=3D<BR>> > >>> R><BR>> > >>> Probably a certain register pair for return<BR>> > values.<BR><BR>> > >>>  =3D3B<BR><BR>> > >>>  =3D3B-<BR>> > Jay<BR><BR> =3D3B<BR>>=3D3B<BR>> > To: =<BR>> > >hosking@cs.purdue.edu<BR>>=3D3B=3D<BR>> > >>> Date: Sat=3D2C 17 Apr 2010 19:47:03<BR>> > -0700<BR>>=3D3B From: =<BR>> > >mika@async.async.c=3D<BR>> > >>> altech.edu<BR>>=3D3B CC: m3devel@elegosoft.com<BR>>=3D3B<BR>> > Subject: =<BR>> > >Re: [M3de=3D<BR>> > >>> vel] INTEGER<BR>>=3D3B<BR>> > <BR>>=3D3B Tony Hosking<BR>> > writes:<BR>>=3D3B =<BR>> > >>=3D3B<BR>=3D<BR>> > >>> >=3D3B ...<BR>>=3D3B<BR>> > >=3D3B<BR>>=3D3B >=3D3B>=3D3B<BR>> > We =<BR>> > >need it to match 64-b=3D<BR>> > >>> it integers on 32-bit machines? That seems<BR>> > =3D3D<BR>>=3D3B =<BR>> > >>=3D3Blike<BR>>=3D<BR>> > >>> =3D3B >=3D3B>=3D3B a very weak<BR>> > rationale indeed=3D2C if the same =<BR>> > >functionality =3D<BR>> > >>> could be =3D3D<BR>>=3D3B<BR>> > >=3D3Bprovided<BR>>=3D3B<BR>> > >=3D3B>=3D3=<BR>> > >B through some o=3D<BR>> > >>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF<BR>> > INTEGER---even =<BR>> > >=3D3D<BR>>=3D3B >=3D3B=3D<BR>> > >>> with<BR>>=3D3B<BR>> > >=3D3B>=3D3B a pragma e.g. =<BR>> > ><=3D3B*CLONGLONG*>=3D3B.. if it i=3D<BR>> > >>> s necessary to tell the compiler<BR>> > =3D3D<BR>>=3D3B =<BR>> > >>=3D3Bthat<BR>>=3D3B<BR>> > >=3D3B&=3D<BR>> > >>> gt=3D3B a special linkage convention is<BR>> > needed).<BR>>=3D3B =<BR>> > >>=3D3B<BR>>=3D3B &=3D<BR>> > >>> gt=3D3BThere's no special linkage convention.<BR>> > Not sure what you mean =<BR>> > >here.<BR=3D<BR>> > >>>> >=3D3B<BR>> > >=3D3B<BR>>=3D3B <BR>>=3D3B I<BR>> > just mean if we =<BR>> > >had<BR>>=3D3B <BR>>=3D<BR>> > >>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF<BR>> > INTEGER<BR>>=3D3B =<BR>> > ><BR>>=3D3B that woul=3D<BR>> > >>> d perhaps not match how C handles "long long"<BR>> > on the same<BR>>=3D3B =<BR>> > >platfor=3D<BR>> > >>> m (which is how=3D2C come to think of<BR>> > it?)=3D2C and that would =<BR>> > >require<BR>>=3D<BR>> > >>> =3D3B special linkage<BR>> > tricks.<BR>>=3D3B <BR>>=3D3B But<BR>> > what would =<BR>> > >be lost? Th=3D<BR>> > >>> e ability to type literals.<BR>> > <BR>>=3D3B <BR>>=3D3B You could get<BR>> > =<BR>> > >the same co=3D<BR>> > >>> de interface on 32- and 64-bit machine<BR>> > by<BR>>=3D3B =<BR>> > >defining<BR>>=3D3B <BR>=3D<BR>> > >>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1]<BR>> > OF [-16_80000000 .. =<BR>> > >+16_7fffffff ]<B=3D<BR>> > >>> R>>=3D3B <BR>>=3D3B and<BR>> > using that.<BR>>=3D3B <BR>>=3D3B =<BR>> > ><BR>>=3D3B Mika<BR=3D<BR>> > >>>> <BR>> > <BR>> > <BR>> > </body><BR>> > >>> </html>=3D<BR>> > >>>=20<BR>> > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_--<BR>> > <BR>> <BR>> <BR>> <BR> </body>
</html>