[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