Word types: Suggestion

Sat, 21 Jun 1997 00:06:57 +0200 (MET DST)

Hello, everybody!

I am trying now to summarize our "Integer type" problems and to
propose a solution.


Problem #1:  Compatibility to BP.

  - Some people want `Word' to have 16 bits, because it has in BP.
  - Some other people want `Word' to have the same size as `Integer',
    because it has in BP.
  - Some people expect `LongInt' to have 32 bits, like in BP.
  - Some other people expect `LongInt' to be bigger than `Integer',
    like in BP.

  Hard to escape!


Problem #2:  Data types with known size.

  Here everybody seems to agree that they are needed, discussions
  are about how they should be named.

  - `int8' and `card8'
  - `int8' and `word8'
  - `Integer ( 8 )' and `Cardinal ( 8 )' and/or `Word ( 8 )'
  - `0..$FF' (always)
  - `packed 0..$FF'

  There is also need for a data type which is guaranteed to be the
  largest signed/unsigned Integer type available.


Problem #3:  Compatibility to GCC.

  In order to access libraries written in GCC, GPC must provide integer
  types which are guaranteed to be the same as `long long unsigned int'
  etc. in GCC.

  - Current implementation:

                 GPC                                 GCC
       ByteInt          Byte             signed char      unsigned char
       ShortInt         ShortWord        short            unsigned short
       Integer          Word             int              unsigned
       LongInt = Comp   LongWord         long long        unsigned long long

    Obviously, an equivalent for GCC's `[unsigned] long' is missing.  This
    is because it's the same as `[unsigned] int'.  If we can make sure that
    this will always be the case, we can safely leave things like they are
    and document them (which I already did: see "info -f gpc -n Integer").

  - Some people propose to change `LongInt' to be the same as GCC's `long'.
    Advantage: closer to GCC's syntax, and same bit size as BP's `LongInt'.
    Disadvantage: `LongInt' would not be longer than `Integer'.

  - While we are discussing all this, GPC already has type modifiers:
    `__long__ Integer' means the same as `long' in GCC.  So there *is* a
    mechanism with syntax close to C which guarantees compatibility.

  (* If we were Borland, we would probably say now: "On all currently
  existing platforms, GCC's `long' is the same as `int', so don't worry
  about the missing equivalent for `long'." *)


Discussion of #1:  Compatibility to BP.

  - GPC is *not* intended to be a drop-in replacement for BP.
    Compatibility is desireable as long as we don't have to pay a high
    price for it.  We want to preserve the "spirit" of BP in GPC, not
    its "letters".  What we do is to "write BP, as it should have been",
    not "rewrite BP, exactly as it is".

  - GPC is a 32-bit compiler.  Maybe we will extend it to 64 bits, some day,
    but we won't restrict it to 16 bits.

  That's why `Word' etc. are as they are, and why I think they should
  not change.

 
Discussion of #2:  Data types with known size.

  I think, Frank is right when he says that we must provide a way to define
  them rather than defining everything in GPC.

  Separate identifiers for everything are not flexible enough.

  Round parentheses are easiest to implement, but their syntax interferes
  with Schemata.  Square brackets come into mind, but they interfere with
  UCSD's "long integers".

  While the remaining two possibilities are certainly the most `Pascalish'
  ones, they are not 100% clear:  What size has `packed $1000..$10FF'?
  Although 8 bits would be sufficient, GPC would allocate 13 bits.  Outside
  of packed arrays and records, they would be rounded to the next unit the
  machine can access, usually 8 bits, but it can also be 16 or 32 bits.

  Despite of the disadvantage sketched above, I think that `packed 0..$FF'
  is the way to go.  Authors of libraries are encouraged to define their own
  types using this mechanism.

  To have `LongestInt' as - currently - a synonym for `LongInt' cannot
  hurt.  If one day there will be something longer than `LongInt', we
  can name it `LongLongInt' (because it might be superseeded again by
  `LongLongLongInt'), but `LongestInt' will always remain the longest one.


Discussion of #3:  Compatibility to GCC.

  I can guarantee that the above GPC <--> GCC compatibility rules for
  `ShortInt' etc. will not change.  Then the only needed thing is something
  which is guaranteed to be the same as `long' in GCC, even if `int' is
  not the same as `long'.  Since we are aiming towards the top, C's `long'
  is just "medium" for us. ;-)  Thus I propose the names `MedInt' and
  `MedWord'.


Summary and Proposal:

  Let all GPC integer types like they are, and add `MedFoo' and
  `LongestFoo':

                 GPC                                 GCC
       ByteInt          Byte             signed char      unsigned char
       ShortInt         ShortWord        short            unsigned short
       Integer          Word             int              unsigned
       MedInt           MedWord          long             unsigned long
       LongInt = Comp   LongWord         long long        unsigned long long
       LongestInt       LongestWord      long long        unsigned long long

  where `MedInt' happens to be the same as `Integer' and `MedWord' the
  same as `Word' on all platforms currently existing.

  Introduce `packed 0..$FF' like discussed above.

  Forget about `Integer ( 8 )'.  But don't forget about UCSD's
  `Integer [ 42 ]' which might be implemented later.


Okay like this?  Or better keep `Integer ( 8 )' (or `Integer < 8 >', or
`Integer : 8' like bit-fields in C, or `Integer * 1' like in FORTRAN?)
which shows more explicitly how many bits a type has?

Yours,

    Peter

 Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
 maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)