gm2
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gm2] addition fundamental data types


From: Gaius Mulley
Subject: [Gm2] addition fundamental data types
Date: 19 Mar 2008 17:09:55 +0000
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Hi,

I'm still in the process of adding bounds checking to various
runtime components of the compiler - and was wondering what
views people have on the issue of addition fundamental data types?

I've had a few emails about size of REALs and INTs etc.  So I wondered
whether it would be helpful to have the following additional
datatypes:

    INT8, INT16, INT32, INT64
    CARD8, CARD16, CARD32, CARD64
           WORD16, WORD32, WORD64
    SET8, SET16, SET32, SET64,
    REAL32, REAL64, REAL96
         (assuming the h/w supports them)

gm2 currently knows about

    BYTE, WORD, LOC, ADDRESS,
    INTEGER, SHORTINT, LONGINT,
    CARDINAL, SHORTCARD, LONGCARD
    BITSET

implementing the new data types is not difficult - (apart from SET*).
So I'll probably not introduce SET* until the rest are mature.

Also if these new data types are added, where should they go?  (SYSTEM
?).  Then there is the issue of any pervasive function which returns a
REAL, CARDINAL or INTEGER (as opposed to a BOOLEAN, ZType or RType).
These functions will probably also need new counterparts.  For
example, we would also need:

    ORD8, ORD16, ORD32, ORD64   (which defines the return type of the
                                 function ORD).

how about HIGH  (which currently returns CARDINAL)?  Should there
be a HIGH8, HIGH16, HIGH32, HIGH64 which is a pseudonym for:

    VAL(CARD8, HIGH(a))
    VAL(CARD16, HIGH(a))
    VAL(CARD32, HIGH(a))
    VAL(CARD64, HIGH(a))  ?

I'm inclined not to implement the HIGH variants as they are only
syntax sugar - the implementation will not store the upper bound as
anything other than a CARDINAL.  But these functions are easy to
implement and so if I'm very willing to add them if they are likely to
be used.  (Or if you feel it make the proposed extensions more orthogonal).
However, more importantly, I guess we do need

TRUNCL, TRUNCS, TRUNC8, TRUNC16, TRUNC32, TRUNC64
FLOAT32, FLOAT64, FLOAT96  (again h/w depending).

as they will effect semantics.  Likewise I suspect the additional
functions should come from SYSTEM

Any comments?

regards,
Gaius




reply via email to

[Prev in Thread] Current Thread [Next in Thread]