[M3devel] LONGINT

Tony Hosking hosking at cs.purdue.edu
Thu Jul 19 21:44:18 CEST 2007


On Jul 19, 2007, at 2:56 PM, Randy Coleburn wrote:

> Tony:
>
> I'd like to better understand the implications of your change as I  
> do use LONGINT as an index in some applications.

In that case, what is the index type of an open array: ARRAY OF X?  I  
assume that dope vectors for open arrays will need to indicate the  
index type.  Moreover, code compiled to manipulate ARRAY OF X will  
need to cope with dynamically-determined index types.  My inclination  
is to avoid this pain by prohibiting ordinals with base type LONGINT  
from being used as the index type for arrays.

>
> 1.  On a computer with a 32-bit word size, will LONGINT be 32 bits  
> or 64 bits?

LONGINT will be the same as C "long long" which is 64 bits on a 32- 
bit machine.  INTEGER will continue to be the same as C "long" which  
is 32 bits on a 32-bit machine.  On a 64-bit machine, both INTEGER  
and LONGINT will be 64 bits.

> 2.  I assume on a computer with a 64-bit word size, LONGINT will be  
> 64 bits.  Is there an option to get a 32-bit integer on these  
> machines?

What's wrong with "BITS 32 FOR [-16_80000000 .. 16_7fffffff]"?

> 3.  Would it make sense to keep LONGINT at 32-bits and make a new  
> type, say LONGINT64, at 64-bits?

I don't think anyone should make any assumption in portable code  
about LONGINT and INTEGER other than that

	BITSIZE(INTEGER) <= BITSIZE(LONGINT)

When assuming a given target I think it is reasonable to assume:

	BITSIZE(INTEGER) = sizeof (long)
	BITSIZE(LONGINT) = sizeof (long long)

so that we have a convenient mapping to C header files and interfaces.

>
> Regards,
> Randy
>
> Randy C. Coleburn
> Senior Systems Engineer, Communications, Networks, & Electronics  
> Division (CNE)
> Corporate & Atlanta Information Systems Security Manager (ISSM)
> Scientific Research Corporation
> 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339
> voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770)  
> 989-9497
>
> Quality Policy:  "SRC CNE Division is committed to delivering  
> continually improving research & engineering excellence that meets  
> or exceeds customer requirements."
>
> >>> Tony Hosking <hosking at cs.purdue.edu> 7/18/2007 11:53 PM >>>
> I've successfully bootstrapped a CM3 compiler that supports LONGINT
> as a 64-bit integer type (equivalent to "long long" in C) in addition
> to INTEGER (same as "long" in C).  This will be useful for
> simplifying interfaces to C library routines that expect to be able
> to treat 64-bit integers such as "off_t" ! for lseek, etc.
>
> Currently, the compiler does not treat LONGINT as an ordinal type
> (I'm not sure this would ever be a good idea) so it cannot be used to
> index arrays, define enumerations etc., though the simple operations
> ABS, MAX, MIN, addition, comparisons, MOD, multiplication,
> subtraction, assignment, are all supported.  This includes changes to
> m3core (with support for Long.T similar to Word.T, plus RTTipe and
> RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle,
> m3front, and the gcc-based compiler backend.  There is still work
> that needs to be done to support and test all the other M3 tools such
> as network objects, etc., with support and testing needed in m3tk for
> the new type, as well as in other tools like m3browser.
>
> How best should I proceed to get this out to the community.  I am
> tempted to push it into the CVS head jus! t so that it gets some
> testing, but perhaps that is prematur e. I can confirm a complete
> bootstrap via "do-cm3-std.sh" that appears to produce perfectly
> functional executables, including mentor, etc.
>
>




More information about the M3devel mailing list