Updated addressing mode table
John R. Mashey
so here it is again: if you saw it before, all that's really different
is some fixes in the table, and a few ckarified explanations:
THE GIANT ADDDRESSING MODE TABLE (Corrections happily accepted)
This table goes with the higher-level table of general architecture
characteristics.
Address mode summary
r register
r+ autoincrement (post) [by size of data object]
-r autodecrement (pre) [by size,...and this was the one I meant]
>r modify base register [generally, effective address -> base]
NOTE: sometimes this subsumes r+, -r, etc,
and is more general, so I categorize it
as a separate case.
d displacement d1 & d2 if 2 different displacements
x index register
s scaled index
a absolute [as a separate mode, as opposed to displacement+(0)
I Indirect
Shown below are 22 distinct addressing modes [you can argue whether
these are right categories]. In the table are the *number* of different
encodings/variations [and this is a little fuzzy; you can especially argue about
the 4 in the HP PA column, I'm not even sure that's right]. For example,
I counted as different variants on a mode the case where the structure was the same, but there were different-sized displacements that had to be decoded.
Note that meaningfully counting addressing modes is *at least as bad* as meaningfully counting opcodes; I did the best I could, and I spect a lot of
hours looking at manuals for the chips I hadn't programmed much, and in
some cases, even after hours, it was hard for me to figure out
meaningful numbers... *Most* of these archiectures are used in general-purpose
systems and *most* have at least one version that uses caches: those
are important because many of the issues in thinking about addressing modes
come from their interactions with MMUs and caches...
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
r r
r r r +d1 +d1
r r r | | r r | r r+ +d +d1 I +s
r r r +d +x +s| s+ s+|s+ +d +d|r+ +d I I I +s I
r +d +x +s >r >r >r|r+ -r a a r+|-r +x +s|I I +s +s +d2 +d2 +d2
-- -- -- -- -- -- --|-- -- -- -- --|-- -- --|-- -- -- -- --- --- ---
AMD 29K 1 | | |
Rxxx 1 | | |
SPARC 1 1 | | |
88K 1 1 1 | | |
HP PA 2 1 1 4 1 1| | |
ROMP 1 2 | | |
POWER 1 1 1 1 | | |
i860 1 1 1 1 | | |
Swrdfish 1 1 1 | 1 | |
ARM 2 2 2 1 1| 1 1
Clipper 1 3 1 | 1 1 2 | |
i960KB 1 1 1 1 | 2 2 | 1 |
S/360 1 | 1 |
i486 1 3 1 1 | 1 1 2 | 2 3|
NSC32K 3 | 1 1 3 3 | 3| 9
MC68000 1 1 | 1 1 2 | 2 |
MC68020 1 1 | 1 1 2 | 2 4| 16 16
VAX 1 3 1 | 1 1 1 1 1| 1 3| 1 3 1 3
COLUMN NOTES:
1) Columns 1-7 are addressing modes used by many machines, but very few,
if any clearly-RISC architectures use anything else. They are all
characterized by what they don't have:
2 adds needed before generating the address
indirect addressing
variable-sized decoding
2) Columns 13-15 include fairly simple-looking addressing modes, which however,
*may* require 2 back-to-back adds beforet he address is available. [*may*
because some of them use index-register=0 or something to avoid
indexing, and usually in such machines, you'll see variable timing figures,
depending on use of indexing.]
3) Columns 16-22 use indirect addressing.
ROW NOTES
1) Clipper & i960, of current chips, are more on the RISC-CISC border,
or are sort of "modern CISCs". ARM is also characterized (by ARM people,
Hot Chips IV: "ARM is not a "pure RISC".
2) ROMP has a number of characteristics different fro mteh rest of the RISCs,
you might call it "early RISC", and it is of course no longer made.
3) You might consider HP PA a little odd, as it appears to have more addressing
modes, in the same way that CISCs do, but I don't think this is the case: it's an issue of whether you call something several modes or one mode with a modifier, just as there is trouble counting opcodes (with & without modifiers).
From my view, neither PA nor POWER have truly "CISCy" addressing modes.
4) Notice difference between 68000 and 68020 (and later 68Ks): a bunch of
incredibly-general & complex modes got added...
5) Note that the addressing on the S/360 is actually pretty simple,
mostly base+displacement, although RX-addressing does take 2 regs+offset.
6) A dimension *not* shown on this particular chart, but also highly
relevant, is that this chart shows the different *types* of modes, *not*
how many addresses can be found in each instruction. That may be worth noting also:
AMD : i960 1 one address per instruction
S/360 - MC68020 2 up to 2 addresses
VAX 6 up to 6
By looking at alignment, indirect addressing, and looking only at those
chips that have MMUs,
consider the number of times an MMU *might* be used per instruction for
data address translations:
AMD - Clipper 2 [Swordfish & i960KB: no TLB]
S/360 - NSC32K 4
MC68Ks (all) 8
VAX 24
When RS/6000 does unaligned, it must be in the same cache line
(and thus also in same MMU page), and traps to software otherwise, thus
avoiding numerous ugly cases.
Note: in some sense, S/360s & VAXen can use an arbitrary number of translations
per instruction, with MOVE CHARACTER LONG, or similar operations & I don't
count them as more, because they're defined to be interruptable/restartable,
saving state in general-purpose registers, rather than hidden internal state.
SUMMARY:
1) Computer design styles mostly changed from machines with:
2-6 addresses per instruction, with variable sized encoding
address specifiers were usually "orthogonal", so that any could ggo
anywhere in an instruction
sometimes indirect addressing
sometimes need 2 adds *before* effective address is available
sometimes with many potential MMU accesses (and possible exceptions)
per instruciton, often buried in the middle of the instruction,
and often *after* you'd normally want to commit state because
of auto-increment or other side effects.
to machines with:
1 address per instruction
address specifiers encoded in small # of bits in 32-bit instruction
no indirect addressing
never need 2 adds before address available
use MMU once per data access
and we usually call the latter group RISCs. I say "changed" because
if you put this table together with the earlier one, which has the
age in years, the older ones were one way, and the newer ones are different.
2) Now, ignoring any other features, but looking at this single attribute
(architectural addressing features and implementation effects therof),
it ought to be clear that the machines in
the first part of the table are doing something *technically* different
from those in the second part of the table. Thus, people may sometimes
call something RISC that isn't, for marketing reasons, but the people
calling the first batch RISC really did have some serious technical issues at
heart.
3) One more time: this is *not* to say that RISC is better than CISC,
or that the few in the middle are bad, or anything like that ... but
that there are clear technical characteristics...
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: ma...@sgi.com
DDD: 415-390-3090
USPS: Silicon Graphics 7U-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311