5 ms·

Author here if you have questions about the Datapoint 2200 :-)

by kens 3y ago

pwg 3y ago
Ken, you have this statement in a footnote: > I haven't been able to find any instruction set before the Datapoint 2200 that required memory addresses to be loaded into a register. For a direction to look, look at the CDC mainframes (the Cybers, the 6600 and 7600 models, and possibly earlier models). A too great many years ago now while in college for my EE degree the college had a pair of CDC's (I think a 6600 and 7600, I only ever had access to the older one for a mandatory "assembly programming" class) and one of the 'quirks' of the CDC CPU design was that the CPU had (if memory serves) eight data registers and eight address registers, and to perform a memory read, one loaded an address into one of the first six address registers, which would cause a memory read from that address, storing the result in the corresponding data register (so A0 caused a read into D0, etc.). For a memory write, one loaded an address into either A6 or A7, which caused the CPU to perform a memory write using data from the corresponding data register (A7 caused D7 to be written to memory). The "production dates" for these CDC systems is relatively contemporary (for a reasonable fudge factor around "contemporary") with the Datapoint terminal, so these might be an example of another architecture from a similar time range (or quite possibly before) that loaded an address into a register in order to access memory.
- kens 3y ago
  Thanks, that's very interesting and I've updated the footnote. I looked at the CDC 6600 manual and it works pretty much like you say. If you change an address register A1-A5, the system automatically reads from memory into the corresponding operand register X1-X5. Similarly, if you change address register A6 or A7, the word in X6 or X7 is stored to memory. It is interesting to look at old systems that do things wildly differently from modern computers. http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/60045000_6600_Computer_System_RefMan_Aug63.pdf http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/60045000_660...
  - adrian_b 3y ago
    > I haven't come across an instruction set other than Datapoint that treated register and memory accesses identically. (If you know of exceptions, please let me know.) The DEC PDP-11 was launched in 1970, slightly earlier than Datapoint 2200. While DEC PDP-11 also had additional addressing modes, its two most simple addressing modes, register direct and register indirect correspond exactly with the addressing modes of Datapoint 2200. The only difference is how they were encoded. Because PDP-11 had longer instructions, they could afford separate bits for encoding the addressing mode. So 3 bits encoded the 8 registers and a separate bit encoded whether the register is used as data (register direct) or as the address of data from memory (register indirect). Datapoint 2200 needed shorter instructions, so they have dispensed with the bit needed for encoding the addressing mode, by using only 7 registers, so that the unused register number could be used to encode the register indirect addressing mode, where the register holding the address had to be implicit, as no other bits were available to specify it. So what is special about the addressing modes of Datapoint 2200 is this encoding trick, which saves 1 bit of the instruction encoding with the price of allowing only one of the general-purpose registers to be used for memory addressing, while the addressing modes themselves are not new. This encoding trick, where it is avoided to have additional bits for encoding addressing modes, by reserving some register numbers to encode those addressing modes, has been reused repeatedly by Intel when defining the 8086 and 80386 ISAs and by AMD when defining the 64-bit extension. For instance, there are no instruction bits to encode addressing modes where the address is computed by adding a base register and an index register. Instead of that, the SP register cannot be used in the basic encoding for memory operands, so using the SP register number denotes that the address is computed by adding a base register and an index register, where those registers are specified by an extra SIB byte. There are a few other cases where some registers cannot be used with certain addressing modes, but when they appear in the instruction those register numbers mean that the operand must be accessed with some different addressing mode, like memory relative to the instruction pointer or memory absolute.
    - rep_lodsb 3y ago
      In PDP-11 terms, the Datapoint 2200 only had these "address modes" ( https://en.wikipedia.org/wiki/PDP-11_architecture#General_register_addressing_modes https://en.wikipedia.org/wiki/PDP-11_architecture#General_re... ): - register - register deferred via HL - autoincrement via PC (immediate operands) No registers other than HL and PC could be output to the address bus at all. The 8080 was much more flexible, but the instructions it added weren't orthogonal, so I would say it's not at all comparable to the PDP-11 addressing modes.
- Animats 3y ago
  The CDC 6600 did that for a completely different reason. It's an early superscalar machine. It overlaps memory operations, and even some compute. This is visible to the programmer. The desired programming style is load, load, load, operate, operate, operate, store, store, store. Then the operations can overlap. There's something called the "scoreboard" to stall the pipeline if there's a conflict, but there's no automatic re-ordering. The tiny machines at the Datapoint 2200 and 80xx level didn't do anything like that. At the other extreme, there were low-end machines where the registers really were in main memory. The compute/memory speed ratio has changed over time. Today, arithmetic is much faster than memory, but in the late 1960s/early 1970s, arithmetic was often slower than memory on low-end machines.
  - drallison 3y ago
    The 6600 was not a superscalar machine but simply a pipelined processor. Superscalar machines first appeared in the floating point processor of the IBM 360/91 and may well be due to John Cocke (IBM) who generalized the notion. Yale Patt (UC Berkeley, U Michigan, U Texas at Austin) refined the ideas. Most processors designed today have superscalar features.
    - Animats 3y ago
      The 6600 had multiple functional units - 2 floating point multipliers, a divider, two adders, etc.,[1] and if the instruction stream allowed it, many of them could be running at the same time. So it was a superscalar machine. [1] https://en.wikipedia.org/wiki/CDC_6600#Central_Processor_(CP) https://en.wikipedia.org/wiki/CDC_6600#Central_Processor_(CP...
      - kens 3y ago
        To be superscalar, a processor must initiate multiple instructions per clock cycle. Having multiple functional units isn't sufficient to be superscalar if one instruction is dispatched at a time. You get higher performance from the multiple functional units since the next instruction isn't blocked while the previous one is executing. According to "Modern Processor Design: Fundamentals of Superscalar Processors", the CDC 6600 was not superscalar because it had scalar instruction issue. This book says the IBM Advanced Computer system was the first superscalar design, but the project was canceled.
adrian_b 3y ago
No questions, just thanks for another interesting article. What I have found especially interesting is the story about the undocumented instructions of 8085, because I was not aware of them. Those instructions would have been actually quite useful and if they had been documented they would have made the Intel 8085 significantly more competitive with Zilog Z80, taking into account also the fact that in the early years 8085 usually had a higher clock frequency (3 MHz or 5 MHz for 8085 versus 2.5 MHz or 4 MHz for Z80). When I was young I have worked to make some improvements in speed to the functions that implemented the floating-point arithmetic operations in the run-time library used by the Microsoft CP/M Fortran compiler, because they were too slow for my needs (obviously after disassembling them, as Microsoft did not document them). On an Intel 8080 CPU, more than 100 FP64 multiply-add operations per second was considered as high speed, while now a CPU that does 100 billion FP64 multiply-add operations per second is considered a very slow CPU (the best desktop CPUs are more than 6 times faster). I am sure that with the extra 16-bit operations provided by 8085, a decent speed-up of those FP arithmetic functions would have been possible and I would have found that useful at that time, because I was able to use IBM PC clones only some years later.
- drallison 3y ago
  The undocumented instructions in the 8085 were described in detail in Dr Dobb's Journal shortly after announcement of the 8085 (with no mention of the "new" instructions).
canucker2016 3y ago
Was the datapoint 2200 a brand new machine or was it influenced by others esp. wrt. the assembly language instruction set? Looking up Datapoint on Wikipedia shows a predecessor box, the 3300. But did the new designers of the 2200 totally ignore the 3300 instruction set? The 3300 seems to have used shift-registers as well. Other data terminals at that time or radio equipment these designers might have used before? Thx https://en.m.wikipedia.org/wiki/Datapoint https://en.m.wikipedia.org/wiki/Datapoint https://en.m.wikipedia.org/wiki/Datapoint_3300 https://en.m.wikipedia.org/wiki/Datapoint_3300
- kens 3y ago
  The Datapoint 3300 was strictly a terminal. It was not programmable and did not have an instruction set. It basically had counters for the cursor position and put characters into memory at that position, and had a ROM to generate characters. Manual: http://bitsavers.org/pdf/datapoint/3300/70116_3300termMaint_Dec76.pdf http://bitsavers.org/pdf/datapoint/3300/70116_3300termMaint_... I don't think the Datapoint 2200 had any specific influences, at least none that I could find. Keep in mind that at the time, it was fairly common to make a processor out of TTL chips. People would make a custom processor for random things like a CNC controller or a video game. These processors were usually ad hoc, with an instruction set that had the features that were needed. If people were going to copy something, it was often a PDP-8 or 11 or a Data General NOVA.
AlbertCory 3y ago
hi Ken! I wrote about DataPoint in The Big Bucks. It turns out I knew Gordon Peterson, architect of ARCNet, so he was a very good source for me. Naturally, there's a book about them. I read these things so you don't have to.
- kragen 3y ago
  why did they collapse it seems like it was only two years from being the darling of wall street to bankruptcy what happened
  - AlbertCory 3y ago
    since I just claimed I read them so you don't have to: they had a major scandal of salespeople misreporting revenue. and then the usual head-in-the-sand attitude of companies who get imprisoned by their success. Being in San Antonio probably didn't help, either.
    - kragen 3y ago
      hmm, interesting, the first part sounds like garden-variety corruption what do you mean about the attitude tho
      - AlbertCory 3y ago
        Ken addressed that: a generational change underway, which is always difficult for a company that's been successful.
    - kens 3y ago
      The accounting scandal was the proximate cause, but I think the underlying issue was Moore's Law. I've examined the performance of Datapoint's TTL-based computers vs microprocessors. In 1972, the 2200 V2 was over 6 times as fast as the 8008. The Datapoint 5500 (1973) was significantly faster than the 8080 (1974). The Z80 (1976) was slightly faster than the Datapoint 6600 (1977). The 8086 (1978) was about twice as fast and Datapoint never managed to catch up. Datapoint tried to pivot to Intel processors, but then they were competing against commodity PCs. Datapoint suffered a hostile takeover in 1984 but didn't go bankrupt until years later in 2000. The point is that Datapoint's TTL-based approach was great in the early 1970s but couldn't keep up with the exponential improvements in microprocessors.

Author here if you have questions about the Datapoint 2200 :-)

