MIPS Assembly: Difference between revisions

no edit summary
(Created page with "Writing MIPS assembly is not necessary to make a Nintendo 64 game. You can make a game entirely using C, C++, or any other programming language you can get working on the Nint...")
 
No edit summary
Line 1:
Writing MIPS assembly is not necessary to make a Nintendo 64 game. You can make a game entirely using C, C++, or any other programming language you can get working on the Nintendo 64. However, you may want to be able to read MIPS assembly from time to time, and you may want to write small snippets of MIPS assembly.
 
This page will not teach you MIPS assembly, but just give you the highlights. See also [[Instruction Cheatsheet]], for a list of instructions.
 
= Learning MIPS Assembly =
Line 21:
In most other processors, you don’t have to know about these things, because the hazards are protected by interlocks. MIPS has some common hazards which are not protected by interlocks, so you must structure your assembly code to avoid the hazards. In some cases, the assembler can help you by '''automatically reordering the instructions''' to avoid hazards.
 
'''Warning:''' The MIPS assemblerassemblers (except Bass) will reorder your instructions by default. This means that the assembly you write will not exactly match what you get when you disassemble the code afterwards. You can disable this with <code>.set noreorder</code>, or you can simply let the MIPS assembler make your job easier.
 
Three hazards you might commonly encounter on the VR4300 are the branch delay slot, the integer multiply and division instructions, and the floating-point multiply instruction (VR4300 multiply bug). There are other hazards that you would only typically see in kernel code, like changes to the TLB—refer to the CPU manual if you are doing anything special.