Re: Does anyone have a netbsd-5 or earlier VAX to hand?

[Johnny Billquist <bqt%softjar.se@localhost>]

On 2012-05-28 08:04, Mouse wrote:
> > > > I think the sane way is to actually just use poly[fd] all the time,
> > > > and let the emulation handle it if the machine don't actually
> > > > implement it in hardware.
>
> > > > No need for explicit checks, it's done automatically by the hardware.
>
> > > (a) Is that true of all hardware which doesn't have direct POLY
> > > support?
>
> > I would think so.  Illegal instructions cause a trap.
>
> Yessss...but do legal instructions that happen to not be implmeneted?
> It's been too long since I looked at that part of the VARM.

They certainly do. Things would break in very bad ways otherwise.

> > > (b) Even if it is, do we want to do that?
>
> > Yes, we definitely want it in general, since we do want code that
> > might be using poly[fd] to work, don't we?
>
> Hm, good point.  But don't we ignore that issue for things like ADDP6
> and EDITPC?

We do. Potentially bad, and we should probably add those at some point 
as well, but they are much less used, and unlikely to cause problems in 
general. I doubt even much VMS code ever use those instructions, and I 
wonder if any Unix code have ever used them...

> > > (b1) I would expect the trap overhead to be significant.
> > It is not that bad I think.  And compared to the overhead of actually
> > emulating the whole poly instruction, I would think it is small.
>
> Maybe.  But this isn't a KA630 doing its funky `macrocoded' instruction
> trap, which is designed to make life easy for emulators; here, the trap
> handler has to not only recognize POLYx instructions and do the
> arithmetic, it also has to do all the necessary instruction decode.
> For polynomials of the degree involved here, I expect operand decoding
> and fetching to cost *at least* as many cycles as doing the arithmetic
> the instruction calls for does.

The trap and instruction decode part is small and easy. Check the NetBSD 
source... The operand decoding is a little more complex, but not really 
that much either.

> > Having the checks inline is also a cost, that otherwise would be
> > taken on every invocation, or else just totally avoid poly
> > instructions.
>
> I would expect the checks to be done once, at libm install? link?
> startup? time, a la the i386's libm387.

That would be nice, but it didn't sound like what the OP had n mind. But 
I agree, doing it that way would probably be the best.

> > > (b2) I have seen it said that many of the more complex instructions
> > > are, on many implementations, actually slower than doing the same
> > > thing with multiple instructions.  POLY is a typical example.
> > I know I read somewhere that it was true for some sequence of
> > instructions, not sure which.  But I also remember reading something
> > about this also being related to that compilers had a hard time using
> > some instructions in a good way.
>
> That's not the form I remember; what I recall had nothing to do with
> compiler issues.
>
> I'd want to test it before I did anything based on assumptions about
> the relative speed of a POLYx versus doing the same computation
> open-coded.

I definitely don't object for us to get some numbers. In fact, if you 
can set up a program to test it, I promise to run it on a VAX-8650, and 
we can get numbers on both poly[fd] and implementations not using it, to 
have an idea for atleast that machine, which version would be preferred.

        Johnny