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 issues. 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. Maciej
