6

This question is NOT about single chip CPUs, but such that were built from many SSI/MSI logic ICs or using a bitslice configuration.

A 74F... or 74S... type TTL gate or flipflop, if you provide them with optimal conditions, will be able to handle 50..70 MHz raw signals; MECLIII and MECL10K went well into three-digit numbers here.

It seems most CPU designs favored CISCish instruction sets that accumulated a lot of propagation delay on the long combinatorial logic paths needed for that. Which usually limited the overall CPU clock to a small fraction of the "raw" speed of the ICs used. The CISC-ness preference is also understandable for most applications, since there likely was much more need for the assembly language specification being something that a human programmer could make sense of.

Were there exceptions (especially earlier or more radical), apart from the first Cray designs, where non-orthogonal instruction sets that kept the propagation delays short - and/or pipelining - were used?

  • What CPU designs with discrete TTL chips with "CISCish ISA" are you referring to? All such designs I can think of right now used microcode (Xerox Alto, Symbolics, Dietz etc.), so clock speed is geared to microcode execution. But of course microcode makes a CISCish ISA the obvious choice. Earlier discrete CPUs (e.g. PDP-8) didn't even have a "proper clock"; opcode execution times wasn't given as multiple of some clock cycle, but varied a lot. – dirkt Apr 14 '18 at 18:55
  • Is VAX-11/7xx microcoded? It is certainly CISC... – rackandboneman Apr 14 '18 at 21:03
  • The VAX-11/780 is microcoded and uses a discrete TTL CPU, the "Microprogramming Tools User's Guide" is at bitsavers. Actually, I would expect all CISC ISA's to be microcoded, no matter if discrete or on a single-chip - implementing CISC in any other way would be very difficult. – dirkt Apr 15 '18 at 16:45
11

It seems most CPU designs favored CISCish instruction sets that accumulated a lot of propagation delay on the long combinatorial logic paths needed for that. Which usually limited the overall CPU clock to a small fraction of the "raw" speed of the ICs used.

First of all, CISC doesn't require longer combinatorial delay. If at all, it usually results in more clock cycles per instruction.

Further when it comes to more complex combinatorial logic it's rather the other way arround. With a monotone clock, it's period must be as long or longer than the slowest element used. So if there are for example three stages with 5 ns, but one with 20ns, the system clock can't go past 50 MHz. An instruction going thru these 4 stages will take 80ns. Now if these 4 elements are part of a single 'complex' stage defined by their combinatorial speed, it will only take 35ns for an instruction to pass - more than double the speed of single stages.

Creating many small stages is only a benefit if they are part of a pipeline - here more than one instruction can be in processing at the same time. While a single instruction will still take the same (often more) execution time, they work more thna one instruction can be in execution, thus increasign effective thruput.

The CISC-ness preference is also understandable for most applications, since there likely was much more need for the assembly language specification being something that a human programmer could make sense of.

Not realy. Instruction sets where always made with a focus on a possible machine structure and the task to be solved, pleasing programmers always came second.

As shown beore, the power of CISC comes from higher speed. This is even more true when considering that Memory of early machines - until the mid 1970s - was magnetic core. Core started out with cycle times of 6 to 9 microseconds. Even a true high speed machine like the CDC 6600 only managed a cycle time of arround 1 us. It didn't improve much from there on. the last generations arround 1975 where still 0.6 us or above. 600 ns is something where quite a lot of computation can be done.

Were there exceptions (especially earlier or more radical), apart from the first Cray designs, where non-orthogonal instruction sets that kept the propagation delays short - and/or pipelining - were used?

It wouldn't have made any sense. The bottleneck wasn't command execution but memory read. Thus shorter but more complex intructions where the way to increase performance.

