Like some others on this newsgroup, I've been noodling around with ideas for an ideal instruction set architecture, though mine are still somewhat vague. I would nonetheless appreciate feedback on what I have. I'm a programmer not a hardware engineer, so it is possible I am missing things a hardware expert will pick up.

The scenario I have in mind is this:

In 1974, Intel released the 8080, which was not the first microprocessor, but was the first good enough that you would want to build a computer around it. People promptly did, initiating a fascinating chain of events that led to a spiritual descendent of that microprocessor being the one on which I am writing this message.

Suppose you could go back to the early seventies and design an architecture to try to outcompete the 8080 and become the long-term basis of the personal computer industry. You get to use everything we have learned between that day and this, with two caveats:

1. You only get to bring back ideas, not equipment, so it must be technically feasible to build the first implementation with the process technology of 1974.

2. It needs to make some kind of commercial sense in the market of the mid to late seventies. The people of that time are not going to listen to a sales pitch like 'trust me, I'm a time traveler, ten years from now, you will be glad you bought into my perfect CPU design'. It needs to offer short to medium-term advantages over competitors like the 8080 and 6800, or at least avoid being dramatically less efficient for no apparent reason.

In that scenario, what's the best that can be done? I don't think a 32-bit RISC microprocessor can be made with the process technology of 1974, and even if it could, I suspect it would be too expensive to succeed in the market.

My idea is to expand the byte to 10 bits, and build a CPU with a 20-bit word size and linear address space, and a 10-bit data bus. I'll call this architecture the 2010.

This immediately gives a megabyte of address space, which is good up through the early eighties. (Even better than it sounds, because on the 2010, an address is two bytes, compared to the Motorola 68000, the OTL chip that was handling a megabyte of linear address space at that time, in which an address is four bytes.) After that, the word size can be expanded to 40 bits, which for all but the largest servers will be good indefinitely. (This schedule has the nonobvious benefit that when the expansion to 40 bits happens, it is hopefully soon enough that the idea that int is always 20 bits, is not yet set in stone. We hopefully avoid what happened OTL where by the time 64-bit machines arrived, we were already stuck forever with 32-bit int.)

A 10-bit byte will be good for a few hundred characters of extended ASCII. A 20-bit word will be good for Unicode, avoiding the trouble that happened OTL when the world tried to squeeze Unicode into a 16-bit word.

I saw Fred Brooks in an interview remark that one of his few regrets about the 8-bit byte was that 64-bit floating point is not quite enough for double precision. The 2010 will have 80-bit double precision (without the trouble that happened on the 8087 when 80-bit numbers tended to be squeezed into 64 bits when saved from registers to memory), which should be an improvement.

Can this chip fit in a 40-pin package? I think so. 20 pins for address bus, 10 for data bus, one each for power and ground, one for clock, one for memory write, one for IRQ, one for reset, still leaves four for things I have not thought of. Or looked at another way, the 6510 took the 6502 pinout and found six more pins for other purposes, which is exactly the extra number needed here.

Will the 20-bit address space make sense in the seventies? I think so. It is true that the numerical majority of individual personal computers did not exceed 64K RAM for the next few years after 1974, but nonetheless, the 64K address space was exhausted very quickly, well before the end of the decade:
https://retrocomputing.stackexchange.com/questions/22194/did-anyone-ever-put-half-a-megabyte-of-memory-in-an-altair

The benefits of 20-bit addressing for serious computing will be clearly visible, as will the advantages of standardizing on a single architecture so that software is easily portable across all microcomputers. (The Z80 and CP/M were motivated by the perceived benefits of such portability, as to some extent were the 8088 and QDOS that became MS-DOS.)

Can the initial implementation be manufactured with available process technology?

https://en.wikipedia.org/wiki/Transistor_count

The above says the Toshiba TLCS-12 was 11,000 transistors in 6-micron process in 1973. That seems consistent with the surrounding entries, in a way that suggests that was about the limit of what you could do, or at least of what was economically feasible, at the time. I'll take that as the applicable limit: 11,000 transistors.

ARM was 25,000 transistors in 1985, which tends to confirm that a 32-bit RISC is not feasible in 1974. Looking at a die photo of ARM-1, the largest parts of the chip are the barrel shifter and the registers (16 x 32-bit general-purpose registers plus some special-purpose ones).

The 2010 cannot afford a barrel shifter, so leave that out. (It will be added in a later version.) Just have an instruction to shift one bit right. (Shift left can be accomplished by adding the operand to itself.)

I think we want 32 architectural integer registers in the long run, so reserve 5 bits for register specifiers. But don't have enough transistors for that many in the initial implementation. Say the initial implementation has 8 registers. That includes the stack pointer and a zero register, but not the program counter. That's much smaller than the register bank on ARM-1, hopefully small enough to be affordable.

This is going to be a RISC CPU in the sense of trying to stay reasonably minimal, few addressing modes (probably just register with small constant offset), load-store architecture, and registers are always treated as words; unlike the 8-bit CPUs, there is no notion of treating a register as a pair of byte-size registers.

All memory access must be aligned, i.e. words must be read or written at even addresses.

