I'm trying to understand the constraints that went into the design of early microprocessors, and one of the questions I have is about orthogonality.

To be specific, say it's the 1970s and you are designing a CPU in the Z80 class. ~1e4 transistor budget, not ultra-minimalist like the 6502, you want some moderately complex instructions in the hope of achieving both speed and code density. As usual for that class of CPU, that time, the data bus is 8 bits and the address bus is 16 bits.

Does it save chip area to have an orthogonal register bank?

Say you have eight registers of 16 bits each. One of them is the stack pointer, and one of them is the instruction pointer.

Of course, if a descendent of the architecture lives into the era of out of order CPUs, having the instruction pointer be a general-purpose register will be a headache! But say you aren't thinking about that, say you are only concerned about the cost and performance of the initial implementation.

It seems to me that it would make sense to say, okay, the hardware provides a small repertoire of operations, like 'add a number to a 16-bit register' or 'Store two bytes at the address pointed to by a 16-bit register'. Then the microcode chains these into sequences of operations.

So a subroutine call, for example: subtract 2 from the stack pointer; store the current instruction pointer at the address pointed to by the stack pointer, load the instruction pointer from the address currently pointed to by the instruction pointer.

All straightforward microcode, /if/ SP and IP are general purpose registers, each designated by a 3-bit register number. But if they aren't, then it gets more complicated, and you have to spend chip area providing additional basic operations.

But I'm a programmer not a hardware engineer, so my intuition about what makes efficient hardware, is not necessarily reliable, and the 8080 and Z80 did not make the IP a general purpose register; maybe they had good reasons for that.

What are the trade-offs about orthogonality? Am I mistaken about the benefits, or missing costs?

On Wednesday, July 26, 2023 at 6:22:09 PM UTC-5, Russell Wallace wrote:
> I'm trying to understand the constraints that went into the design of early microprocessors, and one of the questions I have is about orthogonality.
>
> To be specific, say it's the 1970s and you are designing a CPU in the Z80 class. ~1e4 transistor budget, not ultra-minimalist like the 6502, you want some moderately complex instructions in the hope of achieving both speed and code density. As usual for that class of CPU, that time, the data bus is 8 bits and the address bus is 16 bits.
>
> Does it save chip area to have an orthogonal register bank?
<
You have to remember that in early MOS design, there was only 1 layer of low resistance wiring (aluminum) and 2 non-independent layers of medium resistance wiring; and finally that when the first of these second layers crosses over the third, you have a transistor--what kind of transistor is determined by how the gate and how the source-dram regions are "doped".
<
Given (realistically) only these 3 layers:: yes absolutely regularity was a key to getting things done. But the regularity was all on those second two layers (poly and diffusion) and the metal looks regular because of what it needed to connect as a wire.
>
> Say you have eight registers of 16 bits each. One of them is the stack pointer, and one of them is the instruction pointer.
>
> Of course, if a descendent of the architecture lives into the era of out of order CPUs, having the instruction pointer be a general-purpose register will be a headache! But say you aren't thinking about that, say you are only concerned about the cost and performance of the initial implementation.
<
This is such an easy problem to solve:: you build a comparitor that looks at register operand specifiers and decides if is the IP or some other register. IP = {special wiring, or special sequence, or if microcoded--proceed normally}.
<
But, here, you will have 6 layers of metal, polysilicon has become low-resistance (1Ohm/square), you have transitioned from PMOS to NMOS to CMOS and from 3µ to 60nm. Your die has gone from "about as big as we can yield in the reticle, to smaller than a single I/O pad area.
>
> It seems to me that it would make sense to say, okay, the hardware provides a small repertoire of operations, like 'add a number to a 16-bit register' or 'Store two bytes at the address pointed to by a 16-bit register'. Then the microcode chains these into sequences of operations. {{or just run RISC ISA}}
>
> So a subroutine call, for example: subtract 2 from the stack pointer; store the current instruction pointer at the address pointed to by the stack pointer, load the instruction pointer from the address currently pointed to by the instruction pointer.
>
> All straightforward microcode,
<
A straightforward sequence -- no µCode needed.
<
>/if/ SP and IP are general purpose registers, each designated by a 3-bit register number. But if they aren't, then it gets more complicated, and you have to spend chip area providing additional basic operations.
<
Realistically, you need the same paths whether {SP, IP} are part of RF or separate from RF. Instruction encoding can cause the designer to lean either way.
>
> But I'm a programmer not a hardware engineer, so my intuition about what makes efficient hardware, is not necessarily reliable, and the 8080 and Z80 did not make the IP a general purpose register; maybe they had good reasons for that.
<
PDP 11 did.
>
> What are the trade-offs about orthogonality? Am I mistaken about the benefits, or missing costs?
<
The perceived costs are different when you are at 4+cycles per instruction than when you are at 4+instructions per cycle.
The costs are definitely different when the FETCH stream uses the same AGEN unit as the DATA stream.

