[HN Gopher] Tracing the roots of the 8086 instruction set to the...
___________________________________________________________________
Tracing the roots of the 8086 instruction set to the Datapoint 2200
minicomputer
Author : matt_d
Score : 56 points
Date : 2023-08-12 17:41 UTC (5 hours ago)
(HTM) web link (www.righto.com)
(TXT) w3m dump (www.righto.com)
| rep_lodsb wrote:
| Great article, especially the opcode charts! Almost all you find
| online are unfortunately in hex, which obscures the encoding.
|
| The strangest feature inherited from the 8008 is probably the
| parity flag. There are some uses other than 7-bit ASCII comms for
| it, but this kind of code is probably heavily 'pessimized' on
| modern CPUs: TEST AL,0xc0 JZ
| quadrant0 ;both bits clear JPE quadrant3 ;both
| bits set JS quadrant2 ;only bit 7 set JMP
| quadrant1 ;only bit 6 set
|
| And to this day, even the reserved lower flag bits have the same
| values as they did on the 8080 ('S Z _0_ A _0_ P _1_ C '). I
| wonder if there is actually code out there that depends on bit 1
| being set.
|
| One nitpick:
|
| >The ModR/M byte has been changed in 64-bit mode so the BX
| (originally HL) register is no longer special when accessing
| memory
|
| It was 32-bit mode that made EAX, ECX and EDX usable for
| addressing, though not the 16-bit lower half registers. And
| nothing with that changed in the transition to 64 bits.
| kens wrote:
| Thanks, I've fixed that.
| kens wrote:
| Author here if you have questions about the Datapoint 2200 :-)
| adrian_b wrote:
| 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.
| canucker2016 wrote:
| 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_3300
| kens wrote:
| 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/datapoi
| nt/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.
| pwg wrote:
| 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 wrote:
| 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_660.
| ..
| adrian_b wrote:
| > 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 wrote:
| In PDP-11 terms, the Datapoint 2200 only had these
| "address modes" ( https://en.wikipedia.org/wiki/PDP-11_ar
| chitecture#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 wrote:
| 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.
| AlbertCory wrote:
| 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.
| Hizonner wrote:
| Lessons learned:
|
| 1. Incremental, backward compatible progress wins in the market.
|
| 2. Incremental, backward compatible progress leads to nasty,
| ugly, hard to use hacks that create waste, inefficiency, and user
| pain.
|
| Explains a lot, really.
| kens wrote:
| As Intel engineer Tom Forsyth said, "The REAL cost of x86
| legacy is not gates, it's lots and lots of meetings."
| rob74 wrote:
| _Remarkably, Intel has managed to move from 8-bit computers to
| 16, 32, and 64 bits, while keeping systems mostly compatible._
|
| Well, the move to 64 bit didn't quite turn out as Intel wanted
| it, and they had to copy AMD's version of it. This is
| acknowledged in footnote 20, but the article itself sounds like
| Intel was infallible and never mentions AMD at all...
___________________________________________________________________
(page generated 2023-08-12 23:00 UTC)