Quadibloc <jsavard@ecn.ab.ca> schrieb:
> 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?

That was a very CISC design, taking a _lot_ of cycles for each
instruction. It is also interesting to look at the die shots -
you can see the humungous PAL very clearly.

> 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.

It would take up a lot of space, certainly - as it did the original
RISC design, or in the original ARM design that you can see at
http://blog.visual6502.org/ . For the latter, you can easily see
the layout of the register file together with the ALU, for each
bit individually (plus a huge multiplexer, which I would not use
for a 6502 competitor :-)

So, using around 40% of the tansistor budget for eight registers of 16 bits
each plus some dedicated registers does not sound outlandish iff the
control logic can be made simple enough.

Quadibloc <jsavard@ecn.ab.ca> writes:
>On Monday, August 16, 2021 at 11:24:57 AM UTC-6, EricP wrote:
>> 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.

Not very original in 1976. People had been using 1-bit ALUs and 4-bit
ALUs to implement wider operations for a long time. E.g., the
original Nova used a 4-bit ALU, and cycled it 4 times for 16-bit
operations.

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

Quadibloc <jsavard@ecn.ab.ca> writes:
>And, earlier, in workstations, RISC chips with the MIPS architecture
>competed head-to-head with workstations based on the 68000 architecture
>from Apollo.

Head-to-head? Basically everyone who sold 68k-based workstations
dropped the 68k in favour of a RISC CPU: Sun, HP, SGI, Apollo, and
(different market) Apple. Apollo was late and first lost it's leading
position in the market during 1987, and finally was bought by HP in
1989 (the Unix trend may also have had something to do with that).

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

MitchAlsup <MitchAlsup@aol.com> writes:
>A bit in the sequence ROM takes 1 transistor whether it reads a 0 or a 1.

And the addressing?

>A bit in a dedicated register takes 4 transistors.
>A bit in an addressed register takes 7 transistors.

So, if you use DRAM instead, where a bit costs 2 transistors, does
that bit with addressing overhead cost 5 transistors?

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

"pec...@gmail.com" <peceed@gmail.com> writes:
>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.

True, the addressing modes were mostly orthogonal to the rest of the
instructions, but they required control circuitry and space in the
PLA. And overall the 6502 had a number of non-programmer-visible
registers (IIRC I counted 17 8-bit registers overall), so all this
stuff was not that cheap wrt reducing registers, either.

An alternative architectural approach is to implement

1) Registers that are necessary for the data path: program counter, an
address register, ALU output, maybe ALU inputs.

2) Add a few more to make it possible to have a complete instruction
set without needing extra cycles (which would require registers for
the intermediate results): e.g., flags, return address.

The result would be a Nova-like architecture, but designed for an
8-bit data bus (which implies significant changes).

I think this could reduce the amount of control logic quite a lot
compared to the 6502, which had to have control for, e.g., saving the
return addres on a JSR and restoring the address on a RET.

With the amount of control logic saved, one might be able to afford a
16-bit data path, avoiding the need to have two cycles through the ALU
for 16-bit operations (and the corresponding control logic), or the
need to work around that in software.

Once we are there and know how much of our budget we have spent on
that, we can think about whether we can afford more fancy stuff:

* Just one or two additional registers, and/or auto-increment to avoid
the most glaring inefficiencies in the instruction set.

* A stack machine, like the b16-like architecture I have in mind.

* A register machine, like the RISC Thomas Koenig has in mind.

One might consider the various Nova-like microprocessors (PACE, mN601,
Fairchild 9440, all described and compared in
<https://en.wikipedia.org/wiki/Fairchild_9440>) as examples of the
approach I have in mind, and that it did not succeed, but I think that
they had flaws:

1) They were designed as 16-bit CPUs, both in their pin-out and in
their instruction set (both the kinds of instructions and their
width), and moreover word-addressed. The pin-out alone made sure that
they would not be picked up by the upcoming Apples, Commodores and
Tandys, Sinclairs, etc., nor by the group that designed the IBM PC.

2) And they were apparently heavily microcoded (not sure why one would
do that for this kind of architecture), requiring many clock cycles
for each instruction (alleviated somewhat by high clocks; e.g., the
Fairchild 9440 could do up to 12MHz).

