Scott Mueller's Upgrading and Repairing Forum

When I worked for IBM, I was the programmer on a team with engineers who were developing a new microprocessor. My job was to develop the microcode for the processor. My work would allow another programmer to write object code that would be translated into microcode for execution. Of course, the programmer wouldn't write in 1s and 0s. The programmer would write in assembler language.

In my A+ classes I talk about microcode, object code and assembler language. My question is whether RISC, CISC and EPIC would be considered microcode or object/assembler code. CISC seems extremely detailed for object code. On the other hand, RISC seems very broad in scope for microcode.

When I describe microcode, I tell the students that for me to walk across the room, the microcode would say lift right leg, swing leg forward, lean into the direction of the movement, drop foot to the floor, etc. -- doing the same with the left leg. Whereas, object code would say walk across the room.

Am I full of hot air or am I right on? Thanks for your continued help.

CISC and RISC are architectures, not code. They don't really have much meaning in practicality since they do not exist in pure form, especially not for PCs. However you could say that in theory, so-called CISC processor instructions (binary or object code) are closer to microcode than are so-called RISC instructions. But since there are no clear definitions of any of this, it is all a matter of semantics.



That analogy accurately describes RISC type vs. CISC type object/assembler code. I would extend that analogy to include microcode as the internal signals sent by the brain through the nervous system to lift the leg, drop the foot, etc. In other words, microcode refers to the *internal* instructions hidden deep inside the CPU to make the actual instructions work. CPU instructions are the object/assembler code, while microcode is the internal code hidden deep inside the chip that tells the processor *how* to execute the instructions.

You might find it interesting to note that Intel CPUs based on the P6 and P7 "NetBurst" architecture have *reprogrammable* microcode, which actually allows fixes for certain bugs or "errata" on the fly. These microcode updates are stored in the motherboard BIOS, and are automatically loaded into the CPU every time the system is turned on. Intel has a microcode update utility to update the CPU microcode stored in the BIOS, however this utility is only offered to registered resellers/system builders. In general, the motherboard mfrs. include the latest microcode updates in newer versions of their motherboard BIOS, making the Processor Update Utility somewhat moot for the average user. For more info on these microcode updates see:

Product Training Module - Processor Update Utility
http://tinyurl.com/2assqu

Note that AMD processors as well as the newer Core architecture processors from Intel have fixed microcode, however bugs in these chips can often still be worked around with BIOS updates. This is another good reason to stay up to date with the latest BIOS for a given motherboard.

Scott.

Thanks, Scott, for the reply.

OK, my analogy is good if I read you right and CISC instructions are closer to the microcode I describe to my students if I read you right. How would you go about explaining the difference between CISC and RISC. Every book I pick up talks about them as instruction sets and some books even give examples of the instructions. I want to make sure that my students are able to answer correctly any questions regarding these "architectures" that might appear on the exams.

I look forward to your reply.

Vince

Scott,

I just got out your book and read up on CISC and RISC again. If I get the drift from your light bulb analogy, In a CISC architecture processor, there are fewer instructions, but they are more complex and accomplish more in a cycle than a RISC machine. On the other hand, a RISC machine has more instructions but they are incremental in nature and thus the processor takes more cycles to accomplish the same task as a CISC machine. Am I getting close?

Thanks.

Vince

You have it backwards. I think you are confusing the number of instructions that might be used in a given program (or to accomplish a given task) vs. the total number of instructions in the processor's instruction set.

RISC technology processors generally have an instruction set with far *fewer* instructions than CISC technology processors.

Example:

Motorola released the 68020 in 1984. The 68020 was the first 32-bit chip in the Motorola 68x family of processors, which were considered RISC technology. The 68020 featured an instruction set with 113 total instructions. Apple's Mac systems were originally based on 68x processors.

Intel released the 80386 in 1985. The 386 was the first 32-bit chip in the Intel x86 family of processors, which were considered CISC technology. The 80386 featured an instruction set with 268 total instructions. PCs have always been based on x86 processors.

In 1989 the 486 processor added 93 floating point instructions to the set, increasing the number of x86 instructions to 361. The P6 (Pentium Pro/II/III), P7 (Pentium 4/Netburst) and Core architecture processors added *hundreds* of additional instructions (MMX/SSE, 64-bit, Virtual), bringing the total to *574* instructions in the latest implementations of the x86 instruction set.

Another analogy for RISC/CISC:

RISC = Alphabet. There are only 26 symbols, which normally have to be strung together in lengthy combinations to produce words, sentences or thoughts.

CISC = Kanji. There are thousands of symbols, with many if not most individual symbols having the meaning of entire words, sentences or thoughts.

Continuing with this analogy one might say that a single symbol (instruction) in Kanji (CISC) carries a meaning that might take tens or hundreds of symbols (instructions) in our simple alphabet (RISC).

Programs written to run on CISC architecture processors would naturally be shorter (i.e. have fewer overall steps or instructions) than those written to run on RISC architecture processors. However, even though a RISC type program might be longer (more instructions), since each step (instruction) is simpler, the theory is that the indidual steps would be quicker to execute.

Thus by theoretical comparison CISC type programs are shorter, with complex individual instructions (chosen from a huge set) that take longer to process, while RISC type programs are longer, with simple individual instructions (chosen from a small set) taking less time to process.

In the end, both programs finish in about the same amount of time. <g>

Actually, in practice CISC has proven to be the winning architecture performance-wise, which has a lot to do with why it is not only significantly more popular, but also why Apple (wisely) switched to Intel x86 processors for its Mac systems.

Hope this helps, Scott.

AhHa! I take it when you talk "programs", you are talking about "object code or assembler" programs -- not the actual microcode that runs underneath it. Your analogy to Alphabet and Kanji is the object/assembler code instructions rather than the underlying microcode? Would the underlying microcode be the same for both CISC and RISC or considerably different? However you answer, may I use the analogy in your book and the information in this thread to create a handout for my students? I would run it by you before I published it (as well as give credit to you) just to make sure I've got it right.

Thanks.

Vince Horenkamp

The important thing to note is that programmers writing software only know about object/assembler code. The microcode involved would depend entirely on the specific internal design and circuitry of the processor in question. In other words, nobody but the chip designers would know what is really going on at the microcode level, and they are probably not allowed to tell. Chips with different internal schematics and designs would probably have equally different microcode, irrespective of whether they were considered RISC, CISC, or some variation thereof.

In the original analogy (giving instructions to a person), I would equate microcode to the nerve impulses sent by the person's brain to their muscles as they complete the task. Whether you give the person complex or simple instructions to perform a given task, the nerve impulses sent by their brain to their muscles would be pretty much the same for a given task. However if you gave the same task to an alien creature with a completely different physiology, the specifics about how their brain and muscles communicate might be completely different.

In the Alphabet/Kanji analogy, I'd equate microcode to the individual strokes of pen and ink on paper.

You may use my analogies as long as credit is given to the source. Thanks for asking, Scott.