🚀 go-pugleaf

Markus Freericks <mfx@cs.tu-berlin.de> wrote:
>halasz surely meant to specify "numer of digits + base", no?

If you'll forgive me the presumption of speaking for someone else, the
previous messages he's posted on the topic seem to indicate that he was
advocating specification in terms of decimal digits only.

>typedef unsigned int (1:2) bit;
>typedef unsigned int (1:3) trit;
>typedef unsigned int (8:2) byte;
>typedef unsigned int (1:10) digit;
>
>-- Markus (hey, that would be useful on decimal and trinary computers!)

It's of limited utility.  C is an inherently binary language anyway, so
of all the bases that one could specify integral type size in, binary
is by far the most useful.  Specification in any other base could be
converted to a number of bits by the programmer, and if the above
syntax were allowed they would be so converted by the compiler anyway.

Specification in terms of a base that is some other power of two (i.e.
in terms of some integral number of bits) would be meaningful, but one
really needs single-bit resolution in order to be efficient on machines
with unusual word sizes.  Programmers (well, at least I) find it
natural to think in terms of numbers of bits.

The suggestion someone posted of allowing an absolute upper value to be
specified has some merit.  It's mostly syntactic sugar, but in the case
of signed numbers it might be useful for portability to machines with
different sign representations.  In those cases, a pure number-of-bits
specification would leave one unsure of the exact limits of the type.
There's the capability to avoid some (fairly simple) experiment-program
trickery for some type specifications if this is permitted.

Does anyone else think it's a really silly idea to only require
compilers to accept extended ranges up to 128 bits?  (That's the
requirement in the SBEIR paper.)  We're bound to run up against it
sooner or later, causing problems (for strictly conforming code)
analagous to the current 16-bit int / 32-bit long problem, though not
nearly as bad.  Surely the implementation should be required to support
types as large as system resources will allow?

High-quality implementations will probably allow specifications of up
to INT_MAX (maybe UINT_MAX) bits anyway.  (Or they might divide this by
2^4 or so, to leave room for the required flag bits in a prec_t and
keep it int-sized.)  One could consider the 128 bits to be merely a
minimum implementation limit, but the proposal seems to encourage
implementors to actually use this limit.

-zefram