Timothy McCaffrey <timcaffrey@aol.com> writes:
> I think you meant 6800 (or 8080), 6809 didn't show up to several years later
> (with 3x the number of transistors).

I was trying to design page faults for the 6809. Exercise for the reader:
What is the worst case number of pages faults which need to be resolved
to complete a single instruction?

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

On Friday, July 23, 2021 at 2:21:37 PM UTC-6, Anssi Saari wrote:

> Wasn't it already done with the 65816

That is a better 6502, but the way he phrased his post, I thought
he meant a more optimized 6502, one that fit the 6502 into an
even smaller package with fewer logic gates.

That is something I don't think we could improve on much, if at
all... nor is there any motivation to make the effort to try.

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Friday, July 23, 2021 at 2:21:37 PM UTC-6, Anssi Saari wrote:
>
>> Wasn't it already done with the 65816
>
> That is a better 6502, but the way he phrased his post, I thought
> he meant a more optimized 6502, one that fit the 6502 into an
> even smaller package with fewer logic gates.

It was more along the lines of "what could be the best
microprocessor that could have fitted the transistor and 8 bit
bus limit", which "best" having different quality metrics,
of course.

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.

[Additional boundary conditions from further down:]
|16 bit address bus, combined program and data bus of 8 bit.

>Could we do better knowing what we know now?

I think so.

Maybe something like the small variant of b16 (first called b16-small,
later renamed into b16, while the original (large) b16 was renamed
into b16-dsp):

https://bernd-paysan.de/b16-presentation.pdf

Having the stacks on-chip would be great, but probably does not fit
the transistor budget, so one would only keep TOS and P on-chip, and
replace the rest with stack pointers (maybe 5 bits each) and one
16-bit buffer (not per stack) for keeping one other stack item after
loading it or before storing it.

The b16 feature of having 3+ instructions (without immediates) per
16-bit word could be good for speed, but requires a 16-bit shift
register for holding the instruction, which we may not want due to its
transistor cost. The alternative is to have a 5-bit and a 3-bit
instruction in an 8-bit byte. One would have to analyse the usage to
decide which instructions to make available through the three bits.

The b16 design uses a 16-bit ALU. One can replace that with several
passes through an 8-bit or 4-bit ALU, at an increase in control logic.
Not sure if that would pay off wrt transistors. The first Nova
certainly took the 4-bit-ALU approach. Given that you need a two-pass
approach for 16-bit memory accesses anyway, the additional cost for a
two-pass approach through an 8-bit ALU may be minor.

I don't think that the b16 has interrupts, so you would need to add
that to be on feature-parity with the 6502.

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

About half of the zero page was used for the kernal (OS), and yes,
BASIC used the other half. But if you did not call into BASIC, you
could use that other half. The X register can be used with 16-bit
base addresses, so even if you don't use the zero page, X is useful.
I did find the (...,X) addressing mode useless, though (even though I
had enough zero-page places for my usage).

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

Guillaume <message@bottle.org> writes:
>I guess using a completely different architecture, based on a very
>simple RISC instruction set, you might be able to do something a bit
>more "powerful" with the same amount of logic, and being able to run at
>much higher frequencies even on old processes. But using such a CPU with
>simple dev tools as they were available at them time would be very
>clunky. Only decent compilers can make efficient use of such simple RISC
>architectures while not making the developers' life a hell. I guess.

You guess wrong. RISCs are easy to program in assembly. It's more
the other way round: Assembly programmers can cope with irregular
register sets like the one of the 6502, while compilers have a hard
time with them; they benefit from the regularity of register machines,
both CISC (e.g., PDP-11, VAX, AMD64), and RISC (all of them).

Concerning a "very simple RISC instruction set", the NOVA has a
load/store architecture. The National Semiconductor IPC-16A/520 PACE
seems to be the first single-chip implementation of an instruction set
similar to the Nova (and the first single-chip 16-bit CPU), announced
in 1974 <https://www.cpu-world.com/CPUs/PACE/index.html>, so maybe
with a similar transistor budget as the 6502. It took 10us per
instruction on average (1MHz 6502 2-7us), somewhat negating the 16-bit
advantage. That's apparently also the case for the other
Nova-inspired microprocessors (microNova and Fairchild 9440), and is
probably the reason why they were not successful; it's unclear to me
why they came out this way, but if it is to be a "better 6502", it
must be avoided.