The PACE was available in 1974 (according to
<https://en.wikipedia.org/wiki/Fairchild_9440>) with 4 16-bit
accumulators, which is more featureful than the minimum I have in
mind, so doing something like a have in mind in the 6502 budget should
not be that outlandish.

>The power of RISC lies in the ability to consume high bandwidth of memory bus,

Consuming a lot of bandwidth does not make an instruction set
particularly powerful, see TMS9900. I think that, on the contrary,
some of the power of RISC is thanks to keeping temporary values in
registers rather than loading them all the time from memory and
storing them back, and this reduces the amount of memory accesses
needed for a given task; and if the task consumes the same time, it
reduces the bandwidth needed.

>easy pipelining

Yes, that was RISCs major win.

>and superscalar execution.

That, too. With the advent of OoO, the drawbacks of CISC mostly
ceased to play a role.

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

On Mon, 16 Aug 2021 22:52:05 -0700 (PDT), Quadibloc
<jsavard@ecn.ab.ca> wrote:

>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?

Depends on your definition of "acceptable". Unless the code was
predominantly 16 bit operations, a 1MHz[*] 6502 routinely could
outperform even a 4MHz Z80. It wasn't until the 6MHz chips came along
that the Z80 was always faster.

[*] the 6502 was double pumped internally, so a 1MHz external clock
really meant a 2MHz chip.

Saw the same results with the 65816 vs 80286. The 65816 had no FP
unit, but on integer code an 8Mhz 65816 (in 16 bit mode) routinely
could outperform a 12Mhz 80286.

On Tuesday, August 17, 2021 at 5:24:39 AM UTC-6, George Neuner wrote:
> On Mon, 16 Aug 2021 22:52:05 -0700 (PDT), Quadibloc
> <jsa...@ecn.ab.ca> wrote:
> >And, of course, how on Earth did the Z-80 achieve acceptable
> >performance with a 4-bit ALU?

> Depends on your definition of "acceptable". Unless the code was
> predominantly 16 bit operations, a 1MHz[*] 6502 routinely could
> outperform even a 4MHz Z80. It wasn't until the 6MHz chips came along
> that the Z80 was always faster.

The Z-80 only had to compete with the 8080, not the 6502, since
CP/M wouldn't run on a 6502.

John Savard

On Tuesday, August 17, 2021 at 4:33:26 AM UTC-6, Anton Ertl wrote:
> "pec...@gmail.com" <pec...@gmail.com> writes:
> >Thomas Koenig wrote:

> >The power of RISC lies in the ability to consume high bandwidth of memory bus,

> Consuming a lot of bandwidth does not make an instruction set
> particularly powerful, see TMS9900.

It's certainly true that _wasting_ memory bus bandwidth doesn't make a
processor more powerful. But I think what he meant was that, given
efficient use of memory bus bandwidth, the power of RISC lies in
the ability to be designed with a shorter clock cycle.

He just didn't quite phrase what he meant right.

John Savard

On 8/16/21 10:20 PM, Brett wrote:
> 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.

They aren't. It was the instruction encoding that was the problem. If
you give them an 8 bit encoding, what do you throw out? With a longer
encoding, any advantage fades a bit.

--
http://davesrocketworks.com
David Schultz

On 17.08.2021 13:24, George Neuner wrote:
> On Mon, 16 Aug 2021 22:52:05 -0700 (PDT), Quadibloc
> <jsavard@ecn.ab.ca> wrote:
>
>
> Depends on your definition of "acceptable". Unless the code was
> predominantly 16 bit operations, a 1MHz[*] 6502 routinely could
> outperform even a 4MHz Z80. It wasn't until the 6MHz chips came along
> that the Z80 was always faster.
>
> [*] the 6502 was double pumped internally, so a 1MHz external clock
> really meant a 2MHz chip.
>
>
> Saw the same results with the 65816 vs 80286. The 65816 had no FP
> unit, but on integer code an 8Mhz 65816 (in 16 bit mode) routinely
> could outperform a 12Mhz 80286.
>

80286 had no FP unit either, only there was a 80287 available.
Same for 80386/87.

Only 80486 [DX] included an on-chip FP unit, but in the beginnings they
also offered an 80486SX without FP...

On 17.08.2021 15:10, Quadibloc wrote:
> On Tuesday, August 17, 2021 at 5:24:39 AM UTC-6, George Neuner wrote:
>
>
>
> The Z-80 only had to compete with the 8080, not the 6502, since
> CP/M wouldn't run on a 6502.
>
> John Savard
>

While CP/M was important for personal/home computers with 8080, 8085 and
Z80, many more 8 bit processors were used in embedded devices, where
6502/6510, 6809 and even 8031/8051 were indeed competitive...

On Tuesday, August 17, 2021 at 5:33:26 AM UTC-5, Anton Ertl wrote:
> "pec...@gmail.com" <pec...@gmail.com> writes:
> >Thomas Koenig wrote:
<snip>
> >The power of RISC lies in the ability to consume high bandwidth of memory bus,
> Consuming a lot of bandwidth does not make an instruction set
> particularly powerful, see TMS9900. I think that, on the contrary,
> some of the power of RISC is thanks to keeping temporary values in
> registers rather than loading them all the time from memory and
> storing them back, and this reduces the amount of memory accesses
> needed for a given task; and if the task consumes the same time, it
> reduces the bandwidth needed.
>
> >easy pipelining
>
> Yes, that was RISCs major win.
<
Consider that a bit more than 1/3rd of the 68020 die was microcode
(and sequencer). Essentially, the first RISCs used the area for the staging
flip-flops of the pipeline. This went from averaging 3 clocks per inst
to 1.5 clocks per instruction with only a few percent loss of semantic
density of an instruction and a significant loss in code density.
>
> >and superscalar execution.
<
That was 6 years later.
>
> That, too. With the advent of OoO, the drawbacks of CISC mostly
> ceased to play a role.
<
Which is what we were told when doing the 1st generation of RISC--
why not just hold on until the transistor budget catches up. This
is the "don't upset the cart" philosophy.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Tuesday, August 17, 2021 at 9:49:52 AM UTC-5, Bernd Linsel wrote:
> On 17.08.2021 15:10, Quadibloc wrote:
> > On Tuesday, August 17, 2021 at 5:24:39 AM UTC-6, George Neuner wrote:
> >
> >
> >
> > The Z-80 only had to compete with the 8080, not the 6502, since
> > CP/M wouldn't run on a 6502.
> >
> > John Savard
> >
> While CP/M was important for personal/home computers with 8080, 8085 and
> Z80, many more 8 bit processors were used in embedded devices, where
> 6502/6510, 6809 and even 8031/8051 were indeed competitive...

We used the 6809 for embedded controller projects as SWTPC was down the street.
Great pictures at https://deramp.com/swtpc.html
All gradually ended when PC came on the scene.

On Tue, 17 Aug 2021 16:46:57 +0200, Bernd Linsel
<bl1-removethis@gmx.com> wrote:

>On 17.08.2021 13:24, George Neuner wrote:
>> On Mon, 16 Aug 2021 22:52:05 -0700 (PDT), Quadibloc
>> <jsavard@ecn.ab.ca> wrote:
>>
>>
>> Depends on your definition of "acceptable". Unless the code was
>> predominantly 16 bit operations, a 1MHz[*] 6502 routinely could
>> outperform even a 4MHz Z80. It wasn't until the 6MHz chips came along
>> that the Z80 was always faster.
>>
>> [*] the 6502 was double pumped internally, so a 1MHz external clock
>> really meant a 2MHz chip.
>>
>>
>> Saw the same results with the 65816 vs 80286. The 65816 had no FP
>> unit, but on integer code an 8Mhz 65816 (in 16 bit mode) routinely
>> could outperform a 12Mhz 80286.
>
>80286 had no FP unit either, only there was a 80287 available.

Sorry, I should have explained that better.

There was no simple way to compare FP performance because, AFAIK,
there were no companies that made compilers or FP libraries for both
chips.

The only machine that used 65816 was Apple's //gs which - like the
Macintosh - had Apple's SANE numeric library available in ROM. Every
compiler for the //gs simply used SANE.

Different 80286 compilers had different FP emulations, and there were
stand-alone FP libraries available from different vendors, but SANE
was not among them.

Given the same SANE options, every //gs compiler produced identical
results (how could they not?). In contrast, it was hard even to get
different PC compilers to produce bit identical results ... never mind
results that were bit comparable to Apple's library running on a
different platform.

David Schultz <david.schultz@earthlink.net> wrote:
> On 8/16/21 10:20 PM, Brett wrote:
>> 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.
>
> They aren't. It was the instruction encoding that was the problem. If
> you give them an 8 bit encoding, what do you throw out? With a longer
> encoding, any advantage fades a bit.

The Rockwell 6502 added bit manipulation, there are lots of unused opcodes.

http://archive.6502.org/datasheets/rockwell_r65c00-21_r65c29.pdf

One could argue that the opcodes were saved for the 65816, but WDC failed
to produce that chip in a timely manner.

On 8/17/21 3:41 PM, Brett wrote:
> David Schultz <david.schultz@earthlink.net> wrote:
>> On 8/16/21 10:20 PM, Brett wrote:
>>> 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.
>>
>> They aren't. It was the instruction encoding that was the problem. If
>> you give them an 8 bit encoding, what do you throw out? With a longer
>> encoding, any advantage fades a bit.
>
> The Rockwell 6502 added bit manipulation, there are lots of unused opcodes.
>

I am pretty sure that the designers of the 6809 didn't care too much
about unused 6502 opcodes.

--
http://davesrocketworks.com
David Schultz

I just read the following article on TechSpot:

https://www.techspot.com/news/90826-college-student-made-own-processor-home-garage.html

However, the article had an erroneous title. If the title had not been
erroneous, then the article was about someone who did make a
"better 6502" - a microprocessor with only 100 transistors!

However, when one reads the article, one sees that, no, it wasn't
a processor that he made, but only a test chip... which is still
an incredibly impressive accomplishment in one's garage.

John Savard

On Tuesday, August 17, 2021 at 5:32:26 PM UTC-5, Quadibloc wrote:
> I just read the following article on TechSpot:
>
> https://www.techspot.com/news/90826-college-student-made-own-processor-home-garage.html
>
> However, the article had an erroneous title. If the title had not been
> erroneous, then the article was about someone who did make a
> "better 6502" - a microprocessor with only 100 transistors!
>
> However, when one reads the article, one sees that, no, it wasn't
> a processor that he made, but only a test chip... which is still
> an incredibly impressive accomplishment in one's garage.
<
Impressive !!
<
Back when I was 2 years younger than him, I made a calculator out
of a couple dozen transistors, nearly 60 resistors, 40-ish capacitors,
and 10- small light bulbs with sockets. My input device was the dial
off of a rotary phone, the output was the lights, and I had an 8 gang
switch to change from adding to subtracting. I put the thing in a box
the size of an attache case, you could open the lid and see the rats
nest of wires.
<
Won county and state science fair that year.
>
> John Savard

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:

I have to say I like the structured approach that you are proposing
below. It's a much better than just randomly tossing ideas around :-)

> True, the addressing modes were mostly orthogonal to the rest of the
> instructions, but they required control circuitry and space in the
> PLA. And overall the 6502 had a number of non-programmer-visible
> registers (IIRC I counted 17 8-bit registers overall), so all this
> stuff was not that cheap wrt reducing registers, either.
>
> An alternative architectural approach is to implement

> 1) Registers that are necessary for the data path: program counter, an
> address register, ALU output, maybe ALU inputs.