Most instructions are 20 bits, though a few are 40 bits, specifically: jump and link; jump (a special case: specify r0 as the link register); load a 20-bit constant. Each of these takes a second word as the constant operand. (Is there any benefit to be gained by requiring long instructions to be aligned on 4-byte addresses?)

It's nice to have compare and branch in one instruction, but I don't think that will fit in a 20-bit word anyway, so fall back on the classic four status flags, CNVZ, and let compare and branch be separate instructions.

Decimal arithmetic is important, but I have become convinced that it's not worth implementing BCD in hardware. Just stick to binary integers representing cents, or whatever the current smallest unit being worked with is.

Integer multiply and divide will be left for later implementations. A floating-point coprocessor, MMU etc. will also come later.

Hoping for a clock speed of something like 1 MHz in the initial version, with the simplest instructions (e.g. ADD) taking two cycles, more complex instructions (that need to transfer another word) taking four cycles. That would make the 2010 competitive in performance by the standards of the time.

Does this look feasible? Is there any low hanging fruit I am missing, any clear way to do better with the resources available in this scenario?

On Sunday, December 18, 2022 at 2:05:03 PM UTC, John Dallman wrote:
> The difficulty with persuading someone to build the 2010 is that its
> address space is unnecessarily large for the needs of the early 1970s.
> That's because the early 8-bit microprocessors were not designed for
> microcomputers, which had barely been thought of, but for embedded
> systems. For those, 64KB was plenty.

True! On the other hand, once adequate microprocessors did exist, people very quickly glommed onto them and started building microcomputers around them.

On 12/18/2022 3:51 AM, Russell Wallace wrote:

snip description of interesting thought experiment.

> Most instructions are 20 bits,

With 5 bits for register number, and RISC style instructions requiring
three register specifiers per instruction, that only leave 5 bits for op
code, or a maximum of 32 instructions. Choose carefully! :-)

Alternatively, you might consider instructions where the destination is
also one of the sources. This will cost you some extra instructions to
preserve values in registers, but will give you more bits in the
instruction to use for op codes, etc.

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

On Sunday, December 18, 2022 at 3:19:05 PM UTC, Stephen Fuld wrote:
> On 12/18/2022 3:51 AM, Russell Wallace wrote:
>
> snip description of interesting thought experiment.
> > Most instructions are 20 bits,
> With 5 bits for register number, and RISC style instructions requiring
> three register specifiers per instruction, that only leave 5 bits for op
> code, or a maximum of 32 instructions. Choose carefully! :-)
>
> Alternatively, you might consider instructions where the destination is
> also one of the sources. This will cost you some extra instructions to
> preserve values in registers, but will give you more bits in the
> instruction to use for op codes, etc.

Right :) I am actually thinking the latter, generally speaking; it doesn't seem to be a huge burden for x86 and 68k.

That having been said, as far as availability of instruction bits goes, could take add and subtract, the two most common instructions, and make those three-register, while all the other ALU instructions are two-register.

But would that cost a significant amount of extra chip area for the control circuitry, for two different ALU instruction formats?

Russell Wallace <russell.wallace@gmail.com> writes:
>1. You only get to bring back ideas, not equipment, so it must be technical=
>ly feasible to build the first implementation with the process technology o=
>f 1974.
>
>2. It needs to make some kind of commercial sense in the market of the mid =
>to late seventies. The people of that time are not going to listen to a sal=
>es pitch like 'trust me, I'm a time traveler, ten years from now, you will =
>be glad you bought into my perfect CPU design'. It needs to offer short to =
>medium-term advantages over competitors like the 8080 and 6800, or at least=
> avoid being dramatically less efficient for no apparent reason.
....
>This immediately gives a megabyte of address space, which is good up throug=
>h the early eighties.

But is totally irrelevant in 1974 (at least if you want to compete
with the 8080 and the 6800). 64KB was not limiting for microcomputers
until the 1980s.

>I saw Fred Brooks in an interview remark that one of his few regrets about =
>the 8-bit byte was that 64-bit floating point is not quite enough for doubl=
>e precision.

Those who made the IEEE 754 standard thought differently. And the
hardware makers, too, and there are not enough customers for binary128
FP to get such hardware into the mainstream. Even the 80-bit format
of the 8087 has been retired to a legacy.

>The 2010 will have 80-bit double precision (without the troubl=
>e that happened on the 8087 when 80-bit numbers tended to be squeezed into =
>64 bits when saved from registers to memory),

You can save 80-bit numbers to 80 bits in memory. If people choose to
save them in 64 bits, it shows that they don't care for the 80-bit.

>Can this chip fit in a 40-pin package? I think so. 20 pins for address bus,=
> 10 for data bus,

A 10-bit data bus is 25% more expensive than an 8-bit data bus. At
the same time, with your 20/40-bit instructions, a 10-bit bus requires
2-4 bus cycles to load an instruction, which reduces performance
significantly. There's a reason why the 68008 is perceived as a snail
(compared to the 68000), while the 8088 was good enough (compared to
the 8086).

