![[Home]](/images/hat.png)
GC2
Introduction
GC-2 is NickGuggemos's second major attempt at designing a CPU. GC(Guggemos CPU)-2 is (RISC)? taken to the extreme. This is in contrast to GC1, which was a (CISC)?y design.
The GC-2 has not (yet) been physically implemented, but a simulator is presently being written. The GC-2 implements twelve instructions with one (fixed) addressing mode for each instruction. Registers are not visible to the user. All instructions and data exist in a single global address space.
Overview
Instructions and all registers are one word long, but instruction operands are inserted into the instruction stream. Effectively, this means that instructions may be more than one word long. Instructions that use operands will use the word(s) following the instruction as the operands and adjust the program counter accordingly. All instructions require one machine cycle to execute.
Word length is defined to be 12 bits long. This length was chosen because many CPLDs allocate 16 macro cells per function block (Using 12 macrocells for data in each function block leaves 4 macro cells for block state) and because 4kword (12 bits of address space provide for 4096 unique addresses) sram ICs are inexpensive. Also, having an "extra" four bits in at each address provides for future features such as parity and inhibiting write and execute ability on specific addresses (this is really just an excuse for wasting 25% of the bits in each word).
Memory Details
The GC-2 has one big (big is a relative term) memory space. Because GC-2 is not designed with performance as a primary concern, it lacks cache and does not have any concept of registers in the traditional sense--all system memory is assumed to be available without delay (as if it were just one big block of registers).
However, the GC-2 does have some "special" addresses, named:
| register | address | description |
| pc | 0x00 | program counter |
| op1 | 0x01 | ALU operand 1 |
| op2 | 0x02 | ALU operand 2 |
| dest | 0x03 | ALU result |
| ptr1 | 0x04 | pointer 1 (used as the source pointer for MOVEs) |
| ptr2 | 0x05 | pointer 2 (used as the destination pointer for MOVEs) |
| ptr3 | 0x06 | pointer 3 (used as the branch address for BRCHs) |
| imm | 0x07 | immediate data (loaded by LIM instruction) |
| stat | 0x08 | cpu status |
CPU status flags:
| flag | bit | description |
| of | 0 | overflow/underflow flag |
| carry | 1 | carry flag |
Instruction Details:
ALU instructions:
| instruction | op-code | description |
| ADD | 0x3 | (add op1 and op2) |
| SUB1 | 0x2 | (subtract op1 from op2) |
| SUB2 | 0x1 | (subtract op2 from op1) |
| OR | 0x4 | (bitwise logical or op1 and op2) |
| AND | 0x6 | (bitwise logical and op1 and op2) |
| XOR | 0x5 | (bitwise exclusive-or op1 and op2) |
These instructions do not use operands, but the ALU does use the values in op1 and op2. This is an important distiction, because it means that software must assign values to op1 and op2 before issuing an ALU instruction. It also means that multiple operations may be preformed on the same data without reloading the operands. The result of the instruction is written to dest.
The ALU opcodes are assigned such than the three least significant bits of the code can be directly fed into the ALU. This greatly simplifies instruction decoding.
Moving data:
| instruction | op-code | description |
| LP1 | 0xC | load operand to ptr1 |
| LP2 | 0xB | load operand to ptr2 |
| LIM | 0xA | load operand to imm |
| MOVE | 0x7 | move (ptr1) to (ptr2) |
LP1, LP2, and LIM are similar instructions. Each of these instructions takes one word as an operand which is written to a special address.
The MOVE instruction moves the value at the address in ptr1 and writes it at the address in ptr2.
Additional instrutions:
| instruction | op-code | description |
| NOP | 0x0 | do nothing |
| BRCH | 0x9 | branch to ptr3 if dest = 0 |
NOP(no operation) does not change the state of the processor, except the value of the PC. NOP does not take any operands.
BRCH does not take any operands. If the value of dest is not zero, BRCH acts as a NOP, otherwise BRCH writes the value of ptr3 to the PC. A meaningful value for ptr3 should be written by software before BRCH is issued. An unconditional branch is implemented by directly MOVEing a value to the PC.
Editorial/Software:
Complex Instructions
The machine language of the GC2 is very limited, so a set of pseudo instructions will be defined to handle "simple" operations. Several memory addresses will be defined as unusable (so they can safely be used by the psudo insructions, so the GC-2 might be thought of as having a number of multi-cycle instructions.
| Pseudoinstruction | Implementation |
| Bit shift left | add value to itself |
| Bit rotate left | add value to itself and add carry |
| compare for equality | XOR values |
| compare to zero for equality | XOR value against zero |
| compare magnitude | XOR values then XOR against 0x7FF |
| compare magnitue to zero | XOR value against zero then XOR against 0x7FF |
Software Development
An assembler and a simulator are being tested for the GC2. GC2Sim roughly conforms to the description listed above. GC2PLoader creates memory images suitable for execution by GC2Sim.
Final Notes
GC2 is very awkward to write software for. The awkwardness was a response to the difficulty of designing the part of the CPU that controls execution (the control section). GC3 can implement the GC2 binary interface, or almost any other.
