On 2021-07-31 18:48, MitchAlsup wrote:
> On Saturday, July 31, 2021 at 7:23:02 AM UTC-5, Thomas Koenig wrote:
>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>> If you take the basic concept of a 6502 (single-byte instructions,
>>>> heavy on sequencing, but not as heavy as the Z80) I think they
>>>> were pretty close to optimum on the cost/performance curve.
>>>
>>> What makes you think so? Admittedly, we have not seen anything
>>> guaranteed to be better, but then it's expensive (maybe a person-year)
>>> and commercially pointless to design a CPU with 1975 technology today.
>>>
>>>> To expand a little on a previous post, I still think that a
>>>> proto-RISC design could have been superior. A design with
>>>>
>>>> - All 16 bit instructions only
>>>> - Load/store architecture
>>>> - 16 registers of 16 bits each
>>>> - Eight bit opcode, eight bit data
>>>> - Possibility of 16-bit immediates for all arithmetic
>>>> operations, load and store for the address
>>>> - Format: op Ra, Ra or op Ra, #immediate (4 bits)
>>>>
>>>> can probably be made to fit on a 6502-sized die using the
>>>> technology of the day.
>>>
>>> I see lots of things that make it more expensive:
>>>
>>> 16-bit ALU
>> The ALU should perform:
>>
>> - ADD, SUB, ADDC, SUBC
>> - OR, AND, NOT, XOR
>> - ROL, ROR, ASL
>>
>> The most expensive part is the adder (used as adder subtractor
>> of course). A 16-bit ripple-carry adder (have to leave _some_
>> room for improvement) including the xor is about 500 transistors
>>
>> Shift instructions are just wiring. AND, OR and NOT are cheap, for
>> XOR, the XOR from the adder/subtractor can be re-used.
> <
> Shift instructions require multiplexers.

Are we talking about variable shifts, or 6502-style single-step shifts?

The latter would only be wiring (one fixed wiring per shift opcode).

>>
>> The processor should probably be set up so that the ALU also
>> does branch calculations.
>>
>> So, ~ 700-800 transistors for the ALU including the multiplexers.
>>> 16 registers of 16 bits (in addition to PC and status? or are they included?)
>> 16 registers of 16 bits is 256 bits, four transistors each (like they
>> did on the actual 6502), with multiplexers, lets's say 1200 transistors.
> <
> The 4 transistors make up the storage unit, but you have not added the
> read (mux) or write ports, so the count is a bit higher.
>>
>> 2000 so far.
>>> Bernd Paysan's suggestion of using DRAM for registers might help here.
>>> longer instruction buffer (especially with the 16-bit immediates)
>>>
>>> What might make it cheaper:
>>>
>>> Depending on the instruction set: A simpler decoder with fewer cycles
>>> to generate signals for (although 6502 was ingenious in minimizing the
>>> microcode for its instruction set). Looking at the 6502 die shot
>>> description in
>>> <https://en.wikipedia.org/wiki/MOS_Technology_6502#Technical_description>,
>>> apparently half of the 6502 was dedicated to control (microcode PLA
>>> and random), so there is substantial room for improvement here.
> <
> Like Mc 88100, 6502 used a single NOR plane as microcode.
> <
>> That was the point I was trying to get across. A proto-RISC 16-bit
>> processor could get by without much of the sequencing and control
>> logic on the 6502. Let's say the additional logic is implemented
>> in 1500 transistors (not unreasonable), and we're up to 3500.
>>>> Of course, such a design would be screaming to have a 16-bit
>>>> data bus. Power, Ground, Memory ready, IRQ, Reset, Read/Write,
>>>> NMI, Clock. Would that be enough?
>>>
>>> The 6502 has an extra VSS pin, 3 N.C. (not connected?) pins, a sync
>>> pin, an S0 pin and two clock-out pins in addition. Not sure what the
>>> sync and S0 pins are good for, but if you can do without all these
>>> pins, a 16-bit data bus would be technically possible.
>>
>>> But the result does not fit your original requirements, and in 1975
>>> would have been a commercial failure. Remember that for the 1981 IBM
>>> PC, IBM chose the 8088 over the 8086, because a system with a 16-bit
>>> data bus is significantly more expensive than one with an 8-bit data
>>> bus.
>> You're right, this could be a significant bottleneck, but maybe still
>> better than a 6502.

