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

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> 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.

>> (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?

>> (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.

> 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.

>> (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.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B