Concerning the "much higher frequencies", a 6502 in a computer of its
time does not really benefit from a higher clock frequency, because it
accesses memory in most cycles, so a higher-clocked 6502 would
effectively run at the same speed.

So if we want to design something better, we need to design something
that needs fewer memory accesses. The 6502 needs many instructions
and many memory accesses because it has so few registers. It also
needs many instructions because one needs to synthesize 16-bit
operations from several 8-bit instructions.

OTOH, unlike load/store architectures the 6502 has load-op
instructions (and even a few read-modify-write instructions) that
reduce the number of instructions executed compared to an otherwise
similar load/store instruction set.

Still, if I wanted to rise to the challenge, my first pick would be a
16-bit load/store architecture, with as many registers as fit in the
transistor budget. Use an 8-bit ALU to save transistors (you already
need the sequencing logic for 16-bit memory accesses anyway); or
alternatively, use a 16-bit ALU, and perform 8-bit loads and 8-bit
stores programmatically to avoid the sequencing.

My guess is that 3 general-purpose registers should fit (can be
addressed in 2 bits, and have one option for zero/discard-result).
That's of course very tight, especially because you have no additional
stack pointer. If we can fit more registers, it would be better.

Instructions should fit into 8 bits (plus immediate operands/offsets),
so we can afford only one or two register addresses in each
instruction. Would be an interesting exercise for the instruction-set
designers here. Auto-increment/decrement would be cool, but probably
does not fit in the instruction size or transistor size limit.

Calls store the return address in a register, and return is an
indirect jump through that register.

An extra special-purpose register would be needed for holding the
interrupt return address.

- 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:
>On Friday, July 23, 2021 at 1:15:11 PM UTC-5, Thomas Koenig wrote:
>> The first time I browsed through handbook on the 68000, I thought=20
>> "This is not assembler, this is a high-level language!"
><
>And they took most of it from the PDP-11

Except the best feature of the PDP-11: general-purpose registers.

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

jgd@cix.co.uk (John Dallman) writes:
>The early ARMs were inspired by the 6502, but only in terms of being
>simple and avoiding microcode.

But the 6502 was microcoded (with the microprogram encoded in the
PLA).

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

On Saturday, July 24, 2021 at 10:51:53 AM UTC-5, Anton Ertl wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >On Friday, July 23, 2021 at 1:15:11 PM UTC-5, Thomas Koenig wrote:
> >> The first time I browsed through handbook on the 68000, I thought=20
> >> "This is not assembler, this is a high-level language!"
> ><
> >And they took most of it from the PDP-11
> Except the best feature of the PDP-11: general-purpose registers.
<
They thought they were doing better with A and D registers.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

MitchAlsup wrote:
> On Friday, July 23, 2021 at 11:33:05 AM UTC-5, EricP wrote:
>>
>> Static CMOS doesn't have any equivalent to wire-OR so there is little
>> saving making static PLAs. Instead PLAs are built out of dynamic logic.
>> But I don't see them explicitly referenced in designs much
>> so I think the tricky dynamic aspect keeps designers away.
> <
> Err, no........
> All of the 68K family (at least the ones before 040) used PLAs.
> The 88Ks used a PLA--well, actually ½ a PLA; we used a single NOR
> plane as the decoder in 88100.
> Lots of other designs used PLAs or NOR planes because they were
> DENSE--as dense as DRAMs with mask programmable bit patterns.
> I bet most of the microprocessors, prior to the RISC revolution, used
> PLAs (or NOR planes).
> <
> One of the clever things 68020 did was to place an XOR gate between
> the two NOR planes of the PLA which vastly increases the kinds of
> patterns one could decode !!
> <

Yes but those were 30 to 35 years ago.
I haven't seen PLA's mentioned in a design in at least 20 years,
though I would imagine that Intel and AMD use them for the decoders.

