I've been geeking out on the COSMAC 1802 lately -- it was the first processor that I owned all just for me, and that I wrote programs for (in machine code -- not assembly). One of the features of this chip is that while the usual ALU is 8-bit and centered around memory fetches and the accumulator (which they call the 'D' register), there's a 16 x 16-bit register file. Any one of these registers can be incremented or decremented, either as an explicit instruction or as part of a fetch (basically, you can use any one of them as an index, and you can "fetch and increment"). How would you do this most effectively today? How might it have been done back in the mid 1970's when RCA made the chip? Would it make a difference if you were working with a CPLD, FPGA, or some ASIC where you were determined to minimize chip area? I'm assuming that the original had one selectable increment/decrement unit that wrote back numbers to the registers, but I could see them implementing each register as a loadable counter -- I just don't have a good idea of what might use the least real estate. Thanks. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
increment or decrement one of 16, 16-bit registers
Started by ●May 10, 2017
Reply by ●May 10, 20172017-05-10
On 5/10/2017 5:42 PM, Tim Wescott wrote:> I've been geeking out on the COSMAC 1802 lately -- it was the first > processor that I owned all just for me, and that I wrote programs for (in > machine code -- not assembly). > > One of the features of this chip is that while the usual ALU is 8-bit and > centered around memory fetches and the accumulator (which they call the > 'D' register), there's a 16 x 16-bit register file. Any one of these > registers can be incremented or decremented, either as an explicit > instruction or as part of a fetch (basically, you can use any one of them > as an index, and you can "fetch and increment"). > > How would you do this most effectively today? How might it have been > done back in the mid 1970's when RCA made the chip? Would it make a > difference if you were working with a CPLD, FPGA, or some ASIC where you > were determined to minimize chip area? > > I'm assuming that the original had one selectable increment/decrement > unit that wrote back numbers to the registers, but I could see them > implementing each register as a loadable counter -- I just don't have a > good idea of what might use the least real estate.A counter is a register with an adder (although only needing half adders at each bit), so of course the incrementer will take up more logic than a register. Depending on what functions can be done while the register is incrementing, they may use the ALU for all arithmetic operations. Most of the earlier processors conserved logic by time sequencing operations within an instruction. That's why some instructions take so many cycles to complete, it's shuffling data around internally. If you provide some instructions with their descriptions and the cycle counts I bet I can tell you how much is done sequentially and how much is done in parallel. -- Rick C
Reply by ●May 10, 20172017-05-10
On Wed, 10 May 2017 18:56:36 -0400, rickman wrote:> On 5/10/2017 5:42 PM, Tim Wescott wrote: >> I've been geeking out on the COSMAC 1802 lately -- it was the first >> processor that I owned all just for me, and that I wrote programs for >> (in machine code -- not assembly). >> >> One of the features of this chip is that while the usual ALU is 8-bit >> and centered around memory fetches and the accumulator (which they call >> the 'D' register), there's a 16 x 16-bit register file. Any one of >> these registers can be incremented or decremented, either as an >> explicit instruction or as part of a fetch (basically, you can use any >> one of them as an index, and you can "fetch and increment"). >> >> How would you do this most effectively today? How might it have been >> done back in the mid 1970's when RCA made the chip? Would it make a >> difference if you were working with a CPLD, FPGA, or some ASIC where >> you were determined to minimize chip area? >> >> I'm assuming that the original had one selectable increment/decrement >> unit that wrote back numbers to the registers, but I could see them >> implementing each register as a loadable counter -- I just don't have a >> good idea of what might use the least real estate. > > A counter is a register with an adder (although only needing half adders > at each bit), so of course the incrementer will take up more logic than > a register. > > Depending on what functions can be done while the register is > incrementing, they may use the ALU for all arithmetic operations. Most > of the earlier processors conserved logic by time sequencing operations > within an instruction. That's why some instructions take so many cycles > to complete, it's shuffling data around internally. > > If you provide some instructions with their descriptions and the cycle > counts I bet I can tell you how much is done sequentially and how much > is done in parallel.There's a surprisingly large ecosystem of users for the processor -- I think because it was a popular, dirt-cheap hobby system, and now there's all these experienced digital-heads playing with their old toys. There's even an "Olduino" project that marries a 1802 board with Arduino shields. The 1802 is how I got into doing deep-embedded systems (you can run an RC servo! With a counter! In Software!!!). So I understand the enthusiasm because I share it. Here's the Whole Damned User's Manual: http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf All instructions take 16 or 24 clock cycles, on a fixed program of two or three phases (_everything_ happens on 8-cycle boundaries). A typical instruction would load the byte pointed to by register N into D, then increment the register pointed to by N. I think you may be right about using the ALU for incrementing registers -- they don't show it that way in their logical diagram, but I just now realized that they never increment or decrement a register AND do an arithmetic operation in the same instruction. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by ●May 10, 20172017-05-10
On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote:> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote: > >> On 5/10/2017 5:42 PM, Tim Wescott wrote: >>> I've been geeking out on the COSMAC 1802 lately -- it was the first >>> processor that I owned all just for me, and that I wrote programs for >>> (in machine code -- not assembly). >>> >>> One of the features of this chip is that while the usual ALU is 8-bit >>> and centered around memory fetches and the accumulator (which they call >>> the 'D' register), there's a 16 x 16-bit register file. Any one of >>> these registers can be incremented or decremented, either as an >>> explicit instruction or as part of a fetch (basically, you can use any >>> one of them as an index, and you can "fetch and increment"). >>> >>> How would you do this most effectively today? How might it have been >>> done back in the mid 1970's when RCA made the chip? Would it make a >>> difference if you were working with a CPLD, FPGA, or some ASIC where >>> you were determined to minimize chip area? >>> >>> I'm assuming that the original had one selectable increment/decrement >>> unit that wrote back numbers to the registers, but I could see them >>> implementing each register as a loadable counter -- I just don't have a >>> good idea of what might use the least real estate. >> >> A counter is a register with an adder (although only needing half adders >> at each bit), so of course the incrementer will take up more logic than >> a register. >> >> Depending on what functions can be done while the register is >> incrementing, they may use the ALU for all arithmetic operations. Most >> of the earlier processors conserved logic by time sequencing operations >> within an instruction. That's why some instructions take so many cycles >> to complete, it's shuffling data around internally. >> >> If you provide some instructions with their descriptions and the cycle >> counts I bet I can tell you how much is done sequentially and how much >> is done in parallel. > > There's a surprisingly large ecosystem of users for the processor -- I > think because it was a popular, dirt-cheap hobby system, and now there's > all these experienced digital-heads playing with their old toys. There's > even an "Olduino" project that marries a 1802 board with Arduino > shields. > > The 1802 is how I got into doing deep-embedded systems (you can run an RC > servo! With a counter! In Software!!!). So I understand the enthusiasm > because I share it. > > Here's the Whole Damned User's Manual: > > http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf > > All instructions take 16 or 24 clock cycles, on a fixed program of two or > three phases (_everything_ happens on 8-cycle boundaries). A typical > instruction would load the byte pointed to by register N into D, then > increment the register pointed to by N. > > I think you may be right about using the ALU for incrementing registers > -- they don't show it that way in their logical diagram, but I just now > realized that they never increment or decrement a register AND do an > arithmetic operation in the same instruction. >No surprise on the multiple of 8 cycles. The 1802 was a one-bit serial processor. It's ALU was therefore really small. A bit more logic for all the sequencing, but overall it had a very small footprint in gates. -- Gabor
Reply by ●May 11, 20172017-05-11
On Wed, 10 May 2017 22:28:34 -0400, Gabor wrote:> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote: >> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote: >> >>> On 5/10/2017 5:42 PM, Tim Wescott wrote: >>>> I've been geeking out on the COSMAC 1802 lately -- it was the first >>>> processor that I owned all just for me, and that I wrote programs for >>>> (in machine code -- not assembly). >>>> >>>> One of the features of this chip is that while the usual ALU is 8-bit >>>> and centered around memory fetches and the accumulator (which they >>>> call the 'D' register), there's a 16 x 16-bit register file. Any one >>>> of these registers can be incremented or decremented, either as an >>>> explicit instruction or as part of a fetch (basically, you can use >>>> any one of them as an index, and you can "fetch and increment"). >>>> >>>> How would you do this most effectively today? How might it have been >>>> done back in the mid 1970's when RCA made the chip? Would it make a >>>> difference if you were working with a CPLD, FPGA, or some ASIC where >>>> you were determined to minimize chip area? >>>> >>>> I'm assuming that the original had one selectable increment/decrement >>>> unit that wrote back numbers to the registers, but I could see them >>>> implementing each register as a loadable counter -- I just don't have >>>> a good idea of what might use the least real estate. >>> >>> A counter is a register with an adder (although only needing half >>> adders at each bit), so of course the incrementer will take up more >>> logic than a register. >>> >>> Depending on what functions can be done while the register is >>> incrementing, they may use the ALU for all arithmetic operations. >>> Most of the earlier processors conserved logic by time sequencing >>> operations within an instruction. That's why some instructions take >>> so many cycles to complete, it's shuffling data around internally. >>> >>> If you provide some instructions with their descriptions and the cycle >>> counts I bet I can tell you how much is done sequentially and how much >>> is done in parallel. >> >> There's a surprisingly large ecosystem of users for the processor -- I >> think because it was a popular, dirt-cheap hobby system, and now >> there's all these experienced digital-heads playing with their old >> toys. There's even an "Olduino" project that marries a 1802 board with >> Arduino shields. >> >> The 1802 is how I got into doing deep-embedded systems (you can run an >> RC servo! With a counter! In Software!!!). So I understand the >> enthusiasm because I share it. >> >> Here's the Whole Damned User's Manual: >> >> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf>> >> All instructions take 16 or 24 clock cycles, on a fixed program of two >> or three phases (_everything_ happens on 8-cycle boundaries). A >> typical instruction would load the byte pointed to by register N into >> D, then increment the register pointed to by N. >> >> I think you may be right about using the ALU for incrementing registers >> -- they don't show it that way in their logical diagram, but I just now >> realized that they never increment or decrement a register AND do an >> arithmetic operation in the same instruction. >> >> > No surprise on the multiple of 8 cycles. The 1802 was a one-bit serial > processor. It's ALU was therefore really small. A bit more logic for > all the sequencing, but overall it had a very small footprint in gates.How did they manage the 16-bit register increment and decrement, then? -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by ●May 11, 20172017-05-11
On 5/10/2017 9:28 PM, Gabor wrote:> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote: >> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote: >> >>> On 5/10/2017 5:42 PM, Tim Wescott wrote: >>>> I've been geeking out on the COSMAC 1802 lately -- it was the first >>>> processor that I owned all just for me, and that I wrote programs for >>>> (in machine code -- not assembly). >>>> >>>> One of the features of this chip is that while the usual ALU is 8-bit >>>> and centered around memory fetches and the accumulator (which they call >>>> the 'D' register), there's a 16 x 16-bit register file. Any one of >>>> these registers can be incremented or decremented, either as an >>>> explicit instruction or as part of a fetch (basically, you can use any >>>> one of them as an index, and you can "fetch and increment"). >>>> >>>> How would you do this most effectively today? How might it have been >>>> done back in the mid 1970's when RCA made the chip? Would it make a >>>> difference if you were working with a CPLD, FPGA, or some ASIC where >>>> you were determined to minimize chip area? >>>> >>>> I'm assuming that the original had one selectable increment/decrement >>>> unit that wrote back numbers to the registers, but I could see them >>>> implementing each register as a loadable counter -- I just don't have a >>>> good idea of what might use the least real estate. >>> >>> A counter is a register with an adder (although only needing half adders >>> at each bit), so of course the incrementer will take up more logic than >>> a register. >>> >>> Depending on what functions can be done while the register is >>> incrementing, they may use the ALU for all arithmetic operations. Most >>> of the earlier processors conserved logic by time sequencing operations >>> within an instruction. That's why some instructions take so many cycles >>> to complete, it's shuffling data around internally. >>> >>> If you provide some instructions with their descriptions and the cycle >>> counts I bet I can tell you how much is done sequentially and how much >>> is done in parallel. >> >> There's a surprisingly large ecosystem of users for the processor -- I >> think because it was a popular, dirt-cheap hobby system, and now there's >> all these experienced digital-heads playing with their old toys. There's >> even an "Olduino" project that marries a 1802 board with Arduino >> shields. >> >> The 1802 is how I got into doing deep-embedded systems (you can run an RC >> servo! With a counter! In Software!!!). So I understand the enthusiasm >> because I share it. >> >> Here's the Whole Damned User's Manual: >> >> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf >> >> All instructions take 16 or 24 clock cycles, on a fixed program of two or >> three phases (_everything_ happens on 8-cycle boundaries). A typical >> instruction would load the byte pointed to by register N into D, then >> increment the register pointed to by N. >> >> I think you may be right about using the ALU for incrementing registers >> -- they don't show it that way in their logical diagram, but I just now >> realized that they never increment or decrement a register AND do an >> arithmetic operation in the same instruction. >> > > No surprise on the multiple of 8 cycles. The 1802 was a > one-bit serial processor. It's ALU was therefore really > small. A bit more logic for all the sequencing, but > overall it had a very small footprint in gates. >I believe you are incorrect, several RCA manuals shows the ALU as being 8 bits wide. In the early 70s the CMOS logic was slow, as manufacturing improved many of the chips could get to 8Mhz but they were sold a 2MHz parts. Do you have a link that shows the ALU is serial instead of 8 bit parallel? -- Cecil - k5nwa
Reply by ●May 11, 20172017-05-11
On 5/11/2017 12:59 AM, Cecil Bayona wrote:> On 5/10/2017 9:28 PM, Gabor wrote: >> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote: >>> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote: >>> >>>> On 5/10/2017 5:42 PM, Tim Wescott wrote: >>>>> I've been geeking out on the COSMAC 1802 lately -- it was the first >>>>> processor that I owned all just for me, and that I wrote programs for >>>>> (in machine code -- not assembly). >>>>> >>>>> One of the features of this chip is that while the usual ALU is 8-bit >>>>> and centered around memory fetches and the accumulator (which they >>>>> call >>>>> the 'D' register), there's a 16 x 16-bit register file. Any one of >>>>> these registers can be incremented or decremented, either as an >>>>> explicit instruction or as part of a fetch (basically, you can use any >>>>> one of them as an index, and you can "fetch and increment"). >>>>> >>>>> How would you do this most effectively today? How might it have been >>>>> done back in the mid 1970's when RCA made the chip? Would it make a >>>>> difference if you were working with a CPLD, FPGA, or some ASIC where >>>>> you were determined to minimize chip area? >>>>> >>>>> I'm assuming that the original had one selectable increment/decrement >>>>> unit that wrote back numbers to the registers, but I could see them >>>>> implementing each register as a loadable counter -- I just don't >>>>> have a >>>>> good idea of what might use the least real estate. >>>> >>>> A counter is a register with an adder (although only needing half >>>> adders >>>> at each bit), so of course the incrementer will take up more logic than >>>> a register. >>>> >>>> Depending on what functions can be done while the register is >>>> incrementing, they may use the ALU for all arithmetic operations. Most >>>> of the earlier processors conserved logic by time sequencing operations >>>> within an instruction. That's why some instructions take so many >>>> cycles >>>> to complete, it's shuffling data around internally. >>>> >>>> If you provide some instructions with their descriptions and the cycle >>>> counts I bet I can tell you how much is done sequentially and how much >>>> is done in parallel. >>> >>> There's a surprisingly large ecosystem of users for the processor -- I >>> think because it was a popular, dirt-cheap hobby system, and now there's >>> all these experienced digital-heads playing with their old toys. >>> There's >>> even an "Olduino" project that marries a 1802 board with Arduino >>> shields. >>> >>> The 1802 is how I got into doing deep-embedded systems (you can run >>> an RC >>> servo! With a counter! In Software!!!). So I understand the >>> enthusiasm >>> because I share it. >>> >>> Here's the Whole Damned User's Manual: >>> >>> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf >>> >>> All instructions take 16 or 24 clock cycles, on a fixed program of >>> two or >>> three phases (_everything_ happens on 8-cycle boundaries). A typical >>> instruction would load the byte pointed to by register N into D, then >>> increment the register pointed to by N. >>> >>> I think you may be right about using the ALU for incrementing registers >>> -- they don't show it that way in their logical diagram, but I just now >>> realized that they never increment or decrement a register AND do an >>> arithmetic operation in the same instruction. >>> >> >> No surprise on the multiple of 8 cycles. The 1802 was a >> one-bit serial processor. It's ALU was therefore really >> small. A bit more logic for all the sequencing, but >> overall it had a very small footprint in gates. >> > I believe you are incorrect, several RCA manuals shows the ALU as being > 8 bits wide. In the early 70s the CMOS logic was slow, as manufacturing > improved many of the chips could get to 8Mhz but they were sold a 2MHz > parts. > > Do you have a link that shows the ALU is serial instead of 8 bit parallel?I have looked at serializing adders and multipliers. The control logic is large enough that it greatly mitigates the logic saving of a bit arithmetic unit versus an 8 bit unit. Even for a multiplier a full bit serial unit is not much smaller than a word wide add/shift design. Any time you have bit wide logic the registers need multiplexers which are not much different from adders. -- Rick C
Reply by ●May 11, 20172017-05-11
On 11/05/17 00:20, Tim Wescott wrote:> The 1802 is how I got into doing deep-embedded systems (you can run an RC > servo! With a counter! In Software!!!). So I understand the enthusiasm > because I share it.You might like the XMOS processors for *hard* real-time systems. Wide range available on Digikey. Multicore, "FPGA like" I/O (I/O occurre on specified clock cycles), xC is its CSP/Occam/Transputer event-based programming model. Loop and function times guaranteed by the development environment based on its examining the binary file. I've just started playing with them, and have already managed to use a single-core as a "software frequency counter" that counts the transitions in a 50Mb/s serial data stream. Replicate that in another core and you have the basis of a frequency ratio meter.
Reply by ●May 11, 20172017-05-11
Den torsdag den 11. maj 2017 kl. 07.17.08 UTC+2 skrev rickman:> On 5/11/2017 12:59 AM, Cecil Bayona wrote: > > On 5/10/2017 9:28 PM, Gabor wrote: > >> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote: > >>> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote: > >>> > >>>> On 5/10/2017 5:42 PM, Tim Wescott wrote: > >>>>> I've been geeking out on the COSMAC 1802 lately -- it was the first > >>>>> processor that I owned all just for me, and that I wrote programs for > >>>>> (in machine code -- not assembly). > >>>>> > >>>>> One of the features of this chip is that while the usual ALU is 8-bit > >>>>> and centered around memory fetches and the accumulator (which they > >>>>> call > >>>>> the 'D' register), there's a 16 x 16-bit register file. Any one of > >>>>> these registers can be incremented or decremented, either as an > >>>>> explicit instruction or as part of a fetch (basically, you can use any > >>>>> one of them as an index, and you can "fetch and increment"). > >>>>> > >>>>> How would you do this most effectively today? How might it have been > >>>>> done back in the mid 1970's when RCA made the chip? Would it make a > >>>>> difference if you were working with a CPLD, FPGA, or some ASIC where > >>>>> you were determined to minimize chip area? > >>>>> > >>>>> I'm assuming that the original had one selectable increment/decrement > >>>>> unit that wrote back numbers to the registers, but I could see them > >>>>> implementing each register as a loadable counter -- I just don't > >>>>> have a > >>>>> good idea of what might use the least real estate. > >>>> > >>>> A counter is a register with an adder (although only needing half > >>>> adders > >>>> at each bit), so of course the incrementer will take up more logic than > >>>> a register. > >>>> > >>>> Depending on what functions can be done while the register is > >>>> incrementing, they may use the ALU for all arithmetic operations. Most > >>>> of the earlier processors conserved logic by time sequencing operations > >>>> within an instruction. That's why some instructions take so many > >>>> cycles > >>>> to complete, it's shuffling data around internally. > >>>> > >>>> If you provide some instructions with their descriptions and the cycle > >>>> counts I bet I can tell you how much is done sequentially and how much > >>>> is done in parallel. > >>> > >>> There's a surprisingly large ecosystem of users for the processor -- I > >>> think because it was a popular, dirt-cheap hobby system, and now there's > >>> all these experienced digital-heads playing with their old toys. > >>> There's > >>> even an "Olduino" project that marries a 1802 board with Arduino > >>> shields. > >>> > >>> The 1802 is how I got into doing deep-embedded systems (you can run > >>> an RC > >>> servo! With a counter! In Software!!!). So I understand the > >>> enthusiasm > >>> because I share it. > >>> > >>> Here's the Whole Damned User's Manual: > >>> > >>> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf > >>> > >>> All instructions take 16 or 24 clock cycles, on a fixed program of > >>> two or > >>> three phases (_everything_ happens on 8-cycle boundaries). A typical > >>> instruction would load the byte pointed to by register N into D, then > >>> increment the register pointed to by N. > >>> > >>> I think you may be right about using the ALU for incrementing registers > >>> -- they don't show it that way in their logical diagram, but I just now > >>> realized that they never increment or decrement a register AND do an > >>> arithmetic operation in the same instruction. > >>> > >> > >> No surprise on the multiple of 8 cycles. The 1802 was a > >> one-bit serial processor. It's ALU was therefore really > >> small. A bit more logic for all the sequencing, but > >> overall it had a very small footprint in gates. > >> > > I believe you are incorrect, several RCA manuals shows the ALU as being > > 8 bits wide. In the early 70s the CMOS logic was slow, as manufacturing > > improved many of the chips could get to 8Mhz but they were sold a 2MHz > > parts. > > > > Do you have a link that shows the ALU is serial instead of 8 bit parallel? > > I have looked at serializing adders and multipliers. The control logic > is large enough that it greatly mitigates the logic saving of a bit > arithmetic unit versus an 8 bit unit. Even for a multiplier a full bit > serial unit is not much smaller than a word wide add/shift design. Any > time you have bit wide logic the registers need multiplexers which are > not much different from adders.when you have cycles to spare you can just shift
Reply by ●May 11, 20172017-05-11
On 5/11/2017 11:44 AM, lasselangwadtchristensen@gmail.com wrote:> Den torsdag den 11. maj 2017 kl. 07.17.08 UTC+2 skrev rickman: >> On 5/11/2017 12:59 AM, Cecil Bayona wrote: >>> On 5/10/2017 9:28 PM, Gabor wrote: >>>> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote: >>>>> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote: >>>>> >>>>>> On 5/10/2017 5:42 PM, Tim Wescott wrote: >>>>>>> I've been geeking out on the COSMAC 1802 lately -- it was the first >>>>>>> processor that I owned all just for me, and that I wrote programs for >>>>>>> (in machine code -- not assembly). >>>>>>> >>>>>>> One of the features of this chip is that while the usual ALU is 8-bit >>>>>>> and centered around memory fetches and the accumulator (which they >>>>>>> call >>>>>>> the 'D' register), there's a 16 x 16-bit register file. Any one of >>>>>>> these registers can be incremented or decremented, either as an >>>>>>> explicit instruction or as part of a fetch (basically, you can use any >>>>>>> one of them as an index, and you can "fetch and increment"). >>>>>>> >>>>>>> How would you do this most effectively today? How might it have been >>>>>>> done back in the mid 1970's when RCA made the chip? Would it make a >>>>>>> difference if you were working with a CPLD, FPGA, or some ASIC where >>>>>>> you were determined to minimize chip area? >>>>>>> >>>>>>> I'm assuming that the original had one selectable increment/decrement >>>>>>> unit that wrote back numbers to the registers, but I could see them >>>>>>> implementing each register as a loadable counter -- I just don't >>>>>>> have a >>>>>>> good idea of what might use the least real estate. >>>>>> >>>>>> A counter is a register with an adder (although only needing half >>>>>> adders >>>>>> at each bit), so of course the incrementer will take up more logic than >>>>>> a register. >>>>>> >>>>>> Depending on what functions can be done while the register is >>>>>> incrementing, they may use the ALU for all arithmetic operations. Most >>>>>> of the earlier processors conserved logic by time sequencing operations >>>>>> within an instruction. That's why some instructions take so many >>>>>> cycles >>>>>> to complete, it's shuffling data around internally. >>>>>> >>>>>> If you provide some instructions with their descriptions and the cycle >>>>>> counts I bet I can tell you how much is done sequentially and how much >>>>>> is done in parallel. >>>>> >>>>> There's a surprisingly large ecosystem of users for the processor -- I >>>>> think because it was a popular, dirt-cheap hobby system, and now there's >>>>> all these experienced digital-heads playing with their old toys. >>>>> There's >>>>> even an "Olduino" project that marries a 1802 board with Arduino >>>>> shields. >>>>> >>>>> The 1802 is how I got into doing deep-embedded systems (you can run >>>>> an RC >>>>> servo! With a counter! In Software!!!). So I understand the >>>>> enthusiasm >>>>> because I share it. >>>>> >>>>> Here's the Whole Damned User's Manual: >>>>> >>>>> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf >>>>> >>>>> All instructions take 16 or 24 clock cycles, on a fixed program of >>>>> two or >>>>> three phases (_everything_ happens on 8-cycle boundaries). A typical >>>>> instruction would load the byte pointed to by register N into D, then >>>>> increment the register pointed to by N. >>>>> >>>>> I think you may be right about using the ALU for incrementing registers >>>>> -- they don't show it that way in their logical diagram, but I just now >>>>> realized that they never increment or decrement a register AND do an >>>>> arithmetic operation in the same instruction. >>>>> >>>> >>>> No surprise on the multiple of 8 cycles. The 1802 was a >>>> one-bit serial processor. It's ALU was therefore really >>>> small. A bit more logic for all the sequencing, but >>>> overall it had a very small footprint in gates. >>>> >>> I believe you are incorrect, several RCA manuals shows the ALU as being >>> 8 bits wide. In the early 70s the CMOS logic was slow, as manufacturing >>> improved many of the chips could get to 8Mhz but they were sold a 2MHz >>> parts. >>> >>> Do you have a link that shows the ALU is serial instead of 8 bit parallel? >> >> I have looked at serializing adders and multipliers. The control logic >> is large enough that it greatly mitigates the logic saving of a bit >> arithmetic unit versus an 8 bit unit. Even for a multiplier a full bit >> serial unit is not much smaller than a word wide add/shift design. Any >> time you have bit wide logic the registers need multiplexers which are >> not much different from adders. > > when you have cycles to spare you can just shiftWhat does that have to do with anything? -- Rick C