one each for power and ground, one for clock, one for mem=
>ory write, one for IRQ, one for reset, still leaves four for things I have =
>not thought of. Or looked at another way, the 6510 took the 6502 pinout and=
> found six more pins for other purposes, which is exactly the extra number =
>needed here.
>
>Will the 20-bit address space make sense in the seventies? I think so. It i=
>s true that the numerical majority of individual personal computers did not=
> exceed 64K RAM for the next few years after 1974, but nonetheless, the 64K=
> address space was exhausted very quickly, well before the end of the decad=
>e:
>https://retrocomputing.stackexchange.com/questions/22194/did-anyone-ever-pu=
>t-half-a-megabyte-of-memory-in-an-altair

Which points to https://i.stack.imgur.com/vzO5T.png, which tells us
that a "65K RAM Board Kit" cost $2599 (in 1977), and you need 16 such
boards to achieve 1MB. If you were willing to spend that much money
in 1977, would you buy a 10-bit micro, or a minicomputer?

The market for a micro with more than 64KB was miniscule in the 1970s.

>I think we want 32 architectural integer registers in the long run, so rese=
>rve 5 bits for register specifiers.

Which means you waste instruction bits for a feature you don't use.

>But don't have enough transistors for t=
>hat many in the initial implementation. Say the initial implementation has =
>8 registers.

That's pretty big for 1974, especially with 20-bit registers.

Some time ago we have discussed a similar scenario as you do (in the
thread starting with <sde7eg$hgb$1@newsreader4.netcologne.de>), but
assumed that it had to fit in the transistor count of the 6502. In
<2021Jul24.162915@mips.complang.tuwien.ac.at> I suggested a RISC-style
architecture with three general-purpose registers plus a zero
register.

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

a) All memory is 25% more expensive because you require 10 DRAM DIMMs
instead of 8 DRAM DIMMs (or worse you require 3×4-bit DIMMs instead of 2).

b) byte lookup tables are 4× bigger.

According to Russell Wallace <russell.wallace@gmail.com>:
>In that scenario, what's the best that can be done? I don't think a 32-bit RISC microprocessor can be made with the
>process technology of 1974, and even if it could, I suspect it would be too expensive to succeed in the market.
>
>My idea is to expand the byte to 10 bits, and build a CPU with a 20-bit word size and linear address space, and a 10-bit
>data bus. I'll call this architecture the 2010.

Repeat after me: There Are No New Bad Ideas ...

In the 1970s, BBN built the C/30 to replace the 16-bit Honeywell 316
machines used in Arpanet IMPs because Honeywell stopped making 316s.
The C/30 was microprogrammed to emulate a 316 so it could run the
existing IMP code. BBN believed (wrongly as it turned out) that they
were in the computer business so they expanded it to a larger C/70
just as you proposed, with 10 bit bytes and a 20 bit address space.

It was a complete failure even though it was quite fast and phyiscally
worked fine. I don't know all the reasons it failed but I do recall
talking to one of the people working on it who told me that porting
code from 8-bit byte systems was slow and painful because there were
so many implicit assumptions about the byte size.

There were plenty of machines with 8-bit bytes and 16 bit addresses
that used a variety of mapping and bank switching hacks to handle
more memory. The PDP-11 got up to 22 bit physical addresses before
it died, and the 80286 had 24 bit addresses.

When IBM chose 8 bit bytes in 1964 for S/360 they really hit a
sweet spot. I don't think there was ever another new architecture
that didn't have power of 2 addresses other than some special
purpose DSPs.

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

MitchAlsup <MitchAlsup@aol.com> wrote:
> a) All memory is 25% more expensive because you require 10 DRAM DIMMs
> instead of 8 DRAM DIMMs (or worse you require 3×4-bit DIMMs instead of 2).
>
> b) byte lookup tables are 4× bigger.
>

Six bit bytes is better for that generation and had a large part of the
market.

Uppercase plus numbers and special characters for processing 80 character
punched cards in financial transactions written in COBOL.

On Sunday, December 18, 2022 at 6:03:50 PM UTC, Anton Ertl wrote:
> Russell Wallace <russell...@gmail.com> writes:
> >I saw Fred Brooks in an interview remark that one of his few regrets about =
> >the 8-bit byte was that 64-bit floating point is not quite enough for doubl=
> >e precision.
>
> Those who made the IEEE 754 standard thought differently.

Did they? Look at the resources Intel spent on getting 80-bit floating point into the 8087.

> And the
> hardware makers, too, and there are not enough customers for binary128
> FP to get such hardware into the mainstream. Even the 80-bit format
> of the 8087 has been retired to a legacy.

Actually that is an interesting question: where has the demand for more than 64-bit floating point gone? The impression I get is that people have become used to implementing it with double-double, which is a terribly painful hack, but does actually work, and suffices to bleed off the demand so no one is pushing for direct hardware support anymore.

> A 10-bit data bus is 25% more expensive than an 8-bit data bus. At
> the same time, with your 20/40-bit instructions, a 10-bit bus requires
> 2-4 bus cycles to load an instruction, which reduces performance
> significantly.

Compared to what? The 2010 can add a pair of 20-bit numbers in two cycles. The 6502 added a pair of 16-bit numbers in over twenty cycles. The VAX was faster, sure, but also cost several hundred thousand dollars.

> Some time ago we have discussed a similar scenario as you do (in the
> thread starting with <sde7eg$hgb$1...@newsreader4.netcologne.de>), but
> assumed that it had to fit in the transistor count of the 6502. In
> <2021Jul2...@mips.complang.tuwien.ac.at> I suggested a RISC-style
> architecture with three general-purpose registers plus a zero
> register.

