On Tue, 2021-08-24 at 01:38 +0100, Tom Stepleton via cctalk wrote: IBM 1401 was a character-by-character machine, so most operations had costs proportional to field length. One especially expensive (but very useful) operation was "move characters and edit." Assuming a 17-character control word has been loaded to the destination, e.g. "$ ? , ?0. &CR&**" to edit a data field "00257426" with a "negative" zone bit on the low- order digit, producing "$ ?2,574.26 CR **" requires 41 memory accesses (including seven to fetch the instruction) -- 0.4715 milliseconds. See pages 41-43 at?http://www.bitsavers.org/pdf/ibm/1401/A24-1403-5_1401_Reference_Apr62.pdf On a machine where ?the "Expanded Print Edit Feature" was added, the instruction cost even more. For example, the "Floating Dollar Sign" moves the dollar sign to immediately to the left of the most significant digit. This (and asterisk protection) was to prevent somebody from adding digits between a left-justified dollar sign and leading digits on printed checks. The above edit would cost two more memory cycles. If the datum had had more leading zeroes, even more cycles would have been required. See pages 82-84. Another expensive instruction was the simpler "move characters and suppress zeros" instruction. See page 38.

The Prime 50 Series has a few candidates: 1. The procedure call instruction allocates a stack frame, saves the calling procedure's state, then calculates the effective address of the called procedure's Entry Control Block, from which it loads various register values. It then follows a chain of argument pointer assembly words following the instruction opcode to compute the locations of any arguments, storing those into the stack frame. In the process, it may follow chains of address indirection, perform ring weakening, and extend the stack into a new segment. The process of transferring argument addresses is interruptible, and will be resumed if necessary when the called procedure begins running. 2. A series of semaphore instructions manage serialization. A semaphore consists of a count field and a list of PCB addresses. The wait instruction increments the count and adds the PCB address to the list. A notify decrements the count and schedules the next winner. 3. Instructions related to interrupt handling and process exchange, and stack management. On 50 Series, the operating system sets up various scheduling and process control structures, and then the microode is responsible for selecting entries from scheduling queues, fetching needed state from a process control block, and starting execution of the new process. A process PCB is "on" one queue at a time, whether it be the idle list, or one of various priority level queues. First level interrupt handlers are responsible for notifying second level responders, which entails the microcode manipulating queues and other process control structures. 4. Register save and restore instructions may read or write up to 27 words from main RAM, depending on the save mask. 5. Decimal arithmetic, numeric edit, character string copy / fill / move / compare / translate / edit operations which may read or write up to 64k words of memory. The edit instructions run subprograms of somewhat arbitrary length, and opcodes including conditional copy, fill, insert, etc. De

On 8/23/21 5:38 PM, Tom Stepleton via cctalk wrote: Have a look at the instruction set for the STAR-100: http://bitsavers.org/pdf/cdc/cyber/cyber_200/60256000_STAR-100hw_Dec75.pdf I'm not quite sure if I've ever used a system with more instructions+variations. --Chuck

On Tue, 24 Aug 2021, Tom Stepleton via cctalk wrote: Does a virtual machine count? The BCPL compiler outputs code in few formats, one is called CINTCODE - Compact Intermediate Code. This is a bytecode designed to be interpreted by a suitable interpreter running on real hardware - in the way other bytecode systems work. It has a switch instruction. Actually, it has 2 - one is a linear search and one a binary chop. This is the definition of the binary chop one (because linear is too easy) SWB filler n dlab K1 L1 . . . Kn Ln This instruction is used when the range of case constants is too large for SWL to be economical. It performs the jump using a binary chop strategy. The quantities n, dlab, K1 to Kn and L1 to Ln are 16 bit half words aligned on 16 bit boundaries by the option filler byte. This instruction successively tests A with the case constants in the balanced binary tree given in the instruction. The tree is structured in a way similar to that used in heapsort with the children of the node at position i at positions 2i and 2i + 1. References to nodes beyond n are treated as null pointers. Within this tree, Ki is greater than all case constants in the tree rooted at position 2i, and less than those in the tree at 2i + 1. The search starts at position 1 and continues until a matching case constant is found or a null pointer is reached. If A is equal to some Ki then PC is set using the resolving half word Li , otherwise it uses the resolving half word dlab to jump to the default label. See Section 9.1.3 for details on how resolving half words are interpreted. Obviously it needs the compiler to output the right stuff, but there it is and I won't embarass myself with my implementation of it in 65c816 assembly code.. Gordon

On Mon, Aug 23, 2021 at 6:38 PM Tom Stepleton via cctalk < cctalk at classiccmp.org> wrote: The Intel iAPX 432 General Data Processor was, for its time (1981), one of the CISCiest processors, though these days the x86 has far outpaced it for sheer architectural complexity. A single GDP instruction could allocate a new object, which required dealing with a two-level object table as well as a storage resource object (SRO) and memory claim object (MCO). Another instruction could send a message object to a port object. The latter, in particular, could result in an arbitrary number of additional message sends, because each time a message is sent to a port, it could unblock a processor or a surrogate waiting to receive from that port, which would then cause a send of that object to its dispatching or forwarding port, which could cause another send, etc. Each send could only cause one additional send, so it was tail recursion and didn't require a stack or consume additional storage. 432 GDP instructions were bit-aligned in an instruction object, and occupied anywhere from 6 to 344 bits. The 432 GDP was too complex to be implemented on a single chip using ~1979 fab technology, so it was split into two chips, the 43201 Instruction Unit and the 43202 Execution Unit. In the 432's timeframe (1981-1985), I think only the IBM System/38 processor and perhaps the Fairchild Symbol might reasonably have been considered CISCier than the 432. The Fairchild Symbol was a one-off system that implemented a high level language compiler in HARDWARE (not microcode!). The 432 was a dismal failure. The P7 (code name) processor was to some degree a successor to the 432, though it was much different. The P7 processor became the BiiN processor, which was mostly a RISC but with some microcoded object instructions similar to those of the 432, and with tagged memory to provide a capability architecture. BiiN failed as well, but stripped of the object operations and memory tagging, the processor became the i960, which was successful as an embedded processor. (Later there were a few i960 variants that added back the memory tagging, and perhaps the object operations, and were sold for military use.) Although there are many reasons for the failures of both the 432 and the P7/BiiN processor, one they had in common was that their advanced architectural features were especially suited to high level languages, such as Ada, and very poorly suited to low level languages, such as C. As everyone knows, the world chose to standardize on C. The P7, and later the i960, could run C code perfectly well, but C code couldn't easily take advantage of the advanced architectural capabilities of the P7/BiiN processor.

On Mon, Aug 23, 2021 at 5:38 PM Tom Stepleton via cctalk < cctalk at classiccmp.org> wrote: I'll submit the Xerox Alto, with its extensions to the base DG Nova instruction set. It included "CONVERT", used to render font glyphs to the screen, and of course the legendary "BITBLT" for transferring bitmaps across arbitrary bit boundaries. Both of these were complicated operationst, and the latter revolutionized computer graphics... See p. 18 and 22 of http://bitsavers.org/pdf/xerox/alto/AltoHWRef.part1.pdf. (The Three Rivers PERQ included a similar "RASTEROP" instruction in its repertoire, which was similar to BITBLT but also allowed for various logical operations to be applied to the source and destination.) - Josh