|
I'm a bit confused between the microprogramming level vs machine language level. For example:
|
|||||||||||||
|
|
Micro-code is another level of abstraction beyond machine code. The actual CPU is running microcode, and a translation engine converts machine code into microcode on the fly. This is done for a variety of reasons, including faster, smaller processors, easier to create a complex processor with less debugging, and for backwards compatibility. For instance, the x86 instruction set contains some string processing instructions that are rarely used. However, to remain backwards compatible, they must still be available in modern x86 processors. Rather than hardwiring an execution path for these instructions, they are converted into microcode and executed. This saves silicon, while still remaining backwards compatible.
The machine code resides in the cache (after being pulled from RAM). The micro code resides in a micro code cache, depending on the particular machine architecture. The cache may only be large enough to hold enough microcode to hold the converted microcode from the largest possible machine code instruction, or it may be a larger cache that stores the converted results of many machine codes so that it doesn't need to reconvert all the machine code on each iteration for small loops. In some architectures the converted microcode isn't stored anywhere - the fetch/translate unit simply spits out a series of microcode instructions based on the currently executing machine code. In this case the microcode is executing from a ROM of some sort, and the machine code is essentially an index into the ROM - pointing to the series of microcode instructions that must be run in order to fully execute the machine code instruction.
Machine code and assembly code, in general are 1:1 mapped to assembly instructions. It depends on the assembler. High level assemblers may have a large set of macros that allow one to write one line of assembly code and the assembler will produce several machine codes. But in general "pure" assembly language can be converted directly into machine code using the instruction set table in the processor's manual. I'm not sure what you mean by "true-op instructions" though. Perhaps you can explain the reference.
The format of both machine code and microcode are defined by the processor architecture. |
|||||
|
|
Many processors are driven by a state machine whose transition sequence is affected by the instructions being executed. Microcode "instructions" often specify the interactions among various registers and buses in a way which would not be visible to a programmer. For example, a microcode instruction for an 8-bit CPU in state #1 might specify that output enables for both halves of the program counter should be active (causing the program counter to be output on the upper and lower internal address bus), the program-counter-increment signal should be active, the external address latch signals should be active (so the external address bus will track the internal one) and the RAM-read signal should be active, and the controller should switch to state #2. In state #2, the external data bus should feed to the internal primary data bus, and the instruction register, which reads from that bus, should be loaded. The program counter should as before be output on both halves of the address bus, and another RAM-read issued. Bits 5-7 of the instruction register should be loaded into bits 0-2 of the state controller, bit 3 of the state register should be set unless bits 1-7 of the instruction register are all set, and other bits of the state register should be clear, the net result being that the next state will be #7-#15. Note that microcode isn't really defined in terms of instructions, but rather in terms of combinations of control signals. The hardware will not be set up to allow general-purpose instructions in microcode, but rather to load or output various registers from/to the buses on which they sit, or connect different buses to each other, and use various bits or combinations thereof to select different states. Many aspects of the design will be hard-wired (e.g. opcodes FE and FF might be special-cased in hardware rather than in microcode). The idea with microcode isn't to run programs, but to replace logic. |
|||
|
|
|
Basically, microcode expands a limited CPU instruction set to contain higher level instructions that would be cumbersome to implement in hardware, but relatively easy to build with existing instructions. Microcode allows a processor with a small instruction set to function like one with a larger instruction set. Lets say you're working with a MARIE instruction set and you would like an Add x,y function, but the architecture only allows a Add x (which just adds what's currently in the register to x) so you add a microcode instruction: Now when your machine language code says: it looks up the ADD function you added to ROM (your microcode) and executes it. This is great because it increases your instruction set, which allows more readable machine code, and since your microcode is stored in ROM, it's also a little faster than calling the LOAD and ADD from RAM. I used to work at a company that actually wrote microcode to perform custom measurements at very high speeds on their older systems. However, with the advances in FPGAs they have switched over to those, which are much faster (since you actually are implementing the "custom instructions" in hardware instead of ROM). |
||||
|
|