That is an interesting discussion! The 6502 transistor count is much more constrained. (For good reason; they were explicitly aimed at a minimum-cost CPU for embedded applications.) I don't see a lot of room to do better within that transistor count.

On Sunday, December 18, 2022 at 2:29:26 PM UTC-6, John Levine wrote:
> According to Russell Wallace <russell...@gmail.com>:
> >In that scenario, what's the best that can be done? I don't think a 32-bit RISC microprocessor can be made with the
> >process technology of 1974, and even if it could, I suspect it would be too expensive to succeed in the market.
> >
> >My idea is to expand the byte to 10 bits, and build a CPU with a 20-bit word size and linear address space, and a 10-bit
> >data bus. I'll call this architecture the 2010.
> Repeat after me: There Are No New Bad Ideas ...
>
> In the 1970s, BBN built the C/30 to replace the 16-bit Honeywell 316
> machines used in Arpanet IMPs because Honeywell stopped making 316s.
> The C/30 was microprogrammed to emulate a 316 so it could run the
> existing IMP code. BBN believed (wrongly as it turned out) that they
> were in the computer business so they expanded it to a larger C/70
> just as you proposed, with 10 bit bytes and a 20 bit address space.
>
> It was a complete failure even though it was quite fast and phyiscally
> worked fine. I don't know all the reasons it failed but I do recall
> talking to one of the people working on it who told me that porting
> code from 8-bit byte systems was slow and painful because there were
> so many implicit assumptions about the byte size.
>
> There were plenty of machines with 8-bit bytes and 16 bit addresses
> that used a variety of mapping and bank switching hacks to handle
> more memory. The PDP-11 got up to 22 bit physical addresses before
> it died, and the 80286 had 24 bit addresses.
>
> When IBM chose 8 bit bytes in 1964 for S/360 they really hit a
> sweet spot. I don't think there was ever another new architecture
> that didn't have power of 2 addresses other than some special
> purpose DSPs.
<
PDP-8 was surely post 360.
PDP-6 was surely post 1964.
But, yeah, 8-bit bytes have won.
And so has little endian.
<
There are some things not worth arguing about. 8-bit bytes is one of those.
>
> --
> 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 Sunday, December 18, 2022 at 5:35:03 PM UTC-6, Russell Wallace wrote:
> On Sunday, December 18, 2022 at 6:03:50 PM UTC, Anton Ertl wrote:
> > Russell Wallace <russell...@gmail.com> writes:
> > >I saw Fred Brooks in an interview remark that one of his few regrets about =
> > >the 8-bit byte was that 64-bit floating point is not quite enough for doubl=
> > >e precision.
> >
> > Those who made the IEEE 754 standard thought differently.
> Did they? Look at the resources Intel spent on getting 80-bit floating point into the 8087.
<
That was more of Kahan being on the Intel FP architecture team than 1EEE.
>
> > And the
> > hardware makers, too, and there are not enough customers for binary128
> > FP to get such hardware into the mainstream. Even the 80-bit format
> > of the 8087 has been retired to a legacy.
<
> Actually that is an interesting question: where has the demand for more than 64-bit floating point gone? The impression I get is that people have become used to implementing it with double-double, which is a terribly painful hack, but does actually work, and suffices to bleed off the demand so no one is pushing for direct hardware support anymore.
<
80-bit simply does not fit in memory, and the intermix of 64-bit memory and 80-bit
calculations causes uncountable number of "troubles".
<
> > A 10-bit data bus is 25% more expensive than an 8-bit data bus. At
> > the same time, with your 20/40-bit instructions, a 10-bit bus requires
> > 2-4 bus cycles to load an instruction, which reduces performance
> > significantly.
<
> Compared to what? The 2010 can add a pair of 20-bit numbers in two cycles.. The 6502 added a pair of 16-bit numbers in over twenty cycles. The VAX was faster, sure, but also cost several hundred thousand dollars.
<
> > Some time ago we have discussed a similar scenario as you do (in the
> > thread starting with <sde7eg$hgb$1...@newsreader4.netcologne.de>), but
> > assumed that it had to fit in the transistor count of the 6502. In
> > <2021Jul2...@mips.complang.tuwien.ac.at> I suggested a RISC-style
> > architecture with three general-purpose registers plus a zero
> > register.
> That is an interesting discussion! The 6502 transistor count is much more constrained. (For good reason; they were explicitly aimed at a minimum-cost CPU for embedded applications.) I don't see a lot of room to do better within that transistor count.
<
This is an era where we can only do mental gymnastics. It is an ear that is gone
never to return.
<
My full RISC chip from 1985 fits in less than 0.1mm in 5nm.

On Sunday, December 18, 2022 at 4:41:55 PM UTC-7, MitchAlsup wrote:

> PDP-8 was surely post 360.

But the PDP-5 (with which the PDP-8 is almost compatible) came out in 1963.

> PDP-6 was surely post 1964.

The PDP-6 was first delivered in the summer of 1964, so they started
designing it before the 360 came out, which is why it took so much
inspiration from the 7090.

John Savard

