🚀 go-pugleaf

In article <3169@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>In article <5064@hubcap.clemson.edu> mark@hubcap.clemson.edu (Mark Smotherman) writes:
> [quoting Clark & Strecker]
>
>>  "Anecdotal accounts of irrational implementations are certainly
>>   interesting.  Is it *typical*, however, that composite instructions
>>   run more slowly than equivalent sequences of simple instructions?
>
>In my experience, yes, it is indeed typical.  Taking only the example
>of the VAX, I have found naive code faster than the block operations
>(MOVC3, CMPC3), the loop instruction (ACB), INDEX, and, of course, the
>call instructions.

You should include ALL of the data here.  The proper way of saying
this is: "The implementation of the subset that I need in a particular
case is faster than the full operation."  For example, the VAX CALL
includes aligning the stack and saving enough state so it can be fully
restored, saving the condition codes, pushing a minimum of five
longwords, picking up a mask at the called procedure, and pushing only
those registers with corresponding bits set in the mask.  I'll bet
your substitution code did not do all that.  The string instructions
have logic in them to make sure overlapping strings worked, zero-length
strings worked etc., regardless of the case.  Did your code do that?
INDEX was another example where some of the exception checking was
left out of the emulation.  I guess it USUALLY works!

CALL was never intended to be faster than JSR; it was designed to ease
the programming burden of a consistent calling standard, so
cross-language calls would just work.  Now if there were no JSR, there
would be something to complain about.  But all the simple instructions
are present, and implemented in an optimized way!  So the user has a
choice: use the fully functional instructions if he wants the machine
to do the work, or reinvent all the way down to the bare metal.  With
RISC, there is no choice.
So there! :-) Stan