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

Thu, 19 Jun 1997 03:22:55 +0200

Maurice Lombardi wrote:

> > I'd add {Short,Long,LongLong(?),Longest(?)}{Int,Card} here.
> 
> But this is much harder to standardize: they will have different
> meanings on different systems, whence better to reject them in
> XXcompat units: gpc being cross-platform it will be difficult to
> give a general rule whereas the others are non ambiguous:

I didn't intend them to be in a XXcompat unit, but rather built-in
(the only place they *could* be declared, AFAICS), provided it can be
guaranteed on every platform that

- 2 <= SizeOf(ShortInt) < SizeOf(Integer) < SizeOf(LongInt)
  (or perhaps even
   8 <= 4*SizeOf(ShortInt) = 2*SizeOf(Integer) = SizeOf(LongInt) ?)

- SizeOf(LongInt) < SizeOf(LongLongInt) (if LongLongInt is possible)
  (resp. 2*... = ...)

- SizeOf(LongestInt) is the biggest possible integer size for the given
  compiler.

(The same, of course, for Card*.)

Types like Short* and Long* can be useful e.g. for multplications
(ShortInt * ShortInt always fits in an Integer, Integer * Integer
fits in a LongInt, ...).

Longest* would be useful for programs that want to offer the biggest
possible range without having to know what this is on every platform.

Furthermore, it *might* become useful to have a Cardinal that's exactly
the size of a pointer (since for a normal Cardinal this doesn't always
hold, and AFAIK, only the compiler knows the actual pointer size).
Though pointer arithmetic has mostly eliminated the need for explicit
type casts between pointers and integers, there may be some cases left,
where it's needed...

> but notice that in BP I frequenly used a defreal unit,
> (referenced from the main and all other units) which
> contains either
>
> type real = single
> or
> type real = double
> or
> type real = extended
>
> to have a quick way to see the effect of the size of reals on accuracy
> or speed of some computations. But this is a purely private trick
> which should be restricted to such peculiar purposes.

I think you could do this in gpc as well (I see no reason why not).

PS: No copies by email necessary. I get your mails through the list, anyway.

Peter Gerwinski wrote:

> > > Cardinal        0 .. 2147483647 Non sign=E9, 32 bits

> > If Delphi uses "Cardinal", gpc should use it too, of course.
>
> It already does.  32 bits, unsigned.

True, fine! :-)

> As you can see above,
> `Cardinal' is 31 bits, unsigned, in Delphiy.  Has anybody an
> idea, why?

I guess they didn't want to get into trouble with the internal handling
of integer values in the compiler. If Cardinal is a subset of Integer,
they can store anything in an Integer internally. Otherwise, they'd
have to have a flag indicating if signed or unsigned (I guess this is
what gpc does, right?). IOW: The same reason why there wasn't an
unsigned 32 bit integer in BP (I suppose).

> GPC's current setting - on *all* platforms - is the following:
>
>     GNU Pascal             GNU C
>
>     Byte                   unsigned char
>     ByteInt                signed char

Is a char *always* 1 byte in C?

>     ShortWord              unsigned short
>     ShortInt               short
>     Integer                int, long
>     Word, Cardinal         unsigned, unsigned long
>     LongInt, Comp          long long
>     LongWord               unsigned long long

How about "ShortCard" and "LongCard", too?

I guess, Comp should rather be fixed to 64 bits ("Integer(64)") than
dependent on "long long", for BP compatibility.

Since you didn't mention it, I assume it's not possible (on current
platforms) to have an integer > 64 bits, is it?

> 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.

Is it guaranteed that "short" is always shorter than (resp. half as
big as) "int", and "int" than "long long"?

> The sizes of these types are the same on all platforms I have seen
> so far.  (8, 8, 16, 16, 32, 32, 64, 64.)

Also on the Alpha? Isn't this a 64 bit processor (so "int" should be
64 bits)? But anyway, I guess, this can change in the future...

> 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?

Why not! (With the actual size rounded up to bytes (or to a power of 2
of bytes) unless in a packed array/record?)

> 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.

But it does if you declare the type plainly, i.e. Sizeof(0..$FF) = 4.
This is handled faster than one byte, but takes more memory. What about
"packed" with those types as well ("type Int8 = packed -$80..$7F")? --
Looks strange, I know, but there should be some way to decide if one
wants speed or small size (the latter can be important e.g. in binary
files).

Given this or something equivalent (and of course, subranges that exceed
Integer), I'd prefer this to "Integer(n)".

The African Chief wrote:

> >> {$ifdef _Borland_16_Bit_}
> >
> >Is this defined by default in your unit?
>
> No. The definition is commented out (with a dot before the "$")
>
> > (Otherwise it might be confusing for BP->gpc programmers.)
>
> BP->GPC programmers (like me) may want BP syntax support,
> but not necessarily want to use 16-bit data structures instead
> of the default ones. It is quite easy to remove the dot.

Ok, so by default the unit uses data types like BP, but it can be
changed, right? (That's what I meant how it should be for
unsuspicious BP->gpc programmers.)

BTW: I just took a look at BPCompat1.0. Just a few quick comments:

- How about some sub-directories (perhaps according to the 5 sections
  of files in *.txt)? Would help in order to see immediately what's
  needed for "only" BP compatibility, and what's additional
  functionality.

- Concerning FindFirst and FindNext in Dos: is there any reason why
  they're functions, not procedures? Delphi? If so, perhaps dependent
  on a compiler switch? (Is there a way to test in a program, if
  "--borland-pascal" or "--delphi" was given?) Otherwise, you'll always
  get warnings in BP programs (and I don't think it's a good idea to
  disable warnings globally).

- If you want to use my random functions in System, you're welcome to
  include them, of course. (Perhaps one day we can claim "100% BP
  compatibility -- even the random numbers are the same..." ;-).
  As a preliminary solution for the overloading problem, one could use
  the (case-sensitive!) preprocessor, as by defining
  "{$define random RandReal}". Then "random" would be for real types,
  and all other cases for integers. (Or perhaps vice versa? Or all-caps?)
  At least, programs could be the same for BP and gpc in this respect. :-)
-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
Turbo Pascal:   http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)