`Word' data type et al._(re)

Wed, 18 Jun 1997 23:00:20 +0100 (MET)

In message Wed, 18 Jun 1997 20:13:16 +0200 (MET DST),
  Peter Gerwinski   writes:

> According to Frank Heckenbach:
>
>>
>>   > Cardinal        0 .. 65535      Non sign=E9, 16 bits
>>   >
>>   > Cardinal        0 .. 2147483647 Non sign=E9, 32 bits
>>
>>   [...]
>>
>>   That's fine! If Delphi uses "Cardinal", gpc should use it too,
>>   of course.
>
> It already does.  32 bits, unsigned.  As you can see above,
> `Cardinal' is 31 bits, unsigned, in Delphi.  Has anybody an
> idea, why?
>
Seems a bug or at least it is inconsistent with the comment that
they give to this stuff.
Anyway I have checked that Delphi 2 rejects c:=$FFFFFFFF
with c cardinal (and gives -1 for c integer);

But the idea that we had in mind is that "generic" types are
signed (integer) and unsigned (cardinal) integers
best suited to a given computer, usually 16 bits Five years ago,
32 bits now, 64 bits in next Five years, 128 bits in next 10 years.
This is what is needed for common arithmetic computations.
But other needs are e.g. reading binary files coming from other computers
or reading I/O ports, where the number of bits has to be specified exactly.

>> > Generic Types
>>
>
> GPC's current setting - on *all* platforms - is the following:
>
> GNU Pascal             GNU C
>
> Byte                   unsigned char
> ByteInt                signed char
> ShortWord              unsigned short
> ShortInt               short
> Integer                int, long
> Word, Cardinal         unsigned, unsigned long
> LongInt, Comp          long long
> LongWord               unsigned long long
>
> I see only one possible reason why we should change that:  It is
> not absolutely sure that `int' will always remain the same as `long'
> on GCC.
>
> The sizes of these types are the same on all platforms I have seen
> so far.  (8, 8, 16, 16, 32, 32, 64, 64.)  However I agree that it is
> a good idea to provide types of known size.
>
>
>> > Well defined types
>>   >
>>   > int8      card8   (byte is the only case without doubt)
>>   > int16     card16
>>   > int32     card32
>>   >
>>   > [...]
>>
>>   Sounds good.
>>
>
> I agree, but maybe a different syntax would be preferable.  UCSD Pascal
> has a "long Integer" type which is written as
>
> Type Int42 = Integer [ 42 ];
>
> Where `42' is the number of decimal digits.  (In the long run, this should
> be in GPC, too.)  What about defining
>
> Type Int16 = Integer ( 16 );
> Type Word16 = Word ( 64 );
>
> for types with a specified number of *dual* digits, read: bits?
>
  Seems fine
>
> === BUT ===
>
> What are we talking about?
>
> Pascal has subrange types.  Why not forget about all this and let the
> user specify the types by himself?
>
> Type
> I16 = -$8000..$7FFF;
> W16 = 0..$FFFF;
>
> MyRecordToAccessSomeStrangeSystemData = record
> Descriptor: 0..$FFFFFFFF;
> ImportantData: -$80..$7F;
> FillSpace: array [ 0..42 ] of 0..$FF;
> end (* MyRecordToAccessSomeStrangeSystemData *);
>
> Then, of course, GPC must not reserve more space than necessary for
> them - which it does not do anyway since it has packed records.
> (These topics are related, as you can well imagine.)
>
This is the best Pascalish point of view (and in fact the one I
use in computations, if I know that an integer is within 0 and 100,
I never declare it as byte but as 0..100, letting
the computer determine the amount of space necessary)
But for the binary stuff to work it __must__ be granted that the minimum
space is actually used: Pascal gives the subrange definition which gives
(among others) full compatibility between platforms for computations,
but the amount of space which corresponds to a subrange is not enforced.
Maurice Lombardi                        |
Laboratoire de Spectrometrie Physique   | Maurice.Lombardi@ujf-grenoble.fr
Universite Joseph Fourier de Grenoble   |   tel: (33) 04 76 51 47 51
BP 87                                   |   fax: (33) 04 76 51 45 44
38402 Saint Martin d'Heres Cedex FRANCE |

Maurice Lombardi (Maurice.LOMBARDI@ujf-grenoble.fr)