On Sunday, December 18, 2022 at 11:41:55 PM UTC, MitchAlsup wrote:
> There are some things not worth arguing about. 8-bit bytes is one of those.

Oh, indeed! There is a reason I wrote up my alternate architecture as an intellectual exercise in alternate history, not as a proposal for something to actually build today.

On Sunday, December 18, 2022 at 8:02:06 PM UTC-5, Russell Wallace wrote:
> On Sunday, December 18, 2022 at 11:41:55 PM UTC, MitchAlsup wrote:
> > There are some things not worth arguing about. 8-bit bytes is one of those.
> Oh, indeed! There is a reason I wrote up my alternate architecture as an intellectual exercise in alternate history, not as a proposal for something to actually build today.

I like the “what if” alternate reality thought experiments. One of my favorites is what
if the CPU had become popular 100 years earlier? It is not impossible. I think they
could have been made using diode-diode logic. Power consumption would be
enormous.

One can play with alternate ideas using programmable logic like an FPGA. I think
though the eight-bit byte would be difficult to beat. Rather than a 10-bit machine.
An eight-bit machine something like the 8088, but with a 24-bit address bus could
be made. (Made one in the FPGA paragraph size=256 bytes).

I think a machine with 10-bit bytes would look more like a 68k, PDP machine.. Say
eight or sixteen registers. I do not think the RISC paradigm was well known in the
70’s. I think a design would be unlikely to include additional register spec bits. I
spent some time playing with alternates to the 8-bit byte because just about any
size could be used in an FPGA. I have a 12-bit 6809 machine that works okay..
Coming up 12-bit peripherals was interesting. Designed and coded a machine with
13-bit bytes because it works out to a 52-bit machine instead of a 64-bit machine.
It has a nice progression of floats precision. It is a little less hardware to fit in the
FPGA. 104-bit quad precision arithmetic.

According to robf...@gmail.com <robfi680@gmail.com>:
>On Sunday, December 18, 2022 at 8:02:06 PM UTC-5, Russell Wallace wrote:
>> On Sunday, December 18, 2022 at 11:41:55 PM UTC, MitchAlsup wrote:
>> > There are some things not worth arguing about. 8-bit bytes is one of those.
>> Oh, indeed! There is a reason I wrote up my alternate architecture as an intellectual exercise in alternate history, not
>as a proposal for something to actually build today.
>
>I like the “what if” alternate reality thought experiments. One of my favorites is what
>if the CPU had become popular 100 years earlier? It is not impossible. I think they
>could have been made using diode-diode logic. Power consumption would be
>enormous.

Eccles and Jordan invented the flip-flop in 1918 so, sure. De Forest
invented the triode in 1906 so flip-flops could have been invented a
decade earlier.

I get the impression that for many decades it was considered a
curiosity with little if any practical use. Only in the late 1930s did
anyone start to build electronic logic.
--
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 12/18/2022 8:23 PM, John Levine wrote:
> According to robf...@gmail.com <robfi680@gmail.com>:
>> On Sunday, December 18, 2022 at 8:02:06 PM UTC-5, Russell Wallace wrote:
>>> On Sunday, December 18, 2022 at 11:41:55 PM UTC, MitchAlsup wrote:
>>>> There are some things not worth arguing about. 8-bit bytes is one of those.
>>> Oh, indeed! There is a reason I wrote up my alternate architecture as an intellectual exercise in alternate history, not
>> as a proposal for something to actually build today.
>>
>> I like the “what if” alternate reality thought experiments. One of my favorites is what
>> if the CPU had become popular 100 years earlier? It is not impossible. I think they
>> could have been made using diode-diode logic. Power consumption would be
>> enormous.
>
> Eccles and Jordan invented the flip-flop in 1918 so, sure. De Forest
> invented the triode in 1906 so flip-flops could have been invented a
> decade earlier.
>
> I get the impression that for many decades it was considered a
> curiosity with little if any practical use. Only in the late 1930s did
> anyone start to build electronic logic.

1938 was Shannon's paper demonstrating that you could use switching
circuits to solve all problems that Boolean algebra could solve.

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

On 12/18/2022 10:23 PM, John Levine wrote:
> According to robf...@gmail.com <robfi680@gmail.com>:
>> On Sunday, December 18, 2022 at 8:02:06 PM UTC-5, Russell Wallace wrote:
>>> On Sunday, December 18, 2022 at 11:41:55 PM UTC, MitchAlsup wrote:
>>>> There are some things not worth arguing about. 8-bit bytes is one of those.
>>> Oh, indeed! There is a reason I wrote up my alternate architecture as an intellectual exercise in alternate history, not
>> as a proposal for something to actually build today.
>>
>> I like the “what if” alternate reality thought experiments. One of my favorites is what
>> if the CPU had become popular 100 years earlier? It is not impossible. I think they
>> could have been made using diode-diode logic. Power consumption would be
>> enormous.
>
> Eccles and Jordan invented the flip-flop in 1918 so, sure. De Forest
> invented the triode in 1906 so flip-flops could have been invented a
> decade earlier.
>
> I get the impression that for many decades it was considered a
> curiosity with little if any practical use. Only in the late 1930s did
> anyone start to build electronic logic.

Could have been amusing if there were a world where logic were built
using tiny hydraulic components.

