[PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)
Maciej W. Rozycki
Thu Nov 26 18:01:31 GMT 2020
On Wed, 25 Nov 2020, Joseph Myers wrote:
> > For the other pieces that are missing perhaps my work I did many years
> > ago to port glibc 2.4 (the last one I was able to cook up without NPTL),
> > and specifically libm within, to the never-upstreamed VAX/Linux target
> > might be useful to complete the effort, as there seems to be an overlap
> > here. That port hasn't been fully verified though and I do not promise
> > doing any work related to it anytime either. The glibc patches continue
> > being available online to download and use under the terms of the GNU GPL
> > for anyone though.
> I think I mentioned before: if you wish to bring a VAX port back to
> current glibc, I think it would make more sense to use software IEEE
> floating point rather than adding new support to glibc for a non-IEEE
> floating-point format.
Right, that would be the path of least resistance (non-FP VAX bits are
obviously limited and boil down to the OS interface and some handwritten
assembly such as for optimised string ops), and surely the least involving
one maintenance-wise, so perhaps the only acceptable compromise these days
given that VAX is a niche of a niche now.
The kernel part would have to happen first though, and the old effort
became stuck in 2.6 days, so clearly not suitable for upstreaming. Back
in the day I did enough kernel updates to get interrupt handling right,
i.e. the IPL stuff, based on what the Alpha port does, which is really the
same, and then on top of it ptrace(2) support along with a native GDB and
a `gdbserver' port so that I could actually debug the outstanding userland
But that was surely not enough even back then and is even less so now.
FWIW I was able to run single-user `bash' (with `ncurses', etc.) and some
other programs; native GCC crashed as did GDB, due to a bug leading to
stack exhaustion, but `gdbserver' worked along with single-stepping, etc.,
so that was a good starting point.
The VAX/NetBSD port however does use hardware FP in their libm as far as
I can tell, so I guess it would be reasonable for libgfortran to do so as
well. I haven't checked how correct their implementation actually is, but
barring evidence otherwise I would assume they did the right thing.
Without all the NaN/denormal stuff the handling should be much simpler I
believe, though I gather some numeric algorithms do rely on the presence
of denormals to produce reasonable results in some boundary cases. These
would be lost or a different algorithm would have to be chosen for the
respective computations I suppose.
More information about the Gcc-patches