Thomas Koenig <tkoenig@netcologne.de> writes:
[Golomb Rulers]
>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.

<https://www.csplib.org/Problems/prob006/references/> says:

|Golomb rulers have been featured twice in the Computer Recreations
|column of Scientific American, which did much to popularize them.
....
|A. K. Dewdney
|Computer Recreations
|Scientific American, 21, mar 1986
| |A. K. Dewdney
|Computer Recreations
|Scientific American, 16-26, dec 1985

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

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
> [Golomb Rulers]
>>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.
>
><https://www.csplib.org/Problems/prob006/references/> says:
>
>|Golomb rulers have been featured twice in the Computer Recreations
>|column of Scientific American, which did much to popularize them.
> ...
>|A. K. Dewdney
>|Computer Recreations
>|Scientific American, 21, mar 1986

That must have been the one, then, just before Chernobyl.

Thanks!

On Friday, July 23, 2021 at 4:53:55 PM UTC-7, Andy Valencia wrote:
>
> 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 must have been a bit sheltered, because I never knew of a 6809 system
with virtual memory.

But for page crossings, I suppose a multi-byte instruction and its multi-byte
operand could both straddle page boundaries. Make that an indirect mode
and arrive at a worst case of three? I don't think the 6809 made as much of
a deal about page crossings as the 6502 did.

Bernd Paysan <bernd@net2o.de> writes:
>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.

The 8008 fits an 8x14bits stack in its 3500 (PMOS) transistors, and
has a more complex architecture. And it probably was static rather
than dynamic RAM, because AFAIK there is no way to refresh it by
storing it to memory at regular intervals.

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

Given that we implement interrupts, the interrupt approach looks like
a winner to me. Maybe have an internal cycle counter that generates
this interrupt at regular intervals.

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

Today I lean more towards having a 16-bit ALU and letting the software
synthesize 16-bit memory accesses out of 8-bit accesses, to avoid the
need for a sequencer. Maybe I will revert that again when I think
more about how to deal with immediate arguments.

>The downside of interrupts is that you
>need some stack space for them; the absolute minimum is one return and
>one data stack item.

Yes. That does not look like a deal-breaker to me. The interrupt
handler would first dump as many data and return stack items to memory
as it needs.

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

On 7/25/2021 7:07 AM, John Dallman wrote:
> 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.

Yes, as I have mentioned here before, the Univac 1108, and its
descendants can have "unlimited" memory references, through indirect
addressing or through an Execute instruction chain, but lockup is
prevented by a hardware timer preventing any of these from taking too
long by causing an illegal operation interrupt.

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

John Dallman wrote:
> 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

DG Nova too.
Nova only had 4 general registers AC0..AC3, plus a PC.
AC2, AC3 and PC could be used as index registers.
I believe the intent was to put a bank of virtual registers in memory,
say 16 or 32, and point one of the HW registers at that.

If the Indirect bit in an instruction == 0
the effective address is the address of the operand.
If Indirect bit == 1 the effective address is the address of the address.
Furthermore, if the msb of that second address == 1 then that
is also an address, looping until msb == 0.

if (Indirect)
{ do { addr = *addr; }
while ((int)addr < 0);
}
operand = *addr;

Early Nova models could get into operand read loops that
require a hard reset.

On 7/25/2021 11:16 AM, EricP wrote:
> John Dallman wrote:
>> 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
>
> DG Nova too.
> Nova only had 4 general registers AC0..AC3, plus a PC.
> AC2, AC3 and PC could be used as index registers.
> I believe the intent was to put a bank of virtual registers in memory,
> say 16 or 32, and point one of the HW registers at that.
>
> If the Indirect bit in an instruction == 0
> the effective address is the address of the operand.
> If Indirect bit == 1 the effective address is the address of the address.
> Furthermore, if the msb of that second address == 1 then that
> is also an address, looping until msb == 0.
>
>   if (Indirect)
>   { do { addr = *addr; }
>     while ((int)addr < 0);
>   }
>   operand = *addr;
>
> Early Nova models could get into operand read loops that
> require a hard reset.

I write a compiler for the Nova 1200, that had an iteration limit IIRC.
It could compile itself, one pass, in 64kb that you shared with the OS.
That compiler was how I first met Mitch.

