Word types: Suggestion_(re)

Sun, 22 Jun 1997 01:36:44 +0200

Peter Gerwinski wrote:

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

Agreed. And if someone wants to redeclare them for
"100% silver plate compatibility", this is no problem to do.
(Like in the Chief's system unit with -D_Borland_16_Bit_.)

The only question is if *in*this*special*case* also Integer should be
redeclared to 16 bits. (I know this is quite unusual, but since this
mode is *only* for using existing BP programs without (ideally any)
changes, these programs are likely to expect integer to be 16 bit.)

>   Round parentheses are easiest to implement, but their syntax interferes
>   with Schemata.

Would this a problem? It's very unlikely that someone would declare a
schema called "Integer", isn't it? Such an "Integer(n)" could be a special
built-in schema (special in that the "n" is not stored in the variable).

>   Square brackets come into mind, but they interfere with
>   UCSD's "long integers".

 Are these UCSD "long integers" of arbitrary size, or limited to
subtypes of regular integer types? 

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

This is a strange case, indeed! How are they handled currently in packed
record. Testing seems to show to it's 13 bits in fact.

(* The results are a bit strange. The following program gives "1299" !?!
program x;
type y=packed array [1..800] of $1000..$10ff;
begin
 writeln(sizeof(y))
end. *)

I think it's ok like this. After all, if it's really for a system call
or so, what sense would it make to interpret the values as $10xy if they
were only stored as $xy? As a rule, one might say that the internal
representation of a subrange always includes 0.

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

Can not all machines address 1 byte? I.e., is "Byte" on some machines bigger
than 1 byte (internally)? This gives real problems with binary files,
doesn't it? How do such machines read single bytes from files at all?

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

Fine! :-)

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

Why not! If it's documented, headers should be "easy" to convert then!

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

If you don't mind, please also add {Short,Med,Long,Longest}Card[inal].

> Okay like this?  Or better keep `Integer ( 8 )' (or `Integer < 8 >',

Why not, additionally!
("Integer(n)" is easier to read than "Packed 0..1 shl n-1".)

> or `Integer : 8' like bit-fields in C,

"a:Integer:8" would look strange to me.

> or `Integer * 1' like in FORTRAN?)

Would also look strange to me. "Integer * 2" I would understand as "twice
the size of an integer", if at all...
-- 
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)