The 88100's single NOR plane would have less strict timing than a
PLA with two planes. From what I have read, ideally the first plane
drives the second directly - one doesn't want a layer of latches between.
However before the first plane signals stabilize, they can glitch the
second plane and cause it to erroneously discharge.
I can see this would be finicky circuitry and possibly susceptible
to timing changes due to process variation.

I looked at the 88100 instruction encodings -
I still haven't figured out how you got away with just 1 NOR plane.

>> Also tools like Verilog don't generate PLAs.
> <
> NO but microcode assemblers do !
> <

Yes but how would one do a simulation test of a whole design?

I suppose the PLA assembler could generate a Verilog UNIQUE CASEX statement
with ? don't cares which implements the equivalent logic to the PLA.
That could be used to test the logic functionality but not the timing.

According to Quadibloc <jsavard@ecn.ab.ca>:
>On Friday, July 23, 2021 at 4:59:30 AM UTC-6, 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.
>
>Indeed.
>
>However, even the 6502, let alone the 6800 or the 8080, seemed
>to me to have very complicated instruction sets compared to the
>PDP-8.

The original PDP-8 had only 1409 transisors, each one in a separate can,
so it's not surprising. The first computer I programmed was a PDP-8 and
it was a fantastically well-done tradeoff between extreme simplicity and
usability.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Saturday, July 24, 2021 at 12:19:57 PM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Friday, July 23, 2021 at 11:33:05 AM UTC-5, EricP wrote:
> >>
> >> Static CMOS doesn't have any equivalent to wire-OR so there is little
> >> saving making static PLAs. Instead PLAs are built out of dynamic logic..
> >> But I don't see them explicitly referenced in designs much
> >> so I think the tricky dynamic aspect keeps designers away.
> > <
> > Err, no........
> > All of the 68K family (at least the ones before 040) used PLAs.
> > The 88Ks used a PLA--well, actually ½ a PLA; we used a single NOR
> > plane as the decoder in 88100.
> > Lots of other designs used PLAs or NOR planes because they were
> > DENSE--as dense as DRAMs with mask programmable bit patterns.
> > I bet most of the microprocessors, prior to the RISC revolution, used
> > PLAs (or NOR planes).
> > <
> > One of the clever things 68020 did was to place an XOR gate between
> > the two NOR planes of the PLA which vastly increases the kinds of
> > patterns one could decode !!
> > <
> Yes but those were 30 to 35 years ago.
> I haven't seen PLA's mentioned in a design in at least 20 years,
> though I would imagine that Intel and AMD use them for the decoders.
<
A lot of microcode moved towards ROM territory:: a ROM is a PLA that
happens the the first layer is a decoder (which could be done with a NOR
plane but the decoder is faster and fewer gates.) IIRC: Athlon had a bit
more than 3K µwords and Opteron had a bit more than 4K µwords.
>
> The 88100's single NOR plane would have less strict timing than a
> PLA with two planes. From what I have read, ideally the first plane
> drives the second directly - one doesn't want a layer of latches between.
<
Back in the 88100 there was a latch before the NOR plane and a latch
at the output of the NOR plane and the NOR plane carefully biased
and the latch input carefully sized so that the latch acted as a sense
amplifier.
<
The latch directly drove the first ½ cycle of the datapath select
lines. This corresponds to the first ½ of integer execution or the
delivery of operands to the MUL or FADD units. The second ½
of the cycle might come from the NOR plane (int) or from the
sequencers (AGEN, MUL, and FADD).
<
> However before the first plane signals stabilize, they can glitch the
> second plane and cause it to erroneously discharge.
> I can see this would be finicky circuitry and possibly susceptible
> to timing changes due to process variation.
>
> I looked at the 88100 instruction encodings -
> I still haven't figured out how you got away with just 1 NOR plane.
<
Dig deeper......
<
> >> Also tools like Verilog don't generate PLAs.
> > <
> > NO but microcode assemblers do !
> > <
> Yes but how would one do a simulation test of a whole design?
>
> I suppose the PLA assembler could generate a Verilog UNIQUE CASEX statement
> with ? don't cares which implements the equivalent logic to the PLA.
> That could be used to test the logic functionality but not the timing.
<
Nah:: just have the assembler spit out a VERILOG table directly--there is
no more reason to be able to read it here than the average coder reading
assembly language.