Ivan Godard wrote:
> On 7/25/2021 11:16 AM, EricP wrote:
>> John Dallman wrote:
>>> 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
>>
>> DG Nova too.
>> Nova only had 4 general registers AC0..AC3, plus a PC.
>> AC2, AC3 and PC could be used as index registers.
>> I believe the intent was to put a bank of virtual registers in memory,
>> say 16 or 32, and point one of the HW registers at that.
>>
>> If the Indirect bit in an instruction == 0
>> the effective address is the address of the operand.
>> If Indirect bit == 1 the effective address is the address of the address.
>> Furthermore, if the msb of that second address == 1 then that
>> is also an address, looping until msb == 0.
>>
>> if (Indirect)
>> { do { addr = *addr; }
>> while ((int)addr < 0);
>> }
>> operand = *addr;
>>
>> Early Nova models could get into operand read loops that
>> require a hard reset.
>
> I write a compiler for the Nova 1200, that had an iteration limit IIRC.
> It could compile itself, one pass, in 64kb that you shared with the OS.
> That compiler was how I first met Mitch.

Do you remember ever using infinite indirect?
It strikes me as a feature that sounded good
over beers in the bar but in the cold light
of day is more trouble than it helps.

According to John Dallman <jgd@cix.co.uk>:
>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).

DG Nova, perhaps?

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

The PDP-10 didn't have lockup problems because it took interrupts
during each address calculation cycle. This led to one wart, the "first part done"
flag used by the ILDB and IDBP instructions which first did the standard adress
calculation to fetch a byte pointer, then updated the pointer to refer to the next
byte, did a second address calculation with the address in the pointer, and then
loaded or stored the byte. The FPD flag told the processor not to update the
pointer when resuming from an interrupt between the two halves of the instruction.
The BLT block transfer instruction was interruptible, and stored the updated
to/from pointer word so it could continue when restarted.

One time when I was bored I wrote a little program that made an ever longer chain
of indirect addresses until it stalled because the time to compute the address was
longer than a clock tick.

The GE 635 had a no-interrupt flag in some instructions that you could use to
contruct critical section code and a timer that killed the job if he flag was
on too long.
--
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 7/25/2021 1:00 PM, EricP wrote:
> Ivan Godard wrote:
>> On 7/25/2021 11:16 AM, EricP wrote:
>>> John Dallman wrote:
>>>> 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
>>>
>>> DG Nova too.
>>> Nova only had 4 general registers AC0..AC3, plus a PC.
>>> AC2, AC3 and PC could be used as index registers.
>>> I believe the intent was to put a bank of virtual registers in memory,
>>> say 16 or 32, and point one of the HW registers at that.
>>>
>>> If the Indirect bit in an instruction == 0
>>> the effective address is the address of the operand.
>>> If Indirect bit == 1 the effective address is the address of the
>>> address.
>>> Furthermore, if the msb of that second address == 1 then that
>>> is also an address, looping until msb == 0.
>>>
>>>    if (Indirect)
>>>    { do { addr = *addr; }
>>>      while ((int)addr < 0);
>>>    }
>>>    operand = *addr;
>>>
>>> Early Nova models could get into operand read loops that
>>> require a hard reset.
>>
>> I write a compiler for the Nova 1200, that had an iteration limit
>> IIRC. It could compile itself, one pass, in 64kb that you shared with
>> the OS. That compiler was how I first met Mitch.
>
> Do you remember ever using infinite indirect?
> It strikes me as a feature that sounded good
> over beers in the bar but in the cold light
> of day is more trouble than it helps.

Certainly not infinite, but finite indirect could be used to get around
the paucity of index registers. I think the OS used it for interrupt
vectoring. I don't remember ever using it in the generated code, nor the
compiler itself. But data-indirect is an asm kind of thing, an I was
only using a HLL. Do you know if they repeated the feature in the Eclipse?

According to EricP <ThatWouldBeTelling@thevillage.com>:
>Do you remember ever using infinite indirect?
>It strikes me as a feature that sounded good
>over beers in the bar but in the cold light
>of day is more trouble than it helps.

It could be handy when passing arguments to subroutines, e.g.

subroutine foo(x)

... z = bar(x)

The code in foo() passes an indirect pointer to its incoming argument,
which might in turn be indirect. In PDP-10 Algol they used chains of
XCT instructions to handle call-by-name.

I agree it was hard to find useful examples of indirection more than 2 or 3 deep,
but once you get past 1 level, it's easier not to have a limit.

