Advantages and disadvantages of microcoded vs hardcoded architectures

Problem Detail: 

Preamble

I can't understand what are the advantages and disadvantages of microcoded processor architecture and hardcoded one.
Basically what I understood is that a microcode architecture divides an istruction in more microinstructions. I didn't found much documentation written in a simple way (too much complicated) so I'm asking you: what are the advantages and disadvantages of each one?
Due to the large amount of aspect of this "subject", I'll recap the question into three main aspects:

Question (architectural point of view)

A microcoded architecture should semplify the design of each instruction, it means that it's do much more difficoult to design a full hard coded processor?
Or maybe hardcoded archtecture is suitable for microcontrollers or smaller design?

Question (performance point of view)

Wikipedia (not the most reliable source, I know) says that a microcoded architecture is a little slower than an hardcoded one. It also says that microinstruction are used to build complex instruction, but these are not commonly used because programmers prefer high level languages, and compilers prefer using simpler but faster instruction.
From this point of view, is still necessary to design microcoded processor?

Question (functional point of view)

If microcoded archtectures help the creation of complex instruction (= easier assembly development?), hardcoded ones help programmers in any way during their work? This seems a stupid question but I think it's not.
Looking at this site of assembly game programmers (I hope I can post that link, FAQ says to share your research), one guy says that HuC6280 processor has the best instruction set because:

Fav[ourite]: HuC6280.
Basically a 65CS02 set (Rockwell's added instructions).
Optimizing is soo much fun. There are some super crazy optimizations for this style chip out there.
I know people will fight to the death (or possibly argue) that it's not RISC, but it definitely had some precusor ideas of RISC.
A very small, simple, but fast instruction set (hard coded, not microcoded), a large set of 128 16bit address registers (also halved as 256 8bit data registers).
The immediate operand instructions are very fast and lend themselves perfectly for self modifying code.
The downside is the small logical address range of the PC. All optimizations have to be made local and very specific.
Look up tables (LUTs) need to be organized accordingly (and interleaved for 16bit and wider data elements).
One thing I never understood is why they never implemented immediate operand opcodes as 1 cycle instead of 2, since the chip would perform a fetch cycle while operating an ALU operation on other opcodes.
Same for implied instructions (flag changing).

He seems to be very excited about that architecture. One point to hardcoded design?
However, I found that HuC6280 is an 8bit processor, it is much much simplier than modern ones. It means that hardcoded would be preferrable if its design wasn't so hard?
EDIT: He also quote self modifying code, which is not commonly used today (due to high level programming maybe) but for assembly programmer is quite an important feature.

Examples

I know that this is an hard question, explanation might be long. If you (guy with much more experience than me) want to answer, may you add some example of hardcoded architecture? It would be much appreciated. Both modern and deprecated are ok


And thanks for reading all this poem

Asked By : Ignus

Answered By : Wandering Logic

The distinction between "microcoded" and "hardcoded" multi-cycle control units is a relatively small implementation detail. The distinction was more important in the 1950s when people were inventing new implementation techniques for state machines. In modern processor design there are much more important implementation distinctions, like how much pipelining and instruction overlap you are going to try to achieve, whether you are going to speculatively execute instructions, and whether you are going to try to schedule instructions out-of-order.

That said, here's the distinction: We divide the design into datapath and control. Here's the picture of the MIC-1 from Tanenbaum's Computer Organization book. (The image is by Suyog.karnawat, from Wikimedia commons.) Everything in the design is the datapath except the box in the upper right hand side that says "Instruction decoder and control logic."

The "Insruction decoder and control logic" box is a finite state machine. The datapath in this example is very simple, with only a single bus, so even an instruction to add two registers and put the result in a third register takes multiple cycles (each of which corresponds to a state in the state machine.)

Each instruction goes through the following steps/states (each of which takes a cycle)

1. move the PC (Program Counter) to the MAR (Memory Address Register)
2. assert the controls to perform a load from the memory bus
3. eventually the memory will return the requested data (which corresponds to the next instruction) and put it in the MDR (Memory Data Register)

4. move the instruction from the MDR to the IR (Instruction Register). At this point the instruction gets decoded and we figure out what to do with it. In this case it's an add operation so we know we need to:

5. move Ra to the X register

6. put Rb on the bus (so that it will go to the B input of the ALU) assert the ALU control lines and Mux select appropriately to do an add operation, the result of which will get saved in register Y

7. Move Y to the Rc register, and then every non-branch instruction ends by incrementing the program counter:

8. Put the PC on the bus, set up the ALU to increment (Select the MUX to put constant 1 on the A input and set up the ALU to Add) so that PC+1 will get saved in the Y register

9. Move the Y register back to PC

So 9 state transitions to perform a simple add instruction.

So the "Instruction decoder and control logic" is a finite state machine with inputs from the IR register, outputs are the control signals, and there must be some flip-flops inside to represent the state of the state machine. But there are lots and lots of ways to implement a state machine.

1. $\lceil \log_2 N \rceil$ flip-flops (where $N$ is the number of states) and a lot of combinational logic (to calculate the control signals and next state).
2. $N$ flip-flops with one-hot encoding and a bunch of combinational logic (usually less than with option A, but a lot.)
3. Somewhere between $\lceil \log_2 N \rceil$ and $N$ flip-flops with some combinational logic of intermediate complexity.

And the combinational logic for the control signals and next state functions can be implemented any number of ways:

1. As NAND gates reduced (using Quine-McCluskey, or whatever) to sum-of-products form.
2. As NAND gates reduced to some relatively efficient multiple-level circuit. (This is probably what people think they mean when they talk about "hardwired control.")
3. A design using Multiplexers for the combinational logic
4. A design using Programmable logic arrays (although I don't know if you can even buy these anymore.)
5. A design where the combinational logic is implemented with a ROM. (This is probably what people think they mean when they talk about "microcoded control.") The ROM might be a EEPROM so that it is somewhat easier to modify if you find a bug.

ROMs can get really huge if you're not careful. For example a ROM-based design would almost always use $\lceil \log_2 N \rceil$ flip-flops, because making the state wider also makes it sparser, which is sometimes good for gates but not for ROMs. Also, you would only use the opcode bits as part of the address to the ROM, not the register specifiers and such.

Finally with ROMs you might choose to make the microcode word wide (the microcode word produces the entire set of bits for the control signals) or narrow (the microcode word chooses one of a smaller number of possible control signal combinations and then there's a second ROM that translates from that smaller number to the actual required control signals.

So the distinction between "hardcoded" and "microcoded" is only one very small decision that needs to be made among hundreds of design decisions. And it's certainly not the most important one. (For example, you could choose to put a second bus on the datapath, which would enable you to perform some instructions with a lot less cycles.)

Best Answer from StackOverflow

Question Source : http://cs.stackexchange.com/questions/28388