Re: Some more patches for GCC on NetBSD/VAX coming soon...

[David Brownlee <abs%netbsd.org@localhost>]

 On 30 March 2016 at 07:21, Jake Hamby <jehamby420%me.com@localhost> wrote:
> I'm looking at a few remaining issues in the recent update in NetBSD-current to GCC 5.3, which overall appears to be an improvement over 4.8.5. I dropped GCC-patches from the CC list because I don't think 98% of the subscribers to that list care about VAX, while I know that 100% of the subscribers to this one do. ;-)

That sounds like a very safe assumption :-p

> The previous patch I emailed fixed a fairly serious bug in the cc0 optimizer which I think was causing a lot of issues with branches to go the wrong way. It was a bit conservative, though, as I used the "clobber" attribute for the mov and add instructions because a few of the paths used movz or some sequence of several instructions that wouldn't set the N and Z flags like vax_notice_update_cc() is looking for. If I can get the timing test harness from GMP to compile (which I'm hopeful of) then I'll start to run some benchmarks to see whether a lot of these optimizations in vax.md are useful or not. There are many FIXME and TODO items that are waiting to be worked on.
>
> I'd been concerned that GCC would drop support for VAX altogether, but after spending the last few weeks really digging into the code, it seems like they don't really have to go out of their way to continue to support it, so I'm hopeful that they won't remove it any time soon. There's still a PDP-11 backend in there so I'm hopeful.
>
> One remaining bug that I didn't notice is that there are a bunch of hacks in the NetBSD Makefiles to compile various things with -O0 because of a failing similar to the one that I wrote an m68k patch for, where it fails to compile because it can't find an instruction. Specifically, the VAX crashes look like (this is the cross-compiler from the NetBSD build script):
>
> (insn 3863 3862 3864 537 (set (reg:SI 1417)^M
>         (subreg:SI (mem:DI (plus:SI (mult:SI (reg:SI 644 [ D.14258 ])^M
>                         (const_int 8 [0x8]))^M
>                     (plus:SI (reg:SI 1415)^M
>                         (const_int 96 [0x60]))) [0 MEM[symbol: newblks, index: _1117, step: 8, offset: 96B]+0 S8 A32]) 4)) /home/netbsd/current/src/sys/rump/fs/lib/liblfs/../../../../ufs/lfs/lfs_inode.c:568 -1^M
>      (nil))^M
> /home/netbsd/current/src/sys/rump/fs/lib/liblfs/../../../../ufs/lfs/lfs_inode.c:624:1: internal compiler error: in extract_insn, at recog.c:2343
>
> This is when you remove the ifdef vax then use -O0 hack from the Makefile in that directory. So that's one issue. Another that seems more serious but is easy to reproduce is that /usr/sbin/pkg_info (with either version of GCC, with or without my changes, I believe) was giving weird errors if you used "-a", "-e", or "-E", complaining about imaginary package names that it didn't want that I hadn't put on the command line. Compiled it with -O0 and it worked fine. So that should be fairly easy to track down since it's C code in main().
>
> There are a few other smaller issues with GCC & binutils that I'm looking at cleaning up, but overall, I think NetBSD/vax is in as good of shape as it has ever been. One thing I think would make sense as far as tidying up GCC's vax.md & vax.c is that I think most hobbyists are using CVAX and NVAX-based systems, or related, am I correct? I have a VAXstation 4000 VLC as well as the Model 90, and it seems like other people on the list have something from that era, as opposed to anything pre-Micro VAX. What I'd like to do is use the GMP harness to benchmark, in addition to GMP and MPFR themselves (yes, I want to update the tuning files that haven't been touched in 20 years in those libraries, too), the number of clock cycles of the different flavors of move, copy, compare, add, etc. on a CVAX and an NVAX system and then add compiler flags if the two are wildly different from each other.
>
> VAX has a fairly simple backend: there's no instruction scheduler or anything like that, and I'm not sure if it would even make much sense to try to add one. But at the very least it shouldn't be too difficult to update the values of the numbers that are already there in the C functions in vax.c to calculate the costs of the different types of addressing modes and instruction variants.

I think that would be great. The CVAX/NVAX would definitely make sense
as the default CPU target. If you were interested in getting numbers
for other VAX variants (this is a "what you're already planning is
most excellent", not a "hey you should do this to" :), then I'm sure
there are some list members would be happy to run test or provide
remote access to appropriate machines.

As an aside, I would say the biggest issue for NetBSD/vax (after a
working compiler :) is the footprint of recent gcc versions (and
recent NetBSD itself) is more than any but the fastest (and most
memory rich) VAXen can handle. Thats an unfortunate artefact of
keeping the gcc version up to date and adding features to NetBSD that
are expected on modern platforms (amd64 etc), but it would definitely
be nice if someone were to eke out any performance improvements
possible for the code that gcc generated :)

One thing you may find is that shared libraries have a significant
performance penalty over static linking on VAX (assuming you are
running on a system with enough memory to offset the smaller working
set - which is not usually easy on a VAX :/