--
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 Sunday, July 25, 2021 at 3:28:58 PM UTC-5, John Levine wrote:
> According to EricP <ThatWould...@thevillage.com>:
> >Do you remember ever using infinite indirect?
> >It strikes me as a feature that sounded good
> >over beers in the bar but in the cold light
> >of day is more trouble than it helps.
> It could be handy when passing arguments to subroutines, e.g.
>
> subroutine foo(x)
>
> ... z = bar(x)
>
> The code in foo() passes an indirect pointer to its incoming argument,
> which might in turn be indirect. In PDP-10 Algol they used chains of
> XCT instructions to handle call-by-name.
>
> I agree it was hard to find useful examples of indirection more than 2 or 3 deep,
> but once you get past 1 level, it's easier not to have a limit.
<
Could you find (access) the end of a linked list by infinite indirection ?
> --
> 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

On 7/25/2021 4:00 PM, MitchAlsup wrote:
> On Sunday, July 25, 2021 at 3:28:58 PM UTC-5, John Levine wrote:
>> According to EricP <ThatWould...@thevillage.com>:
>>> Do you remember ever using infinite indirect?
>>> It strikes me as a feature that sounded good
>>> over beers in the bar but in the cold light
>>> of day is more trouble than it helps.
>> It could be handy when passing arguments to subroutines, e.g.
>>
>> subroutine foo(x)
>>
>> ... z = bar(x)
>>
>> The code in foo() passes an indirect pointer to its incoming argument,
>> which might in turn be indirect. In PDP-10 Algol they used chains of
>> XCT instructions to handle call-by-name.
>>
>> I agree it was hard to find useful examples of indirection more than 2 or 3 deep,
>> but once you get past 1 level, it's easier not to have a limit.
> <
> Could you find (access) the end of a linked list by infinite indirection ?
>> --
>> 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

You could just access address zero directly without bothering to go
through the chain.

Anton Ertl wrote:
>
> The 8008 fits an 8x14bits stack in its 3500 (PMOS) transistors, and
> has a more complex architecture. And it probably was static rather
> than dynamic RAM, because AFAIK there is no way to refresh it by
> storing it to memory at regular intervals.

8008 (circa 1972) and 8080 (circa 1974) were both dynamic internally.

8008 required an externally generated 2 phase non overlapping
pulsed clock with some rather strict timing requirements.
Cycle time of each phase had minimum of 2 us, max of 3 us
taking 2 clock cycles for 1 machine state cycle.
First cycle, phase 1 is the precharge to internal memory and buses,
phase 2 is read, second cycle phase 1 is precharge, phase 2 is write.

8080 is similar but different phase and pulse width timings.

Motorola 6800 was also dynamic internally but it generated any
multiphase clocking it needed internally from the external clock,
withing a min and max frequency of 0.1 to 1.0 MHz.

RCA 1802 was static cmos so you could run it at any frequency,
or turn the clock off and it took just 0.1 (typical) uAmps
to retain its state.

MitchAlsup wrote:
> On Sunday, July 25, 2021 at 3:28:58 PM UTC-5, John Levine wrote:
>> According to EricP <ThatWould...@thevillage.com>:
>>> Do you remember ever using infinite indirect?
>>> It strikes me as a feature that sounded good
>>> over beers in the bar but in the cold light
>>> of day is more trouble than it helps.
>> It could be handy when passing arguments to subroutines, e.g.
>>
>> subroutine foo(x)
>>
>> ... z = bar(x)
>>
>> The code in foo() passes an indirect pointer to its incoming argument,
>> which might in turn be indirect. In PDP-10 Algol they used chains of
>> XCT instructions to handle call-by-name.
>>
>> I agree it was hard to find useful examples of indirection more than 2 or 3 deep,
>> but once you get past 1 level, it's easier not to have a limit.
> <
> Could you find (access) the end of a linked list by infinite indirection ?

Sure but such a chain has to be constructed with all but the last
pointer having its indirect bit set and the last pointer clear.
For a dynamic chain, managing the indirect bits is more expensive
than the list management. A circular single linked list with a
tail pointer is cheapest.

To use this auto-indirect feature, the chain of links between
data structures would have to be planned in advance.
That limits its to pretty much what John Levine said, 2 or 3 levels max.

Note also the to get this indirect bit on every pointer they give
up byte addresses. Using little-endian bit numbering here
(Nova uses big-endian) bits [14:0] are a 16-bit word address
- there is no bit to hold a byte selector. Sure you could play
games right rotating char addresses but that all costs.

EricP <ThatWouldBeTelling@thevillage.com> schrieb:

