Algol 68 real vs IEEE 754 vs x86 extended precision

[chris hermansen]

Thanks for the reply, Jose,

On Tue, Mar 10, 2026 at 2:13 PM Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> Hi Chris.
>
> > Hello everyone,
> >
> > Back with more questions... I hope not too irritating.
> >
> > Awhile ago, I asked whether we could implement a "real to bits"
> conversion
> > operator similar to BIN which currently converts int to bits; and of
> course
> > the reverse, "bits to real", which is implemented as ABS in the case of
> > bits to int.
> >
> > I've been looking into this and related topics in the context of the IEEE
> > 754 that we seem to deal with as a matter of course in today's computing,
> > and I see a few sticky points that stem from the x86 extended precision
> (80
> > bit floating point) type:
> >
> >    1. given that long long int is 128 bits and long long bits is
> therefore
> >    also 128 bits, the concept of op BIN = (L real r) L bits would of
> needs
> >    convert an 80 bit long long real to a 128 bit long long bits value
> >    2. can we even define op ABS = (L bits b) L real? or should we rather
> >    chose a name like REAL_BIN and BIN_REAL for this pair?
> >    3. and whether it's ABS b or BIN_REAL b presumably we would convert a
> >    128 bit long long bits value to an 80 bit long long real value
>
> I don't think we can rely on any relationship between reals and bits "of
> the same size" the same way we do between ints and bits "of the same
> size".
>
> In most targets long long bits will be 64-bit long, not 128.
>

Wow I am completely out to lunch here.  When I wrote this, I thought that I
had tested long long int and maybe long long bits and found them to be 128
bits in length.

I guess I put this aside for too long.


> Widening only works on the int to real direction, for ints and reals "of
> the same size".
>
> The BIN operator applied to reals would work in the opposite direction,
> but as you observe, a long long real is 80 bits, which will not fit in a
> 64-bit long long bits.
>

 Perhaps it's better to return to the alternative idea that we discussed
awhile back, which is separating the sign, exponent and mantissa, for
example as:

op REAL_BIN = (L real r) struct (int sign, int exponent, L int mantissa):
...
op BIN_REAL = (struct (int sign, int exponent, L int mantissa)) L real: ...

which I think was Jose's suggestion earlier on.

I think this should work since real, long real and long long real have 24,
53 and 64 bits of mantissa and int, long int and long long int provide 32,
64 and 64 bits.

Given the idea of the two operators REAL_BIN and BIN_REAL above, could we
then write the L max real constants as:

real max_real = BIN_REAL(1, 127, ABS 16r00FFFFFF);
long real max_long_real = BIN_REAL(1, 127, ABS 16r003FFFFFFFFFFFFF);
long long real max_long_long_real = BIN_REAL(1, 1023, ABS
16rFFFFFFFFFFFFFFFF); { or maybe 16r7FFFFFFFFFFFFFFF since the conversion
could put back the 1 digit }

??

>
> > Similarly, and harking back to the discussion over twos-complement and -
> > max_int, I feel as though we should define min_real, long_min_real and
> > long_long_min_real as the negative minima.
> >
> > Further, the concept of small_real (and long_small_real,
> > long_long_small_real) throws me off given that we have these subnormal
> > numbers in IEEE 754.  Should the "small" values be the minimum normal or
> > minimum subnormal values, and in either case, what should the other small
> > values be called?
> >
> > We could for instance decide that small_real, long_small_real and
> > long_long_small_real refer to the subnormal numbers following the RR
> > definition:
> >
> > L real L small_real= { the smallest L real value such that both
> >    L 1 + L small real > L 1 and
> >    L 1 - L small real < L 1 (2.2.2.b} };
> >
> > Yet it seems that it might be better to encourage programmers to work
> with
> > normal values and leave subnormal values for "special occasions".
>
> Would both options be conformant with the RR?
>

As I understand it, the "true" smallest real value such that 1 + small_real
> 1 would be the subnormal smallest number, that is approximately  1.40e-45
rather than the normal smallest number, approximately 1.18e-38.

It's my impression that the intent of subnormal numbers is to avoid
underflow, that is they exist to be the result of computation rather than
numbers to be used directly.

Certainly, given that the smallest normal number is greater than the
smallest subnormal number, it would satisfy the inequality but not the term
"smallest".

>
> >
> > Final preoccupation - it seems to me that we should also directly support
> > NaN and infinity, at least with standard prelude constants or operators.
>
> Yes definitely, these identifiers would go in the extended standard
> prelude.
>

Cool, thanks!


-- 
Chris Hermansen · clhermansen "at" gmail "dot" com

C'est ma façon de parler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/algol68/attachments/20260310/43cc4550/attachment-0001.htm>