On Saturday, July 24, 2021 at 1:06:33 PM UTC-5, John Levine wrote:
> According to Quadibloc <jsa...@ecn.ab.ca>:
> >On Friday, July 23, 2021 at 4:59:30 AM UTC-6, 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.
> >
> >Indeed.
> >
> >However, even the 6502, let alone the 6800 or the 8080, seemed
> >to me to have very complicated instruction sets compared to the
> >PDP-8.
>
> The original PDP-8 had only 1409 transisors, each one in a separate can,
> so it's not surprising. The first computer I programmed was a PDP-8 and
> it was a fantastically well-done tradeoff between extreme simplicity and
> usability.
<
Not quite a fair comparison: In the logic family of the PDP-8, 1 transistor
could make a 5-input NAND gate whereas in the 6502 logic family this
would take 6 transistors (5 pull downs (N-ch) and 1 pull up (depletion).)
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Guillaume <message@bottle.org> writes:

> Concerning a "very simple RISC instruction set", the NOVA has a
> load/store architecture. The National Semiconductor IPC-16A/520 PACE
> seems to be the first single-chip implementation of an instruction set
> similar to the Nova (and the first single-chip 16-bit CPU), announced
> in 1974 <https://www.cpu-world.com/CPUs/PACE/index.html>, so maybe
> with a similar transistor budget as the 6502.

https://www.cpu-world.com/CPUs/INS8900/index.html states that

# The fastest INS8900 instruction can be executed in 4 machine
# cycles, and require 1 read cycle. Since each machine cycle takes
# 4 clock cycles, it takes at least 17 clock cycles to execute one
# instruction. INS8900 CPU, running at 2 MHz, has 0.5 microsecond
# cycle, and thus can execute at most 117,600 instructions per
# second. That is much slower than instruction per second rate of
# many popular 8-bit processors of the time - Intel 8080, MOS 6502,
# or Motorola 6800.

Having "machine cycles" which were quite a few clock cycles seems
to have been done frequently, the Z80 also did this (I assume to
deal with its 4-bit ALU). This is also why the Z80 was not much
faster than the 6502 despite its much higher clock rates.

I think the 6502 had its clock cycles (only? partially?) determined
by its 8-bit ripple carry adder(s), which is why many instructions
where the address + index crossed a page boundary took an extra
cycle.

On Fri, 23 Jul 2021 12:27:39 -0700 (PDT), Timothy McCaffrey
<timcaffrey@aol.com> wrote:

>On Friday, July 23, 2021 at 6:59:30 AM UTC-4, 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.
>
>16 bit Stack pointer.
>
>Some optimizations that found their way into follow on products (I think these are documented on the Wikipedia page).
>IIRC, there was a sequencer optimization to one of the addressing modes that sped things up by ~15%.
>
>16 bit X & Y would have been great, especially if they supported some 16 bit math.
>Get rid of the (mostly) unused addressing modes.
>Direct Page register like the 6809.

That's the 65c802: 16-bit registers, direct page, pin compatible with
65c02.

65c816 adds 24 bit address space.

WDC supposedly also was working on a 32-bit version that included
floating point ... but AFAIK, nothing came of it.

On Saturday, July 24, 2021 at 12:06:33 PM UTC-6, John Levine wrote:
> According to Quadibloc <jsa...@ecn.ab.ca>:

> >However, even the 6502, let alone the 6800 or the 8080, seemed
> >to me to have very complicated instruction sets compared to the
> >PDP-8.

> The original PDP-8 had only 1409 transisors, each one in a separate can,
> so it's not surprising. The first computer I programmed was a PDP-8 and
> it was a fantastically well-done tradeoff between extreme simplicity and
> usability.

I wonder what the transistor count of the PDP-5 was.

The PDP-5 was the predecessor of the PDP-8; its instruction set
was almost identical. However, it used memory location 0 as the
program counter.

When the program counter was added to the PDP-8 as a separate
register, they changed the locations used to save return data for
interrupts to use location 0, making the two computers incompatible.

Also, the PDP-5 was normally connected to a 5-level Teletype rather
than an ASCII one.

John Savard

