Extremely CISC instructions

-----Original Message----- From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Tom Stepleton via cctalk Sent: 24 August 2021 01:39 To: cctalk at classiccmp.org Subject: Extremely CISC instructions Hello, For the sake of illustration to folks who are not necessarily used to thinking about what computers do at the machine code level, I'm interested in collecting examples of single instructions for any CPU architecture that are unusually prolific in one way or another. This request is highly underconstrained, so I have to rely on peoples' good taste to determine what counts as "interesting" here. Perhaps a whole lot of different kinds of work or lots of different resources accessed is what I'm after. I expect these kinds of "busy" instructions were more common in architectures that are now less common, so perhaps this list is a good place to ask. For example, if we're thinking "number of times an item is retrieved from RAM", then any application of the x86 string instructions that could walk over memory for a while perhaps aren't so interesting. By contrast, by my count, the NS32000 series instruction "addw ext(4), ext(7)" requires at least five separate noncontiguous retrievals just to fetch the arguments into the ALU. (Note that I'm not differentiating between different sizes of data here: loading a 16-bit item and loading a 32-bit address both count as a "retrieval" in this example.) Instructions that are simply lengthy might be interesting, but not always: long literals or lots of redundant prefixes on x86 aren't that impressive, for example. Number of registers read or modified might be good too, but just saving or loading for the sake of subroutine calls (e.g. "movem.l r0-r7/a0-a6,-(sp)" on the 68k) seems pretty pedestrian. Other criteria may seem worthwhile; I trust peoples' judgement on this. Although I don't know it well, I suspect VAX will place well in one way or another. But to give an example of a candidate instruction that's prolific in a way I find more noteworthy, I'll go back to the NS32k and offer addw ext(4)+6[r1:w], ext(7)+12[r2:w] which in order to get its arguments (I think) requires the five retrievals already mentioned and adds two shifts and four additions to the bill. I think this statement reads: "Add the r1'th word counting from 6 bytes past the fourth address in the current module's link table to the r2'th word counting from 12 bytes past the seventh address in the current module's link table". That's a mouthful --- it takes a lot of work to describe what that one line does! Maybe that's what I'm hoping to share with people. I hope this is interesting to discuss, --Tom