>  Stephen Fuld wrote:
> > To expand a little on a previous post, I still think that a
> > proto-RISC design could have been superior. A design with
> > - All 16 bit instructions only
> > - Load/store architecture
> > - 16 registers of 16 bits each
> > - Eight bit opcode, eight bit data
> > - Possibility of 16-bit immediates for all arithmetic
> > operations, load and store for the address
> > - Format: op Ra, Ra or op Ra, #immediate (4 bits)
> >
> > can probably be made to fit on a 6502-sized die using the
> > technology of the day.
> >
> > Of course, such a design would be screaming to have a 16-bit
> > data bus.
> Yes. With only an 8 bit bus, every instruction will require two memory
> reads to fetch the instruction, which will substantially hurt
> performance. 8088 anyone? :-(
6502 fetches 2 bytes per instruction anyway, so what is the problem?
Performance depends on total code density, it can be comparable for 8 bit, and much better for 16 bit arithmetic.
16 registers can be optional for next generation, 8 is enough for early variants and increases interrupt performance.
There is no 2r1w register file (too expensive), so processor needs much higher internal clock like Z80.

On Saturday, July 31, 2021 at 12:31:34 PM UTC-5, Marcus wrote:
> On 2021-07-31 18:48, MitchAlsup wrote:
> > On Saturday, July 31, 2021 at 7:23:02 AM UTC-5, Thomas Koenig wrote:
> >> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> >>> Thomas Koenig <tko...@netcologne.de> writes:
> >>>> If you take the basic concept of a 6502 (single-byte instructions,
> >>>> heavy on sequencing, but not as heavy as the Z80) I think they
> >>>> were pretty close to optimum on the cost/performance curve.
> >>>
> >>> What makes you think so? Admittedly, we have not seen anything
> >>> guaranteed to be better, but then it's expensive (maybe a person-year)
> >>> and commercially pointless to design a CPU with 1975 technology today.
> >>>
> >>>> To expand a little on a previous post, I still think that a
> >>>> proto-RISC design could have been superior. A design with
> >>>>
> >>>> - All 16 bit instructions only
> >>>> - Load/store architecture
> >>>> - 16 registers of 16 bits each
> >>>> - Eight bit opcode, eight bit data
> >>>> - Possibility of 16-bit immediates for all arithmetic
> >>>> operations, load and store for the address
> >>>> - Format: op Ra, Ra or op Ra, #immediate (4 bits)
> >>>>
> >>>> can probably be made to fit on a 6502-sized die using the
> >>>> technology of the day.
> >>>
> >>> I see lots of things that make it more expensive:
> >>>
> >>> 16-bit ALU
> >> The ALU should perform:
> >>
> >> - ADD, SUB, ADDC, SUBC
> >> - OR, AND, NOT, XOR
> >> - ROL, ROR, ASL
> >>
> >> The most expensive part is the adder (used as adder subtractor
> >> of course). A 16-bit ripple-carry adder (have to leave _some_
> >> room for improvement) including the xor is about 500 transistors
> >>
> >> Shift instructions are just wiring. AND, OR and NOT are cheap, for
> >> XOR, the XOR from the adder/subtractor can be re-used.
> > <
> > Shift instructions require multiplexers.
>
> Are we talking about variable shifts, or 6502-style single-step shifts?
>
> The latter would only be wiring (one fixed wiring per shift opcode).
<
You still need to select between the ROR, ROL, and ASL and that requires
said multiplexer.
>
> >>
> >> The processor should probably be set up so that the ALU also
> >> does branch calculations.
> >>
> >> So, ~ 700-800 transistors for the ALU including the multiplexers.
> >>> 16 registers of 16 bits (in addition to PC and status? or are they included?)
> >> 16 registers of 16 bits is 256 bits, four transistors each (like they
> >> did on the actual 6502), with multiplexers, lets's say 1200 transistors.
> > <
> > The 4 transistors make up the storage unit, but you have not added the
> > read (mux) or write ports, so the count is a bit higher.
> >>
> >> 2000 so far.
> >>> Bernd Paysan's suggestion of using DRAM for registers might help here.
> >>> longer instruction buffer (especially with the 16-bit immediates)
> >>>
> >>> What might make it cheaper:
> >>>
> >>> Depending on the instruction set: A simpler decoder with fewer cycles
> >>> to generate signals for (although 6502 was ingenious in minimizing the
> >>> microcode for its instruction set). Looking at the 6502 die shot
> >>> description in
> >>> <https://en.wikipedia.org/wiki/MOS_Technology_6502#Technical_description>,
> >>> apparently half of the 6502 was dedicated to control (microcode PLA
> >>> and random), so there is substantial room for improvement here.
> > <
> > Like Mc 88100, 6502 used a single NOR plane as microcode.
> > <
> >> That was the point I was trying to get across. A proto-RISC 16-bit
> >> processor could get by without much of the sequencing and control
> >> logic on the 6502. Let's say the additional logic is implemented
> >> in 1500 transistors (not unreasonable), and we're up to 3500.
> >>>> Of course, such a design would be screaming to have a 16-bit
> >>>> data bus. Power, Ground, Memory ready, IRQ, Reset, Read/Write,
> >>>> NMI, Clock. Would that be enough?
> >>>
> >>> The 6502 has an extra VSS pin, 3 N.C. (not connected?) pins, a sync
> >>> pin, an S0 pin and two clock-out pins in addition. Not sure what the
> >>> sync and S0 pins are good for, but if you can do without all these
> >>> pins, a 16-bit data bus would be technically possible.
> >>
> >>> But the result does not fit your original requirements, and in 1975
> >>> would have been a commercial failure. Remember that for the 1981 IBM
> >>> PC, IBM chose the 8088 over the 8086, because a system with a 16-bit
> >>> data bus is significantly more expensive than one with an 8-bit data
> >>> bus.
> >> You're right, this could be a significant bottleneck, but maybe still
> >> better than a 6502.

On Saturday, July 31, 2021 at 12:42:10 PM UTC-5, pec...@gmail.com wrote:
> > Stephen Fuld wrote:
> > > To expand a little on a previous post, I still think that a
> > > proto-RISC design could have been superior. A design with
> > > - All 16 bit instructions only
> > > - Load/store architecture
> > > - 16 registers of 16 bits each
> > > - Eight bit opcode, eight bit data
> > > - Possibility of 16-bit immediates for all arithmetic
> > > operations, load and store for the address
> > > - Format: op Ra, Ra or op Ra, #immediate (4 bits)
> > >
> > > can probably be made to fit on a 6502-sized die using the
> > > technology of the day.
> > >
> > > Of course, such a design would be screaming to have a 16-bit
> > > data bus.
> > Yes. With only an 8 bit bus, every instruction will require two memory
> > reads to fetch the instruction, which will substantially hurt
> > performance. 8088 anyone? :-(
> 6502 fetches 2 bytes per instruction anyway, so what is the problem?
<
> Performance depends on total code density,
<
Performance depends entirely on the total number of memory references.
<
> it can be comparable for 8 bit, and much better for 16 bit arithmetic.
> 16 registers can be optional for next generation, 8 is enough for early variants and increases interrupt performance.
<
Both PDP-11 and Nova got away with fewer registers. PDP-11 had 8.
<
> There is no 2r1w register file (too expensive), so processor needs much higher internal clock like Z80.

Marcus <m.delete@this.bitsnbites.eu> schrieb:
> On 2021-07-31 18:48, MitchAlsup wrote:
>> On Saturday, July 31, 2021 at 7:23:02 AM UTC-5, Thomas Koenig wrote:
>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
>>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>>> If you take the basic concept of a 6502 (single-byte instructions,
>>>>> heavy on sequencing, but not as heavy as the Z80) I think they
>>>>> were pretty close to optimum on the cost/performance curve.
>>>>
>>>> What makes you think so? Admittedly, we have not seen anything
>>>> guaranteed to be better, but then it's expensive (maybe a person-year)
>>>> and commercially pointless to design a CPU with 1975 technology today.
>>>>
>>>>> To expand a little on a previous post, I still think that a
>>>>> proto-RISC design could have been superior. A design with
>>>>>
>>>>> - All 16 bit instructions only
>>>>> - Load/store architecture
>>>>> - 16 registers of 16 bits each
>>>>> - Eight bit opcode, eight bit data
>>>>> - Possibility of 16-bit immediates for all arithmetic
>>>>> operations, load and store for the address
>>>>> - Format: op Ra, Ra or op Ra, #immediate (4 bits)
>>>>>
>>>>> can probably be made to fit on a 6502-sized die using the
>>>>> technology of the day.
>>>>
>>>> I see lots of things that make it more expensive:
>>>>
>>>> 16-bit ALU
>>> The ALU should perform:
>>>
>>> - ADD, SUB, ADDC, SUBC
>>> - OR, AND, NOT, XOR
>>> - ROL, ROR, ASL
>>>
>>> The most expensive part is the adder (used as adder subtractor
>>> of course). A 16-bit ripple-carry adder (have to leave _some_
>>> room for improvement) including the xor is about 500 transistors
>>>
>>> Shift instructions are just wiring. AND, OR and NOT are cheap, for
>>> XOR, the XOR from the adder/subtractor can be re-used.
>> <
>> Shift instructions require multiplexers.
>
> Are we talking about variable shifts, or 6502-style single-step shifts?
> The latter would only be wiring (one fixed wiring per shift opcode).

I had envisioned only single-step shifts left and right, like the 6502,
so once the right instruction is selected it's just wire. Fitting
a barrel shifter into < 5000 transistors seems over-ambitious. Leave
opcode space for later revisions, that's all.

However, multiplexers are still needed to select between the different
wires (not sure if that was what Mitch meant).

I would also leave out a multiplier, the 6809 has demonstrated that
customers would not be willing to pay for that.

What I would include, however, is something like an ANDC Ra, Rb -
instruction, AND register with carry, for the shift and add method
of multiplication.

MitchAlsup <MitchAlsup@aol.com> schrieb:
(I wrote)
>> 16 registers of 16 bits is 256 bits, four transistors each (like they
>> did on the actual 6502), with multiplexers, lets's say 1200 transistors.
><
> The 4 transistors make up the storage unit, but you have not added the
> read (mux) or write ports, so the count is a bit higher.

OK.

> Like Mc 88100, 6502 used a single NOR plane as microcode.

That would probably be the way to go, too. However, they also had
an afwul lot of sequencing logic, which I would try to get rid of
as far as possible.

Hm... does anybody (Anton?) have a few students who
could do Master's thesis implementing and simulating the
different 6502 competitors we have been discussing here?

https://github.com/hneemann/Digital/tree/master/src/main/dig/processor
is a design that could probably be modified pretty easily
(i.e. simplified) to one of be one of these competitors.

pec...@gmail.com <peceed@gmail.com> schrieb:

>> Yes. With only an 8 bit bus, every instruction will require two memory
>> reads to fetch the instruction, which will substantially hurt
>> performance. 8088 anyone? :-(
> 6502 fetches 2 bytes per instruction anyway, so what is the problem?

Still awkward, like I said, such a design screams for a 16-bit
data bus.

[...]

> There is no 2r1w register file (too expensive), so processor needs much higher internal clock like Z80.

2r1w seems doable, but I haven't yet figured out how to do a
multiplexer in depletion-load NMOS. Higher internal clock is what
I would like to avoid if at all possible, because that would put
all the sequencing logic back, the many registers would not
fit on the die any more, and the concept would not fly.

On Saturday, July 31, 2021 at 1:30:21 PM UTC-5, Thomas Koenig wrote:
> pec...@gmail.com <pec...@gmail.com> schrieb:
> >> Yes. With only an 8 bit bus, every instruction will require two memory
> >> reads to fetch the instruction, which will substantially hurt
> >> performance. 8088 anyone? :-(
> > 6502 fetches 2 bytes per instruction anyway, so what is the problem?
> Still awkward, like I said, such a design screams for a 16-bit
> data bus.
>
> [...]
> > There is no 2r1w register file (too expensive), so processor needs much higher internal clock like Z80.
> 2r1w seems doable, but I haven't yet figured out how to do a
> multiplexer in depletion-load NMOS.
<
Pass gate logic.
<
> Higher internal clock is what
> I would like to avoid if at all possible, because that would put
> all the sequencing logic back, the many registers would not
> fit on the die any more, and the concept would not fly.

> MitchAlsup wrote:
> > Performance depends on total code density,
> Performance depends entirely on the total number of memory references.
It means the same when you have minimal 8-bit bus and load-store architecture: the lack of 8-bit individual instructions doesn't matter. General tradeoff of RISC is a higher instruction bandwidth and a lower data bandwidth.

BTW, i think that the Universe with 12-bit bytes and microcomputers could be better: the transition from 24 bit to 48 bit address spaces would be both earlier and "final", only "supercomputers" need go higher. Home computers could stay 24-bit until mid-nineties. In 8-bit reality we got 2 quick transitions one after another.
12-bit is better for graphics (screen positions up to 4K resolution, true color on 2 bytes, direct 4096 hi-color on Amiga/Atari, independent hdr components), unicode-like standard could be adopted earlier. 48 bit floating point is sufficient for most purposes, etc.

> > it can be comparable for 8 bit, and much better for 16 bit arithmetic.
> > 16 registers can be optional for next generation, 8 is enough for early variants and increases interrupt performance.
> <
> Both PDP-11 and Nova got away with fewer registers. PDP-11 had 8.
We can call it "Reduced RISC" :), but 4 (as in Nova) is too little to get performance advantage and we need 5 to get minimal comfort of usability. I suppose that 8 16-bit register file will be too hard for die size, so 6 can be a optimal value.

6502 was, in most of its commercial applications, a real 8 bit computer, embedded systems didn't have more than 256 bytes of memory. It was also many times faster than required.
Microcomputer-centric improvements were totally obsolete, BCD support was the most important feature :)

The "problem" with original 6502 was that it couldn't have natural performance oriented extension, that is the real reason why 65816 was so late. RRISC can, but only within 16-bit address space, so it has to be a very quick follower.

That's why I would like to have 2 variants - initial, maximally simple to conquer the embedded world, and fully socket compatible powerful extension for microcomputers.

In more advanced variant I would like to have a prefetch/loop buffer for 3-4 instructions (6-8 bytes),
after every executed short backward branch prefetch starts act as loop buffer. First execution of the loop body is slower than the following one. Hardware MUL is considered useful.

The next step is variant having 16-bit data bus.
How to overcome address limitations?
The most elegant and efficient way is to implement 32bit registers as register pairs and add new instructions for memory access.

> > 6502 fetches 2 bytes per instruction anyway, so what is the problem?
> Still awkward, like I said, such a design screams for a 16-bit
> data bus.
Welcome to 1975.
Remember, 5 years later 68000 lost to 8088 due to lack of 8-bit bus support!
At least our 16-bit orientation gives possibility of performance upgrade - as long as you don't use 8-bit or unaligned 16-bit access.
> [...]
> > There is no 2r1w register file (too expensive), so processor needs much higher internal clock like Z80.
> 2r1w seems doable, but I haven't yet figured out how to do a
> multiplexer in depletion-load NMOS. Higher internal clock is what
> I would like to avoid if at all possible, because that would put
> all the sequencing logic back, the many registers would not
> fit on the die any more, and the concept would not fly.
Sorry, i was thinking not about an internal clock, but high external clock and multi-cycle memory access.
BTW, IIRC 6502 was internally "double pumped".

On 7/31/2021 2:25 PM, pec...@gmail.com wrote:
>> MitchAlsup wrote:
>>> Performance depends on total code density,
>> Performance depends entirely on the total number of memory references.
> It means the same when you have minimal 8-bit bus and load-store architecture: the lack of 8-bit individual instructions doesn't matter. General tradeoff of RISC is a higher instruction bandwidth and a lower data bandwidth.
>
> BTW, i think that the Universe with 12-bit bytes and microcomputers could be better: the transition from 24 bit to 48 bit address spaces would be both earlier and "final", only "supercomputers" need go higher. Home computers could stay 24-bit until mid-nineties. In 8-bit reality we got 2 quick transitions one after another.
> 12-bit is better for graphics (screen positions up to 4K resolution, true color on 2 bytes, direct 4096 hi-color on Amiga/Atari, independent hdr components), unicode-like standard could be adopted earlier. 48 bit floating point is sufficient for most purposes, etc.

Interesting. And, it naturally allows Mitch's preferred instruction
size of 36 bits!

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Stephen Fuld wrote:
> On 7/31/2021 2:25 PM, pec...@gmail.com wrote:
> > BTW, i think that the Universe with 12-bit bytes and microcomputers could be better: the transition from 24 bit to 48 bit address spaces would be both earlier and "final", only "supercomputers" need go higher. Home computers could stay 24-bit until mid-nineties. In 8-bit reality we got 2 quick transitions one after another.
> > 12-bit is better for graphics (screen positions up to 4K resolution, true color on 2 bytes, direct 4096 hi-color on Amiga/Atari, independent hdr components), unicode-like standard could be adopted earlier. 48 bit floating point is sufficient for most purposes, etc.
> Interesting. And, it naturally allows Mitch's preferred instruction
> size of 36 bits!
Variable length would be much more practical.
We need one single byte (12-bit) instruction - NOP (padding for no cross page instructions )
90% of instructions should fit in 2 bytes (24 bits).

pec...@gmail.com <peceed@gmail.com> schrieb:
> Thomas Koenig wrote:
>> 2r1w seems doable, but I haven't yet figured out how to do a
>> multiplexer in depletion-load NMOS.
>
> Forget it: 2r1w is too big. We are trying to be better than one
> the smallest processors ever designed.

OK, then try something else...

If we must have two cycles to access a full instruction, then the
fist byte could contain the register number of the instruction
that needs to be read, if any. Fetching the second part of the
instruction would then be parallel to reading the fist register
and putting it into an intermediate register.

Call it proto-pipelining on the proto-RISC we are discussing.

>> Forget it: 2r1w is too big. We are trying to be better than one
>> the smallest processors ever designed.
> OK, then try something else...

Maybe a belt-style architecture?

Have a 8-elements belt (16bit each), where operations push their result
on the belt (dropping the last belt element into /dev/null), and have
arithmetic operations take one of their inputs from the "top" of
the belt and the other from one of the *other* elements.
So you only need 1 read port on "the top" and 1 read port on "the rest".

Stefan

On 8/1/2021 8:46 AM, Stefan Monnier wrote:
>>> Forget it: 2r1w is too big. We are trying to be better than one
>>> the smallest processors ever designed.
>> OK, then try something else...
>
> Maybe a belt-style architecture?
>
> Have a 8-elements belt (16bit each), where operations push their result
> on the belt (dropping the last belt element into /dev/null), and have
> arithmetic operations take one of their inputs from the "top" of
> the belt and the other from one of the *other* elements.
> So you only need 1 read port on "the top" and 1 read port on "the rest".
>
>
> Stefan
>

That works best if the dataflow is left-linear or can be made so by the
compiler. Otherwise you have a lot of "move one of rest to top".

Also, if the "rest" addressing works the way it does in a Mill, with
temporal addressing in the source being mapped to in-flight bypass
latches, then I don't think you can fit the mapper into the transistor
budget available.

Or maybe you can - you no longer need muxes to address a regfile, so you
could put those transistors into the mapper, which means the routing
cost is much the same. But there's still translation cost, and the
spiller, and ... So I'm doubtful.

We've always said that the Mill cannot reach the extreme low end and the
Z80 market is safe from us, but if you can figure out a way to do it,
please get in touch :-)

> Also, if the "rest" addressing works the way it does in a Mill, with
> temporal addressing in the source being mapped to in-flight bypass latches,
> then I don't think you can fit the mapper into the transistor
> budget available.

Hmm... I think in the context of 4k transitors there'd be no "bypass
latches". The only thing you have is that when a new value is put into
the accumulator (aka the "top of the belt") the old value is not lost
but is shifted to the rest of belt instead.

> Or maybe you can - you no longer need muxes to address a regfile, so you
> could put those transistors into the mapper, which means the routing cost is
> much the same. But there's still translation cost, and the spiller, and
> ... So I'm doubtful.

No spiller. No "phi nodes". It's up to the programmer to arrange for
different control flows to end up with the same values at the same
places in the belt, or otherwise to just not use those belt locations.
These CPUs were coded in hand-tuned assembly, so it seems
perfectly acceptable.

Stefan

In article <jwvczqxaym8.fsf-monnier+comp.arch@gnu.org>,
monnier@iro.umontreal.ca (Stefan Monnier) wrote:

> No spiller. No "phi nodes". It's up to the programmer to
> arrange for different control flows to end up with the same
> values at the same places in the belt, or otherwise to just
> not use those belt locations. These CPUs were coded in hand-
> tuned assembly, so it seems perfectly acceptable.

Except for customer resistance. A belt would be a completely new idea at
the time, and most of the people programming 8-bit microprocessors had no
computer science training. It could readily acquire a reputation as
"really clever, but too hard to program."

John

John Dallman [2021-08-01 22:45:00] wrote:
> In article <jwvczqxaym8.fsf-monnier+comp.arch@gnu.org>,
> monnier@iro.umontreal.ca (Stefan Monnier) wrote:
>> No spiller. No "phi nodes". It's up to the programmer to
>> arrange for different control flows to end up with the same
>> values at the same places in the belt, or otherwise to just
>> not use those belt locations. These CPUs were coded in hand-
>> tuned assembly, so it seems perfectly acceptable.
> Except for customer resistance. A belt would be a completely new idea at
> the time, and most of the people programming 8-bit microprocessors had no
> computer science training.

"No CS training" makes it sound like they should have no bias towards
any pre-existing ISA, so they should not offer any special resistance to
a belt (they wouldn't even know it's a new idea).

> It could readily acquire a reputation as "really clever, but too hard
> to program."

I'm not sure that it's "really clever" nor whether it gives a good
result, but in the context of trying to come up with a better CPU within
the constraints of the 6502's budget it might be worth exploring.
It might be too hard to program, indeed, but then again the CPUs of that
era required a fair bit of work to program effectively, and it would be
easy to let the assembler do some of the work for you (e.g. lets you give
a name to a result, and when you refer to it later the assembler turns
it into the corresponding belt position or signals an error if the value
is not on the belt any more or emit a warning if a label was encountered
in between).

Stefan

Thomas Koenig wrote:
> If we must have two cycles to access a full instruction, then the
> fist byte could contain the register number of the instruction
> that needs to be read, if any. Fetching the second part of the
> instruction would then be parallel to reading the fist register
> and putting it into an intermediate register.
>
> Call it proto-pipelining on the proto-RISC we are discussing.
I had exactly the same idea. Instruction format should be defined this way, that first nibble is a "always read" register. Single 8 bit memory access takes 2 cycles, so pipelining is an attractive idea.
Reading the shortest instruction takes 4 cycles, fast implementation with 16 bit adder should be executed in the same time, so 16 bit RISC on 8 bit bus makes sense - we can saturate bandwidth executing register-register operations.
We have time to read 2 values, but it requires second intermediate register and doesn't save time.

John Dallman wrote:
> In article <jwvczqxaym8.fsf-...@gnu.org>,
> mon...@iro.umontreal.ca (Stefan Monnier) wrote:
>
> > No spiller. No "phi nodes". It's up to the programmer to
> > arrange for different control flows to end up with the same
> > values at the same places in the belt, or otherwise to just
> > not use those belt locations. These CPUs were coded in hand-
> > tuned assembly, so it seems perfectly acceptable.
> Except for customer resistance. A belt would be a completely new idea at
> the time, and most of the people programming 8-bit microprocessors had no
> computer science training. It could readily acquire a reputation as
> "really clever, but too hard to program."
It is easy to solve by using named variables having limited implicite scope in the source instead of variable belt positions.
This way programming can be _easier_ , because of meaningful names.

The real problem is that belt semantics doesn't offer anything meaningful for ultra-low-end except a little higher code density (albeit patent protection can be substantial).
Belt can be a virtual mapping of fragment of physical registers. The obvious solution is to contain belt positions and permanent registers in the same "specifier space". Not 8+8, more like 4-6+12-10. MOV is used instead of spill.
I suppose it is out of our scope. The only upgrade path is to make proto-risc first and then update it by a new mode to proto-belt.

BTW, We can see accumulators as a degenerated belts having one position.

On 8/1/2021 2:44 PM, John Dallman wrote:
> In article <jwvczqxaym8.fsf-monnier+comp.arch@gnu.org>,
> monnier@iro.umontreal.ca (Stefan Monnier) wrote:
>
>> No spiller. No "phi nodes". It's up to the programmer to
>> arrange for different control flows to end up with the same
>> values at the same places in the belt, or otherwise to just
>> not use those belt locations. These CPUs were coded in hand-
>> tuned assembly, so it seems perfectly acceptable.
>
> Except for customer resistance. A belt would be a completely new idea at
> the time, and most of the people programming 8-bit microprocessors had no
> computer science training. It could readily acquire a reputation as
> "really clever, but too hard to program."

But to the old timers is is almost a stack machine. But it has the
advantage that a lot of the "move to top of stack" instructions can be
replaced by a direct "stack address".

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 8/2/2021 10:20 AM, pec...@gmail.com wrote:
> John Dallman wrote:
>> In article <jwvczqxaym8.fsf-...@gnu.org>,
>> mon...@iro.umontreal.ca (Stefan Monnier) wrote:
>>
>>> No spiller. No "phi nodes". It's up to the programmer to
>>> arrange for different control flows to end up with the same
>>> values at the same places in the belt, or otherwise to just
>>> not use those belt locations. These CPUs were coded in hand-
>>> tuned assembly, so it seems perfectly acceptable.
>> Except for customer resistance. A belt would be a completely new idea at
>> the time, and most of the people programming 8-bit microprocessors had no
>> computer science training. It could readily acquire a reputation as
>> "really clever, but too hard to program."
> It is easy to solve by using named variables having limited implicite scope in the source instead of variable belt positions.
> This way programming can be _easier_ , because of meaningful names.
>
> The real problem is that belt semantics doesn't offer anything meaningful for ultra-low-end except a little higher code density (albeit patent protection can be substantial).
> Belt can be a virtual mapping of fragment of physical registers. The obvious solution is to contain belt positions and permanent registers in the same "specifier space". Not 8+8, more like 4-6+12-10. MOV is used instead of spill.
> I suppose it is out of our scope. The only upgrade path is to make proto-risc first and then update it by a new mode to proto-belt.
>
> BTW, We can see accumulators as a degenerated belts having one position.
>

One could; it's an interesting viewpoint, leading to speculation about
two-position "ping-pong" accumulators, in which setting either as
destination causes the former content to be moved to the other.

pec...@gmail.com <peceed@gmail.com> schrieb:
> Thomas Koenig wrote:
>> If we must have two cycles to access a full instruction, then the
>> fist byte could contain the register number of the instruction
>> that needs to be read, if any. Fetching the second part of the
>> instruction would then be parallel to reading the fist register
>> and putting it into an intermediate register.
>>
>> Call it proto-pipelining on the proto-RISC we are discussing.
> I had exactly the same idea. Instruction format should be defined
> this way, that first nibble is a "always read" register.

For reasons of aesthetics, I would probably prefer to have
the first nibble the major opcode, the second one the register.

The major opcode could also show that the register nibble
is a four-bit immediate.

> Single 8
> bit memory access takes 2 cycles, so pipelining is an attractive
> idea.

May have to wait until it is clear that the transistor budget is
not overspent.

> Reading the shortest instruction takes 4 cycles,

If there are only two-byte instructions, the decode of the first
byte can be done in parallel to the fetch of the second one, because
it is clear that there will always be a second read.

>fast implementation with 16 bit adder should be executed in
> the same time, so 16 bit RISC on 8 bit bus makes sense - we can
> saturate bandwidth executing register-register operations.

That was the idea of having as many registers as possoble, of course.

> We have time to read 2 values, but it requires second intermediate register and doesn't save time.

I think so, too.

Thomas Koenig wrote:
> > Reading the shortest instruction takes 4 cycles,
> If there are only two-byte instructions, the decode of the first
> byte can be done in parallel to the fetch of the second one, because
> it is clear that there will always be a second read.
You meant "If there is no single-byte instructions...". We need 4-byte instructions having 2-byte address for memory operations, and 3-byte instructions for long jumps, so we probably want to have 1 byte NOP.

I think it doesn't make sense. We can win one cycle at most, only when prefetch didn't work, so the total gain is 1 cycle per jump to instruction, that can benefit . If you consider the fact, that we have 4 times more cycles than 6502, the overall gain is small.
Working prefetch is much more essential, partial instruction decoding seems to be too complicated for me, and too restrictive for allowed instruction formats.

> >fast implementation with 16 bit adder should be executed in the same time
"in one cycle" of course.
> That was the idea of having as many registers as possoble, of course.
> > We have time to read 2 values, but it requires second intermediate register and doesn't save time.
> I think so, too.

On Saturday, July 31, 2021 at 1:58:55 PM UTC-4, MitchAlsup wrote:
> On Saturday, July 31, 2021 at 12:42:10 PM UTC-5, pec...@gmail.com wrote:
> > > Stephen Fuld wrote:
> > > > To expand a little on a previous post, I still think that a
> > > > proto-RISC design could have been superior. A design with
> > > > - All 16 bit instructions only
> > > > - Load/store architecture
> > > > - 16 registers of 16 bits each
> > > > - Eight bit opcode, eight bit data
> > > > - Possibility of 16-bit immediates for all arithmetic
> > > > operations, load and store for the address
> > > > - Format: op Ra, Ra or op Ra, #immediate (4 bits)
> > > >
> > > > can probably be made to fit on a 6502-sized die using the
> > > > technology of the day.
> > > >
> > > > Of course, such a design would be screaming to have a 16-bit
> > > > data bus.
> > > Yes. With only an 8 bit bus, every instruction will require two memory
> > > reads to fetch the instruction, which will substantially hurt
> > > performance. 8088 anyone? :-(
> > 6502 fetches 2 bytes per instruction anyway, so what is the problem?
> <
> > Performance depends on total code density,
> <
> Performance depends entirely on the total number of memory references.
> <
> > it can be comparable for 8 bit, and much better for 16 bit arithmetic.
> > 16 registers can be optional for next generation, 8 is enough for early variants and increases interrupt performance.
> <
> Both PDP-11 and Nova got away with fewer registers. PDP-11 had 8.
> <
> > There is no 2r1w register file (too expensive), so processor needs much higher internal clock like Z80.

I don't know what the sequencing logic overhead would be (probably too much), but consider:
Get rid of the direct page.
Make the SP 16 bits.
Instead of the DP, change most DP addressing to be SP+(unsigned) offsets.
I'm not real familar with the 6502 ISA, but I think you should be able to do something
like: LDA [SP+offset],X
which adds offset to SP, loads the 16 bit address, adds X to it and loads A from the resulting address.
Since all this is on the stack, instantly gets rid off all the DP allocation contention.
It is also MUCH friendlier to generated code from compilers.
The stack based values end up acting like registers, and if you want to make things faster, start caching the stack...

(I know, everyone liked to put MMIO devices in the DP. Great for the embedded market, not so much for general computing).

- Tim