headers
Pierre-Philipp Braun | 8 Aug 2011 18:36
Gravatar

uVAX 3100-80 dmesg

NetBSD 5.1 (GENERIC) #0: Sat Nov  6 19:48:36 UTC 2010

builds <at> b8.netbsd.org:/home/builds/ab/netbsd-5-1-RELEASE/vax/201011061943Z-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/vax/compile/GENERIC
MicroVAX 3100/80
total memory = 40696 KB
avail memory = 36160 KB
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root)
cpu0 at mainbus0: KA47, Mariah, 2KB L1 cache, 256KB L2 cache
vsbus0 at mainbus0
vsbus0: 32K entry DMA SGMAP at PA 0x480000 (VA 0x80480000)
vsbus0: interrupt mask 0
le0 at vsbus0 csr 0x200e0000 vec 770 ipl 17 maskbit 1 buf 0x0-0xffff
le0: address 08:00:2b:91:ce:15
le0: 32 receive buffers, 8 transmit buffers
dz0 at vsbus0 csr 0x200a0000 vec 124 ipl 17 maskbit 4
dz0: 4 lines
lkms0 at dz0
wsmouse0 at lkms0 mux 0
asc0 at vsbus0 csr 0x200c0080 vec 774 ipl 17 maskbit 0
asc0: NCR53C94, 25MHz, SCSI ID 6
scsibus0 at asc0: 8 targets, 8 luns per target
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
timecounter: Timecounter "diagtimer" frequency 1000000 Hz quality 100
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 2 lun 0: <DEC, RZ26L    (C) DEC, 440C> disk fixed
sd0: 1001 MB, 3117 cyl, 8 head, 82 sec, 512 bytes/sect x 2050860 sectors
sd0: sync (160.00ns offset 15), 8-bit (6.250MB/s) transfers, tagged queueing
sd1 at scsibus0 target 3 lun 0: <DEC, RZ26L    (C) DEC, 440C> disk fixed
sd1: 1001 MB, 3117 cyl, 8 head, 82 sec, 512 bytes/sect x 2050860 sectors
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thor Lancelot Simon | 15 Aug 2011 20:24
Picon
Favicon

Re: UNS: Compiling vax kernel with pcc

On Thu, Jul 28, 2011 at 08:49:06AM -0400, Brad Parker wrote:
> 
> My assumption (perhaps incorrect) is that once pcc is up to speed it
> might well generate better
> code for the vax than gcc does, with less cpu and memory.

I wouldn't count on it.  Today's pcc is of course better than "traditional"
pcc but, for what it's worth, when I was running a real 11/750 as a
fairly busy UUCP and Usenet site, I eked at least another year of life
out of the tired old beast just by recompiling everything I could with
GCC -- which I think at the time was 1.21.  This was after we'd long
since switched from the 4.3 UUCP to Vixie's UUCP to Taylor UUCP,
moved the modems from DHU11 to DMF32 and removed all vestige of DZ
serial controllers from the system.

My hazy memory tells me that compress(1) got around 25% faster when
compiled with GCC.  Modern GCC probably does better still.
Permalink | Reply | 3 comments |
headers
Dave McGuire | 15 Aug 2011 20:38

Re: UNS: Compiling vax kernel with pcc

On 08/15/2011 02:24 PM, Thor Lancelot Simon wrote:
>> My assumption (perhaps incorrect) is that once pcc is up to speed it
>> might well generate better
>> code for the vax than gcc does, with less cpu and memory.
>
> I wouldn't count on it.  Today's pcc is of course better than "traditional"
> pcc but, for what it's worth, when I was running a real 11/750 as a
> fairly busy UUCP and Usenet site, I eked at least another year of life
> out of the tired old beast just by recompiling everything I could with
> GCC -- which I think at the time was 1.21.  This was after we'd long
> since switched from the 4.3 UUCP to Vixie's UUCP to Taylor UUCP,
> moved the modems from DHU11 to DMF32 and removed all vestige of DZ
> serial controllers from the system.
>
> My hazy memory tells me that compress(1) got around 25% faster when
> compiled with GCC.  Modern GCC probably does better still.

   I've had similar experiences with GCC on VAX, under UNIX 
implementations and VMS.  The same goes for 68020, when compared to 
Sun's (early) compiler.  GCC's optimization on those platforms is excellent.

            -Dave

--

-- 
Dave McGuire, AK4HZ
New Kensington, PA
Permalink | Reply | 2 comments |
headers
Isildur | 16 Aug 2011 14:04
Favicon

