Subject: Re: NetBSD/vax 1.6 pkgsrc perl build?
To: John Klos <john@sixgirls.org>
From: Brian Chase <vaxzilla@jarai.org>
List: port-vax
Date: 11/02/2002 19:02:35
On Sat, 2 Nov 2002, John Klos wrote:

> Hi,
>
> > Has anyone here attempted to build the `lang/perl5' (Perl 5.6.1) package
> > from the 1.6 release on thier VAX?  I've just run through the first
> > attempt on my MicroVAX 3100 and its errored out in the install phase
> > while generating the perl man pages.  I'm working on regenerating the
> > error.
>
> I can make a generic binary package from the bulk package machine (it just
> got a new hard drive and a new home, so it will be building full time
> soon), but I don't know if your already started build will actually take
> longer than my disklabelling, newfsing, populating, and building.
>
> > I'd also noticed earlier in the build process that perl had complaining
> > with a warning about `make test' not having been run.  I'd presumed
> > this was a choice made by the person who assembled the perl5 package.
> > Curious, I went into the working directory of my failed build and
> > manually ran `make test'.  I found the following tests to have failed:
> >
> >   op/cmp...............FAILED at test 0
> >   op/numconvert........FAILED at test 0
> >   lib/bigfltpm.........FAILED at test 351
> >   lib/complex..........FAILED at test 0
> >   lib/trig.............FAILED at test 0
>
> None of this stuff is surprising; VAX floating point is not IEEE floating
> point, so anything that tries to compare floating point results with some
> pre-calculated results may be expected to fail.

I've got the kernel compiling in the background, but also I'm drilling
in a bit deeper to the tests.  It looks like perl is crashing and
dumping core on most of the above.  I'd not be surprised at failures
given the expectations of IEEE fp, but crashing and dumping core is not
a good thing.  I'm /fairly/ certain that the perl 5.0 releases passed
all of the tests successfully.

> Just for curiosity, I'd love to know more about VAX floating point... is
> it more accurate / less accurate? What does a fp register look like?

I guess that depends on the format you're looking to use; the VAX most
commonly supports 3 different fp data types: F_floating, D_floating, and
G_floating.  Some of the systems supported the extended accuracy type of
H_floating.  And then the MicroVAX-I came in either F&D_floating or
F&G_floating flavors.

The F_float is a 32-bits.  It's sign magnitude number with a sign bit,
7-bits of exponent, and 24-bits for the fractional part.  The range is
given as 0.29x10^-38 through 1.7x10^38.  Precision is given as about 1
part in 2^23 or 7 decimal places.

The D_float is 64-bits.  It's sign magnitude number with a sign bit,
7-bits of exponent, and 56-bits for the fractional part.  The range is
given as 0.29x10^-38 through 1.7x10^38.  Precision is given as about 1
part in 2^55 or 16 decimal places.

The G_float is 64-bits.  It's sign magnitude number with a sign bit,
11-bits of exponent, and 52-bits for the fractional part.  The range is
given as 0.56x10^-308 through 0.9x10^308.  Precision is given as about 1
part in 2^52 or 15 decimal places.

The H_float is 128-bits, sign magnitude number with a sign bit, 15-bits
of exponent, and 112-bits for the fractional part.  The range is given
as 0.84x10^-4932 through 0.59x10^4932.  Precision is given as about 1
part in 2^112 or 33 decimal places.

In a regular VAX, there are no special floating point registers.  The
same set of registers used for integer operations work with the floating
point data types; you can span the operands across registers, just like
with the integer operations.

In the VAXen equipped with vector processors, there are additional
vector registers.  I believe there are 16 vector registers per vector
processor, each register can hold 64 64-bit elements.  There are also
special vector instructions for operating on those.

> If you'll be building a kernel, I'll definitely have a perl package
> before you. I'll post it when it's uploaded.

That's quite likely--thanks.  Trying to run two sizeable compiles on a
16MB 2.5VUP MicroVAX 3100 takes a while.  I always wondered why DEC
didn't include a secondary cache on the early MicroVAX 3100s while they
did on their workstation sibling of the same era, the VAXstation 3100.
Not that it makes /that/ much difference--but still!

-brian.