Bytes, chars, ints, etc (gnu algol 68, C, ...)

[chris hermansen]

Just a brief thing below...


On Thu, Jan 15, 2026, 18:51 Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> > Jose and everyone,
> >
> > On Thu, Jan 15, 2026, 12:57 Jose E. Marchesi <jemarch@gnu.org> wrote:
> >
> >>
> >> >> Hello All,
> >> >>
> >> >> Please let me know if this mail list is not the proper place for this
> >> >> kind of question.
> >> >
> >> > It is exactly the right place :)
> >> >
> >> >> Recent postings touch upon "bytes" (with respect to transput), and
> >> >> "chars" have been mentioned (with respect to unicode).
> >> >>
> >> >> Algol 68 was developed creating its own vocabulary for various
> >> datatypes.
> >> >>
> >> >> C has data types: "char", "int", etc.  Types sizes became more
> diverse
> >> >> yielding "short",  "int", "long int", "long long int".  Their actual
> >> >> sizes may vary from system to system.
> >> >>
> >> >> To clearly fix the sizes to a given name, some languages (for example
> >> >> zig) have created types such as:  unsigned integer types, "u8",
> "u16",
> >> >> "u32, "u64, and float types "f16", "f32", etc.  The naming discloses
> >> >> concrete numerical properties of each.
> >> >>
> >> >> Finally, here is the question:
> >> >>
> >> >> Given GNU Algol 68 shall be a superset, when introducing new
> primitive
> >> >> types must we restrict ourselves to the using the same/similar names
> >> >> used by "C"?  (And along with the "wiggle-room" on bytes sizes?)
> >> >>
> >> >> Or, would we be open for newer types with byte-size clarity from
> name.
> >> >> (Question motivated most recently  by the "byte, bits, etc for binary
> >> >> IO" postings.  Perhaps "u8" would be nice for this.)
> >> >
> >> > I have been actually reflecting about the possibility of having
> >> > size-named integral modes, as aliases to the corresponding `sizety
> int',
> >> > and I am coming to the conclusion that it may be not that good idea
> >> > after all.
> >> >
> >> > Thing is, in C you have types:
> >> >
> >> >     char
> >> >     short
> >> >     int
> >> >     long int
> >> >     long long int
> >> >
> >> >
> >> > which, depending on the target, may be of different sizes.  Also the
> >> > `char' may be signed or unsigned.
> >> >
> >> > For example, a typical 32-bit target:
> >> >
> >> >     char      8-bit (signed)
> >> >     short     16-bit
> >> >     int       32-bit
> >> >     long      32-bit
> >> >     long long 64-bit
> >> >
> >> > And a typical 64-bit target:
> >> >
> >> >     char      8-bit (signed)
> >> >     short     16-bit
> >> >     int       32-bit
> >> >     long      64-bit
> >> >     long long 64-bit
> >> >
> >> > Then C added types like int8_t, int16_t, int32_t and int64_t.  These
> are
> >> > aliases (typedefs) to the corresponding "unsized" type.  So in the
> >> > 32-bit target you have:
> >> >
> >> >     typedef char      int8_t;
> >> >     typedef short     int16_t;
> >> >     typedef int       int32_t;
> >> >     typedef long long int int64_t;
> >> >
> >> > This works well, in C.
> >> >
> >> > While discussing transput we thought about the possiblity of using a
> >> > similar strategy in GNU Algol 68.  The idea would be the same: lets
> >> > introduce aliases (mode names) with explicit sizes.
> >> >
> >> > For a typical 64-bit target:
> >> >
> >> >
> >> >     mode Int8  = short short int,
> >> >          Int16 = short int,
> >> >          Int32 = int,
> >> >          Int64 = long int;
> >> >
> >> >
> >> > For a typical 32-bit target:
> >> >
> >> >     mode Int8  = short short int,
> >> >          Int16 = short int,
> >> >          Int32 = int,
> >> >          Int64 = long int;
> >> >
> >> > Note that, unlike in C, they are the same in both arches!
> >> >
> >> > This is because, unlike in C, you cannot have a `long int' with the
> same
> >> > size than an `int'.  This is because the language rules say that if
> you
> >> > keep adding `long's at some point the precision "saturates" and
> further
> >> > additions don't have any further effect.  There is an enviroment
> enquiry
> >> > that tells you exactly how many `long's can you add that are actually
> >> > relevant.  Same consideration applies for shortsetys.
> >> >
> >> > This is documented in the report:
> >> >
> >> >   2.1.3.1 Plain values
> >> >
> >> >   [...]
> >> >
> >> >   b) An arithmetic value has a "size" i.e., an integer characterizing
> he
> >> >      degree of discrimination with which it is kept in the computer.
> >> >
> >> >   c) The mode of an integer or of a real number of size n is,
> >> >      respectively, some 'SIZETY integral' or 'SIETY real' here, if n
> is
> >> >      positive (zero, negative), that 'SIZETY' is n times 'long' (is
> >> >      empty, is -n times 'short').
> >> >
> >> >   d) The number of integers or of real numbers of a given size that
> can
> >> >      be distinguished increases (decreases) with that size until a
> >> >      certain size is reached, viz., the "number of extra lengths"
> (minus
> >> >      the "number of extra shorts") of integers or of real numbers,
> >> >      respectively, after which it is constant.
> >> >
> >> >
> >> > What I am coming to realize is that the C aliases would be pretty
> >> > useless for Algol 68.  This is because there are no implicit coercions
> >> > from, say, `short int' to `int'.  Widening only happens from int to
> real
> >> > of same sizety, and from real to complex of same sizety.  (Genie has
> an
> >> > extension to allow the other kind of coercions, but I don't want to
> >> > support it.)  This means that you would start writing something like
> the
> >> > following, to initialize a counter to zero:
> >> >
> >> >
> >> >      Int64 counter := _
> >> >
> >> >
> >> > and then, what, should you write:
> >> >
> >> >      Int64 counter := long 0;
> >> >
> >> > or should you write:
> >> >
> >> >      Int64 counter := long long 0;
> >> >
> >> > You see the point: the programmer needs to know the size of all the
> >> > supported `sizety int'.  If she doesn't, she will never be able to
> work
> >> > with the "sized" integral aliases.  And if she does, then she doesn't
> >> > need the sized integral aliases.
> >> >
> >> > HOWEVER...  this may be just fine.
> >> >
> >> > The reason why in C int64_t, etc, are so useful, is because given the
> >> > size of `int' you cannot really determine the size of the other types:
> >> > `long int' may be 32 bit, or 64.
> >> >
> >> >
> >> > But if to the existing Algol 68 rules we add a new one, as an
> extension,
> >> > saying that each increment (decrement) in size shall be doubling
> >> > (halving) the underlying number of bits, then given the size of `int
> and
> >> > the number of meaningful sizes, we can derive the size of any `SIZETY
> >> > int'.
> >> >
> >> > In other words, if `int' is 32-bit, `long int' will always be 64-bit,
> if
> >> > it is meaningful.  And `short int' and `short short int' will always
> be
> >> > 16-bit and 8-bit if they are meaningful.
> >> >
> >> > This could not accommodate targets with "non-regular" register sizes
> >> > such as 40 or 24 bits, but it _can_ accommodate true 16-bit targets,
> for
> >> > example, where you could have the following meaningful sizeties:
> >> >
> >> >
> >> >       short int -> 8-bit
> >> >       int       -> 16-bit
> >> >       long int  -> 32-bit
> >> >
> >> > And even true 8-bit targets:
> >> >
> >> >       int      -> 8-bit
> >> >       long int -> 16-bit
> >> >
> >> > So at this point my thinking (at least for now 8-)) is:
> >> >
> >> > 1. Adding explicitly sized integral mode names like Int64 and friends
> is
> >> >    not a good idea.
> >> >
> >> > 2. We should not fix Byte to be `short short int'.  It should be set
> by
> >> >    the compiler to be an alias to whatever `SIZETY int' mode is 8-bit.
> >> >
> >> > 3. There must be always a `SIZETY int' mode with size 8-bit.
> >> >
> >> > Thoughts?
> >>
> >> Just wanted to add a practical note.
> >>
> >> In all targets currently shipped in GCC, to the best of my knowledge,
> >> `int' is 32-bit.
> >>
> >> This means that in virtually every target used today,
> >>
> >>   `short short int' will be 8-bit.
> >>   `short int'       will be 16-bit.
> >>   `int'             will be 32-bit.
> >>   `long int'        will be 64-bit.
> >>   `long long int'   will be 128-bit (if supported by the arch).
> >>
> >> But, the proposed rule still allow supporting the language in
> >> architectures where you would typically use other compilers (even if
> >> there are some GCC ports available for these, off-tree) and where an
> >> `int' would need to be, for example, 16-bit, or even 8-bit.
> >>
> >> So, for all practical purposes, `long int' will always be 64-bit.
> >>
> >> Pietro: and this means we would have to change lseek to use `long int'
> >> and not `long long int'.
> >>
> >
> > There are some other related things to consider.
> >
> > For example not every other Algol 68 is going to support UCS-4, or even
> > Unicode. Someone might follow Java's path and char could be 16 bit.
>
> I don't follow.  How is the absence of Int8, Int16, etc impacting that?
>

Because ABS of some char value has to fit in an int of some sort and REPR
vice versa?

>
> > And the wonder that is 80 bit extended precision floating point...
>
> Ditto.
>

My eyes glaze over with some of the FP <-> integer conversion algorithms
but I believe I've seen one that starts with bit patterns.

So I think we really want BIN to apply to real and ¿what? to do the
reverse? Maybe we  want to do that in two operations, one on the exponent,
one on the mantissa, with ABS?

But anyway I guess a real in bits should fit into bits,  long real into
long bits, long long real (either the 80 bit beauty or the more obvious 128
bit float for which we don't have hardware support) into long long bits,
via BIN.

>
> > Anyway... If we are to support writing 8 bit somethings from GNU Algol 68
> > and continue to recognize that byte as defined in the RR is
> >
> > counterproductive (to say the least), we will want to be able to refer to
> > something like
> >
> > []short short bits
> >
> > knowing that short short bits is 8 of those very same bits.
> >
> > And so probably we will become tired and grumpy writing short short bits
> > all the time...
> >
> > As you say the compiler could supply this name somehow but then we should
> > still come up with a name that we like, ¿no?
> >
> > By the way given that the RR separates arithmetic operations on int base
> > modes from but twiddling operations on bits base modes, we really need
> two
> > compiler supplied modes "equivalent to" short short bits and short short
> > int with the ability to coerce one to the other and vice versa.
> >
> > Depending on what we are doing in a given module it may be worthwhile to
> > define arithmetic operators on bits and bit twiddling operators on int by
> > encapsulating the appropriate calls to BIN and ABS.
>
>
> Yes the mode compiler-provided Byte we want to add technically has the
> same problem than Int8, Int16, etc.
>
> But considering that the _vast_ majority of targets, in GCC or
> otherwise, have 32-bit int and 16-bit short int and 8-bit short short
> int, a program that does:
>
>     Byte b = short short 16rff;
>
> ought to be pretty darn portable..
>

Ok so your are thinking that Byte will be provided by the compiler with the
"obvious" semantics and that the L bits operators will work on it?

>
> So I think this won't be a problem in practice and we can proceed with
> defining Byte as `short short bits' unconditionally. Algol 68 programs
> written for the Commodore 64 won't be very portable, but such is life..
>
> > I feel that I'm going on too long here...
>
> You can even go long long!
>

In fact I can go on even further but it will amount to the same thing...

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/algol68/attachments/20260115/7cd47add/attachment-0001.htm>