MIPS MIPS32 74K Series, Programming Manual

Page: 67 / 156

Chapter 5
Programming the MIPS32® 74K™ Core Family, Revision 02.14 67
Kernel-mode (OS) programming and Release 2 of the
MIPS32® Architecture
[MIPS32] tells you how to write OS code which is portable across all compliant CPUs. Most OS code should be
CPU-independent, and we won’t tell you how to write it here. But release 2 of the MIPS32 Specification [MIPS32]
introduced a few new optional features which are not yet well known, so are worth describing here:
• A better way of managing software-visible pipeline and hardware delays associated with CP0 programming in
Section 5.1, "Hazard barrier instructions" .
• New interrupt facilities described in Section 5.2, "MIPS32® Architecture Release 2 - enhanced interrupt
system(s)" ;
• That led on to Section 5.3.1 “Summary of exception entry points” : where do exceptions go, and what options are
available?
• The ability to use one or more extra sets of registers (“shadow sets”) to reduce context-saving overhead in inter-
rupt handlers, in
Section 5.4, "Shadow registers" .
• How to get at any power-saving features, in Section 5.5, "Saving Power"
• How to control user-privilege access to “hardware registers”, in Section 5.6 “The HWREna register - Control
user rdhwr access” .
5.1 Hazard barrier instructions
When privileged “CP0” instructions change the machine state, you can get unexpected behavior if an effect is
deferred out of its normal instruction sequence. But that can happen because the relevant control register only gets
written some way down the pipeline, or because the changes it makes are sensed by other instructions early in their
pipeline sequence: this is called a CP0 hazard.
Your 74K family core offers you the option of removing many CP0 hazards by setting the
Config7[IHB]
option bit as
described in the notes to Table B.3 . But you might be better off sticking to the rules described in [MIPS32] , so your
code will run on any compliant CPU: it may be best to see this feature as the way to rescue legacy code.
It’s possible to get hazards in user mode code too, and many of the instructions described here are not solely for ker-
nel-privilege code. But they’re most often met around CP0 read/writes, so they found their way to this chapter.
Traditionally, MIPS CPUs left the kernel/low-level software engineer with the job of designing sequences which are
guaranteed to run correctly, usually by padding the dangerous operation with enough
nop
or
ssnop
instructions.
From Release 2 of the MIPS32 specification this is replaced by explicit hazard barrier instructions. If you execute a
hazard barrier between the instruction which makes the change (the “producer”) and the instruction which is sensitive
to it (the “consumer”), you are guaranteed that the change will be seen as complete. Hazards can appear when the pro-