Plus the ALU, and the incrementer for the PC (which makes sense
to have independent of the ALU).

Another thing to design would be the load/store unit, which should
be able to load or store a byte at 500 ns, which the RAM at the
time could do. 1 MHz time for word-sized access sounds good.

> 2) Add a few more to make it possible to have a complete instruction
> set without needing extra cycles (which would require registers for
> the intermediate results): e.g., flags, return address.

Flags: Ack.

Return address: You mean a link register for subroutine calls,
and for interrupts?

> The result would be a Nova-like architecture, but designed for an
> 8-bit data bus (which implies significant changes).
>
> I think this could reduce the amount of control logic quite a lot
> compared to the 6502, which had to have control for, e.g., saving the
> return addres on a JSR and restoring the address on a RET.

Agreed. This is probably better implemented by BL / jump to
link register or even by two instructions.

> With the amount of control logic saved, one might be able to afford a
> 16-bit data path, avoiding the need to have two cycles through the ALU
> for 16-bit operations (and the corresponding control logic), or the
> need to work around that in software.

Agreed.

> Once we are there and know how much of our budget we have spent on
> that, we can think about whether we can afford more fancy stuff:
>
> * Just one or two additional registers, and/or auto-increment to avoid
> the most glaring inefficiencies in the instruction set.

