lnz@lucid.com (Leonard Zubkoff) (04/03/89)
Since there seems to be interest in this group in how different processors handle unaligned data, let me describe how Apollo's PRISM (Parallel RISC Multiprocessing) Architecture handles it. The CPU has two processors that operate concurrently, an integer processor and a floating point processor. Each instruction is either a 32 bit integer-only instruction or a 64 bit integer/floating point instruction pair. A bit in the integer instruction specifies whether or not it has a companion floating point instruction. The floating point processor has two functional units within it, so up to three operations can actually be dispatched per cycle in some cases. All instructions must be naturally aligned; 64 bit instruction pairs must be aligned on 64 bit boundaries. Branching to an unaligned instruction produces a trap. Memory references to unaligned data generate an unaligned data trap. A subset of these are fixed up by the trap handler and allowed to continue. Specifically, loading a 32 bit word from a 16 bit aligned address is fixed up. The purpose for this fixup is to provide data compatibility between the 68K series of processors and the PRISM processors. Ideally, people can rewrite their code to use natural alignment, but this mechanism allows unaligned data to be used with a performance penalty. There are also source language directives to tell the compiler to use particular alignments for structure components, so the compilers can generate efficient code to access unaligned data. There are a couple of advantages to using software rather than hardware here, or at least functionality that's not typically supported by hardware that handles unaligned references. First, there is a way when running the debugger to disable the unaligned data fixup; this allows you to detect uses of unaligned data and correct them. This may be important as accessing unaligned data may be slowing down your program, and with a pure hardware solution you can rarely determine why your program is slower than it should be. Second, some programming languages may want to use the unaligned data trap to detect incorrect operation at runtime. Our Common Lisp implementation for the PRISM, as well as for other machines that provide an unaligned data trap, uses this feature to give free runtime type-checking of certain Lisp operations. Leonard N. Zubkoff Lucid, Incorporated