Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!decwrl!pyramid!leadsv!esl!ian From: ian@esl.UUCP (Ian Kaplan) Newsgroups: comp.arch Subject: Re: Do RISC Compilers Consider Multiprogramming? Message-ID: <677@esl.UUCP> Date: 6 May 88 20:19:14 GMT References: <620@speedy.mcnc.org> Reply-To: ian@esl.UUCP (Ian Kaplan) Organization: ESL, Inc., Sunnyvale, CA. Lines: 74 Keywords: RISC compiler context-switch architecture multiprogramming In article <620@speedy.mcnc.org> davis@mcnc.org (Mark C. Davis) writes: > [text deleted] >A central assumption for RISC is that modern optimizing compilers can >produce efficient code for such machines. These compilers further >assume that they can predict the state of the machine, eg. register 1 >contains a certain variable or keeping inner loop code close together >will make it more likely for a cache hit. [more text deleted] >However, on a high order multiprogramming machine ( > 100 context >switches / sec) assumptions about machine state may no longer be >correct. Data may need to be reloaded into registers before continuing >(admittedly an operating system task, but one that must be done if data >is kept in registers) and code may no longer be in the cache. > To properly attack this question I think that we must first carefully define what is meant by RISC. Three features come to mind: - Reduced instruction set (e.g., most instructions executed in 1 cycle) - Relatively large numbers of registers (e.g., register windows) - Optimizing compilers that perform code reordering A side issue that has become increasingly important for RISC machines because of their high bus/memory usage is that of cache. Reduced Instruction Set The reduced instruction feature is a non-issue for "hard" real time systems. If anything, implementing instructions in logic rather than microcode so that most instructions are executed in one cycle is good for real time systems. Cache as a RISC Issue In hard real time systems caches can be a problem whether the CPU is RISC or CISC. As others on the net have commented, this results from the non-deterministic execution time introduced by the chance of cache miss. Registers The effect of a large number of registers in a processor used in a hard real time environment is an interesting question. Aside from issues of silicon real estate, this question can be divorced from the RISC question. As Prof. Jensen at CMU has pointed out, you can build CISC processors with large register files too. The compilers for a processor with a large register file may not only attempt to optimize register usage, but also cache usage. Mark's point is that in a hard real time environment, the assumptions the compiler makes in optimizing for register and cache usage (e.g., loop optimization for example) may be incorrect, since the program is constantly being interrupted by higher priority processes. In this case, a large number of "live" registers could actually slow the system down, since the registers might need to be stored on context switch. RISC processors can provide separate sets of registers for user processes and the operating system. This avoids saving registers on context switch to the OS. RISC processors can also provide separate "register banks" for the different processes. This is an old technique that goes back to the Xerox Dorado. When a context switch takes place, the register bank is simply switched. Of course the context for the process may not be loaded into registers, but if a sufficient number of register banks are provided, most commonly used processes will tend to be cached in registers. Cache A similar technique can be used for the cache. Many systems have a separate cache partitions for the operating system, so system calls do not cause cache flushes. If the cache is big enough and uses physical address cache tags, the cache does not have to be flushed on context switch and the data needed by commonly executed processes will tend to be in the cache.