Not sure I'm sold on the auto-increment. This would mean two
register writes per instruction, and I am envisioning this processor
as (potentially) a single-cycle machine, or at least a machine where
every instuction takes the same number of cycles, for simplicity.

One of the instructions could be the encoding of immediates
as discussed in another thread. Another could be two to four
bit immediates for ADD and SUB.

> * A stack machine, like the b16-like architecture I have in mind.
>
> * A register machine, like the RISC Thomas Koenig has in mind.

Both viable options.

[...]

MitchAlsup <MitchAlsup@aol.com> schrieb:

> Back when I was 2 years younger than him, I made a calculator out
> of a couple dozen transistors, nearly 60 resistors, 40-ish capacitors,
> and 10- small light bulbs with sockets. My input device was the dial
> off of a rotary phone, the output was the lights, and I had an 8 gang
> switch to change from adding to subtracting. I put the thing in a box
> the size of an attache case, you could open the lid and see the rats
> nest of wires.
><
> Won county and state science fair that year.

Now, that _is_ impressive.

I guess your professional career was foreshadowed by this :-)

MitchAlsup <MitchAlsup@aol.com> writes:
>On Tuesday, August 17, 2021 at 5:33:26 AM UTC-5, Anton Ertl wrote:
>> That, too. With the advent of OoO, the drawbacks of CISC mostly
>> ceased to play a role.
><
>Which is what we were told when doing the 1st generation of RISC--
>why not just hold on until the transistor budget catches up. This
>is the "don't upset the cart" philosophy.

