🚀 go-pugleaf

In article <5064@hubcap.clemson.edu> mark@hubcap.clemson.edu (Mark Smotherman) writes:
>In article <573@loligo.cc.fsu.edu>, bauer@loligo.cc.fsu.edu (Jeff Bauer) writes:
>   Douglas Clark and William Strecker, "Comments on 'The Case for the
>   Reduced Instruction Set Computer,' by Patterson and Ditzel," Computer
>I've always wondered why they seem to take a swipe at their own designers when,
>in discussing why the INDEX function was faster on the 780 if implemented as a
>sequence of simple instructions, they say:
>   the 780.  This is a problem of implementation, not architecture.
>   Fundamentally, after all, the implementation of the INDEX
>   *function* with more than one instruction simply cannot take less
>   time than the one-instruction version, assuming equal hardware in
>   both cases.  The explanation of this anomaly is that the 780's
>   Floating Point Accelerator speeds up the multiply in the...

OK, I admit it, I'm the one responsible for this mess.  There was a
really good reason at the time.  I was doing the FPA.  There was no
INDEX instruction at the time, and I decided that I would add 32-bit
integer mul (MULL) to those instructions the FPA would optimize, for
exactly that reason: so the sequence to do array address calcs would
go faster.  (There was opposition to this, but I made it stick
anyway!)  So I added MULL.  Late in the program, the architecture
committee added the INDEX instruction.  But my boards were in the
board shop, and it was too late for me to add it to the FPA.  So the
microcoded version was all you got.  So it was a case of bad timing,
not proof that RISC's or CISC's are good, bad, or indifferent after
all.

I don't think the later VAXes had this problem.
-Stan