> RCA 1802 was static cmos so you could run it at any frequency,
> or turn the clock off and it took just 0.1 (typical) uAmps
> to retain its state.

Sounds like an attractive property for spacecraft (together with
the radiation-hardening properties from Silicon-on-Sapphire
that they apprently used).

On 7/26/21 1:17 PM, Thomas Koenig wrote:
> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>
>> RCA 1802 was static cmos so you could run it at any frequency,
>> or turn the clock off and it took just 0.1 (typical) uAmps
>> to retain its state.
>
> Sounds like an attractive property for spacecraft (together with
> the radiation-hardening properties from Silicon-on-Sapphire
> that they apprently used).
>

The C2L design (MOSFETs were always closed loops with the drain in the
center) provided some intrinsic radiation hardening.

Some extra was applied via special process steps. See:
https://www.osti.gov/biblio/6054040.

SOS was just icing on the cake.

And of course the 1802 was used in spacecraft with the most famous use
probably being the Galileo probe.

Some code from Galileo turned up a while back. They had a problem with
the memory and needed to patch the code. But the ability to run the
Forth Inc. MicroFORTH system had vanished. So a system was whipped up in
LISP to allow the task to be done.

https://github.com/rongarret/gll-mag-patch/

--
http://davesrocketworks.com
David Schultz

Thomas Koenig <tkoenig@netcologne.de> writes:
> > RCA 1802 was static cmos so you could run it at any frequency,
> > or turn the clock off and it took just 0.1 (typical) uAmps
> > to retain its state.
> Sounds like an attractive property for spacecraft (together with
> the radiation-hardening properties from Silicon-on-Sapphire
> that they apprently used).

If you debounced a switch, you could actually advance it cycle by cycle
manually. My Super Elf's display would follow along as the CPU (slowly)
progressed. A poor man's single step debugger.

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

On Monday, July 26, 2021 at 6:49:10 PM UTC-5, Andy Valencia wrote:
> Thomas Koenig <tko...@netcologne.de> writes:
> > > RCA 1802 was static cmos so you could run it at any frequency,
> > > or turn the clock off and it took just 0.1 (typical) uAmps
> > > to retain its state.
> > Sounds like an attractive property for spacecraft (together with
> > the radiation-hardening properties from Silicon-on-Sapphire
> > that they apprently used).
<
> If you debounced a switch, you could actually advance it cycle by cycle
> manually. My Super Elf's display would follow along as the CPU (slowly)
> progressed. A poor man's single step debugger.
<
Debouncing a switch is the original job of the S-R flip-flop.
<
> Andy Valencia
> Home page: https://www.vsta.org/andy/
> To contact me: https://www.vsta.org/contact/andy.html

On Monday, July 26, 2021 at 7:40:14 PM UTC-5, MitchAlsup wrote:
> On Monday, July 26, 2021 at 6:49:10 PM UTC-5, Andy Valencia wrote:
> > Thomas Koenig <tko...@netcologne.de> writes:
> > > > RCA 1802 was static cmos so you could run it at any frequency,
> > > > or turn the clock off and it took just 0.1 (typical) uAmps
> > > > to retain its state.
> > > Sounds like an attractive property for spacecraft (together with
> > > the radiation-hardening properties from Silicon-on-Sapphire
> > > that they apprently used).
> <
> > If you debounced a switch, you could actually advance it cycle by cycle
> > manually. My Super Elf's display would follow along as the CPU (slowly)
> > progressed. A poor man's single step debugger.
> <
> Debouncing a switch is the original job of the S-R flip-flop.
> <
> > Andy Valencia
> > Home page: https://www.vsta.org/andy/
> > To contact me: https://www.vsta.org/contact/andy.html

Putting on my low cost embedded systems hat:
every wire and every switch contact has a cost:
a SPST switch and one wire is lower cost than SPDT and two wires,
so the job falls to the interrupt handler or a polling routine.

> Debouncing a switch is the original job of the S-R flip-flop.
And 2X two-input nand or nor gates is about as low cost as it gets.

Given Musk's and others emphasis on no parts being
more desirable or reliable, one wonders how the cost/reliability
of software affects the trade-off?

MitchAlsup <MitchAlsup@aol.com> wrote:
> On Saturday, July 24, 2021 at 1:06:33 PM UTC-5, John Levine wrote:
>>
>> The original PDP-8 had only 1409 transisors, each one in a separate can,
>> so it's not surprising.

And about 10,000 diodes.

>> The first computer I programmed was a PDP-8 and it was a
>> fantastically well-done tradeoff between extreme simplicity and
>> usability.