by kens 3y ago

Author here if you have questions about the Datapoint 2200 :-)

pwg 3y ago

Ken, you have this statement in a footnote: > I haven't been able to find any instruction set before the Datapoint 2200 that required memory addresses to be loaded into a register. For a direction to look, look at the CDC mainframes (the Cybers, the 6600 and 7600 models, and possibly earlier models). A too great many years ago now while in college for my EE degree the college had a pair of CDC's (I think a 6600 and 7600, I only ever had access to the older one for a mandatory "assembly programming" class) and one of the 'quirks' of the CDC CPU design was that the CPU had (if memory serves) eight data registers and eight address registers, and to perform a memory read, one loaded an address into one of the first six address registers, which would cause a memory read from that address, storing the result in the corresponding data register (so A0 caused a read into D0, etc.). For a memory write, one loaded an address into either A6 or A7, which caused the CPU to perform a memory write using data from the corresponding data register (A7 caused D7 to be written to memory). The "production dates" for these CDC systems is relatively contemporary (for a reasonable fudge factor around "contemporary") with the Datapoint terminal, so these might be an example of another architecture from a similar time range (or quite possibly before) that loaded an address into a register in order to access memory.

kens 3y ago
Thanks, that's very interesting and I've updated the footnote. I looked at the CDC 6600 manual and it works pretty much like you say. If you change an address register A1-A5, the system automatically reads from memory into the corresponding operand register X1-X5. Similarly, if you change address register A6 or A7, the word in X6 or X7 is stored to memory. It is interesting to look at old systems that do things wildly differently from modern computers. http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/60045000_6600_Computer_System_RefMan_Aug63.pdf http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/60045000_660...
- adrian_b 3y ago
  > I haven't come across an instruction set other than Datapoint that treated register and memory accesses identically. (If you know of exceptions, please let me know.) The DEC PDP-11 was launched in 1970, slightly earlier than Datapoint 2200. While DEC PDP-11 also had additional addressing modes, its two most simple addressing modes, register direct and register indirect correspond exactly with the addressing modes of Datapoint 2200. The only difference is how they were encoded. Because PDP-11 had longer instructions, they could afford separate bits for encoding the addressing mode. So 3 bits encoded the 8 registers and a separate bit encoded whether the register is used as data (register direct) or as the address of data from memory (register indirect). Datapoint 2200 needed shorter instructions, so they have dispensed with the bit needed for encoding the addressing mode, by using only 7 registers, so that the unused register number could be used to encode the register indirect addressing mode, where the register holding the address had to be implicit, as no other bits were available to specify it. So what is special about the addressing modes of Datapoint 2200 is this encoding trick, which saves 1 bit of the instruction encoding with the price of allowing only one of the general-purpose registers to be used for memory addressing, while the addressing modes themselves are not new. This encoding trick, where it is avoided to have additional bits for encoding addressing modes, by reserving some register numbers to encode those addressing modes, has been reused repeatedly by Intel when defining the 8086 and 80386 ISAs and by AMD when defining the 64-bit extension. For instance, there are no instruction bits to encode addressing modes where the address is computed by adding a base register and an index register. Instead of that, the SP register cannot be used in the basic encoding for memory operands, so using the SP register number denotes that the address is computed by adding a base register and an index register, where those registers are specified by an extra SIB byte. There are a few other cases where some registers cannot be used with certain addressing modes, but when they appear in the instruction those register numbers mean that the operand must be accessed with some different addressing mode, like memory relative to the instruction pointer or memory absolute.
  - rep_lodsb 3y ago
    In PDP-11 terms, the Datapoint 2200 only had these "address modes" ( https://en.wikipedia.org/wiki/PDP-11_architecture#General_register_addressing_modes https://en.wikipedia.org/wiki/PDP-11_architecture#General_re... ): - register - register deferred via HL - autoincrement via PC (immediate operands) No registers other than HL and PC could be output to the address bus at all. The 8080 was much more flexible, but the instructions it added weren't orthogonal, so I would say it's not at all comparable to the PDP-11 addressing modes.
Animats 3y ago
The CDC 6600 did that for a completely different reason. It's an early superscalar machine. It overlaps memory operations, and even some compute. This is visible to the programmer. The desired programming style is load, load, load, operate, operate, operate, store, store, store. Then the operations can overlap. There's something called the "scoreboard" to stall the pipeline if there's a conflict, but there's no automatic re-ordering. The tiny machines at the Datapoint 2200 and 80xx level didn't do anything like that. At the other extreme, there were low-end machines where the registers really were in main memory. The compute/memory speed ratio has changed over time. Today, arithmetic is much faster than memory, but in the late 1960s/early 1970s, arithmetic was often slower than memory on low-end machines.
- drallison 3y ago
  The 6600 was not a superscalar machine but simply a pipelined processor. Superscalar machines first appeared in the floating point processor of the IBM 360/91 and may well be due to John Cocke (IBM) who generalized the notion. Yale Patt (UC Berkeley, U Michigan, U Texas at Austin) refined the ideas. Most processors designed today have superscalar features.
  - Animats 3y ago
    The 6600 had multiple functional units - 2 floating point multipliers, a divider, two adders, etc.,[1] and if the instruction stream allowed it, many of them could be running at the same time. So it was a superscalar machine. [1] https://en.wikipedia.org/wiki/CDC_6600#Central_Processor_(CP) https://en.wikipedia.org/wiki/CDC_6600#Central_Processor_(CP...
    - kens 3y ago
      To be superscalar, a processor must initiate multiple instructions per clock cycle. Having multiple functional units isn't sufficient to be superscalar if one instruction is dispatched at a time. You get higher performance from the multiple functional units since the next instruction isn't blocked while the previous one is executing. According to "Modern Processor Design: Fundamentals of Superscalar Processors", the CDC 6600 was not superscalar because it had scalar instruction issue. This book says the IBM Advanced Computer system was the first superscalar design, but the project was canceled.

adrian_b 3y ago

No questions, just thanks for another interesting article. What I have found especially interesting is the story about the undocumented instructions of 8085, because I was not aware of them. Those instructions would have been actually quite useful and if they had been documented they would have made the Intel 8085 significantly more competitive with Zilog Z80, taking into account also the fact that in the early years 8085 usually had a higher clock frequency (3 MHz or 5 MHz for 8085 versus 2.5 MHz or 4 MHz for Z80). When I was young I have worked to make some improvements in speed to the functions that implemented the floating-point arithmetic operations in the run-time library used by the Microsoft CP/M Fortran compiler, because they were too slow for my needs (obviously after disassembling them, as Microsoft did not document them). On an Intel 8080 CPU, more than 100 FP64 multiply-add operations per second was considered as high speed, while now a CPU that does 100 billion FP64 multiply-add operations per second is considered a very slow CPU (the best desktop CPUs are more than 6 times faster). I am sure that with the extra 16-bit operations provided by 8085, a decent speed-up of those FP arithmetic functions would have been possible and I would have found that useful at that time, because I was able to use IBM PC clones only some years later.

drallison 3y ago
The undocumented instructions in the 8085 were described in detail in Dr Dobb's Journal shortly after announcement of the 8085 (with no mention of the "new" instructions).

canucker2016 3y ago

Was the datapoint 2200 a brand new machine or was it influenced by others esp. wrt. the assembly language instruction set? Looking up Datapoint on Wikipedia shows a predecessor box, the 3300. But did the new designers of the 2200 totally ignore the 3300 instruction set? The 3300 seems to have used shift-registers as well. Other data terminals at that time or radio equipment these designers might have used before? Thx https://en.m.wikipedia.org/wiki/Datapoint https://en.m.wikipedia.org/wiki/Datapoint https://en.m.wikipedia.org/wiki/Datapoint_3300 https://en.m.wikipedia.org/wiki/Datapoint_3300

kens 3y ago
The Datapoint 3300 was strictly a terminal. It was not programmable and did not have an instruction set. It basically had counters for the cursor position and put characters into memory at that position, and had a ROM to generate characters. Manual: http://bitsavers.org/pdf/datapoint/3300/70116_3300termMaint_Dec76.pdf http://bitsavers.org/pdf/datapoint/3300/70116_3300termMaint_... I don't think the Datapoint 2200 had any specific influences, at least none that I could find. Keep in mind that at the time, it was fairly common to make a processor out of TTL chips. People would make a custom processor for random things like a CNC controller or a video game. These processors were usually ad hoc, with an instruction set that had the features that were needed. If people were going to copy something, it was often a PDP-8 or 11 or a Data General NOVA.

AlbertCory 3y ago

hi Ken! I wrote about DataPoint in The Big Bucks. It turns out I knew Gordon Peterson, architect of ARCNet, so he was a very good source for me. Naturally, there's a book about them. I read these things so you don't have to.

kragen 3y ago
why did they collapse it seems like it was only two years from being the darling of wall street to bankruptcy what happened
- AlbertCory 3y ago
  since I just claimed I read them so you don't have to: they had a major scandal of salespeople misreporting revenue. and then the usual head-in-the-sand attitude of companies who get imprisoned by their success. Being in San Antonio probably didn't help, either.
  - kragen 3y ago
    hmm, interesting, the first part sounds like garden-variety corruption what do you mean about the attitude tho
    - AlbertCory 3y ago
      Ken addressed that: a generational change underway, which is always difficult for a company that's been successful.
  - kens 3y ago
    The accounting scandal was the proximate cause, but I think the underlying issue was Moore's Law. I've examined the performance of Datapoint's TTL-based computers vs microprocessors. In 1972, the 2200 V2 was over 6 times as fast as the 8008. The Datapoint 5500 (1973) was significantly faster than the 8080 (1974). The Z80 (1976) was slightly faster than the Datapoint 6600 (1977). The 8086 (1978) was about twice as fast and Datapoint never managed to catch up. Datapoint tried to pivot to Intel processors, but then they were competing against commodity PCs. Datapoint suffered a hostile takeover in 1984 but didn't go bankrupt until years later in 2000. The point is that Datapoint's TTL-based approach was great in the early 1970s but couldn't keep up with the exponential improvements in microprocessors.