Re: UNS: Compiling vax kernel with pcc


i'd doubt, though, that there is much difference in the code generated by
an older 1.x era gcc versus a modern gcc. has there really been much (any) 
work on vax optimization in the past 15 years (or more)?

On Mon, 15 Aug 2011, Dave McGuire wrote:

> Date: Mon, 15 Aug 2011 14:38:18 -0400
> From: Dave McGuire <mcguire <at> neurotica.com>
> To: port-vax <at> NetBSD.org
> Subject: Re: UNS: Compiling vax kernel with pcc
> 
> On 08/15/2011 02:24 PM, Thor Lancelot Simon wrote:
>>> My assumption (perhaps incorrect) is that once pcc is up to speed it
>>> might well generate better
>>> code for the vax than gcc does, with less cpu and memory.
>> 
>> I wouldn't count on it.  Today's pcc is of course better than "traditional"
>> pcc but, for what it's worth, when I was running a real 11/750 as a
>> fairly busy UUCP and Usenet site, I eked at least another year of life
>> out of the tired old beast just by recompiling everything I could with
>> GCC -- which I think at the time was 1.21.  This was after we'd long
>> since switched from the 4.3 UUCP to Vixie's UUCP to Taylor UUCP,
>> moved the modems from DHU11 to DMF32 and removed all vestige of DZ
>> serial controllers from the system.
>> 
>> My hazy memory tells me that compress(1) got around 25% faster when
>> compiled with GCC.  Modern GCC probably does better still.
>
>  I've had similar experiences with GCC on VAX, under UNIX implementations
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jan-Benedict Glaw | 16 Aug 2011 20:43
Picon
Favicon

Re: UNS: Compiling vax kernel with pcc

On Tue, 2011-08-16 08:04:32 -0400, Isildur <mrfusion <at> vaxpower.org> wrote:
> 
> i'd doubt, though, that there is much difference in the code generated by
> an older 1.x era gcc versus a modern gcc. has there really been much
> (any) work on vax optimization in the past 15 years (or more)?

In GCC, you don't have all that much target-specific optimizations.
Most of all, these are done in intermediate representations, thus
they're available to all backends. (However, it helps if target
backend code supplies all ways to do things that can be represented
within GCC's data model, as well as correct costs for those.)

So... While compile time usually rises all the time with most new GCC
releases, as well as memory consumption, there *are* enhancements that
most/all architectures profit from.

MfG, JBG

--

-- 
      Jan-Benedict Glaw      jbglaw <at> lug-owl.de              +49-172-7608481
Signature of:              Träume nicht von Deinem Leben: Lebe Deinen Traum!
the second  :
Permalink | Reply | 0 comments |
headers
John Klos | 28 Aug 2011 22:15

Fun with VLC

Hi, all,

I just wanted to share my experiences with a donated VLC. I put netbsd-5 
built from 21-August-2011 on a 64 gig SSD on the SCSI bus and have been 
running it ever since. It's stable, happy, slow as all heck, but such a
visceral example of tangible VAX hardware. I know a rack full of cards on 
a real backplane is closer to a real VAX, but this hardware is much more 
touchable than even my 4000/60 or 4000/90 systems (perhaps because of how 
much of the CPU / motherboard is obscured by the CD carrier, the video 
card and the memory).

It took four days to CVS the source tree. Damn! But all in all it's a fun 
little machine.

John Klos
Permalink | Reply | 1 comment |
headers
Dave McGuire | 28 Aug 2011 22:48

Re: Fun with VLC

On 08/28/2011 04:15 PM, John Klos wrote:
> I just wanted to share my experiences with a donated VLC. I put netbsd-5
> built from 21-August-2011 on a 64 gig SSD on the SCSI bus and have been
> running it ever since. It's stable, happy, slow as all heck, but such a
> visceral example of tangible VAX hardware. I know a rack full of cards
> on a real backplane is closer to a real VAX, but this hardware is much
> more touchable than even my 4000/60 or 4000/90 systems (perhaps because
> of how much of the CPU / motherboard is obscured by the CD carrier, the
> video card and the memory).
>
> It took four days to CVS the source tree. Damn! But all in all it's a
> fun little machine.

   Excellent.  VLCs are wonderful little boxes.

             -Dave

--

-- 
Dave McGuire
Port Charlotte, FL
Permalink | Reply | 0 comments |

Gmane