[M3devel] INTEGER

[Jay K]

TYPE LONGINT = 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,lo:LONGINT END (see LARGE_INTEGER and ULARGE_INTEGER in winnt.h)

 

Differences that come to mind:

  infix operators  <=== 

  possibly passed differently as a parameter

  or returned differently as a result

  ie. probably "directly compatible with" "long long", passed by value (of course you could always pass by pointer and achieve compatibilitity trivially)

 

 

I have to say though, 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 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.

A good example is that Java infix operator + on string, besides the various integers, and nothing else.

 

 

I think C# lets you define operators, yet people don't complain that it is "a mess" as they do of C++.

I think Python does now too.

So it is feature growing in popularity among "mainstream" languages, not just C++.

   C++ of course is extremely mainstream, but also a favorite target. (http://www.relisoft.com/tools/CppCritic.html)

 

 

We also have subranges of LONGINT.

I'm not sure what the generalization of subranges are, granted.

 Maybe some sort of C++ template that takes constants in the template and does range checks at runtime. Yeah, maybe.

 

 

And as you point out, convenient literal syntax.

 

 

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.

(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.)

 

> that would perhaps not match how C handles "long long" on the same
> platform (which is how, come to think of it?), and that would require


 

On NT/x86, __int64/long long is returned in the register pair edx:eax.

edx is high, eax is low.

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.

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)

 

 

I don't know how long long works on other platforms but probably similar.

Probably a certain register pair for return values.

 

 - Jay

 
> To: hosking at cs.purdue.edu
> Date: Sat, 17 Apr 2010 19:47:03 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER
> 
> Tony Hosking writes:
> >
> ...
> >
> >> We need it to match 64-bit integers on 32-bit machines? That seems =
> >like
> >> a very weak rationale indeed, if the same functionality could be =
> >provided
> >> through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even =
> >with
> >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler =
> >that
> >> a special linkage convention is needed).
> >
> >There's no special linkage convention. Not sure what you mean here.
> >
> 
> I just mean if we had
> 
> TYPE LONGINT = ARRAY [0..1] OF INTEGER
> 
> that would perhaps not match how C handles "long long" on the same
> platform (which is how, come to think of it?), and that would require
> special linkage tricks.
> 
> But what would be lost? The ability to type literals. 
> 
> You could get the same code interface on 32- and 64-bit machine by
> defining
> 
> TYPE FileOffset = ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ]
> 
> and using that.
> 
> 
> Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100418/2274a7cd/attachment-0002.html>