The CDC 6600 is in fact a great example how to work arround the memory problem. While the CPU clock was 10 MHz, the memory cycle was 1 us (1 Mhz). Similar the PPUs. There where 10 of them, each operating with a 1 MHz clock, but interleaved. To feed all of this memory was also build up as 32 interleaved blocks or 4096 words with 12 Bit each. Each PPUs could get each one word per turn as long a it was mostly consecutive. Well, it wasn't always, and thruput was quit dependent on the way instruction stream (and data) was aranged

So while the CDC was already somewhat RISCy, it was way more limited by memory speed than gate speed or clock rate. The whole idea behind this rather extreme design was to squeeze as much action arround the slow memory. Other, much simpler design where just condemed to wait for the momory most of the time.

And it didn't feature any pipeline at all. Especially not one having different instructions in different stages of competion - like you question may assume.


Now while the next step, the 7600 did crank up clock speed to 35 MHz, its memory was in fact slower with about 1.4us. This got leveled by a more sopisticated structure, now including a pipeline - quite unlike a 'classic' instruction pipeline, more like a reordering buffer to find instructions that can be issued to some function unit in parallel. But even with this much more sophisticated structure, memory was still the bottleneck, not any clock speed or instruction set.

  • "CISC doesn't require longer combinatorial delay". Yep, it typically does, comparing apples of the day with other apples of the day. One of the original pushes for RISC over CISC was fewer data sources and simpler datapaths leading to shorter gate paths and a higher clock rate. Have a look into the logic designs for each, you'll see why. Speed through simplicity was one of the key benefits for RISC, along with simpler circuit by removing rarely-used complex sequence instructions, with code density one of the losses. – TonyM Apr 13 '18 at 9:11
  • But not necessarily longer or more complex combinatorial logic. It's not related. Thak a CISC instruction like incrementing a memory word and the equal three instructions of a RISC implementation. Both constist of the same three steps (Load, Inrement and Store). Each of these will run in sequence. On a CISC system controlled by a microprogram within a single instruction, on a RISC due three seperate instructions. The funcional units and their gate path are quite the same. Aren't they? The same point can be made for next to any other instruction. An adder is an adder, no mater if RISC or CISC – Raffzahn Apr 13 '18 at 9:24
  • @TonyM: Many vintage processors that required many clocks per instruction (e.g. the Z80) did so not because they were CISC, but because they had limited resources for handling arithmetic or moving data around. The Z80 had a 4-bit full-featured ALU and a 16-bit increment/decrement unit. Parts of the Z80's instruction set were a poor fit for the available resources (e.g. LDIR has to test all four nybbles of BC separately to see if they were equal to zero; making it decrement B only would have been faster), but the chip doesn't waste many cycles "deciding what to do". – supercat Nov 26 '18 at 21:33
4

A 74F... or 74S... type TTL gate or flipflop ... will be able to handle 50..70 MHz raw signals

74F and especially 74S are consuming a lot of power. Integrating them into CPU core is a problematic task. Heat dissipation increases with the speed of operation (switching speed), thus there must be a trade-off between size of the die, performance of the core and reliability of the chip and system in overall.

It seems most CPU designs favored CISCish instruction sets

I think there're simple reasons for it - scarce memory (RAM or ROM) and their organization in 8-bits, when you can fit CISC instructions in them; and performance of periphery - those RAMs, ROMs and I/O. The way microprocessor design historically moved may be considered to be kind of optimal, with RISC forking for special computational tasks and when technology allowed it to be feasible.

where non-orthogonal instruction sets that kept the propagation delays short - and/or pipelining - were used?

I can give you mid-80s example - Yamaha V9938 VDP, the upgraded version of TMS99x8 video chip. While is it not microprocessor, it is using data pipelining and has very effective and efficient timing in managing its RAM and the CPU requests.

  • 2
    "pre microprocessor CPUs", so no integrating into single chips ... and yes, the reasons why it MOSTLY was done the "slower" way are clear. And switching speed has comparatively little bearing on power dissipation with the bipolar logic we mention. – rackandboneman Apr 12 '18 at 6:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.