I hated it, but by then we were well into the 1970s and it looked like
something out of the stone age.

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

Indeed, and when the PDP-8 was actually implemented as a single
(IM6100) IC it took 4000 tranisistors, which given the awfulness of
the instruction set no longer looked like such a good deal.

Andrew.

aph@littlepinkcloud.invalid writes:
>MitchAlsup <MitchAlsup@aol.com> wrote:
>> 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).)
>
>Indeed, and when the PDP-8 was actually implemented as a single
>(IM6100) IC it took 4000 tranisistors, which given the awfulness of
>the instruction set no longer looked like such a good deal.

However, the IM6100 was in CMOS (compared to NMOS for 6502), which
costs extra transistors (I think 10 transistors for the 5-input NAND
gate). Also, the IM6100 included the "Extended Arithmetic Element"
(multiply and divide instructions, and the MQ register). So I expect
that an NMOS implementation of the basic PDP-8 instruction set would
take fewer transistors than a 6502. I would not consider it a better
6502, though, and it certainly does not fit the "8-bit data bus"
requirement.

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

On Tuesday, July 27, 2021 at 12:53:02 PM UTC-5, Anton Ertl wrote:
> a...@littlepinkcloud.invalid writes:
> >MitchAlsup <Mitch...@aol.com> wrote:
> >> 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).)
> >
> >Indeed, and when the PDP-8 was actually implemented as a single
> >(IM6100) IC it took 4000 tranisistors, which given the awfulness of
> >the instruction set no longer looked like such a good deal.
> However, the IM6100 was in CMOS (compared to NMOS for 6502), which
> costs extra transistors (I think 10 transistors for the 5-input NAND
> gate). Also, the IM6100 included the "Extended Arithmetic Element"
> (multiply and divide instructions, and the MQ register). So I expect
> that an NMOS implementation of the basic PDP-8 instruction set would
> take fewer transistors than a 6502. I would not consider it a better
> 6502, though, and it certainly does not fit the "8-bit data bus"
> requirement.
<
Is the requirement to have only a 16-bit address bus and a 8-bit data bus?
<
If so, why not just use something that is already in a library as a CPU and
not bother ?
<
The utility of reinventing this wheel in today's world and market is so close
to zero it nears exponent underflow.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

MitchAlsup <MitchAlsup@aol.com> schrieb:

> Is the requirement to have only a 16-bit address bus and a 8-bit data bus?

The question was of the "what if" type, what could have been in the
mid 1970s to build a better chip with what we know about chips now,
instead of building a 6502, with similar boundary conditions.

> If so, why not just use something that is already in a library as a CPU and
> not bother ?
><
> The utility of reinventing this wheel in today's world and market is so close
> to zero it nears exponent underflow.

Nobody suggested developing such beast for today's market; it
would be a hobby project at most.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Tuesday, July 27, 2021 at 12:53:02 PM UTC-5, Anton Ertl wrote:
>> a...@littlepinkcloud.invalid writes:
>> >MitchAlsup <Mitch...@aol.com> wrote:
>> >> 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).)
>> >
>> >Indeed, and when the PDP-8 was actually implemented as a single
>> >(IM6100) IC it took 4000 tranisistors, which given the awfulness of
>> >the instruction set no longer looked like such a good deal.
>> However, the IM6100 was in CMOS (compared to NMOS for 6502), which
>> costs extra transistors (I think 10 transistors for the 5-input NAND
>> gate). Also, the IM6100 included the "Extended Arithmetic Element"
>> (multiply and divide instructions, and the MQ register). So I expect
>> that an NMOS implementation of the basic PDP-8 instruction set would
>> take fewer transistors than a 6502. I would not consider it a better
>> 6502, though, and it certainly does not fit the "8-bit data bus"
>> requirement.
><
>Is the requirement to have only a 16-bit address bus and a 8-bit data bus?

The IM6100 also does not satisfy the 16-bit address bus requirement.

The other requirement given by the OP
<sde7eg$hgb$1@newsreader4.netcologne.de> was:

|Squeezing the functionality of a CPU into ~3500 transistors (plus
|~1000 transistors used as resistors) was quite an achievement.

>If so, why not just use something that is already in a library as a CPU and
>not bother ?
><
>The utility of reinventing this wheel in today's world and market is so close
>to zero it nears exponent underflow.

The problem is not about utility, but about insight:

|Could we do better knowing what we know now?

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