On 2012-05-27 19:47, Mouse wrote:
Would it make sense to re-code that to use poly[df] instructions on machines that have them? Would the run-time check be more trouble (or cycles) than it's worth?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. DEC them self definitely use this in VMS. I think it's even what is suggested (mandated?) in 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?
(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. Having the checks inline is also a cost, that otherwise would be taken on every invocation, or else just totally avoid poly instructions.
(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 don't know how true this is, but if it is true on a significant fraction of the VAXen we care about then we might want to go with the open-coded version instead of using POLY.
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. Not sure about the whole picture here, as far as that goes.
There are a lot of instructions in a VAX which a compiler have a hard time to use well. The architecture is really geared towards assembly programming...
Johnny