Thomas Koenig <tkoenig@netcologne.de> writes:
>I think the 6502 had its clock cycles (only? partially?) determined
>by its 8-bit ripple carry adder(s), which is why many instructions
>where the address + index crossed a page boundary took an extra
>cycle.

The extra cycle is necessary because the high byte then has to run
through the 8-bit ALU to get incremented. See the data path at
<http://www.weihenstephan.org/~michaste/pagetable/6502/6502.jpg>. The
only other parts that can increment are only connected to the program
counter.

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

Am Sat, 24 Jul 2021 10:22:08 GMT schrieb Anton Ertl:

> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Could we do better knowing what we know now?
>
> I think so.
>
> Maybe something like the small variant of b16 (first called b16-small,
> later renamed into b16, while the original (large) b16 was renamed into
> b16-dsp):
>
> https://bernd-paysan.de/b16-presentation.pdf
>
> Having the stacks on-chip would be great, but probably does not fit the
> transistor budget, so one would only keep TOS and P on-chip, and replace
> the rest with stack pointers (maybe 5 bits each) and one 16-bit buffer
> (not per stack) for keeping one other stack item after loading it or
> before storing it.

Dynamic structures (DRAM-style storage elements) are ok with an NMOS
CPU. A DRAM cell is 2 transistors (one used as switch, one used as
capacitor). 2*256 transistors for 2*8 cells stack looks ok.

As long as the stack is used push/pull only (means NOS is kept in a
register), reads can be destructive (you read when you pull, so the data
is no longer needed). Refresh logic could be software requirement (don't
keep things on the on-chip stack for more than a few 1000 instructions),
or a refresh interrupt would read out the stacks into main memory and
read them in again once every few 1000 instructions.

> The b16 design uses a 16-bit ALU. One can replace that with several
> passes through an 8-bit or 4-bit ALU, at an increase in control logic.
> Not sure if that would pay off wrt transistors. The first Nova
> certainly took the 4-bit-ALU approach. Given that you need a two-pass
> approach for 16-bit memory accesses anyway, the additional cost for a
> two-pass approach through an 8-bit ALU may be minor.

Probably. ALUs are not that big after all.

> I don't think that the b16 has interrupts, so you would need to add that
> to be on feature-parity with the 6502.

Yes. The use cases of the b16 didn't require interrupts, a “wait for an
event” feature was sufficient. The downside of interrupts is that you
need some stack space for them; the absolute minimum is one return and
one data stack item.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
https://bernd-paysan.de/

According to Quadibloc <jsavard@ecn.ab.ca>:
>I wonder what the transistor count of the PDP-5 was.
>
>The PDP-5 was the predecessor of the PDP-8; its instruction set
>was almost identical. However, it used memory location 0 as the
>program counter.

Probably not that much fewer than the PDP-8. The main difference was that
the PDP-8 was reimplemented in flip chips rather than the older system
modules. As you note, it put the PC in a register which would mean a few
more flip flops but the architecture was otherwise the same.

>Also, the PDP-5 was normally connected to a 5-level Teletype rather
>than an ASCII one.

No, the price list and manuals say it came with an ASR-33.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Friday, July 23, 2021 at 3:59:30 AM UTC-7, 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?
>
How about wider "bytes"? You could discard the silly 8-bit convention
and go with 9 or 10. You don't lose the classic flavor, but you increase
your opcode space by a power of two and your addressing space by a
power of four. Add a few more registers and a few more addressing
modes, add without carry, subtract without borrow, signed comparisons,
bsr, brl, conditional rts ... whatever floats your boat.

I grew up with the 6502 and the Z80, and they are both brilliant little gems
from the mid-70s. I gravitated toward the 6502 because it was more
accessible to me, and it fit better into my thought processes. I still post
frequently on 6502.org because I love how its assembly language feels in
my tired old brain. The 65816 with its width mode bits ... not so much.

Mike B.

Michael Barry <barrym95838@yahoo.com> schrieb:
> On Friday, July 23, 2021 at 3:59:30 AM UTC-7, 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?
>>
> How about wider "bytes"?