In article <a9b8478f-f179-410a-8bf5-431ef45b53ecn@googlegroups.com>,
Russell Wallace <russell.wallace@gmail.com> wrote:
>I'm trying to understand the constraints that went into the design of
>early microprocessors, and one of the questions I have is about
>orthogonality.
>
>To be specific, say it's the 1970s and you are designing a CPU in the
>Z80 class. ~1e4 transistor budget, not ultra-minimalist like the 6502,
>you want some moderately complex instructions in the hope of achieving
>both speed and code density. As usual for that class of CPU, that time,
>the data bus is 8 bits and the address bus is 16 bits.
>
>Does it save chip area to have an orthogonal register bank?
>
>Say you have eight registers of 16 bits each. One of them is the stack
>pointer, and one of them is the instruction pointer.
>
>Of course, if a descendent of the architecture lives into the era of out
>of order CPUs, having the instruction pointer be a general-purpose
>register will be a headache! But say you aren't thinking about that, say
>you are only concerned about the cost and performance of the initial
>implementation.
>
>It seems to me that it would make sense to say, okay, the hardware
>provides a small repertoire of operations, like 'add a number to a
>16-bit register' or 'Store two bytes at the address pointed to by a
>16-bit register'. Then the microcode chains these into sequences of
>operations.
>
>So a subroutine call, for example: subtract 2 from the stack pointer;
>store the current instruction pointer at the address pointed to by the
>stack pointer, load the instruction pointer from the address currently
>pointed to by the instruction pointer.
>
>All straightforward microcode, /if/ SP and IP are general purpose
>registers, each designated by a 3-bit register number. But if they
>aren't, then it gets more complicated, and you have to spend chip area
>providing additional basic operations.
>
>But I'm a programmer not a hardware engineer, so my intuition about what
>makes efficient hardware, is not necessarily reliable, and the 8080 and
>Z80 did not make the IP a general purpose register; maybe they had good
>reasons for that.
>
>What are the trade-offs about orthogonality? Am I mistaken about the
>benefits, or missing costs?

Mitch answered parts of your question.

First, it's important to realize in the 1976-1982 era, things were changing
fast. Something that didn't make sense in 1976 could be a good idea in 1979.

But to a first approximation, early CPUs were organized around their ALU.
And having orthogonal operations on the registers doesn't help much. The
logic to drive custom registers living spread out to the ALU is pretty
similar to the logic to read from an 8 entry "register file" (merely because
there were no tools to make a register file, so you did it by hand).
Not everyone got the same tools--some folks were doing very manual work
by the mid 1980's whereas others had much more involved tools by then.
Everything was a potential competitive advantage.

Early CPUs used one-byte opcodes (with additional bytes for operands), and
no one was going to encode two 3-bit registers in a one-byte instruction.
So non-orthogonal was the style, and why some operations could only
happen on some registers.

Kent

Kent Dickey <kegs@provalid.com> schrieb:

> Early CPUs used one-byte opcodes (with additional bytes for operands),

I assume you mean early microprocessors.

Early CPUs used a wide variety of opcode sizes: The IBM 701 had 18-bit
instructions with five-bit opcodes, for example.

kegs@provalid.com (Kent Dickey) writes:
>In article <a9b8478f-f179-410a-8bf5-431ef45b53ecn@googlegroups.com>,
>Russell Wallace <russell.wallace@gmail.com> wrote:
>>I'm trying to understand the constraints that went into the design of
>>early microprocessors, and one of the questions I have is about
>>orthogonality.
>>
>>To be specific, say it's the 1970s and you are designing a CPU in the
>>Z80 class. ~1e4 transistor budget, not ultra-minimalist like the 6502,
>>you want some moderately complex instructions in the hope of achieving
>>both speed and code density. As usual for that class of CPU, that time,
>>the data bus is 8 bits and the address bus is 16 bits.
>>
>>Does it save chip area to have an orthogonal register bank?
>>
>>Say you have eight registers of 16 bits each. One of them is the stack
>>pointer, and one of them is the instruction pointer.
>>
>>Of course, if a descendent of the architecture lives into the era of out
>>of order CPUs, having the instruction pointer be a general-purpose
>>register will be a headache! But say you aren't thinking about that, say
>>you are only concerned about the cost and performance of the initial
>>implementation.
>>
>>It seems to me that it would make sense to say, okay, the hardware
>>provides a small repertoire of operations, like 'add a number to a
>>16-bit register' or 'Store two bytes at the address pointed to by a
>>16-bit register'. Then the microcode chains these into sequences of
>>operations.
>>
>>So a subroutine call, for example: subtract 2 from the stack pointer;
>>store the current instruction pointer at the address pointed to by the
>>stack pointer, load the instruction pointer from the address currently
>>pointed to by the instruction pointer.
>>
>>All straightforward microcode, /if/ SP and IP are general purpose
>>registers, each designated by a 3-bit register number. But if they
>>aren't, then it gets more complicated, and you have to spend chip area
>>providing additional basic operations.
>>
>>But I'm a programmer not a hardware engineer, so my intuition about what
>>makes efficient hardware, is not necessarily reliable, and the 8080 and
>>Z80 did not make the IP a general purpose register; maybe they had good
>>reasons for that.
>>
>>What are the trade-offs about orthogonality? Am I mistaken about the
>>benefits, or missing costs?
>
>Mitch answered parts of your question.
>
>First, it's important to realize in the 1976-1982 era, things were changing
>fast. Something that didn't make sense in 1976 could be a good idea in 1979.
>
>But to a first approximation, early CPUs were organized around their ALU.
>And having orthogonal operations on the registers doesn't help much.

In that era, most early CPUs had at most one register (an accumulator, e.g. PDP8),
and several had no registers for general arithmentic operational use, supporting
instead operations directly on memory (eg.g the Electrodata and early Burroughs
BCD machines, IBM 1401), or were stack based like the B5500 and successors.

>Early CPUs used one-byte opcodes (with additional bytes for operands), and
>no one was going to encode two 3-bit registers in a one-byte instruction.
>So non-orthogonal was the style, and why some operations could only
>happen on some registers.

B3500, for example (Electrodata 220, B300 were similar)

OP AF BF AAAAAA BBBBBB CCCCCC

