Fantasy architecture: the 10-bit byte
248 views
Skip to first unread message
Russell Wallace
Dec 18, 2022, 6:51:50 AM12/18/22
to
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?
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?
John Dallman
Dec 18, 2022, 9:05:03 AM12/18/22
to
In article <41a60986-1046-4318...@googlegroups.com>,
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.
John
russell...@gmail.com (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.
>
> 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.)
The 68000 handled 16MB of RAM, with 24-bit external addressing.
> 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.)
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.
John
Russell Wallace
Dec 18, 2022, 9:15:38 AM12/18/22
to
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.
> 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.
Stephen Fuld
Dec 18, 2022, 10:19:05 AM12/18/22
to
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)
snip description of interesting thought experiment.
> Most instructions are 20 bits,
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)
Russell Wallace
Dec 18, 2022, 10:28:51 AM12/18/22
to
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?
John Dallman
Dec 18, 2022, 11:23:45 AM12/18/22
to
In article <d204423f-d342-4cf6...@googlegroups.com>,
happening, and the time when it's too late to introduce a competing
architecture, is very narrow. The Z80 managed to hit it, but it started
because some engineers at Intel were unhappy with management, before
microcomputers started to become popular. It's also software-compatible
with the 8080, and the 2010 isn't compatible with anything.
A machine that uses 10-bit bytes also isn't compatible with lots of
existing parts, such as 8-bit-wide ROMs, EPROMs, and so on, nor UARTs
that handle 7- and 8-bit characters. So building a microcomputer out of
it is expensive, in an era where low cost was critical.
If you want 10-bit bytes to become popular, I think you need to get them
into the IBM 360, which will be hard.
John
russell...@gmail.com (Russell Wallace) wrote:
> True! On the other hand, once adequate microprocessors did exist,
> people very quickly glommed onto them and started building
> microcomputers around them.
Perfectly true. However, the window between the time when that started
> True! On the other hand, once adequate microprocessors did exist,
> people very quickly glommed onto them and started building
> microcomputers around them.
happening, and the time when it's too late to introduce a competing
architecture, is very narrow. The Z80 managed to hit it, but it started
because some engineers at Intel were unhappy with management, before
microcomputers started to become popular. It's also software-compatible
with the 8080, and the 2010 isn't compatible with anything.
A machine that uses 10-bit bytes also isn't compatible with lots of
existing parts, such as 8-bit-wide ROMs, EPROMs, and so on, nor UARTs
that handle 7- and 8-bit characters. So building a microcomputer out of
it is expensive, in an era where low cost was critical.
If you want 10-bit bytes to become popular, I think you need to get them
into the IBM 360, which will be hard.
John
Anton Ertl
Dec 18, 2022, 1:03:50 PM12/18/22
to
Russell Wallace <russell...@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=
>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 =
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=
>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
<2021Jul2...@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...@googlegroups.com>
>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
<2021Jul2...@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...@googlegroups.com>
MitchAlsup
Dec 18, 2022, 1:06:26 PM12/18/22
to
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.
instead of 8 DRAM DIMMs (or worse you require 3×4-bit DIMMs instead of 2).
b) byte lookup tables are 4× bigger.
John Levine
Dec 18, 2022, 3:29:26 PM12/18/22
to
According to Russell Wallace <russell...@gmail.com>:
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, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
>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 ...
>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.
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, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Brett
Dec 18, 2022, 6:03:48 PM12/18/22
to
market.
Uppercase plus numbers and special characters for processing 80 character
punched cards in financial transactions written in COBOL.
Russell Wallace
Dec 18, 2022, 6:35:03 PM12/18/22
to
On Sunday, December 18, 2022 at 6:03:50 PM UTC, Anton Ertl wrote:
> 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.
> 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.
> >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.
> 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.
> 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.
MitchAlsup
Dec 18, 2022, 6:41:55 PM12/18/22
to
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.
MitchAlsup
Dec 18, 2022, 6:46:24 PM12/18/22
to
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.
> 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.
<
80-bit simply does not fit in memory, and the intermix of 64-bit memory and 80-bit
> > 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.
<
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
> > 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.
<
never to return.
<
My full RISC chip from 1985 fits in less than 0.1mm in 5nm.
Quadibloc
Dec 18, 2022, 7:30:16 PM12/18/22
to
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-8 was surely post 360.
> PDP-6 was surely post 1964.
designing it before the 360 came out, which is why it took so much
inspiration from the 7090.
John Savard
Russell Wallace
Dec 18, 2022, 8:02:06 PM12/18/22
to
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.
> There are some things not worth arguing about. 8-bit bytes is one of those.
robf...@gmail.com
Dec 18, 2022, 10:18:53 PM12/18/22
to
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.
John Levine
Dec 18, 2022, 11:23:14 PM12/18/22
to
According to robf...@gmail.com <robf...@gmail.com>:
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.
>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
>> 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.
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.
Stephen Fuld
Dec 19, 2022, 12:02:26 AM12/19/22
to
On 12/18/2022 8:23 PM, John Levine wrote:
> According to robf...@gmail.com <robf...@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
> According to robf...@gmail.com <robf...@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.
circuits to solve all problems that Boolean algebra could solve.
BGB
Dec 19, 2022, 12:41:43 AM12/19/22
to
On 12/18/2022 10:23 PM, John Levine wrote:
> According to robf...@gmail.com <robf...@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
> According to robf...@gmail.com <robf...@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.
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.
...
Thomas Koenig
Dec 19, 2022, 1:11:02 AM12/19/22
to
Russell Wallace <russell...@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.
> 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.
IBM certainly knew better, from the 704.
Chosing the exponent range of real and double to coincide was not
a great decision, either.
BGB
Dec 19, 2022, 1:12:48 AM12/19/22
to
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.
> 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.
>
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.
>
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.
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.
...
Marcus
Dec 19, 2022, 1:45:13 AM12/19/22
to
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
> 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.
>
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.
BGB
Dec 19, 2022, 2:10:12 AM12/19/22
to
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
> 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.
>
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.
...
Thomas Koenig
Dec 19, 2022, 2:18:44 AM12/19/22
to
BGB <cr8...@gmail.com> schrieb:
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 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
>> 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.
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.
Russell Wallace
Dec 19, 2022, 2:46:54 AM12/19/22
to
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 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 you tried releasing a 10-bit-byte machine today, of course, you're right, it would be a nonstarter.
Scott Lurndal
Dec 19, 2022, 10:10:37 AM12/19/22
to
>PDP-6 was surely post 1964.
EricP
Dec 19, 2022, 11:36:53 AM12/19/22
to
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
>
> 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.
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
BGB
Dec 19, 2022, 11:53:46 AM12/19/22
to
On 12/19/2022 1:18 AM, Thomas Koenig wrote:
> BGB <cr8...@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.
>
But, the IBM PC was mostly intended for home and business users? ...
> BGB <cr8...@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.
>
Or, I think it was like, the main PC was intended for business, PCjr for
home users, but the PCjr was a flop, people either going for the full PC
or the PC clones.
Granted, I guess it is possible Intel could have had markets for this
other than the IBM PC ?...
> And binary16 is only useful for very limited applications, like neural
> networks. Even calculating everyday geometries will get you into
> trouble.
Neural Nets (*1);
Pixel calculations;
Audio filtering;
...
*1: Though, in my own testing here, it is necessary to fiddle with stuff
here to try to prevent the net from training itself in ways that values
will go out of range (in effect, the training algorithm also needs to
use Binary16).
For 3D geometry, they work well enough if the 3D model isn't too large
or doesn't require too much detail.
For something like a character model, no one is likely to notice.
For something like scene geometry, usually need a little more than this.
For things like the transformation matrices, one really needs full
single precision if possible.
But, with ~ 3 significant figures, they should be fairly widely
applicable to many sorts of problems (along with the common tendency of
people to express typical values as x.xx*10^y or similar).
And, also all of the people that use 3.14 as their standard value for
PI, 2.72 for E, ... And also often don't want answers that are much
longer than 2 or 3 digits.
Granted, the dynamic range for Binary16 isn't particularly large.
But, as noted, some things it wouldn't really work. For example, it
couldn't give cent-accurate values for adding up values on a typical
shopping receipt, ...
But, for many of the types of problems where one might otherwise use,
say, 13.3 fixed point or similar, Binary16 could have been be a usable
alternative.
More just a question of why Binary32 was seemingly seen as the minimum
here, in an era where aggressive cost optimization of pretty much
everything seemed like a sensible option.
Or, for x87, why it bothered with a bunch of complex operators (such as
FSIN and FCOS, ...), when presumably the FPU could have been simpler and
cheaper had they had people to do most of these in software ?...
Or, if Binary16 itself would have added cost, why not have had an
instruction that truncated the Binary32 format to 16 bits on store, and
padded it with with zeroes on load. Shouldn't have added too much
additional cost to whatever mechanism they were using to Load/Store
values to RAM.
Anton Ertl
Dec 19, 2022, 1:46:39 PM12/19/22
to
BGB <cr8...@gmail.com> writes:
[8087]
Intel started the 8087 project in 1977 and the 8087 was launched in
1980, before the IBM PC (1981). And the IBM PC (and its clones) were
not an instant hit; e.g., in the early stages of the 386 project
(started 1982) the 386 was just a minor project.
Interestingly, there were earlier math coprocessors: The Am9511 (1977,
fixed point, but with, e.g., trigonometric functions) and Am9512
(1979, floating-point, compatible with draft 754; binary32 and
binary64), which Intel licensed as 8231 and 8232.
>Or, for x87, why it bothered with a bunch of complex operators (such as
>FSIN and FCOS, ...), when presumably the FPU could have been simpler and
>cheaper had they had people to do most of these in software ?...
CISC was in full swing in 1977, RISC at the time limited to the IBM
801 group.
There are also cases where a more complex instruction allows later
improved hardware implementations that are not possible in software,
although I think this kind of thinking was far more common in those
times than waranted, and it's unclear to me whether the 8087 or its
successors ever made use of that (e.g., additional precision in
intermediate results).
But thinking about it again (after reading up on the earlier
co-processors), I think the main reason was that the 8087 ran
asynchronously to the 8086/8088. So the benefit of FSIN was that the
CPU could start an FSIN operation, then do a lot of other stuff, then
deal with the result of the FSIN; by contrast, with an FSIN software
function, you call it, and the CPU is blocked until it is finished.
>Or, if Binary16 itself would have added cost, why not have had an
>instruction that truncated the Binary32 format to 16 bits on store, and
>padded it with with zeroes on load.
The 8087 converts everything into its internal 80+-bit format on
loading and back on storing (plus some optional rounding of the
mantissa to 53 or 23 bits on computations). Binary16 would certainly
have added a cost, and, at the time, provided no benefit. People were
not interesting in FP16 until a few years ago.
[8087]
>Granted, I guess it is possible Intel could have had markets for this
>other than the IBM PC ?...
Certainly.
>other than the IBM PC ?...
Intel started the 8087 project in 1977 and the 8087 was launched in
1980, before the IBM PC (1981). And the IBM PC (and its clones) were
not an instant hit; e.g., in the early stages of the 386 project
(started 1982) the 386 was just a minor project.
Interestingly, there were earlier math coprocessors: The Am9511 (1977,
fixed point, but with, e.g., trigonometric functions) and Am9512
(1979, floating-point, compatible with draft 754; binary32 and
binary64), which Intel licensed as 8231 and 8232.
>Or, for x87, why it bothered with a bunch of complex operators (such as
>FSIN and FCOS, ...), when presumably the FPU could have been simpler and
>cheaper had they had people to do most of these in software ?...
801 group.
There are also cases where a more complex instruction allows later
improved hardware implementations that are not possible in software,
although I think this kind of thinking was far more common in those
times than waranted, and it's unclear to me whether the 8087 or its
successors ever made use of that (e.g., additional precision in
intermediate results).
But thinking about it again (after reading up on the earlier
co-processors), I think the main reason was that the 8087 ran
asynchronously to the 8086/8088. So the benefit of FSIN was that the
CPU could start an FSIN operation, then do a lot of other stuff, then
deal with the result of the FSIN; by contrast, with an FSIN software
function, you call it, and the CPU is blocked until it is finished.
>Or, if Binary16 itself would have added cost, why not have had an
>instruction that truncated the Binary32 format to 16 bits on store, and
>padded it with with zeroes on load.
loading and back on storing (plus some optional rounding of the
mantissa to 53 or 23 bits on computations). Binary16 would certainly
have added a cost, and, at the time, provided no benefit. People were
not interesting in FP16 until a few years ago.
Anton Ertl
Dec 19, 2022, 2:02:07 PM12/19/22
to
Russell Wallace <russell...@gmail.com> writes:
>On Sunday, December 18, 2022 at 6:03:50 PM UTC, Anton Ertl wrote:
>> Russell Wallace <russell...@gmail.com> writes:=20
>On Sunday, December 18, 2022 at 6:03:50 PM UTC, Anton Ertl wrote:
>> >I saw Fred Brooks in an interview remark that one of his few regrets abo=
>ut =3D=20
>> >the 8-bit byte was that 64-bit floating point is not quite enough for do=
>ubl=3D=20
>> >e precision.=20
>>=20
>> Those who made the IEEE 754 standard thought differently.=20
>
>Did they?
According to
<https://en.wikipedia.org/wiki/IEEE-754#Basic_and_interchange_formats>:
|The binary32 and binary64 formats are the single and double formats of
|IEEE 754-1985 respectively.
>> A 10-bit data bus is 25% more expensive than an 8-bit data bus. At=20
>> the same time, with your 20/40-bit instructions, a 10-bit bus requires=20
>> 2-4 bus cycles to load an instruction, which reduces performance=20
>> significantly.=20
>
>Compared to what?
Compared to having 10-bit instructions (plus immediate operands).
There is a reason why instruction sets with many implicit registers
like the 6502 and 8086 were successful when we still had 8-bit busses
and no I-cache.
>The 2010 can add a pair of 20-bit numbers in two cycles. =
A 2010 with 10-bit instructions can take one cycle for an addition (if
you have a 20-bit ALU).
>The 6502 transistor count is much more c=
>onstrained. (For good reason; they were explicitly aimed at a minimum-cost =
>CPU for embedded applications.)
Maybe. But it was hugely successful in general-purpose computers for
the cost reason.
>I don't see a lot of room to do better with=
>in that transistor count.
I do. And actually it's a small-enough project that a dedicated
hoppyist could achieve it in reasonable time. But I am not taking it
on, proving that point is not important enough to me.
John Levine
Dec 19, 2022, 8:16:12 PM12/19/22