Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ld assertion failures building NetBSD-VAX with GCC 4.5

On Sun, Mar 10, 2013 at 11:56 PM, John Klos <john%ziaspace.com@localhost> wrote:
> I've noticed that the VAXstation 4000/60 was around the speed of an m68040
> system and that while the 4000/90a was noticeably faster than an m68040, it
> wasn't quite as fast as an m68060. It's still a pretty impressive machine
> considering its age.
> Has there been any progress with making gcc 4.5.x happier with VAX?

I put aside debugging GCC 4.5 and binutils for a few days to
investigate a few other areas of NetBSD that need some work on VAX.
It's a little tedious having to reverse engineer the VAX ELF ABI from
the source code, without any spec describing what the VAX-specific
parts are supposed to look like. There's a comment in elf32-vax.c
mentioning an SVR4 ABI supplement for VAX, but I can't find any copies
of that processor supplement online, and I'm not sure how much it
would actually help for NetBSD.

I'll get back to debugging gcc 4.5 tonight, since it seems like it's
got to be something simple. The next item on my list is that the SCSI
driver (asc0) seems to have a bottleneck that is limiting my data
transfers to ~3.5 MB/s rather than the 6.25 MB/s that I'm supposed to
be getting, and SCSI transfers also seem to be interfering with
Ethernet performance, as I'm seeing drops in FTP download speed that
seem to correspond to disk accesses.

The VAXstation 4000 has a fairly elegant but complex bus arrangement
that is fortunately well documented by a Digital Tech Journal article.
See the link at the bottom of this page, which also has a bunch of
cool photos of the VS 4000/90:

It was definitely an elegant and powerful machine for its time. I just
upgraded the RAM on mine to 128 MB. The CPU is definitely much faster
than a 68040, but something is slowing down the SCSI data transfer
rate on NetBSD (at least on my box) which is making it feel much
slower than it ought to be. It looks like we might be mapping and
unmapping the DMA window for each SCSI transfer, and I'm wondering if
this is what's causing the slowdown. It seems like if it's nontrivial
to set up the SCSI DMA map, then we should be creating a single 64K
(max transfer size) buffer at a fixed location in physical memory for
DMA, setting up the VAXstation DMA map once, and then memcpy'ing
everything to/from that buffer, rather than trying to DMA everything
in place. It should still be faster than PIO transfers, but I'll try
that option as well, just for comparison.

I'll send another email once I've made progress on the GCC and/or kernel bugs.


Home | Main Index | Thread Index | Old Index