[PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

Maciej W. Rozycki macro@linux-mips.org
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 mailing list