[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&nbsp=3B32bit system is very c=
>lose to LONGINT.<BR>
>&nbsp=3BPlus treating it opaquely and providing a bunch of functions to ope=
>rate on it.<BR>
>&nbsp=3BJust as well therefore could be RECORD hi=2Clo:LONGINT END (see LAR=
>GE_INTEGER and ULARGE_INTEGER in winnt.h)<BR>
>&nbsp=3B<BR>
>Differences that come to mind:<BR>
>&nbsp=3B&nbsp=3Binfix operators&nbsp=3B &lt=3B=3D=3D=3D <BR>
>&nbsp=3B possibly passed differently&nbsp=3Bas a parameter<BR>
>&nbsp=3B or returned differently as a result<BR>
>&nbsp=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>
>&nbsp=3B<BR>
>&nbsp=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>
>&nbsp=3B<BR>
>&nbsp=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>
>&nbsp=3B&nbsp=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>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>We also have subranges of LONGINT.<BR>
>I'm not sure what the generalization of subranges are=2C granted.<BR>
>&nbsp=3BMaybe some sort of C++ template that takes constants in the templat=
>e and does range checks at runtime. Yeah=2C maybe.<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>And as you point out=2C convenient literal syntax.<BR>
>&nbsp=3B<BR>
>&nbsp=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>
>&nbsp=3B<BR>
>&gt=3B that would perhaps not match how C handles "long long" on the same<B=
>R>&gt=3B platform (which is how=2C come to think of it?)=2C and that would =
>require<BR><BR>
>&nbsp=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"&nbsp=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&nbsp=3Breally an "incorrect" way.&nbsp=3BNotice the mingw problem I had=
> passing a Win32 point struct by value=2C I cheated and passed it by VAR to=
> a&nbsp=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>
>&nbsp=3B<BR>
>&nbsp=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>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR><BR>&nbsp=3B<BR>&gt=3B To: hosking at cs.purdue.edu<BR>&gt=3B=
> Date: Sat=2C 17 Apr 2010 19:47:03 -0700<BR>&gt=3B From: mika at async.async.c=
>altech.edu<BR>&gt=3B CC: m3devel at elegosoft.com<BR>&gt=3B Subject: Re: [M3de=
>vel] INTEGER<BR>&gt=3B <BR>&gt=3B Tony Hosking writes:<BR>&gt=3B &gt=3B<BR>=
>&gt=3B ...<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B&gt=3B We need it to match 64-b=
>it integers on 32-bit machines? That seems =3D<BR>&gt=3B &gt=3Blike<BR>&gt=
>=3B &gt=3B&gt=3B a very weak rationale indeed=2C if the same functionality =
>could be =3D<BR>&gt=3B &gt=3Bprovided<BR>&gt=3B &gt=3B&gt=3B through some o=
>ther mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even =3D<BR>&gt=3B &gt=3B=
>with<BR>&gt=3B &gt=3B&gt=3B a pragma e.g. &lt=3B*CLONGLONG*&gt=3B.. if it i=
>s necessary to tell the compiler =3D<BR>&gt=3B &gt=3Bthat<BR>&gt=3B &gt=3B&=
>gt=3B a special linkage convention is needed).<BR>&gt=3B &gt=3B<BR>&gt=3B &=
>gt=3BThere's no special linkage convention. Not sure what you mean here.<BR=
>>&gt=3B &gt=3B<BR>&gt=3B <BR>&gt=3B I just mean if we had<BR>&gt=3B <BR>&gt=
>=3B TYPE LONGINT =3D ARRAY [0..1] OF INTEGER<BR>&gt=3B <BR>&gt=3B that woul=
>d perhaps not match how C handles "long long" on the same<BR>&gt=3B platfor=
>m (which is how=2C come to think of it?)=2C and that would require<BR>&gt=
>=3B special linkage tricks.<BR>&gt=3B <BR>&gt=3B But what would be lost? Th=
>e ability to type literals. <BR>&gt=3B <BR>&gt=3B You could get the same co=
>de interface on 32- and 64-bit machine by<BR>&gt=3B defining<BR>&gt=3B <BR>=
>&gt=3B TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ]<B=
>R>&gt=3B <BR>&gt=3B and using that.<BR>&gt=3B <BR>&gt=3B <BR>&gt=3B Mika<BR=
>> 		 	   		  </body>
></html>=
>
>--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_--



More information about the M3devel mailing list