🚀 go-pugleaf

>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, ...
[examples...]
>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.

You make a valid point:  the complex instructions do a lot of work, and
that work is sequenced in a transparent way so that instruction fetch
overhead is eliminated and advantage of low-level special cases can be
taken in microcode (well, you didn't say all that; I guessed you were
thinking it).  Unfortunately, all the work that the complex instructions
do is rarely needed.  And in the case of the call instruction, I find
the VAX complex instruction sorta insulting:  assuming that compiler
writers are too stupid to adhere to a common spec for inter-language call
protocol.  Having the microcode do it is no better than having a subroutine
in the compiler emit the sequence of instructions that implements the
agreed-upon protocol.  And the agreed-upon protocol can do just what is
needed.  Maybe compiler writers are that stupid, in general, or were at
the time of the VAX's conception.  You are also right when you say with
RISC there is no choice:  one is FORCED to use the fast instructions!  :-)