(Of course what I am now writing is shifting the goalpost on "8 bit
data bus").

One possibility would be a 16-bit RISC chip simplified down to the
bone, like what Helmut Neeman has done for his Digital simulator.

This is a 16-register, two-operand machine where instructions take
two bytes (one byte opcode, one byte operand) where short immediates
go into the instructions and long immediates are possible. It is
desiged for two-cycle operation, one cycle of memory operation
and one cycle of execution.

If you throw out the multiplier and replace the control ROM by a
PLA, this would come to around 6000 transistors (I have assumed
20 transistors for a full adder, which may be off). Add some more
logic for interrupt handling, and you are higher than the 6502,
but lower than the Z80, and any such CPU would have run rings around
any of the 8-bit CPUs at the time even when clocked a bit lower
than the 6502.

So, for that time machine to go back and tell people about the RISC
revolution in the 1970s - maybe Edson De Castro or Ken Olsen would
have been the wrong people to talk to, Chuck Peddle or Frederico
Faggin would have been better.

Thomas Koenig wrote:
> Guillaume <message@bottle.org> schrieb:
>> Only decent compilers can make efficient use of such simple RISC
>> architectures while not making the developers' life a hell. I guess.
>
> Hardly a decent compiler around for the 6502 in those days, at
> least I knew none. It was Basic or Assembler (or machine code
> via a monitor, with a hard reset if you made a programming mistake).

Let me fix that documentation bug for you:

"with a hard reset WHEN you made a programming mistake"

:-)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Andy Valencia wrote:
> Timothy McCaffrey <timcaffrey@aol.com> writes:
>> I think you meant 6800 (or 8080), 6809 didn't show up to several years later
>> (with 3x the number of transistors).
>
> I was trying to design page faults for the 6809. Exercise for the reader:
> What is the worst case number of pages faults which need to be resolved
> to complete a single instruction?

I did write some 6809 asm many years ago, but I don't remember enough of
the details now. :-(

In particular, any system with unlimited memory indirect can also cause
unimited number of page faults, even without any hardware looping, but
I'm pretty sure the 6809 didn't allow this?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:
>> Guillaume <message@bottle.org> schrieb:
>>> Only decent compilers can make efficient use of such simple RISC
>>> architectures while not making the developers' life a hell. I guess.
>>
>> Hardly a decent compiler around for the 6502 in those days, at
>> least I knew none. It was Basic or Assembler (or machine code
>> via a monitor, with a hard reset if you made a programming mistake).
>
> Let me fix that documentation bug for you:
>
> "with a hard reset WHEN you made a programming mistake"
>
>:-)

While better than the original, this is still not quite correct.
There were some programming mistakes (maybe 10% or so) which only
led to incorrect results and not to a freeze.

So, maybe

"with a hard reset most of the times when you made a programming
mistake" ?

The longest-running program I ever ran on that machine was searching
for Golomb rulers after reading an article on them in the German
version of Scientific American (using Basic for I/O), that ran
for three weeks; the lack of peripherals meant that I had to
take care that nobody unplugged the machine during that time.

Hm. I just saw that Martin Gardner's article in Scientific American
appeared 1972, far too early for me or for the C-64. They must have
reprinted it more than a decade later in the German edition.

Terje Mathisen <terje.mathisen@tmsw.no> writes:
> In particular, any system with unlimited memory indirect can also cause
> unimited number of page faults, even without any hardware looping, but
> I'm pretty sure the 6809 didn't allow this?

We were kicking it around in private email (my memory is fuzzy, too).
Given the 6809's unaligned everything, you can have the instruction
straddle pages, the memory ref, the indirect ref, and the result
store all be unaligned memory refs. So... 8?

Of course, bulk memory move/set would also have unbounded, but that
has its own family of fixes to address it.

I vaguely remember a CPU where you could have unlimited indirect
memory references, and you could lock it up with an infinite
loop of them (until they fixed the implementation).

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

In article <162722089396.5736.3112557284479151479@media.vsta.org>,
vandys@vsta.org (Andy Valencia) wrote:

> I vaguely remember a CPU where you could have unlimited indirect
> memory references, and you could lock it up with an infinite
> loop of them (until they fixed the implementation).

The DEC PDP-10 had this, although there may have been others.

John