Re: pbulk bootstrap: `awk` running into FP overflow during bison build (Grater picture: How to bootstrap pkgsrc / pbulk?)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> [...] that leaves a range overflow expecting to produce an infinity
> still a valid possibility.

It does.  How does awk handle infinities on ports that have them?  The
awks I have on hand respond to division by zero with a fatal error
("division by zero" - formatting varies) rather than generating an
infinity.

Running { a = $0; print a * a; } and feeding it 1e100, 1e150, and
1e200, I find the first two do reasonable things and the last prints
"inf" (5.2 amd64) or "Inf" (1.4T sparc).

> Though, hmm, it has struck me that the program might expect the IEEE
> 754 exponent range of the double FP type, [...]

True - good point!

> which raises a question: which of D_floating and G_floating format
> has our port chosen?

D, I would guess.  There was hardware that included D-float but for
which G-float was optional (the -11/750 and -11/780), according to
EL-00032-00-decStd32_Jan90.

> Overall I think we ought to support both, but it might be a bit
> tricky on the toolchain side,

To do it right, it seems to me you'd need a compiler with three FP
types (or four if you want H-float support too), two of which are the
same size but have different details and use different instructions.
(How you'd represent this at the source-code level is another
interesting question.  As far as I can recall from my VAX/VMS days
using FORTRAN, there was just "REAL*4" and "REAL*8"; I don't recall any
way for the source code to specify D-float versus G-float, though there
may have been a compiler switch.  There might also have been REAL*16
for H-float, but I don't recall ever even trying it.)

This is, of course, not the least bit difficult conceptually, but
probably somewhat, ahem, "interesting" in practice.  In C, H-float
would be a decent match to long double, but someone would have to
invent something for D- versus G-, especially when we get into library
support (consider printf, strtod, and much of libm).

> Did any machine actually implement H_floating in hardware, or was it
> only ever emulated?

All that follows assumes EL-00032-00-decStd32_Jan90 is accurate.

Yes: the -11/730 was "the first to include G_floating and H_floating as
standard".  H-float was optional for the 750 and 780.  Later models,
such as the 8200, "include[] all the instructions", but I wouldn't take
that too literally in view of the same document describing lots of
instructions, such as the vector and hypervisor instructions, that I am
inclined to doubt the 8200 had.  The document says that F-, D-, and
G-float are required, with H-float is emulation-only - the hardware is
not required to support H-float operations directly, but is required to
provide enough support for them to be emulated.

As for support for the other types, the MicroVAX-I came in two
versions, one with support for F- and D-, the other for F- and G-.  The
MicroVAX-II had F-, D-, and G-, but by implication not H-.  The 730
included G- and H- standard, as mentioned above; the PDF is silent on
whether it includes F- and/or D-, but I feel fairly sure it had both;
it "includes all the instructions" (though the remark above about the
8200 also applies here, with more doubt).  The 750 and 780 also
"include[] all the instructions", with G-float and H-float optional.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B