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