Since the logic doesn't need to drive large cylinders, could use very
small hydraulic lines at low pressures.

Possibly all the hydraulic lines and valves could be made out of copper
and brass, using a lot of cast-brass components for all of the valves, ...

Brass would allow components to be cast in molds, and then soldered
together for final assembly.

Then, say, one has a small steam engine running the hydraulic pump (with
the hydraulic fluid then fed through a condenser).

Valves could be a mix multiply types, say:
Butterfly valves (for mechanical on/off);
Spool valves (like in traditional hydraulics);
Interference valves (using the shape of a valve cavity and turbulence
for logic, similar to a Tesla valve, *);
....

*: Say, a Tesla valve could function sort of like a hydraulic diode, but
would be unable to (completely) avoid back-flow.

Spool valves would have less issue with leakage or back-flow, but would
be harder to mass produce or miniaturize as effectively. In either case,
it would likely be more cost-effective to cast the parts out of brass
(likely using machined molds), rather than machining every valve housing
and spool on a lathe or similar.

Then, say, one knows if they have an improperly terminated connection,
because then all their data leaks out onto the floor...

Possibly data-connections look like bundles of small pipes with a
connector plate consisting of rows of holes, with a dense rubberized
separator/gasket. Data connections are then bolted together.

Possibly, say, read-only memory devices consist of spinning metal disks
or drums with holes drilled into them, with valves then used to gate the
data-bits through when the disk or drum rotates to the correct position.

Whether a bit is 1 or 0 depends mostly if (at the moment it is clocked
in) the line is connected to the supply or being let drain to the sump
(with the clock as an alternating supply/drain being driven by a
spinning rotor).

Not entirely sure what level of absurdity would be involved with trying
to build a register file or RAM out of hydraulic components. Seems like
for RAM, it might make sense to have the mass of valves representing the
memory device to essentially spin around as a drum (making connections
every time the drum rotates into a position where the holes line up).

Likely, a pair of lines could be used to signal Read or Write
operations, with the Read signal causing the drum to drive the outputs,
and the Write signal causing the drum to update its internal valves (at
that position) to whatever value is being driven on the data ports.

Possibly the memory bits are a bistable component, likely using a
rotating metal component and a latch/spring (driving the Write port
releases the latch, with the Read port allowed to drain to the sump,
where driving the bit causes it to turn to one position due to the
applied pressure, and no signal causes it to return to the other
position due to the spring; when no Write signal is asserted, the latch
prevents the valve from rotating, and driving the Read signal drives the
output bit based on whether the valve in question is in the open or
closed position at that moment).

External storage could be in the form of perforated tape (which then
either allows "sense pins" to push through the holes, or blocks the
sense pins, which in turn drive small hydraulic valves).

Seems like something like this could have possibly been built with early
1800s technology.

....

Russell Wallace <russell.wallace@gmail.com> schrieb:

> I saw Fred Brooks in an interview remark that one of his few
> regrets about the 8-bit byte was that 64-bit floating point is
> not quite enough for double precision.

No regrets about the 32-bit floating point real that was introduced?
IBM certainly knew better, from the 704.

Chosing the exponent range of real and double to coincide was not
a great decision, either.

On 12/18/2022 5:35 PM, Russell Wallace wrote:
> On Sunday, December 18, 2022 at 6:03:50 PM UTC, Anton Ertl wrote:
>> Russell Wallace <russell...@gmail.com> writes:
>>> I saw Fred Brooks in an interview remark that one of his few regrets about =
>>> the 8-bit byte was that 64-bit floating point is not quite enough for doubl=
>>> e precision.
>>
>> Those who made the IEEE 754 standard thought differently.
>
> Did they? Look at the resources Intel spent on getting 80-bit floating point into the 8087.
>

For most use cases, 80 bit is overkill.

Meanwhile:
64-bit can do "nearly everything";
32-bit is "usually sufficient";
16-bit is "often sufficient", but more hit/miss.

I suspect likely Binary16 would have been far more popular had it been
popular 20 years earlier.

Not sure why Binary16 wasn't a thing in the 80s, given values were
(generally) smaller back then.

Not sure how much it would have cost though to put a Binary16 FPU into
an 8088 or 80286.

Then again, I guess Binary16 wouldn't have had enough precision to be
usable for spreadsheets or similar.

>> And the
>> hardware makers, too, and there are not enough customers for binary128
>> FP to get such hardware into the mainstream. Even the 80-bit format
>> of the 8087 has been retired to a legacy.
>
> Actually that is an interesting question: where has the demand for more than 64-bit floating point gone? The impression I get is that people have become used to implementing it with double-double, which is a terribly painful hack, but does actually work, and suffices to bleed off the demand so no one is pushing for direct hardware support anymore.
>

I suspect it may be more often the case that people are like "double is
more than sufficient" and leave it at that.

