Showing posts with label mips. Show all posts
Showing posts with label mips. Show all posts

2015-10-13

MIPS, part 4: Branches and jumps

Conditional branches and unconditional jumps are the last piece of the puzzle. They allow programs to make decisions, skip over code, and call subroutines.

You'll want to read MIPS part 1: Registers and calling convention and MIPS part 2: ALU instructions first.

The branch delay slot (#delay)

An important feature of the MIPS architecture is that the instruction following branches and jumps is executed before the target instruction is. This is known as the branch delay slot, or sometimes delay slot for short.

2015-10-05

MIPS, part 3: Memory access instructions

Even on MIPS, with its plentiful registers, fast memory access is essential.

To make address resolution simpler for the processor, MIPS I only defines one addressing mode: register plus signed 16-bit offset. This allows it to resolve addresses in one cycle, no more, no less.

Memory load requests are first brought up to the data cache, which may service the load immediately. If the data cache doesn't have the requested data, one whole cache line of data is read using a memory burst command.

Memory store requests are first brought up to the store buffer. The cache line surrounding the write has to be loaded in order to preserve the surrounding bytes, but the store buffer allows more operations to be carried out while waiting for the cache line to be loaded. Then, the data is only written when the data cache line needs to be evicted for another memory access, using a memory burst command.

This setup can be bypassed if needed by using uncached memory access. However, most games, and most code within those games, will be using cached accesses. The data cache is very efficient for these accesses.

You'll want to read MIPS part 1: Registers and calling convention first.

MIPS, part 2: ALU instructions

Here are some common instructions in MIPS I and their effects. Some of those effects are important for optimization purposes, so they'll be described in greater detail.

These instructions are common on the Sony PlayStation. Counter-intuitively, they are also much more common than 64-bit instructions on the Nintendo 64: because its data bus is 32-bit, loading and storing 64-bit quantities to memory would take twice as long, so most games were written with 32-bit data and instructions only. Some games could even be run on a pure 32-bit MIPS processor!

You'll want to read MIPS part 1: Registers and calling convention first.

2015-09-25

MIPS, part 1: Registers and calling convention

In 1994 and 1995, Sony released its PlayStation console. It would soon be followed, in 1996 and 1997, by Nintendo's Nintendo 64 console. What both of them had in common, as briefly described in the entry "Why Old Games, New Tech?", was that they both contained processors running the MIPS architecture.

The MIPS architecture was a very large departure from the previous generation of consoles, sometimes known as the 16-bit era, due to the heavy focus on bits: