On Sunday, August 15, 2021 at 8:45:56 AM UTC-5, Thomas Koenig wrote:
> Stefan Monnier <mon...@iro.umontreal.ca> schrieb:
> > Which part of the 6502's instruction set do you find "complicated" and
> > what kind of change do you think would have reduced the number of
> > transistors needed to implement it?
> The memory operands. A load/store architecture would have saved
> a lot of decoding and sequencing and associated transistor (or,
> better measure area), which could have been used for more and bigger
> registers.
<
Registers cost a lot of transistors, roughly 10 transistors per bit.
Flip-flops cost only 4 transistors per bit. Registers need to be
addressed, flip-flops are implicit. A sequencer can orchestrate
16 flip flops into a series of bus cycles that perform the memory
and memory indirect accesses desired.
>
> The Z80 is even stranger, with its 4-bit ALU for an 8-bit design,
> and taking multiple CPU cycles for each "machine cycle" and multiple
> machine cycles for each instruction.
>
> Note that I am not confident that we can actually do better for
> overall performance per transistor for the 6502. For the Z80,
> I would be.

On Sunday, August 15, 2021 at 9:34:15 AM UTC-5, Stefan Monnier wrote:
> Thomas Koenig [2021-08-15 13:45:54] wrote:
> > Stefan Monnier <mon...@iro.umontreal.ca> schrieb:
> >> Which part of the 6502's instruction set do you find "complicated" and
> >> what kind of change do you think would have reduced the number of
> >> transistors needed to implement it?
> > The memory operands. A load/store architecture would have saved
> > a lot of decoding and sequencing and associated transistor (or,
> > better measure area), which could have been used for more and bigger
> > registers.
> I think the discussion so far hasn't reached a clear conclusion on
> whether it would have lead to something better (smaller or faster or
> both).
<
I think consensus has been achieved--we cannot do better than the 6502 guys did.
<
> You might be right, but I think it's hard to tell without trying
> it out [ and compared to the original designers we benefit from what
> we've learned from history, so I really can't blame them. ].
> I suspect that it could end up smaller but slower (because of the extra
> memory accesses needed because of a less compact code).
> > The Z80 is even stranger, with its 4-bit ALU for an 8-bit design,
> > and taking multiple CPU cycles for each "machine cycle" and multiple
> > machine cycles for each instruction.
> For the Z80 I think the question is closed, indeed: we can clearly do
> better with those resources. But note that part of its appeal/goal was
> backward compatibility.
>
>
> Stefan

David Schultz <david.schultz@earthlink.net> wrote:
> On 8/15/21 10:58 AM, Anton Ertl wrote:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>> One important point is the extreme cost of memory at the time.
>>> People designed their ISAs for a very high code density because
>>> of that.
>>
>> Not so sure about the 6502 in that respect, with having to often put a
>> CLC before an ADC, having to use one or two address bytes in addition
>> to the opcode for many instructions, and having to use at least twice
>> as many instructions for 16-bit operations.
>>
>
> It could be worse. I still remember writing code for a PIC16F628 and my
> shock at the lack of an add with carry instruction. You could fake it
> but it took more than one extra instruction to do it. A real PITA
>
>
> I suspect that it was more important that the design tools were nearly
> non-existent. At best you could start with a design that was built using
> TTL. Then you had to transfer that to a collection of transistors. Laid
> out by hand using tape and a sharp knife.
>
> That took a lot of time and because of the costs and slow turn around
> from fabrication there would be a premium on getting it right the first
> time. So go with what you know.
>
> I will have to dig out the BYTE magazine article on the design of the
> 6809. That happened a few years later with slightly better design tools.
>
> It looks like I will not have to dig into the paper archives:
> https://tlindner.macmess.org/?page_id=119

Point 4 says no bit manipulation, but I see AND, OR, XOR, RORL, RORR, and
bit compare.
What are they talking about missing?

On 8/15/21 5:47 PM, Brett wrote:
> David Schultz <david.schultz@earthlink.net> wrote:
>> It looks like I will not have to dig into the paper archives:
>> https://tlindner.macmess.org/?page_id=119
>
> Point 4 says no bit manipulation, but I see AND, OR, XOR, RORL, RORR, and
> bit compare.
> What are they talking about missing?
>

Probably specific things like the bclr, bset, and btst instructions on
the 68000.

--
http://davesrocketworks.com
David Schultz

Stefan Monnier wrote:
> Thomas Koenig [2021-08-15 13:45:54] wrote:
> > The Z80 is even stranger, with its 4-bit ALU for an 8-bit design,
> > and taking multiple CPU cycles for each "machine cycle" and multiple
> > machine cycles for each instruction.
> For the Z80 I think the question is closed, indeed: we can clearly do
> better with those resources. But note that part of its appeal/goal was
> backward compatibility.
The 4-bit ALU was used to circumvent the patent on 8080.

On Monday, August 16, 2021 at 8:10:25 AM UTC-5, pec...@gmail.com wrote:
> Stefan Monnier wrote:
> > Thomas Koenig [2021-08-15 13:45:54] wrote:
> > > The Z80 is even stranger, with its 4-bit ALU for an 8-bit design,
> > > and taking multiple CPU cycles for each "machine cycle" and multiple
> > > machine cycles for each instruction.
> > For the Z80 I think the question is closed, indeed: we can clearly do
> > better with those resources. But note that part of its appeal/goal was
> > backward compatibility.
> The 4-bit ALU was used to circumvent the patent on 8080.
<
8008 ?

pec...@gmail.com wrote:
> Stefan Monnier wrote:
>> Thomas Koenig [2021-08-15 13:45:54] wrote:
>>> The Z80 is even stranger, with its 4-bit ALU for an 8-bit design,
>>> and taking multiple CPU cycles for each "machine cycle" and multiple
>>> machine cycles for each instruction.
>> For the Z80 I think the question is closed, indeed: we can clearly do
>> better with those resources. But note that part of its appeal/goal was
>> backward compatibility.
> The 4-bit ALU was used to circumvent the patent on 8080.

How could Intel get a patent on an 8-bit ALU?
There must be more to the story than that.

pec...@gmail.com <peceed@gmail.com> schrieb:
> Stefan Monnier wrote:
>> Thomas Koenig [2021-08-15 13:45:54] wrote:
>> > The Z80 is even stranger, with its 4-bit ALU for an 8-bit design,
>> > and taking multiple CPU cycles for each "machine cycle" and multiple
>> > machine cycles for each instruction.
>> For the Z80 I think the question is closed, indeed: we can clearly do
>> better with those resources. But note that part of its appeal/goal was
>> backward compatibility.
> The 4-bit ALU was used to circumvent the patent on 8080.

Ah, that makes sense.

Was it, by any chance, a patent that the later developers of the
Z80 wrote while still at Intel?

Getting around your own patents can certainly be an interesting
situation, since you are working against yourself, in a way.
because after trying to make the patent airtight in the first
place you are then trying to exploit gaps which you left.

I've never been in that particular situation, fortunately or not :-)

Thomas Koenig wrote:
> Stefan Monnier <mon...@iro.umontreal.ca> schrieb:
> > Which part of the 6502's instruction set do you find "complicated" and
> > what kind of change do you think would have reduced the number of
> > transistors needed to implement it?
> The memory operands. A load/store architecture would have saved
> a lot of decoding and sequencing and associated transistor (or,
> better measure area), which could have been used for more and bigger
> registers.
It is a false assumption. Address modes are quite orthogonal pices of logic simply triggered as kind of subroutines, they have a very dense encoding in the ISA and logic is much cheaper than RAM required for analogous memory access code.
LOAD/STORE with a lot of registers is a better target for compilers, but doesn't offer a better performance when you are constrained by 8-bit bus. Code size will be higher.
The power of RISC lies in the ability to consume high bandwidth of memory bus, easy pipelining and superscalar execution. RISC could be a viable competitor for 68k.

>
> The Z80 is even stranger, with its 4-bit ALU for an 8-bit design,
> and taking multiple CPU cycles for each "machine cycle" and multiple
> machine cycles for each instruction.
>
> Note that I am not confident that we can actually do better for
> overall performance per transistor for the 6502. For the Z80,
> I would be.
Performance per transistor is not as important. When you really need performance, CPU is a very small fraction of total system cost.
BTW, Z80 is a bigger processor than 6809, 3.4x bigger than 6502!

EricP wrote:
> pec...@gmail.com wrote:
>> Stefan Monnier wrote:
>>> Thomas Koenig [2021-08-15 13:45:54] wrote:
>>>> The Z80 is even stranger, with its 4-bit ALU for an 8-bit design,
>>>> and taking multiple CPU cycles for each "machine cycle" and multiple
>>>> machine cycles for each instruction.
>>> For the Z80 I think the question is closed, indeed: we can clearly do
>>> better with those resources. But note that part of its appeal/goal
>>> was backward compatibility.
>> The 4-bit ALU was used to circumvent the patent on 8080.
>
> How could Intel get a patent on an 8-bit ALU?
> There must be more to the story than that.

Ok, I think I see what went on.
Its not the 8-bits, its the carry propagate delay.

Intel had two 1976/77 patents on fast carry propagate circuits.
IIUC since NMOS transitions from 1 to 0 faster than 0 to 1,
they precharge all the carry logic to 1, then do a fast ripple
carry with NMOS pull-downs.
"The result is that a 16 bit adder may be fabricated which in the
worst case will add two such numbers in 30 nanoseconds or less."

Propagation line adder and method for binary addition, Intel 1976
https://patents.google.com/patent/US4031379A/

Single line propagation adder and method for binary addition, Intel 1977
https://patents.google.com/patent/US4152775A/

Designing the Z80, Federico Faggin would not have had access to
those patents and would have had to go with either a slow ripple
carry or more logic for a carry lookahead.

Instead, according to the Zilog Oral History Panel,
he went with a pipelined 4-bit ALU, saving lots of transistors,
and allowing a higher clock but getting the same performance as 8080.

MitchAlsup wrote:
> I think consensus has been achieved--we cannot do better than the 6502 guys did.
Yes, we can but in the different dimension.
We should make 6502 more forward compatible.
Lets assume, that the second processor in the line is a little adjusted 6809.
"Better 6502" should have a strict subset of instructions of bigger "better 6809", both chips should be electrically compatible.
This way we have strong market synergy between products and free upgrade path.
Removal of decimal arithmetic (we can use procedures) can give us area for two 8-bit registers.
My choice is a 16 bit stack pointer and relocatable direct page.

pec...@gmail.com <peceed@gmail.com> schrieb:
> Thomas Koenig wrote:
>> Stefan Monnier <mon...@iro.umontreal.ca> schrieb:
>> > Which part of the 6502's instruction set do you find "complicated" and
>> > what kind of change do you think would have reduced the number of
>> > transistors needed to implement it?
>> The memory operands. A load/store architecture would have saved
>> a lot of decoding and sequencing and associated transistor (or,
>> better measure area), which could have been used for more and bigger
>> registers.
> It is a false assumption. Address modes are quite orthogonal
> pices of logic simply triggered as kind of subroutines, they have
> a very dense encoding in the ISA and logic is much cheaper than
> RAM required for analogous memory access code.

Cheaper in which way?

If you look at

https://en.wikipedia.org/wiki/MOS_Technology_6502#/media/File:MOS_6502_die.jpg

you can see that the PLA and control logic (left and center)
take up more space than all the rest, including registers, ALU,
PC with adder etc.

> LOAD/STORE with a lot of registers is a better target for
> compilers, but doesn't offer a better performance when you are
> constrained by 8-bit bus. Code size will be higher.

I'm still not convinced that the overall balance would be so
bad. Remember that SWEET16 was introduced to reduce code size
at the expense of execution speed...

> The power of RISC lies in the ability to consume high bandwidth
> of memory bus, easy pipelining and superscalar execution. RISC
> could be a viable competitor for 68k.

It also needs a small decoder and few memory accesses.

On 23.07.2021 12:59, Thomas Koenig wrote:
> Another direction for retro-architectures... I've been looking
> at the 6502 a bit, and it really is quite an interesting design.
> Squeezing the functionality of a CPU into ~3500 transistors (plus
> ~1000 transistors used as resistors) was quite an achievement.
>
> Could we do better knowing what we know now?
>
> "Better" could of course mean different things - more instructions
> per cycle, possibility of higher frequency, higher code density,
> easier programming (programming the 6502 was not easy, especially
> on the C-64 where Commodore had used up almost all of the zero
> page for its Basic - I hardly ever used the X register).
>
> The boundary conditions were of course severe. 16 bit address
> bus, combined program and data bus of 8 bit. At least memory
> was rather fast and could be accessed once per cycle without
> problems (and even with the possibility of another, interleaved
> access for graphics). Plus, any more transistors were bound to
> increase the size and decrease the yield, leading to much
> higher cost and erosion of the competetive advantage that the
> 6502 and its derivatives had at the time.
>

A really interesting discussion so far, but:

Wouldn't it be a better question, what could be achieved with today's
knowledge and technology at the retail price of the 6502 at the time?

In September 1975, a 6502 was priced at USD 25, which is roughly USD 120
in today's value.

Thomas Koenig wrote:
> pec...@gmail.com <pec...@gmail.com> schrieb:
> > It is a false assumption. Address modes are quite orthogonal
> > pices of logic simply triggered as kind of subroutines, they have
> > a very dense encoding in the ISA and logic is much cheaper than
> > RAM required for analogous memory access code.
> Cheaper in which way?
$. Memory was very expensive.

> If you look at
> https://en.wikipedia.org/wiki/MOS_Technology_6502#/media/File:MOS_6502_die.jpg
> you can see that the PLA and control logic (left and center)
> take up more space than all the rest, including registers, ALU,
> PC with adder etc.
You need 8 general purpose 16-bit registers. It is the size of Z80 register set!
I estimate that around 150% of 6502 die area is required in the best case. Very close, but embedded guys have no reason to pay 80% higher price per unit. 8/16-bit RISC is a competitor to Z80/6809/8088, not the 6502.

> > LOAD/STORE with a lot of registers is a better target for
> > compilers, but doesn't offer a better performance when you are
> > constrained by 8-bit bus. Code size will be higher.
> I'm still not convinced that the overall balance would be so
> bad. Remember that SWEET16 was introduced to reduce code size
> at the expense of execution speed...

> > The power of RISC lies in the ability to consume high bandwidth
> > of memory bus, easy pipelining and superscalar execution. RISC
> > could be a viable competitor for 68k.
> It also needs a small decoder and few memory accesses.
I don't belive in a much smaller decoder compared to 6502. Essential instructions are the same, just reduced to "registry address mode", we need to synthetize 16-bit operations using 8-bit ALU, every instruction has to have up to 3 registry acceses interleaved with logical operations, the amount of major opcodes is very similar.

pec...@gmail.com <peceed@gmail.com> schrieb:
> Thomas Koenig wrote:

>> If you look at
>> https://en.wikipedia.org/wiki/MOS_Technology_6502#/media/File:MOS_6502_die.jpg
>> you can see that the PLA and control logic (left and center)
>> take up more space than all the rest, including registers, ALU,
>> PC with adder etc.
> You need 8 general purpose 16-bit registers. It is the size of Z80 register set!
> I estimate that around 150% of 6502 die area is required in
> the best case.

Based on what? Did you design such a chip?

> Very close, but embedded guys have no reason to
> pay 80% higher price per unit. 8/16-bit RISC is a competitor to
> Z80/6809/8088, not the 6502.

[...]

On Monday, August 16, 2021 at 12:24:57 PM UTC-5, EricP wrote:
> EricP wrote:
> > pec...@gmail.com wrote:
> >> Stefan Monnier wrote:
> >>> Thomas Koenig [2021-08-15 13:45:54] wrote:
> >>>> The Z80 is even stranger, with its 4-bit ALU for an 8-bit design,
> >>>> and taking multiple CPU cycles for each "machine cycle" and multiple
> >>>> machine cycles for each instruction.
> >>> For the Z80 I think the question is closed, indeed: we can clearly do
> >>> better with those resources. But note that part of its appeal/goal
> >>> was backward compatibility.
> >> The 4-bit ALU was used to circumvent the patent on 8080.
> >
> > How could Intel get a patent on an 8-bit ALU?
> > There must be more to the story than that.
> Ok, I think I see what went on.
> Its not the 8-bits, its the carry propagate delay.
>
> Intel had two 1976/77 patents on fast carry propagate circuits.
> IIUC since NMOS transitions from 1 to 0 faster than 0 to 1,
> they precharge all the carry logic to 1, then do a fast ripple
> carry with NMOS pull-downs.
<
For much the same reasons all DEC buses were 0V = 1, VDD = 0.
<
> "The result is that a 16 bit adder may be fabricated which in the
> worst case will add two such numbers in 30 nanoseconds or less."
>
> Propagation line adder and method for binary addition, Intel 1976
> https://patents.google.com/patent/US4031379A/
>
> Single line propagation adder and method for binary addition, Intel 1977
> https://patents.google.com/patent/US4152775A/
>
> Designing the Z80, Federico Faggin would not have had access to
> those patents and would have had to go with either a slow ripple
> carry or more logic for a carry lookahead.
>
> Instead, according to the Zilog Oral History Panel,
> he went with a pipelined 4-bit ALU, saving lots of transistors,
> and allowing a higher clock but getting the same performance as 8080.

On Monday, August 16, 2021 at 2:05:12 PM UTC-5, Thomas Koenig wrote:
> pec...@gmail.com <pec...@gmail.com> schrieb:
> > Thomas Koenig wrote:
> >> Stefan Monnier <mon...@iro.umontreal.ca> schrieb:
> >> > Which part of the 6502's instruction set do you find "complicated" and
> >> > what kind of change do you think would have reduced the number of
> >> > transistors needed to implement it?
> >> The memory operands. A load/store architecture would have saved
> >> a lot of decoding and sequencing and associated transistor (or,
> >> better measure area), which could have been used for more and bigger
> >> registers.
> > It is a false assumption. Address modes are quite orthogonal
> > pices of logic simply triggered as kind of subroutines, they have
> > a very dense encoding in the ISA and logic is much cheaper than
> > RAM required for analogous memory access code.
> Cheaper in which way?
>
> If you look at
>
> https://en.wikipedia.org/wiki/MOS_Technology_6502#/media/File:MOS_6502_die.jpg
>
> you can see that the PLA and control logic (left and center)
> take up more space than all the rest, including registers, ALU,
> PC with adder etc.
<
Yes, but adding registers for a LD/ST machine would add crap-loads(r)
of transistors.
>
> > LOAD/STORE with a lot of registers is a better target for
> > compilers, but doesn't offer a better performance when you are
> > constrained by 8-bit bus. Code size will be higher.
> I'm still not convinced that the overall balance would be so
> bad. Remember that SWEET16 was introduced to reduce code size
> at the expense of execution speed...
> > The power of RISC lies in the ability to consume high bandwidth
> > of memory bus, easy pipelining and superscalar execution. RISC
> > could be a viable competitor for 68k.
> It also needs a small decoder and few memory accesses.

On Monday, August 16, 2021 at 3:33:33 PM UTC-5, Thomas Koenig wrote:
> pec...@gmail.com <pec...@gmail.com> schrieb:
> > Thomas Koenig wrote:
> >> If you look at
> >> https://en.wikipedia.org/wiki/MOS_Technology_6502#/media/File:MOS_6502_die.jpg
> >> you can see that the PLA and control logic (left and center)
> >> take up more space than all the rest, including registers, ALU,
> >> PC with adder etc.
> > You need 8 general purpose 16-bit registers. It is the size of Z80 register set!
> > I estimate that around 150% of 6502 die area is required in
> > the best case.
> Based on what? Did you design such a chip?
<
A bit in the sequence ROM takes 1 transistor whether it reads a 0 or a 1.
<
A bit in a dedicated register takes 4 transistors.
A bit in an addressed register takes 7 transistors.
<
> > Very close, but embedded guys have no reason to
> > pay 80% higher price per unit. 8/16-bit RISC is a competitor to
> > Z80/6809/8088, not the 6502.
> [...]

David Schultz <david.schultz@earthlink.net> wrote:
> On 8/15/21 5:47 PM, Brett wrote:
>> David Schultz <david.schultz@earthlink.net> wrote:
>>> It looks like I will not have to dig into the paper archives:
>>> https://tlindner.macmess.org/?page_id=119
>>
>> Point 4 says no bit manipulation, but I see AND, OR, XOR, RORL, RORR, and
>> bit compare.
>> What are they talking about missing?
>>
>
> Probably specific things like the bclr, bset, and btst instructions on
> the 68000.

I fail to see how those could be expensive in die space.

What I really wanted was a barrel roller for arbitrary one cycle shifts,
but the 68000 did not have that either. A barrel roller does take up die
space, especially on a one metal process.

For the Macintosh one cycle shifts could have doubled the performance of
the machine, well worth the extra die cost.

Apple was the prime customer for the 68000, though not so early as to help
design.

After reading how rinky dink the ARM design team was, that confirmed to me
that Apple should design its own chips. Decades before such happened.

Bernd Linsel <bl1-removethis@gmx.com> wrote:
> On 23.07.2021 12:59, Thomas Koenig wrote:
>> Another direction for retro-architectures... I've been looking
>> at the 6502 a bit, and it really is quite an interesting design.
>> Squeezing the functionality of a CPU into ~3500 transistors (plus
>> ~1000 transistors used as resistors) was quite an achievement.
>>
>> Could we do better knowing what we know now?
>>
>> "Better" could of course mean different things - more instructions
>> per cycle, possibility of higher frequency, higher code density,
>> easier programming (programming the 6502 was not easy, especially
>> on the C-64 where Commodore had used up almost all of the zero
>> page for its Basic - I hardly ever used the X register).
>>
>> The boundary conditions were of course severe. 16 bit address
>> bus, combined program and data bus of 8 bit. At least memory
>> was rather fast and could be accessed once per cycle without
>> problems (and even with the possibility of another, interleaved
>> access for graphics). Plus, any more transistors were bound to
>> increase the size and decrease the yield, leading to much
>> higher cost and erosion of the competetive advantage that the
>> 6502 and its derivatives had at the time.
>>
>
> A really interesting discussion so far, but:
>
> Wouldn't it be a better question, what could be achieved with today's
> knowledge and technology at the retail price of the 6502 at the time?
>
> In September 1975, a 6502 was priced at USD 25, which is roughly USD 120
> in today's value.
>

The iPhone 12 A14 Bionic chipset is said to cost $40.
And it is pretty much the same as the M1 in the Macs which is estimated at
$40 to $50.

Thomas Koenig <tkoenig@netcologne.de> writes:

> Another direction for retro-architectures... I've been looking
> at the 6502 a bit, and it really is quite an interesting design.
> Squeezing the functionality of a CPU into ~3500 transistors (plus
> ~1000 transistors used as resistors) was quite an achievement.
>
> Could we do better knowing what we know now?
>
> "Better" could of course mean different things - more instructions
> per cycle, possibility of higher frequency, higher code density,
> easier programming (programming the 6502 was not easy, especially
> on the C-64 where Commodore had used up almost all of the zero
> page for its Basic - I hardly ever used the X register).
>
> The boundary conditions were of course severe. 16 bit address
> bus, combined program and data bus of 8 bit. At least memory
> was rather fast and could be accessed once per cycle without
> problems (and even with the possibility of another, interleaved
> access for graphics). Plus, any more transistors were bound to
> increase the size and decrease the yield, leading to much
> higher cost and erosion of the competetive advantage that the
> 6502 and its derivatives had at the time.

Apparently you can do a lot with 6502, case in point:
https://www.youtube.com/watch?v=zprSxCMlECA

On Monday, August 16, 2021 at 9:13:52 AM UTC-6, EricP wrote:

> How could Intel get a patent on an 8-bit ALU?
> There must be more to the story than that.

Good heavens, yes. The IBM System/360 Model 30 is prior art...
not to mention the Model 40 and the Model 50, which proved
that it is possible to build computers with 16-bit and 32-bit
ALUs.

....and, of course, there are many other possible examples. The
Honeywell 516, the Hewlett-Packard 2160, the PDP-11 are all
examples of computers with 16-bit ALUs.

And, of course, how on Earth did the Z-80 achieve acceptable
performance with a 4-bit ALU?

John Savard

On Monday, August 16, 2021 at 11:24:57 AM UTC-6, EricP wrote:

> Ok, I think I see what went on.
> Its not the 8-bits, its the carry propagate delay.
>
> Intel had two 1976/77 patents on fast carry propagate circuits.
> IIUC since NMOS transitions from 1 to 0 faster than 0 to 1,
> they precharge all the carry logic to 1, then do a fast ripple
> carry with NMOS pull-downs.
> "The result is that a 16 bit adder may be fabricated which in the
> worst case will add two such numbers in 30 nanoseconds or less."
>
> Propagation line adder and method for binary addition, Intel 1976
> https://patents.google.com/patent/US4031379A/
>
> Single line propagation adder and method for binary addition, Intel 1977
> https://patents.google.com/patent/US4152775A/
>
> Designing the Z80, Federico Faggin would not have had access to
> those patents and would have had to go with either a slow ripple
> carry or more logic for a carry lookahead.
>
> Instead, according to the Zilog Oral History Panel,
> he went with a pipelined 4-bit ALU, saving lots of transistors,
> and allowing a higher clock but getting the same performance as 8080.

This... sort of... explains it. I would have thought a conventional carry look-ahead
would not only be the obvious solution, but the one most likely to work and give
good performance. That a _pipelined_ 4-bit ALU could do as well is certainly an
ingenious and original idea, though.

And since they patented that trick, no doubt, it explains why the first 16-bit
processors weren't designed that way.

John Savard

On Monday, August 16, 2021 at 2:33:33 PM UTC-6, Thomas Koenig wrote:
> pec...@gmail.com <pec...@gmail.com> schrieb:

> > You need 8 general purpose 16-bit registers. It is the size of Z80 register set!
> > I estimate that around 150% of 6502 die area is required in
> > the best case.

> Based on what? Did you design such a chip?

I used to work with the TI 9900 in the 990/4 computer. Remember it?
It was one of the first 16-bit microprocessors, with an instruction set like
that of the PDP-11.
It achieved this... by putting the entire register set in external memory.
So that putting general registers on a chip takes a _lot_ of space, at least
by the standards of the 8-bit era, is very believable to me.

John Savard

On Monday, August 16, 2021 at 11:10:53 AM UTC-6, pec...@gmail.com wrote:

> The power of RISC lies in the ability to consume high bandwidth of
> memory bus, easy pipelining and superscalar execution. RISC could
> be a viable competitor for 68k.

Given that Motorola basically dropped the 68k architecture in favor
of the PowerPC, a RISC architecture, and billed their ColdFire truncated
68k embedded chips as "RISC-like", I'd say that we don't have to speculate,
we have historical proof of that.

And, earlier, in workstations, RISC chips with the MIPS architecture
competed head-to-head with workstations based on the 68000 architecture
from Apollo.

John Savard