Word types..._(re)

Fri, 20 Jun 1997 01:08:29 +0200 (MET DST)

According to Orlando Llanes:
> 
> 	The only reason I suggested having Platform specific types is because
> since the size varies per system, and you save a file using natural types
> on one, they have to be read in using the same size. For example, let's say
> a Word is 32-bit on one system, and then you have the PC where it's 16-bit,
> let's call them Word (32-bit) and PCWord (16-bit).

The natural size of a Word on the PC equipped with a 80386 or higher
is 32-bit.  The restriction of most applications to 16 bits is an
artificial one and orginates to Microsoft which did not react on the
hardware improvement.  We do.

> 	Word is 4 bytes, PCWord is 2 bytes. If data was written using PCWord, it
> could be read into a Word. But if a Word was written, then it needs 2
> PCWords to read it properly. In this way, it's not cross platform because
> you have to make adjustments per platform.

So what you are really worrying about is the binary format (which includes
the size) of these types, not the platform where they are "natural".  I agree.
This means that the following is the way to go:

> I'm all for the IntX data types
> suggested earlier for this reason, if one data type is treated the same
> across all platforms, then all you have to do is write a program once, and
> then compile it across all platforms without having to use platform
> specific compiler options. [...]

So it's clear what has to be implemented.  Now we must discuss about
their syntax.

Where do such data types matter?  Everywhere where we must set up a record
type of well-known size and structure, for example when reading a binary
file created by some other program, or when communicating with the operating
system.

For this reason, the syntax must be compact, and somehow closer to the bare
metal (assembler) than to the clouds (Modula).  That's why I prefer `Word'
here with respect to `Cardinal'.  (* Another reason is that when I read
`Card', I think of games, not of cardinalship. ;*)  (Due to the need for
compactness, I think my "Integer ( 8 )" notation was not the best idea.  Or
perhaps it was, and the programmer can define the below in his own Units?)
So what about this?

    Int8    Word8 = Byte
    Int16   Word16
    Int32   Word32
    Int64   Word64

Once more discussing subranges as an alternative:  "True Pascal" does not
specify the storage size, but valid values for those.  So I am no more sure
whether it is wise to guarantee that their size will always be the minimal
one.  And anyway, they are no true replacement for built-in data types of
well-defined size because no programmer will write `0..$FF' everytime he
wants to express that something has 8 bits.  He will define his own type
for this reason: "Type Byte = 0..$FF".  (Note that `Byte' is built-in in
GPC!)  If we don't want terrible confusion among future GPC hackers, we
should provide built-in types for such purposes.

The other thing we must worry about is compatibility to GNU C, because
the use of GNU Pascal depends on library written in GNU C.  For this reason,
`ShortInt', `ShortWord', `ByteInt', and `Byte' must stay like they are;
I think it's quite natural then to have `Word' for an unsigned 32-bit Integer.
I am not sure whether `int' in GNU C might ever change to be different from
`long int'.  (DOES SOMEBODY KNOW???)  If so, our (my;) choice for the meaning
of `LongInt' and `LongWord' might be subject to change.  (Note again that
I am speaking about types that *are* built-in in GPC with the mentioned
meanings.)

    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)