Who told you that with what goal? Did the 68000 people try to
convince the 88000 people that the 68000 will catch up eventually? It
seems to me that the 68000's problem was not the 88000, but SPARC,
HPPA, MIPS, 29000, and eventually PowerPC (although, without these,
the 88000 would have been a problem for the 68000).

And did they refer to OoO with the transistor budget, or to
pipelining? They certainly did the pipelining with the 68040 in 1990,
and then did superscalar with the 68060 in 1994, but never did OoO.

What I meant with the drawbacks of CISC mostly ceasing to play a role
is that the separation of execution and commit would have allowed to
do complex instructions like those of the 68020 and VAX, with multiple
memory accesses, all of which can trap relatively straightforwardly:
just wait for all operations of the instruction to complete before
committing any part of the instruction, and if there is an exception,
throw all the parts away (precise exceptions rather than stack puke).

Complex instructions would still come with a cost: There have to be
enough resources available to guarantee forward progress (rather than
trapping every time), even in the worst case of all memory accesses in
conflicting cache lines and conflicting pages (in case of a
non-fully-associative TLB), and page table entries in conflicting
pages. And validating all the cases is a burden that CISCs have to
bear.

So maybe OoO would not have saved heavy CISCs like the VAX (last
implementation NVAX in 1992) and the 68020 architecture (68060 in
1994). But it seems to me that the main reason for their demise was
the decision by the computer makers to switch to RISC CPUs. IA-32 and
S/360 descendants survived based on their software legacy, and shortly
after (in case of IA-32) succeeded with OoO implementations (the S/360
descendants took much longer AFAIK).

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

Thomas Koenig <tkoenig@netcologne.de> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> An alternative architectural approach is to implement
>
>
>> 1) Registers that are necessary for the data path: program counter, an
>> address register, ALU output, maybe ALU inputs.
>
>Plus the ALU, and the incrementer for the PC (which makes sense
>to have independent of the ALU).

Yes, of course you need a data path, and there are quite a bit of
design options there.

>> 2) Add a few more to make it possible to have a complete instruction
>> set without needing extra cycles (which would require registers for
>> the intermediate results): e.g., flags, return address.
>
>Flags: Ack.
>
>Return address: You mean a link register for subroutine calls,
>and for interrupts?

Yes. However, the dedicated return address register is a thinko. One
could store the return address in the accumulator.

>> Once we are there and know how much of our budget we have spent on
>> that, we can think about whether we can afford more fancy stuff:
>>
>> * Just one or two additional registers, and/or auto-increment to avoid
>> the most glaring inefficiencies in the instruction set.
>
>Not sure I'm sold on the auto-increment. This would mean two
>register writes per instruction, and I am envisioning this processor
>as (potentially) a single-cycle machine, or at least a machine where
>every instuction takes the same number of cycles, for simplicity.

Given that the registers are dedicated registers, you can write the
incremented address in the same cycle as the read data, they just need
to be on different buses. E.g., the PC is auto-incremented every time
an instruction byte is loaded.

As for single-cycle, you certainly need two memory cycles for a byte
load and a byte store (one for the instruction, one for the data), and
three memory cycles if you also want to implement word load and word
store.

Given that you want a separate incrementer for the PC in the data
path, you could also use that incrementer for the address register.
If you support word loads and word stores, incrementing the address
register is necessary anyway, unless words can only be accessed at
even addresses; in the latter case, one byte would be loaded from the
top 15bits of the address and 0 for the least-significant bit, the
next byte with 1 for the lsb.

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

