[CST-2] Comp. Arch 1998.7.3 - backwards compatibility problems

[George van den Driessche]

"Older computer architectures often contain features that hamper
high-performance implementation using modern techniques. Describe several
such features, explaining how they affect implementation; describe what
techniques (if any) have been developed to help overcome these
difficulties." [14 marks]

So far, I have the following:

o    Small register file (x86): introduces extra data dependencies into
code, causing more pipeline stalls. Superscalar architectures cannot work at
all with a small number of registers, so CPI is limited to >1. Overcome by
register renaming: undo register colouring, spreading data among many
registers, to exploit ILP and enable OoO execution.

o    Specialised instructions (VAX POLY, memory indirect load/store):
complicate pipeline stages, limiting clock speeds. May have to handle
exceptions mid-execution, adding further complication. Also requires higher
transistor count, of course. Overcome by emulation, either in u-code or by
throwing an exception and letting the OS deal with it.

o    Unaligned memory accesses: loading/storing a register from an address
that is not a multiple of the word size. Requires two loads, bytemasking,
ORing and then maybe a store, instead of one load/store. Complicates
pipeline stages again, increases transistor count, limits clock speed. Can
also throw exceptions partway through. Overcome by: emulation in u-code, or
raising exception to OS (!).

o    Special registers for instructions (x86 MUL): keep instruction encoding
small, but give compiler a hard time allocating registers, so that false
dependencies arise (as in first point). How does one overcome this?

o    Does support for self-modifying code count? It means the I-cache has to
snoop the D-cache, which I suppose can be a little irritating, especially if
you're trying to do OoO execution. How does one overcome this?


Does anyone have any further points to add, criticism/corrections to make,
or answers to my questions?

Cheers,
George

Soon to be gbmvdd@cantab.net