2-digit (1 byte) opcode, 2 digit A operand length (00 to 99 units of digits
or bytes depending, where 00 = 100), a 2 digit B operand length (") and two or
three operand syllables (6 digit memory address).

02 05 16 000100 000200 000300

Would add a 5 digit field at address 100 to a 16 digit
field at address 200 and store it in a 16-digit field
at address 300.

The B300 (circa 1960) was designed with all instructions supporting
three operands, even if the instruction opcode only required one
or two operands - the programmer was encouraged to use the unused
operand fields in the instruction stream for data storage....

The B3500 had an accumulator register for fixed point arithmetic,
but wasn't widely used by the COBOL code that ran on the machine.

In article <Vu9GM.803951$TPw2.281893@fx17.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>kegs@provalid.com (Kent Dickey) writes:
>>In article <a9b8478f-f179-410a-8bf5-431ef45b53ecn@googlegroups.com>,
>>Russell Wallace <russell.wallace@gmail.com> wrote:
>>>I'm trying to understand the constraints that went into the design of
>>>early microprocessors, and one of the questions I have is about
>>>orthogonality.
>>>
>>>To be specific, say it's the 1970s and you are designing a CPU in the
>>>Z80 class. ~1e4 transistor budget, not ultra-minimalist like the 6502,
>>>you want some moderately complex instructions in the hope of achieving
>>>both speed and code density. As usual for that class of CPU, that time,
>>>the data bus is 8 bits and the address bus is 16 bits.
>>>
>>>Does it save chip area to have an orthogonal register bank?
>>>
>>>Say you have eight registers of 16 bits each. One of them is the stack
>>>pointer, and one of them is the instruction pointer.
>>>
>>>Of course, if a descendent of the architecture lives into the era of out
>>>of order CPUs, having the instruction pointer be a general-purpose
>>>register will be a headache! But say you aren't thinking about that, say
>>>you are only concerned about the cost and performance of the initial
>>>implementation.
>>>
>>>It seems to me that it would make sense to say, okay, the hardware
>>>provides a small repertoire of operations, like 'add a number to a
>>>16-bit register' or 'Store two bytes at the address pointed to by a
>>>16-bit register'. Then the microcode chains these into sequences of
>>>operations.
>>>
>>>So a subroutine call, for example: subtract 2 from the stack pointer;
>>>store the current instruction pointer at the address pointed to by the
>>>stack pointer, load the instruction pointer from the address currently
>>>pointed to by the instruction pointer.
>>>
>>>All straightforward microcode, /if/ SP and IP are general purpose
>>>registers, each designated by a 3-bit register number. But if they
>>>aren't, then it gets more complicated, and you have to spend chip area
>>>providing additional basic operations.
>>>
>>>But I'm a programmer not a hardware engineer, so my intuition about what
>>>makes efficient hardware, is not necessarily reliable, and the 8080 and
>>>Z80 did not make the IP a general purpose register; maybe they had good
>>>reasons for that.
>>>
>>>What are the trade-offs about orthogonality? Am I mistaken about the
>>>benefits, or missing costs?
>>
>>Mitch answered parts of your question.
>>
>>First, it's important to realize in the 1976-1982 era, things were changing
>>fast. Something that didn't make sense in 1976 could be a good idea in 1979.
>>
>>But to a first approximation, early CPUs were organized around their ALU.
>>And having orthogonal operations on the registers doesn't help much.
>
>In that era, most early CPUs had at most one register (an accumulator,
>e.g. PDP8),
>and several had no registers for general arithmentic operational use, supporting
>instead operations directly on memory (eg.g the Electrodata and early Burroughs
>BCD machines, IBM 1401), or were stack based like the B5500 and successors.
>
>
>
>>Early CPUs used one-byte opcodes (with additional bytes for operands), and
>>no one was going to encode two 3-bit registers in a one-byte instruction.
>>So non-orthogonal was the style, and why some operations could only
>>happen on some registers.
>
>B3500, for example (Electrodata 220, B300 were similar)
>
> OP AF BF AAAAAA BBBBBB CCCCCC
>
>2-digit (1 byte) opcode, 2 digit A operand length (00 to 99 units of digits
>or bytes depending, where 00 = 100), a 2 digit B operand length (") and two or
>three operand syllables (6 digit memory address).
>
> 02 05 16 000100 000200 000300
>
>Would add a 5 digit field at address 100 to a 16 digit
>field at address 200 and store it in a 16-digit field
>at address 300.
>
>The B300 (circa 1960) was designed with all instructions supporting
>three operands, even if the instruction opcode only required one
>or two operands - the programmer was encouraged to use the unused
>operand fields in the instruction stream for data storage....
>
>The B3500 had an accumulator register for fixed point arithmetic,
>but wasn't widely used by the COBOL code that ran on the machine.

Those are not Z80 class microprocessors from the 1970s. They are not
even microprocessors. IBM mainframes of the time did not use microprocessors.

Kent

kegs@provalid.com (Kent Dickey) writes:
[8-bit microprocessors]
>Early CPUs used one-byte opcodes (with additional bytes for operands), and
>no one was going to encode two 3-bit registers in a one-byte instruction.
>So non-orthogonal was the style, and why some operations could only
>happen on some registers.

Yes. Some time ago some of us explored the idea of what we would do
if we were in 1975 or so (with the transistor/area budget for the 6502
or maybe the Z80, and, of course, with an 8-bit data bus), but with
today's knowledge about computer architecture.

What I found was that, with a 6502 transistor budget, you could not
afford many registers and even fewer 16-bit registers. With a Z80
transistor budget, that restriction is more relaxed (and maybe you
could afford a 16-bit ALU; but does that really save much if you are
limited by an 8-bit data bus?), but you are very limited in the
instruction encoding:

If you use 16-bit instructions for, say, a load/store-architecture
with 8 16-bit registers, every instruction takes two memory cycles to
load, and it uses 2 bytes of the precious memory. And people
programmed these CPUs in assembly language, and humans are quite good
at dealing with non-orthogonal instructions (even though they usually
prefer orthogonal). So it was better to provide a bunch of dedicated
registers that are implicit in the instructions.

An interesting example is the 8086, designed for a 16-bit data bus,
but with an 8-bit legacy. It has orthogonal instructions for common
operations that can deal with all 8 registers and all the (limited)
addressing modes, somewhat in the PDP-11 style, but it also has
instructions like lods where all registers are implicit. You can see
a modern result of this in SectorLisp: IIRC it uses LODSW when it
wants to increment SI by 2, because LODSW uses only one byte, whereas
"ADD SI,2" uses more.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Anton Ertl wrote:
> kegs@provalid.com (Kent Dickey) writes:
> [8-bit microprocessors]
>> Early CPUs used one-byte opcodes (with additional bytes for operands), and
>> no one was going to encode two 3-bit registers in a one-byte instruction.
>> So non-orthogonal was the style, and why some operations could only
>> happen on some registers.
>
> Yes. Some time ago some of us explored the idea of what we would do
> if we were in 1975 or so (with the transistor/area budget for the 6502
> or maybe the Z80, and, of course, with an 8-bit data bus), but with
> today's knowledge about computer architecture.
>
> What I found was that, with a 6502 transistor budget, you could not
> afford many registers and even fewer 16-bit registers. With a Z80
> transistor budget, that restriction is more relaxed (and maybe you
> could afford a 16-bit ALU; but does that really save much if you are
> limited by an 8-bit data bus?), but you are very limited in the
> instruction encoding:
>
> If you use 16-bit instructions for, say, a load/store-architecture
> with 8 16-bit registers, every instruction takes two memory cycles to
> load, and it uses 2 bytes of the precious memory. And people
> programmed these CPUs in assembly language, and humans are quite good
> at dealing with non-orthogonal instructions (even though they usually
> prefer orthogonal). So it was better to provide a bunch of dedicated
> registers that are implicit in the instructions.
>
> An interesting example is the 8086, designed for a 16-bit data bus,
> but with an 8-bit legacy. It has orthogonal instructions for common
> operations that can deal with all 8 registers and all the (limited)
> addressing modes, somewhat in the PDP-11 style, but it also has
> instructions like lods where all registers are implicit. You can see
> a modern result of this in SectorLisp: IIRC it uses LODSW when it
> wants to increment SI by 2, because LODSW uses only one byte, whereas
> "ADD SI,2" uses more.
>
> - anton

By coincidence, Ken Shirriffs blog has a recent article which traces the
instructions from the Datapoint 2200, to 8008, to 8080, to 8086.

Tracing the roots of the 8086 instruction set to the
Datapoint 2200 minicomputer
http://www.righto.com/2023/08/datapoint-to-8086.html

On Saturday, August 26, 2023 at 9:27:55 AM UTC-5, EricP wrote:
> Anton Ertl wrote:
> > ke...@provalid.com (Kent Dickey) writes:
> > [8-bit microprocessors]
> >> Early CPUs used one-byte opcodes (with additional bytes for operands), and
> >> no one was going to encode two 3-bit registers in a one-byte instruction.
> >> So non-orthogonal was the style, and why some operations could only
> >> happen on some registers.
> >
> > Yes. Some time ago some of us explored the idea of what we would do
> > if we were in 1975 or so (with the transistor/area budget for the 6502
> > or maybe the Z80, and, of course, with an 8-bit data bus), but with
> > today's knowledge about computer architecture.
> >
> > What I found was that, with a 6502 transistor budget, you could not
> > afford many registers and even fewer 16-bit registers. With a Z80
> > transistor budget, that restriction is more relaxed (and maybe you
> > could afford a 16-bit ALU; but does that really save much if you are
> > limited by an 8-bit data bus?), but you are very limited in the
> > instruction encoding:
> >
> > If you use 16-bit instructions for, say, a load/store-architecture
> > with 8 16-bit registers, every instruction takes two memory cycles to
> > load, and it uses 2 bytes of the precious memory. And people
> > programmed these CPUs in assembly language, and humans are quite good
> > at dealing with non-orthogonal instructions (even though they usually
> > prefer orthogonal). So it was better to provide a bunch of dedicated
> > registers that are implicit in the instructions.
> >
> > An interesting example is the 8086, designed for a 16-bit data bus,
> > but with an 8-bit legacy. It has orthogonal instructions for common
> > operations that can deal with all 8 registers and all the (limited)
> > addressing modes, somewhat in the PDP-11 style, but it also has
> > instructions like lods where all registers are implicit. You can see
> > a modern result of this in SectorLisp: IIRC it uses LODSW when it
> > wants to increment SI by 2, because LODSW uses only one byte, whereas
> > "ADD SI,2" uses more.
> >
> > - anton
> By coincidence, Ken Shirriffs blog has a recent article which traces the
> instructions from the Datapoint 2200, to 8008, to 8080, to 8086.
>
> Tracing the roots of the 8086 instruction set to the
> Datapoint 2200 minicomputer
> http://www.righto.com/2023/08/datapoint-to-8086.html

This is marvelous.
Illustrates the x86 ISA history in full, incremental detail
|>Tracing the roots of the 8086 instruction set to the
|>Datapoint 2200 minicomputer

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Anton Ertl wrote:
>> An interesting example is the 8086, designed for a 16-bit data bus,
>> but with an 8-bit legacy. It has orthogonal instructions for common
>> operations that can deal with all 8 registers and all the (limited)
>> addressing modes, somewhat in the PDP-11 style, but it also has
>> instructions like lods where all registers are implicit. You can see
>> a modern result of this in SectorLisp: IIRC it uses LODSW when it
>> wants to increment SI by 2, because LODSW uses only one byte, whereas
>> "ADD SI,2" uses more.
>>
>> - anton
>
>By coincidence, Ken Shirriffs blog has a recent article which traces the
>instructions from the Datapoint 2200, to 8008, to 8080, to 8086.
>
>Tracing the roots of the 8086 instruction set to the
>Datapoint 2200 minicomputer
>http://www.righto.com/2023/08/datapoint-to-8086.html

Yes, very interesting. And looking at this posting and the 8080
instructions, I partially retract my claim above:

First of all, many of the instructions with implicit registers were
introduced with the 8086 instead of coming from the 8080 legacy,
in particular including the LODS instructions mentioned above.

However, the orthogonal instructions on the 8080 were much more
limited than on the 8086: on the 8080 you can do (in 8086 syntax):

add al, src
add al, imm

where src could be one of ch, cl, dh, dl, bh, bl, [bx], or al.

By contrast, on the 8086 this cabability was extended to

add reg, r/m
add r/m, reg

with byte or word width, in PDP-11 style. There are also encodings
for

add al/ax, imm
add r/m, imm

for the different widths.

For the memory operands we have an evolution towards more
orthogonality:

Datapoint 2200-Intel 8080: [BX] (in 8086 syntax)
8086: [bx/bp+si/di]+disp, [bx/bp/si/di]+disp, or absolute addressing.
IA-32: disp(reg), disp(reg,reg,1/2/4/8)

where on IA-32 you could use any register (except for minor
limitations on ESP).

The Datapoint 2200->8080 evolution is an interesting contrast to what we
see in the 6800 and its offspring:

The 8080 just has register, immediate, and indirect; I don't even see
absolute addressing in the instruction table for the 8080.

The 6800 has

addr8/addr16 direct/extended absolute
disp8,IX (index, only 8-bit displacement allowed, IX is 16-bit)

The 6502 is supposedly minimal, and it reduced the two accumulators
of the 6800 to one accumulator, and replaced the one 16-bit index
register IX with two 8-bit index registers X and Y. But the 6502 has
a lot of addressing modes. For the adc instruction (with one operand
and the destination in the accumulator), the addressing modes are:

addr8/addr16 zero-page/absolute
immediate
disp16,x/y EA=disp16+x/y
disp8,x EA=disp8+x
(disp8,x) tmp16=disp8+x, EA=[tmp16]
(addr8),y tmp16=[addr8], EA=tmp16+y

There are some other addressing modes used in other instructions:

disp8,y EA=disp8+y
(addr16) EA=[addr16]
offset8 PC-relative, EA=PC+offset8 (probably also in 6800)

The other notable descendant of the 6800 is the 6809, which also
provided many addressing modes:

PC-relative long and short
absolute direct and extended as on 6800
extended indirect EA=[addr16]
disp,X/Y/U/S constant-offset indexed
A/B/D,X/Y/U/S accumulator indexed
,X/Y/U/S+/++ autoincrement indexed
,-/--X/Y/U/S autodecrement indexed
[indexed] indirect indexed
PC-relative not just for branch instructions

The indirect indexed modes just add an indirection behind one of the
indexed addressing modes.

I wonder how much of this richness of addressing modes would have been
added to the 6809 if the 6502 had not existed or would have been
unsuccessful.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> Anton Ertl wrote:
>>> An interesting example is the 8086, designed for a 16-bit data bus,
>>> but with an 8-bit legacy. It has orthogonal instructions for common
>>> operations that can deal with all 8 registers and all the (limited)
>>> addressing modes, somewhat in the PDP-11 style, but it also has
>>> instructions like lods where all registers are implicit. You can see
>>> a modern result of this in SectorLisp: IIRC it uses LODSW when it
>>> wants to increment SI by 2, because LODSW uses only one byte, whereas
>>> "ADD SI,2" uses more.
>>>
>>> - anton
>> By coincidence, Ken Shirriffs blog has a recent article which traces the
>> instructions from the Datapoint 2200, to 8008, to 8080, to 8086.
>>
>> Tracing the roots of the 8086 instruction set to the
>> Datapoint 2200 minicomputer
>> http://www.righto.com/2023/08/datapoint-to-8086.html
>
> Yes, very interesting. And looking at this posting and the 8080
> instructions, I partially retract my claim above:
>
> First of all, many of the instructions with implicit registers were
> introduced with the 8086 instead of coming from the 8080 legacy,
> in particular including the LODS instructions mentioned above.
>
> However, the orthogonal instructions on the 8080 were much more
> limited than on the 8086: on the 8080 you can do (in 8086 syntax):
>
> add al, src
> add al, imm
>
> where src could be one of ch, cl, dh, dl, bh, bl, [bx], or al.
>
> By contrast, on the 8086 this cabability was extended to
>
> add reg, r/m
> add r/m, reg
>
> with byte or word width, in PDP-11 style. There are also encodings
> for
>
> add al/ax, imm
> add r/m, imm
>
> for the different widths.
>
> For the memory operands we have an evolution towards more
> orthogonality:
>
> Datapoint 2200-Intel 8080: [BX] (in 8086 syntax)
> 8086: [bx/bp+si/di]+disp, [bx/bp/si/di]+disp, or absolute addressing.
> IA-32: disp(reg), disp(reg,reg,1/2/4/8)
>
> where on IA-32 you could use any register (except for minor
> limitations on ESP).
>
> The Datapoint 2200->8080 evolution is an interesting contrast to what we
> see in the 6800 and its offspring:
>
> The 8080 just has register, immediate, and indirect; I don't even see
> absolute addressing in the instruction table for the 8080.

Yes, but 8080 doesn't have any register indirect + offset addressing either
so you have to build such accesses.

So a ptr->field [reg+disp] memory access winds up as something like
LDA [abs16] // ptr.l
ADI #offset.l
MOV L,A
LDA [abs16] // ptr.h
ADI #offset.h
MOV H,A
MOV A,M

7 instructions for one 8-bit ptr->field read where ptr is a global address.
Even more if ptr was an arg on the stack.

8080 also doesn't have relative branches, just absolute jump/call
to a 16-bit immediate or a HL register value.

Basically you assemble the whole program each time, starting at a fixed
base address, the one where your EPROM's are hard-wired on the motherboard.
That's ok because you can only afford 2kB of EPROM memory and 1kB of DRAM.

This is mostly a consequence of having a 8-bit opcode and 8 registers.
So all of its opcode space is taken up with 3-bit register specifiers.

(My 8-bit ISA also has 8 general registers but more addressing modes.
The key is the dual-accumulator approach, borrowed from 6800.)

> The 6800 has
>
> addr8/addr16 direct/extended absolute
> disp8,IX (index, only 8-bit displacement allowed, IX is 16-bit)

6800 also had relative branch/call.

And it had the two accumulators, and only 4 general registers.
The two accumulators was also important because all ALU operations
are of the form A = A OP B where all registers are implicit.
So it had the opcode space to afford more and fancier addressing modes.

> The 6502 is supposedly minimal, and it reduced the two accumulators
> of the 6800 to one accumulator, and replaced the one 16-bit index
> register IX with two 8-bit index registers X and Y. But the 6502 has
> a lot of addressing modes. For the adc instruction (with one operand
> and the destination in the accumulator), the addressing modes are:
>
> addr8/addr16 zero-page/absolute
> immediate
> disp16,x/y EA=disp16+x/y
> disp8,x EA=disp8+x
> (disp8,x) tmp16=disp8+x, EA=[tmp16]
> (addr8),y tmp16=[addr8], EA=tmp16+y
>
> There are some other addressing modes used in other instructions:
>
> disp8,y EA=disp8+y
> (addr16) EA=[addr16]
> offset8 PC-relative, EA=PC+offset8 (probably also in 6800)
>
> The other notable descendant of the 6800 is the 6809, which also
> provided many addressing modes:
>
> PC-relative long and short
> absolute direct and extended as on 6800
> extended indirect EA=[addr16]
> disp,X/Y/U/S constant-offset indexed
> A/B/D,X/Y/U/S accumulator indexed
> ,X/Y/U/S+/++ autoincrement indexed
> ,-/--X/Y/U/S autodecrement indexed
> [indexed] indirect indexed
> PC-relative not just for branch instructions
>
> The indirect indexed modes just add an indirection behind one of the
> indexed addressing modes.
>
> I wonder how much of this richness of addressing modes would have been
> added to the 6809 if the 6502 had not existed or would have been
> unsuccessful.
>
> - anton

I built systems with the 8080, the 6800, and RCA 1802. I knew of the 6502
but never worked with it. Of the 8080, 6800 and 6502, the 8080 was the
most primitive, both from a software and hardware point of view.
The hardware interface for 8080 was just a pain.
The 6800 was a pleasure to work with.

I designed my own 8-bit ISA which also had 8 16-bit registers but I
borrowed the 6800's dual accumulator idea, also called A and B.
Having two accumulators is an advantage for an 8-bit ISA because the
ALU operations are the form A = A OP B where the registers are implicit.
This frees up all that opcode space for more addressing modes and even
a few 16-bit operations, more of a LD/ST ISA.

Going back to the original question::

On Wednesday, July 26, 2023 at 6:22:09 PM UTC-5, Russell Wallace wrote:
> I'm trying to understand the constraints that went into the design of early microprocessors, and one of the questions I have is about orthogonality.
>
> To be specific, say it's the 1970s and you are designing a CPU in the Z80 class. ~1e4 transistor budget, not ultra-minimalist like the 6502, you want some moderately complex instructions in the hope of achieving both speed and code density. As usual for that class of CPU, that time, the data bus is 8 bits and the address bus is 16 bits.
>
> Does it save chip area to have an orthogonal register bank?
>
> Say you have eight registers of 16 bits each. One of them is the stack pointer, and one of them is the instruction pointer.
<
It saves chip area but it costs performance. At a 1E4 transistor count this will be a wash. At a 1E6 transistor count it will start hurting.
>
> Of course, if a descendent of the architecture lives into the era of out of order CPUs, having the instruction pointer be a general-purpose register will be a headache! But say you aren't thinking about that, say you are only concerned about the cost and performance of the initial implementation.
<
It harms future performance while making the original design easier in some regards, and harder in others. ALA PDP-11
>
> It seems to me that it would make sense to say, okay, the hardware provides a small repertoire of operations, like 'add a number to a 16-bit register' or 'Store two bytes at the address pointed to by a 16-bit register'. Then the microcode chains these into sequences of operations.
<
Chains is not the right word, there; performs is a more resonable choice.
>
> So a subroutine call, for example: subtract 2 from the stack pointer; store the current instruction pointer at the address pointed to by the stack pointer, load the instruction pointer from the address currently pointed to by the instruction pointer.
>
> All straightforward microcode, /if/ SP and IP are general purpose registers, each designated by a 3-bit register number. But if they aren't, then it gets more complicated, and you have to spend chip area providing additional basic operations.
<
What is more complicated (takes more control bits) writing directly to a vector of flip flops, or writing to a specific vector of flips flops in an array of flip flops ?? No modern general purpose architecture has chosen to place the IP in the register file--mainly because one needs the IP every cycle to fetch the next instructions and reading and writing into a register file for this requires more ports in the RF, and adds latency to this calculation (FETCH) loop.
>
> But I'm a programmer not a hardware engineer, so my intuition about what makes efficient hardware, is not necessarily reliable, and the 8080 and Z80 did not make the IP a general purpose register; maybe they had good reasons for that.
>
> What are the trade-offs about orthogonality? Am I mistaken about the benefits, or missing costs?
<
The trade offs are different at the several cycles per instruction than at the several instructions per cycle realms.