[koalahedron]

Thanks for your thoughtful comment.

I'm afraid my DEC assembly language study ended at the PDP-11, but it is edifying to know the VAX had such an instruction.

In some domains like numerical programming, ML, and graphics using SDF having a Calc 102 operation like a gradient op might be considered useful enough to include in a RISC instruction set, and the RISC entry on Wikipedia says this about the RISC-V architecture:

> The ISA is designed to be extensible from a barebones core sufficient for a small embedded processor to supercomputer and cloud computing use with standard and chip designer defined extensions and coprocessors.

Maybe a derivative op belongs in a math coprocessor?

[DougMerritt]

> I'm afraid my DEC assembly language study ended at the PDP-11

You're better off; the PDP-11 was a beautiful ISA but the VAX was not, it was just a kitchen-sink approach, and is part of what motivated interest in the RISC approach.

If the VAX had simply been a clean 32 bit extension of the PDP-11, a lot of related history probably would have turned out interestingly different -- not that it would have stopped the RISC revolution, but still.

Specifically, the VAX CISC instructions overall, and the polynomial instruction in particular, were significantly slower than just using the regular VAX instructions to do the equivalent -- which was widely agreed to be unfortunate if not outright pathetic.

Nor was that particularly rare with CISC instructions. It's just a lot easier to make RISC instructions go fast, whether microcoded or not. It's typically not impossible to make CISC instructions optimally fast, but it's an extra cost in implementation and testing for the manufacturer, so it often got/gets comparatively neglected.

The Intel processor looping instructions re-fetched the instruction on every loop, so they didn't (and still don't, as far as I know) even save on the instruction fetch bandwidth.

Typical comment on that that I just found: "You should normally never use the loop instruction unless optimizing for code-size at the expense of speed, because it's slow. Compilers don't use it. (So CPU vendors don't bother to make it fast; catch 22.)" [1]

There was also a mindset issue (with both users and manufacturers) where it was viewed as a boost to assembly language programming to have fancy opcodes, although in retrospect that particular angle could have been just as easily addressed by the manufacturer with fancy assembly macros. I'm not sure why that was usually left to users.

> Maybe a derivative op belongs in a math coprocessor?

Sure, why not. Although theoretically it still needs to justify the opcode real estate and coprocessor silicon real estate and/or microcode space that it uses.

I personally like the concept of CISC, and I like things like Lisp machines, and I like GPUs, and so on. But they don't automatically justify themselves logically; it depends on the tradeoffs in each case.

[1] https://stackoverflow.com/questions/46881279/how-exactly-doe...

[koalahedron]

Thanks again. Like you said it is fun to dream (ask the "Scheme Machine" guys sometime about how they would go about it now), but practically with technology like Julia's Zygote:

https://github.com/FluxML/Zygote.jl

the efficiency of autodiff might be similar to that of an opcode anyway.

So, how did DEC do on the Alpha processor? I always heard good things about it--IIRC (I didn't) it was ~~based~~ to replace the VAX, but 64 bit. I learned PDP-11 assembler at RPI, during their college program for high school students in about 1984. We hand assembled code and really got to know the architecture.

[koalahedron]

By the way, back to the original topic, a bare-bones machine like the KIM-1 also required a lot of hand assembly.

I guess everybody is gone from this post too, but I wonder if there is a fixed point corollary to Godwin's law--if you post enough off topic comments, you reach the original topic again. :)