Where does the MIPS opcode lookup table exist?

Question

We are currently covering the MIPS architecture. I am gaining an understanding of computer architecture and MIPS assembly, which is good.

However, I tried googling this answer but I have not found a suitable answer. I am confused from a layer below the ISA and micro architecture design. Where does the MIPS opcode lookup table exist, say in a specific location in memory ? How are variable and variable types represented as in MIPS (since the format of the variable type or variables in binary are not specified in the MIPS opcode, rather just the MIPS assembly instructions). Thank you.

EDIT: Is the CPU of it's lookup table (or is the opcode table just a useful reference for programmers and that this table doesn't exist in the hardware)? Or is the MIPS hardware configured so that it acts per the MIPS opcode?

Answer 1

If you want to look up MIPS assembly opcodes (aka MIPS "instruction set"), you should refer to the MIPS documentation. For example:

http://www.mrc.uidaho.edu/mrc/people/jff/digital/MIPSir.html

The MIPS hardware implements the instruction set. There is no "lookup table" per se in the CPU.

The specific part of the CPU responsible is the "instruction decoder", part of the "control unit". Here's a short animation that gives you more details about the instruction Fetch/Decode/Execute cycle:

https://prezi.com/bz0fc-00otft/computer-architecture-registers-and-the-fetch-execute-cycle/

Answer 2

Opcode tables actually don't exist anywhere (except in some architectures that have microcode... explained below). The way that they work is that the opcodes for a microprocessor are interpreted by a series of digital circuits that implement a state machine. These circuits are called the control unit. The control unit is responsible for enabling memory reads, writes, controlling the ALU etc to create the behavior desired for a specific opcode.

An example. Suppose you issue an opcode for loading data from an immediate instruction to a register. This opcode will trigger the state machine to increment the program counter by one and issue a memory read, enabling internal buses so that the read appears on the input line of the latches for the specific regester (all controled by internal buffer lines). When the clock signal hits, the location of ram at the incremented program counter is on the data bus and is read into the register. Then the controller moves onto the next state, which is to fetch the next opcode.

How these states are encoded into the circuitry is by logic gates that assert signals at the correct time based on specific inputs to the control register. Somtimes this was implemented as a ROM, othertimes as logic circuits. On older microprocessors such as the 6502 this had an interesting side effect. There were several undefined opcodes that were not designed to do anything, however when issuing these opcodes, they would trigger functionality of the controller that the designers didn't intend, because these undefined opcodes would appear to be part of a specific opcode for one part of the control unit and another part of the opcode will be interpreted differently for yet another aspect of the control unit. This lead to undefined behavior, some of which was useful and was actually utilized in code. Others were useless and would halt the processor or mbe unstable.

Architectures that utilize microcode, which is about every modern architecture, read the opcode and have a table with a specific set of internal instructions for implementing that opcode. These instructions would be comparable to a reduced instruction set for the microprocessor, but not directly accessible by the programmer. At this point, these smaller microcode instructions behave just like the traditional architectures in that they would be interpreted by a small state machine to control the behavior of the microprocessor.

An interesting feature of microcode is that the CPU engineers can update the functionality of the processor with microcode table updates. Intel often does this if a bug is found or better way of implementing an opcode is discovered.

For more information on this, see:

http://www.pagetable.com/?p=39

http://en.wikipedia.org/wiki/Control_unit#Hardwired_control_unit

https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Microcode.html

Answer 3

Some instruction sets are microcoded, the 6502, some maybe all x86, etc. but mips, arm and others (RISC, but the line between RISC and CISC is pretty fuzzy), are not microcoded. Even those that are microcoded we dont generally get access to the microcode itself, our interface is strictly front, door ISA. The microcode if there is some would need to either be in an on chip/package (non volatile) rom or downloaded to ram on boot from some rom somewhere. Based on news articles many years ago, x86 and/or amd may have the ability to have the burned in microcode modified by the bios on boot.

As far as mips goes it is way to generic of a term, because it is a teaching architecture, every Nth computer engineer has made their own implementation, so there are tens to hundreds of thousands of mips implementations in addition to however many real implementations from MIPS itself. And sure, one/many of the educational versions done by a class or studied by a class, etc may be microcoded just for the sake of teaching microcoding. And naturally if those exist the microcode encoding would itself be an invention of that implementation as there isnt a universal microcode instruction set that everyone uses...