• Aucun résultat trouvé

Other Innovations in MIPS III

Dans le document 0.1 Style and Limits (Page 57-61)

MIPS Architecture

2.7 MIPS I to MIPS IV 64-Bit (and Other) Exten- Exten-sions

2.7.4 Other Innovations in MIPS III

The widespread extensions required in going to 64 bits provide an opportunity to add some useful instructions (unrelated to 64-bit operation).

36 2.7. MIPS I to MIPS IV 64-Bit (and Other) Extensions

Multiprocessor Synchronization Operations

There’s a special pair of instructions — a load linked and a store conditional

— whose job is to allow the implementation of software semaphores in a way that works with shared memory multiprocessor systems. They do the same job as the atomic read-modify-write (RMW) or locked instructions offered by more recent CISC architectures — but RMW and locking get very inefficient in large multiprocessor systems. We’ll account for their operation in Section 5.8.4 below. Meanwhile, here’s what they do.

ll is a regular load-word instruction, but it keeps a record of the address you used in a special internal register; sc is a store-word instruction, but it only does the store if

• The CPU has not taken any interrupt or exception since a preceding ll at the same address, and

• (For multiprocessor systems) no other CPU has signalled a write to (or intention to write to) a region of memory including the address used by the 11

And then sc returns a value telling the program whether or not the store succeeded.

Although designed for multiprocessor systems, ll and sc allow you to implement a semaphore in a uniprocessor without haveing to disable all in-terrupts.

Loop-Closing Branches (Branch Likely)

Efficient MIPS code requires that the compiler be able to find useful work to do in most branch delay slots. In many cases, the instruction that would logically have preceded the branch is a good choice. This can’t be done, of course, when the branch is a conditional one and the instruction sequence before it is devoted to computing the condition.

Page 36 of the original book is missed.

38 2.7. MIPS I to MIPS IV 64-Bit (and Other) Extensions

0x0000 0000 0x8000 0000 0xA000 0000 0xC000 0000

Mapped (kseg2)

32-bit user space (kuseg) 2GB

Unmapped uncached(kseg1)

Unmapped cached (kseg0)

Figure 2.1: MIPS memory map: the 32-bit view

(sometimes they’re close, but not the same). We’ll refer to them asprogram addresses1 and physical addresses, respectively.

A MIPS CPU runs at one of two privilege levels: user and kernel.2 We’ll often talk about “user mode” and “kernel mode” for brevity, but it’s a feature of the MIPS architecture that the change from kernel to user never makes anything work differently, it just sometimes makes it illegal. At the user level, any program address with the most-significant bit of the address set is illegal and causes a trap. Also, some instructions cause a trap in user mode.

In the 32-bit view (Figure 2.1), the program address space is divided into four big areas with traditional (and thoroughly meaningless) names; different things happen according to the area an address lies in, as follows:

kuseg 0x0000 0000-7FFF FFFF(low 2GB): These are the addresses permit-ted in user mode. In machines with an MMU, they will always be

trans-1I had worked with operating systems before I met up with MIPS, so it’s natural for me to call the program addresses “virtual addresses” — but for many people “’virtual address”

suggests a lot of operating system complications that aren’t relevant here.

2MIPS CPUs after R40000 have a third “supervisor” mode; however, since all MIPS OSs so far have ignored it, we will mostly do so too.

lated (see Chapter 6). You should not attempt to use these addresses unless the MMU is set up.

For machines without an MMU, what happens is implementation de-fined; your particular CPU’s manual may tell you about something use-ful you could do with them. But if you want your code to be portable to and between MMU-less MIPS processors, avoid this area.

kseg0 0x8000 0000-9FFF FFFF (512MB): These addresses are translated into physical addresses by merely stripping off the top bit and mapping them contiguously into the low 512MB of physical memory. Since this is a trivial translation, these addresses are often called “untranslated”, but now you know better!

Addresses in this region are almost always accessed through the cache, so they may not be used until the caches are properly initialized. They will be used for most programs and data in systems not using the MMU and will be used for the OS kernel for systems that do use the MMU.

ksegl 0xA000 0000-BFFF FFFF (512MB): These addresses are

mapped into physical addresses by stripping off the leading 3 bits, giving a duplicate mapping of the low 512MB of physical memory. But this time, access will not use the cache.

The ksegl region is the only chunk of the memory map that is guaranteed to behave properly from system reset; that’s why the after-reset starting point (0xBFC0 0000) lies within it. The physical address of the starting point is0x1FC0 0000 — tell your hardware engineer.1

You will therefore use this region to access your initial program ROM, and most people use it for I/O registers. If your hardware designer pro-poses to map such things outside the low 512MB of physical memory, apply persuasion.

kseg2 0xC000 0000-FFFF FFFF(1GB): This area is only accessible in kernel mode but is once again translated through the MMU. Don’t access it before the MMU is set up. Unless you are writing a serious operating system, you will probably never have cause to use kseg2.

Dans le document 0.1 Style and Limits (Page 57-61)