>> A 10-bit data bus is 25% more expensive than an 8-bit data bus. At
>> the same time, with your 20/40-bit instructions, a 10-bit bus requires
>> 2-4 bus cycles to load an instruction, which reduces performance
>> significantly.
>
> Compared to what? The 2010 can add a pair of 20-bit numbers in two cycles. The 6502 added a pair of 16-bit numbers in over twenty cycles. The VAX was faster, sure, but also cost several hundred thousand dollars.
>
>> Some time ago we have discussed a similar scenario as you do (in the
>> thread starting with <sde7eg$hgb$1...@newsreader4.netcologne.de>), but
>> assumed that it had to fit in the transistor count of the 6502. In
>> <2021Jul2...@mips.complang.tuwien.ac.at> I suggested a RISC-style
>> architecture with three general-purpose registers plus a zero
>> register.
>
> That is an interesting discussion! The 6502 transistor count is much more constrained. (For good reason; they were explicitly aimed at a minimum-cost CPU for embedded applications.) I don't see a lot of room to do better within that transistor count.

6502 did pretty well for what it was.

Then again, I guess it wasn't quite minimal, given the Ricoh 2A03 was
still able to drop a few features.

Apparently, WDC still exists and still sells 65C02 and 65C816 based
chips (somehow, was not aware that they still existed).

Also apparently, a 6502 variant is still being made and sold by Renesas.

....

On 2022-12-18, Russell Wallace wrote:
> On Sunday, December 18, 2022 at 3:19:05 PM UTC, Stephen Fuld wrote:
>> On 12/18/2022 3:51 AM, Russell Wallace wrote:
>>
>> snip description of interesting thought experiment.
>>> Most instructions are 20 bits,
>> With 5 bits for register number, and RISC style instructions requiring
>> three register specifiers per instruction, that only leave 5 bits for op
>> code, or a maximum of 32 instructions. Choose carefully! :-)
>>
>> Alternatively, you might consider instructions where the destination is
>> also one of the sources. This will cost you some extra instructions to
>> preserve values in registers, but will give you more bits in the
>> instruction to use for op codes, etc.
>
> Right :) I am actually thinking the latter, generally speaking; it doesn't seem to be a huge burden for x86 and 68k.
>

Yes, I think that on the large, having three register specifiers is
overrated (even though I like it myself, for modern machines), and in
the 1970's it would not be of much value anyway. First of all you would
not have enough GPRs to make it a valuable feature. At best you would
have four "GPRs", or thereabout.

> That having been said, as far as availability of instruction bits goes, could take add and subtract, the two most common instructions, and make those three-register, while all the other ALU instructions are two-register.
>
> But would that cost a significant amount of extra chip area for the control circuitry, for two different ALU instruction formats?

On 12/19/2022 12:45 AM, Marcus wrote:
> On 2022-12-18, Russell Wallace wrote:
>> On Sunday, December 18, 2022 at 3:19:05 PM UTC, Stephen Fuld wrote:
>>> On 12/18/2022 3:51 AM, Russell Wallace wrote:
>>>
>>> snip description of interesting thought experiment.
>>>> Most instructions are 20 bits,
>>> With 5 bits for register number, and RISC style instructions requiring
>>> three register specifiers per instruction, that only leave 5 bits for op
>>> code, or a maximum of 32 instructions. Choose carefully! :-)
>>>
>>> Alternatively, you might consider instructions where the destination is
>>> also one of the sources. This will cost you some extra instructions to
>>> preserve values in registers, but will give you more bits in the
>>> instruction to use for op codes, etc.
>>
>> Right :) I am actually thinking the latter, generally speaking; it
>> doesn't seem to be a huge burden for x86 and 68k.
>>
>
> Yes, I think that on the large, having three register specifiers is
> overrated (even though I like it myself, for modern machines), and in
> the 1970's it would not be of much value anyway. First of all you would
> not have enough GPRs to make it a valuable feature. At best you would
> have four "GPRs", or thereabout.
>

Agreed, if the choice was between, say, 32 or 64 registers and 2R
encodings, or fewer 8 or 16 registers and 3R encodings, I would choose
the 2R encodings...

That said, having 3R for most common-case instructions is a decidedly
"nice to have" feature.

Bus, as for the topic, IMO a 10-bit byte (vs an 8-bit byte) would be a
bad idea.

If one has 8-bit bytes, 8/16/32/64 bit twos-complement and little
endian, ... then they can more easily port most existing code.

If one drops any of these, the amount of "easily ported" code drops to
"almost nothing".

If all the data types and layouts look basically like what one has on a
PC, one can mostly ignore that it is not a PC.

....

>> That having been said, as far as availability of instruction bits
>> goes, could take add and subtract, the two most common instructions,
>> and make those three-register, while all the other ALU instructions
>> are two-register.
>>
>> But would that cost a significant amount of extra chip area for the
>> control circuitry, for two different ALU instruction formats?
>

BGB <cr88192@gmail.com> schrieb:
> On 12/18/2022 5:35 PM, Russell Wallace wrote:
>> On Sunday, December 18, 2022 at 6:03:50 PM UTC, Anton Ertl wrote:
>>> Russell Wallace <russell...@gmail.com> writes:
>>>> I saw Fred Brooks in an interview remark that one of his few regrets about =
>>>> the 8-bit byte was that 64-bit floating point is not quite enough for doubl=
>>>> e precision.
>>>
>>> Those who made the IEEE 754 standard thought differently.
>>
>> Did they? Look at the resources Intel spent on getting 80-bit floating point into the 8087.
>>
>
> For most use cases, 80 bit is overkill.
>
> Meanwhile:
> 64-bit can do "nearly everything";
> 32-bit is "usually sufficient";
> 16-bit is "often sufficient", but more hit/miss.
>
>
> I suspect likely Binary16 would have been far more popular had it been
> popular 20 years earlier.
>
>
> Not sure why Binary16 wasn't a thing in the 80s, given values were
> (generally) smaller back then.