On Wednesday, August 18, 2021 at 12:19:00 PM UTC+3, Anton Ertl wrote:
>
> So maybe OoO would not have saved heavy CISCs like the VAX (last
> implementation NVAX in 1992) and the 68020 architecture (68060 in
> 1994). But it seems to me that the main reason for their demise was
> the decision by the computer makers to switch to RISC CPUs. IA-32 and
> S/360 descendants survived based on their software legacy, and shortly
> after (in case of IA-32) succeeded with OoO implementations (the S/360
> descendants took much longer AFAIK).
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

It seems, OoO implementations of S/360 and descendants is [so far] a story of three chapters.
Chapter 1. is Tomasulo's S/360 Model 91/191. This chapter was brief. I am not sure how to call it, a failure or a limited success.
Chapter 2. are water-cooled S/390 Models 820 and 900. Replaced by simpler "CMOS" models.
Chapter 3 started with z196 in 2010 and is still going (zEC12, z13, z14, z15).

Thomas Koenig wrote:
> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
>
> I have to say I like the structured approach that you are proposing
> below. It's a much better than just randomly tossing ideas around :-)
> > True, the addressing modes were mostly orthogonal to the rest of the
> > instructions, but they required control circuitry and space in the
> > PLA. And overall the 6502 had a number of non-programmer-visible
> > registers (IIRC I counted 17 8-bit registers overall), so all this
> > stuff was not that cheap wrt reducing registers, either.
> >
> > An alternative architectural approach is to implement
>
>
> > 1) Registers that are necessary for the data path: program counter, an
> > address register, ALU output, maybe ALU inputs.
> Plus the ALU, and the incrementer for the PC (which makes sense
> to have independent of the ALU).
>
> Another thing to design would be the load/store unit, which should
> be able to load or store a byte at 500 ns, which the RAM at the
> time could do. 1 MHz time for word-sized access sounds good.
Don't forget to hire a fairy to refresh the dram: P Without her you have 0.5Mhz for word-sized access.
What we can do better is a smart refresher integrated with prefetcher.
> > 2) Add a few more to make it possible to have a complete instruction
> > set without needing extra cycles (which would require registers for
> > the intermediate results): e.g., flags, return address.
> Flags: Ack.
>
> Return address: You mean a link register for subroutine calls,
> and for interrupts?
> > The result would be a Nova-like architecture, but designed for an
> > 8-bit data bus (which implies significant changes).
> >
> > I think this could reduce the amount of control logic quite a lot
> > compared to the 6502, which had to have control for, e.g., saving the
> > return addres on a JSR and restoring the address on a RET.
> Agreed. This is probably better implemented by BL / jump to
> link register or even by two instructions.
> > With the amount of control logic saved, one might be able to afford a
> > 16-bit data path, avoiding the need to have two cycles through the ALU
> > for 16-bit operations (and the corresponding control logic), or the
> > need to work around that in software.
> Agreed.
> > Once we are there and know how much of our budget we have spent on
> > that, we can think about whether we can afford more fancy stuff:
> >
> > * Just one or two additional registers, and/or auto-increment to avoid
> > the most glaring inefficiencies in the instruction set.
> Not sure I'm sold on the auto-increment. This would mean two
> register writes per instruction, and I am envisioning this processor
> as (potentially) a single-cycle machine,
2r1w register file is _impossible_.
> or at least a machine where
> every instuction takes the same number of cycles, for simplicity.
What about shift operation?
Complication is marginal - there is no pipelining, every RISC operation is translated into sequence of internal operations anyway. The gains are substantial in both speed and code density. Writing the result of post-increment to the register may ovelap with the execution of the next instruction.
> One of the instructions could be the encoding of immediates
> as discussed in another thread. Another could be two to four
> bit immediates for ADD and SUB.
> > * A stack machine, like the b16-like architecture I have in mind.
> >
> > * A register machine, like the RISC Thomas Koenig has in mind.
> Both viable options.
>
> [...]

> With the amount of control logic saved, one might be able to afford a
> 16-bit data path, avoiding the need to have two cycles through the ALU
> for 16-bit operations (and the corresponding control logic), or the
> need to work around that in software.

I think as long as you're stuck with an accumulator design (i.e.
a very small number of registers), the benefits of a 16bit datapath
would be marginal, since you still constantly need to read or write
it to memory (in 2 steps, given the 8bit memory bus).

For the CPUs of the time, performance was dictated by the number of
bytes going over the memory bus. So I think the main focus should be on
maximizing the number of registers (to reduce the amount of data memory
accesses) while keeping the instruction encoding compact (to reduce the
amount of instruction memory accesses), which calls for implicit
register references, as is the case in stack machines and (to a lesser
extent) belt machines.

Stefan