For scientific or engineering computations, 32-bit floats are
barely adequate, or they don't work at all. This is why a lot
of scientific code is in 64-bit. 36-bit floats were much better.

And binary16 is only useful for very limited applications, like neural
networks. Even calculating everyday geometries will get you into
trouble.

On Monday, December 19, 2022 at 7:10:12 AM UTC, BGB wrote:
> If one has 8-bit bytes, 8/16/32/64 bit twos-complement and little
> endian, ... then they can more easily port most existing code.
>
> If one drops any of these, the amount of "easily ported" code drops to
> "almost nothing".

Hence the alternate history scenario. Almost all the code that ran on microcomputers, was written on microcomputers, after 1974, rather than being ported from existing larger machines, so the question of easily ported code was not so important.

If you tried releasing a 10-bit-byte machine today, of course, you're right, it would be a nonstarter.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Sunday, December 18, 2022 at 2:29:26 PM UTC-6, John Levine wrote:
>> According to Russell Wallace <russell...@gmail.com>:
>> >In that scenario, what's the best that can be done? I don't think a 32-bit RISC microprocessor can be made with the
>> >process technology of 1974, and even if it could, I suspect it would be too expensive to succeed in the market.
>> >
>> >My idea is to expand the byte to 10 bits, and build a CPU with a 20-bit word size and linear address space, and a 10-bit
>> >data bus. I'll call this architecture the 2010.
>> Repeat after me: There Are No New Bad Ideas ...
>>
>> In the 1970s, BBN built the C/30 to replace the 16-bit Honeywell 316
>> machines used in Arpanet IMPs because Honeywell stopped making 316s.
>> The C/30 was microprogrammed to emulate a 316 so it could run the
>> existing IMP code. BBN believed (wrongly as it turned out) that they
>> were in the computer business so they expanded it to a larger C/70
>> just as you proposed, with 10 bit bytes and a 20 bit address space.
>>
>> It was a complete failure even though it was quite fast and phyiscally
>> worked fine. I don't know all the reasons it failed but I do recall
>> talking to one of the people working on it who told me that porting
>> code from 8-bit byte systems was slow and painful because there were
>> so many implicit assumptions about the byte size.
>>
>> There were plenty of machines with 8-bit bytes and 16 bit addresses
>> that used a variety of mapping and bank switching hacks to handle
>> more memory. The PDP-11 got up to 22 bit physical addresses before
>> it died, and the 80286 had 24 bit addresses.
>>
>> When IBM chose 8 bit bytes in 1964 for S/360 they really hit a
>> sweet spot. I don't think there was ever another new architecture
>> that didn't have power of 2 addresses other than some special
>> purpose DSPs.
><
>PDP-8 was surely post 360.

PDP-8 (released 1965, designed 63-64) was based on the 12-bit LINC from 1962.

>PDP-6 was surely post 1964.

The 1963 36-bit PDP-6 followed the 18-bit PDP-1 from 1959.

Russell Wallace wrote:
>
> My idea is to expand the byte to 10 bits, and build a CPU with a 20-bit word size and linear address space, and a 10-bit data bus. I'll call this architecture the 2010.

I was searching for info on the TLCS-12 as I found the
Wikipedia claim of 11,000 transistors in 1973 suspect.
However it does seem to be confirmed by a contemporary document that
said it had 2800 gates (presumably pmos with 1 gate = ~4 transistors).

During that search I tripped over info by a fellow claiming that his was
the first microprocessor, whose design started in 1968, completed 1970.
It was 20-bits and was the fly-by-wire controller for the F-14 Tomcat.
The reason you never heard about it was it was classified until 1998.

Internally it is pipelined and has multiple concurrent function units,
but instructions and data are transferred serially to "minimize pin count".

F-14 CADC (F-14's Central Air Data Computer)
https://en.wikipedia.org/wiki/MP944

World's First Microprocessor
"a 20-bit, pipelined, parallel multi-microprocessor chip set for
the greatest fighter jet the USA has ever flown"
https://firstmicroprocessor.com/
https://firstmicroprocessor.com/documents/

“Architecture Of A Microprocessor”
by Ray M. Holt original date: January 1971
https://firstmicroprocessor.com/wp-content/uploads/2020/02/ap1-26-97.pdf

Powerpoint slides with additional info
https://firstmicroprocessor.com/wp-content/uploads/2020/02/2013powerpoint.ppt

Function Unit chip Transistors*chips
- Parallel Multiplier Unit (PMU), 1063*1= 1063
- Parallel Divider Unit (PDU), 1241*1= 1241
- Special Logic Function (CPU) 743*1 743
- Data Steering Unit (SLU) 771*3= 2313
- Random Access Memory (RAM) 2330*3= 6990
- Read-Only Memory Unit (ROM) 3268*19=62092
total 74442

There is also an interesting ~40 min video on its design.
(You can skip the first 10 min)
https://www.youtube.com/watch?v=3GROYRkWvxc