8

The predecessor 6502 did not use microcode, but a PLA. But what about the 6510 and 8502?

Coder
  • 1,068
  • 3
  • 20
  • 4
    I think you might need to define what you mean by microcode. I think I could build a case to suggest that the 6502 did use microcode of a sort. – JeremyP Jul 18 '23 at 08:05
  • 1
    As far as my understanding is correct, microcode comes from a storage like ROM or Flash and has to be loaded in order for the CPU to be usable. On the other hand, if the decoding unit is hard-wired as a PLA, then the CPU works right away. – Coder Jul 18 '23 at 08:19
  • 3
    I don't understand how we can say the 6502 did not use microcode, but I have heard that before. From what I understand, the 6510 and 8502 use the same die as a 6502, just a little extra support circuitry in the same package. That would mean they are the same in every respect, even down to illegal instructions. – Omar and Lorraine Jul 18 '23 at 08:19
  • 7
    If you follow the Wikipedia definition of microcode ("hardware-level instructions that implement higher-level machine code instructions or control internal finite-state machine sequencing"), then the 6502 very much uses microcode. That the microcode is generated by a PLA and not a ROM doesn't matter. So you really need to define what you mean by "microcode" in the context of your question. And no, microcode doesn't has "to be loaded" - there are lots of CPUs which uses microcode right from the ROM. – dirkt Jul 18 '23 at 09:33
  • 1
    And no, the decoding unit in the 6502 isn't "hardwired as a PLA", either. – dirkt Jul 18 '23 at 09:35
  • 5
    Whether or not microcode needs to be 'loaded' is an implementation decision that does not affect whether it can be called 'microcode'. The sole determinant is whether the microcode operation is set by 'programming' a more general-purpose device,or set by explicit wiring. – dave Jul 18 '23 at 11:44
  • 1
    @Coder I'm sorry, but I think that your understanding is flawed. There are at least three cases: "horizontal" microcode which is quite simply a property of the chip, "horizontal" microcode which is loaded into the processor's control store at startup (as it was on some mainframes, which is where floppies came from) and "vertical" microcode which is often in a reserved area of main or ancillary memory. "Horizontal" microcode is typically 30-100 bits wide, and directly controls the CPU at the gate level; if it's in a PLA etc. then it's /just/ /there/ like any other logic. – Mark Morgan Lloyd Jul 18 '23 at 17:19
  • @all Thank you for your clarification. In that case i mean case no. 1: ""horizontal" microcode which is quite simply a property of the chip" and is made of an PLA or any other logic, but not in the form of data that is stored in some kind of memory. – Coder Jul 18 '23 at 22:08
  • 1
    @Coder The micro program ROM of a CPU isn't 'data stored kind of memory' but a fixed function hardware. It can not be loaded with something else. Changing its content means changing transistors and connections within the chip. – Raffzahn Jul 19 '23 at 01:08
  • @Coder Internal to a CPU, there's really no distinction between (horizontal) microcode in a PLA and in a ROM: in both cases a partially-decoded opcode is applied as an "address" and some tens of bits are generated as "data": these bits directly control the logic (ALU function etc.). There might be a difference in design and implementation technology, but that's at an even lower level. Note also that in all cases we're talking about fast bipolar ROMs in this context, not slow PROMS (EPROMs etc.) which would have to be copied to some faster control store to get acceptable performance. – Mark Morgan Lloyd Jul 19 '23 at 08:09
  • @Raffzahn, If ROM isn't a kind of memory, then why do they call it "ROM?" Last time I heard, the "M" in "ROM" stood for "Memory." Any time I ever encountered something called "ROM," it behaved in every respect like SRAM save for one: You couldn't write it. – Solomon Slow Jul 19 '23 at 16:03
  • @Raffzahn, Re, "changing its content means changing transistors and..." But nobody here is asking how to change the contents of a mask-programmed ROM chip. We are talking about whether or not a certain microprocessor was microprogrammed. – Solomon Slow Jul 19 '23 at 16:10
  • @MarkMorganLloyd, I always understood "horizontal" vs. "vertical" to be distinguished by how much of the hardware was directly controlled by the bits in a microinstruction. In a "horizontal" processor, like you said, lots of gates are directly tied to bits in the current control word. In a more "vertical" processor, more gates are controlled by bits in registers whose contents can be written by the microprogram. "Horizontal" is so called because the words are wide. "Vertical" is so-called because you tend to need more steps of the microprogram to execute a single ISA-level instruction. – Solomon Slow Jul 19 '23 at 16:24
  • @SolomonSlow I wouldn't like to say when that distinction came in, but the impression I've always had was that- originally at least- H-ucode had a single wide ucode per higher-level opcode while V-ucode had multiple and they might be narrower i.e. it was literally how a rectangle containing the bits looked. An extreme case of V-ucode might be the special OS-specific handlers which I believe were loaded into memory for an Alpha. Obviously, the distinction got blurred with time: you could perhaps say that ultimately ucode ended up square with the cool guys using RISC implemented by random logic. – Mark Morgan Lloyd Jul 19 '23 at 16:36
  • @SolomonSlow The point made by the OP (pls. check previous comments) is that the microcode has to be some 'data stored in a memory' and that this 'loadability' is what makes it a microcode and everything else not. – Raffzahn Jul 19 '23 at 18:40

2 Answers2

8

TL;DR:

The 6510/8502 are the very same CPU (*1) as the 6502. No difference in implementation.

Details:

The predecessor 6502 did not use microcode, but a PLA. But what about the 6510 and 8502?

The 6510/8502 are the very same CPU (*1) than the 6502. The changed pinout and additional peripherals doesn't change that in any way.

As far as my understanding is correct, microcode comes from a storage like ROM or Flash and has to be loaded in order for the CPU to be usable.

Same here, as a PLA is a ROM (*2). Every PLA can be replaced by a classic ROM and vice versa (*3). The main, but not principal difference is that a PLA's decoding is the primary mean of configuration, while regular ROMs configure the output. Doing the programming on decoding side allows to 'compress' redundant content by encoding duplicate entries only once and encoding multiple output bits by multiple entries (when needed).

That topic was already covered in part in this question.

On the other hand, if the decoding unit is hard-wired as a PLA,

A micro program ROM 'hard wired' the very same way as a PLA.

then the CPU works right away.

Which is as well true for a micro coded CPU - as long as the microcode is present at startup, which is true for all micro processors (*4).

Here might lay some confusion due modern CPU which allow to load additional/modified micro code at startup. Those CPUs do quite well start up and work right away (*5) as their micro code is already contained in ROM. That is best shown by the fact that loading additional micro code is done by a regular program in the main instruction set.

The ability to load additional microcode adds flexibility but doesn't change the instant on ability.

The ability to load additional microcode is intended to patch bugs an add new features after the CPU was delivered.

Is the 6502 Microcoded?

Yes, as it follows the very primal requirement of micro code of being executed by stepping thru a stored program (*6). It doesn't matter how that program is stored, as long as it's stored. The fact that the ROM content is a single bit and that multiple entries can fire in the same step is purely representational and doesn't change this.

The space saving beauty of the 6502 is that it combines the high density of ROM structures with low requirement of routing - back then routing space was way more expensive than transistors (*7).

In the end it's another embodiment of why the 6502 was such a great advancement in CPU design over more school book inspred CPUs.

*1 - I guess in today's ligo MOS would talk about them using the same core.

*2 - In some way one may see a PLA as an inverted ROM and working as assoziative memory (contend addressable memory).

*3 - Just note the various times ROMs are used, especially in the Commodore world, to replace no longer available PLA.

*4 - Well, almost, as there were a few designs, usually bit slice, which did load micro code first using some external CPU.

*5 - Unlike some /360 models, which not only pioneered loadable micro code but that code had also be loaded first from a service unit before the CPU could start.

*6 - In the 6502 the clock logic generates up to 8 steps (T0..T6) per instruction which in turn are used to sequence the PLA entries during execution. Although, the sequence isn't as simple as some states are inserted depending on instruction process. Another ingenuity saving entries and circuitry, but also making interpretation harder. One has to really follow it thru :))

*7 - Not saying they were plenty :))

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • I'd say the 6502 is "kinda sorta" microcoded, since the PLA is more ROM-like than typical random-placement logic, but isn't really an addressable memory. I would view the system as more micro-code like if the sequencer supported internal branching, and if e.g. STA $FE and STA ($FE),Y were both handled by branching to the same state immediately after the step that computed the address, so the step that performs the store would be handled in a manner agnostic to which state instruction execution was on. – supercat Jul 18 '23 at 15:37
  • 2
    I think this discussion https://news.ycombinator.com/item?id=23554713 is useful, noting the supporting photo link. Also https://comp.sys.cbm.narkive.com/yXTim3UH/6502-microcode-pla-equations particularly the contribution of "Allan" half way down. The bottom line is that the PLA- visible at the top of the cited photo- is "horizontal microcode" by normal industry standards. "horizontal microcode" also, of course, includes the sort of stuff you'd put in a microcode ROM for a bitslice CPU, as IIRC discussed in "Soul of a New Machine". – Mark Morgan Lloyd Jul 18 '23 at 17:28
  • @all Thank you. – Coder Jul 18 '23 at 22:25
  • 1
    If I understand Wikipedia's (both the German and the English one!) definition of the word microcode correctly, it is not sufficient that the logic table of a gate is stored in a ROM (similar to an FPGA where the logic tables are stored in SRAM). If I understand correctly, the word "microcode" implies that one assembly instruction triggers (or can at least trigger) a sequence (this means: two or more) of microcode-level instructions which are executed sequentially. – Martin Rosenau Jul 19 '23 at 17:02
  • @MartinRosenau No, definitely not. I've worked with machines where (at least some types of) opcodes explicitly triggered a single uOp i.e. by having the opcode's MSB set with the remaining bits being the uOp address in (bipolar) ROM and there not being an incrementing uAR etc. I think what you've got is the "vertical" vs "horizontal" distinction again. – Mark Morgan Lloyd Jul 19 '23 at 17:54
  • @MartinRosenau Jain. It's one or more, as simple instruction may of course be simple enough to fit in a single micro code instructions - think something like setting a flag. (Not to mention that real machines can be a mixup as well) – Raffzahn Jul 19 '23 at 18:38
  • 1
    @MarkMorganLloyd: I don't think the fact that some of the 6502's logic is laid out in PLA format really makes it microcode. If one looks at e.g. Atari's STELLA chip, the address decoding is all done with a PLA-style layout, but one would hardly call that microcode. – supercat Jul 20 '23 at 16:21
  • @supercat because it's purpose is address decoding, not instruction decoding - simple, isn't it? – Raffzahn Jul 20 '23 at 16:33
  • @Raffzahn: Machines that are described as microcoded would typically have more than seven states. Even the Apple II floppy drive controller has 16 states each for three of its four operating modes. – supercat Jul 20 '23 at 18:24
  • @supercat Comparing states between systems is not useful. Street lights may have more than 16 - still doesn't make them CPUs. I guess you agree that the 8686 is microcoded. Still most (~60%) of its ISA instructions (~75) consist of <=4 micro code instructions and only two (CMPS/MOVS) need more than 8. Considering hat teh 6500 is a way_ more basic CPU than the 8086, 8 seems quite luxurious :) – Raffzahn Jul 20 '23 at 19:14
  • 1
    @Raffzahn: The 8086 microcode engine can branch among 512 states. If the 6502 had e.g. processed all of the addressing modes abs,x, abs,y, (ind),y by branching to a common state after the MSB of the address was fetched, so as to use common logic for an "add an index register chosen by a particular opcode bit to the effective address" cycle, then I would view it as a microcoded architecture, but from what I can tell the operations for cycle 4 of abs,y versus cycle 5 of (ind),y are handled independently, Very different from the way the 8086 branches through states during EA calculations. – supercat Jul 20 '23 at 19:38
  • @supercat Looks like you discovered that a microprogram can be structured in different ways with differen CPU designs, isn't it? – Raffzahn Jul 20 '23 at 22:37
  • 1
    @Raffzahn: If the 6502 was "microcoded", do you think any meaningful amount of "microcode" was written after the surrounding circuitry design was complete, or was each column of the PLA added with the particular intention of it testing for a particular combination of high, low, and don't care bits? – supercat Jul 21 '23 at 15:34
6

No, the 65xx and 85xx chips did not use microcode.

Microcode is the term used to describe an internal CPU programming paradigm in which the low-level microprocessor 'machine-code' instructions are themselves comprised of even lower-level 'private' instruction primitives. These primitives are almost RISC-like, generalised (to an extent) and permit the manufacturer to construct the 'public' instructions which represent, for one example, the x86 instruction set. When asked to execute an x86 instruction, the chip actually executes the set of primitives that comprise that instruction.

This has great advantages over static PLA-based microprocessors, since the internal instruction execution pipeline circuitry design can more generalised - instead of hard-wired instruction-specific decode/execute circuitry, the chip can be built with non-specific circuitry intended to execute primitives which can be put together in myriad permutations. This makes debugging much easier, and of course (given mutable microcode storage) allows changes to be made to the microprocessor instruction set long after the microprocessor is made available for commercial use.

The MOS 65xx and 85xx family of 8-bit microprocessors used hardware circuitry to decode and execute their instructions. Some very clever design facilitated a degree of circuitry re-use between instructions, and even a rudimentary pipelining effect where the next instruction could be in the fetch register before the previous one had completely finished execution. However, there was no microcode involved - this was all hardware, driven by the physical bit-pattern of the 8-bit instruction opcode. An internal T-state counter progresses the instruction fetch/decode/execute pipeline, but is not a program and does not constitute microcode.

The so-called 'illegal' or 'undocumented' opcodes are a direct manifestation of the hardware-dictated operation of the 65xx/85xx instruction set, since they are instances of bit-patterns which engender unsupported circuitry behavior. Unsupported in this context means 'the manufacturer did not explicitly design this instruction and therefore the bit-pattern is not guaranteed to produce meaningful or useful results'. However it is interesting to note (well, for us 65xx/85xx greybeards) that a number are genuinely useful, though some are pretty obscure in real-world use and a few are actually electronically unstable and do not produce deterministic results from one execution to the next.

Eight-Bit Guru
  • 1,083
  • 7
  • 16
  • 2
    Erm, "execute primitives which can be put together in myriad permutations." Isn't that the very definition of microcode? Also "The so-called 'illegal' or 'undocumented' opcodes are a direct manifestation [thereof]" Same is true for the 8086 (see for example 6x vs. 7x), which everyone will agree is a prime example for microcoded. – Raffzahn Jul 18 '23 at 09:21
  • 2
    @Raffzahn Re. your first point, erm yes that's exactly what the paragraph is saying - that microcoded architectures benefit from generalised circuitry which enables primitives to be assembled in lots of different ways to create higher-level instructions. Re. your second point, I did not say that microcoded architectures did/do not experience anomalous hardware crosstalk or misfiring decodes, only that the 65xx/85xx architecture illegal opcodes are explicitly a result of that. – Eight-Bit Guru Jul 18 '23 at 10:44
  • Well, that is exactly what the 6502 does as well. It only takes additional lines in the PLA to create new instructions - like two additional PLA lines is all creating an ADD X+#IMM would need. Second, if it doesn't show a distinction, then it's not a valid argument (also, it's not anomalous at all, as it's defined to be exactly that way - otherwise they wouldn't be useful like noted). – Raffzahn Jul 18 '23 at 11:18
  • (Thinking of it, it may be only a single PLA line - and could cover several addressing modes with the right opcode alignment) – Raffzahn Jul 18 '23 at 11:30
  • 3
    Microprogrammed Processor Having PLA Control Store, IBM, 1979. – dave Jul 18 '23 at 11:50
  • 1
    To me, this answer seems not to distinguish clearly between the microcode and the microcode execution engine. – dave Jul 18 '23 at 11:51
  • 2
    The 6502 has lower level generalised hardware e.g. an ALU, some registers, some buses. The PLA takes an input which is the instruction and certain parts of the CPU state and produces outputs which would control the various components. It was definitely programmable (the P doesn't stand for "pizza"). Therefore we have microcode of sorts. As is often the case, the boundary is quite fuzzy. – JeremyP Jul 18 '23 at 14:13
  • 2
    People may draw boundaries between "array logic" versus "microcode" in different ways, but I think I'd draw it based upon whether a control logic supports branching between sequenced steps. From what I understand, the only form of "branching" within the 6502's sequencing logic is "go back to start". – supercat Jul 18 '23 at 16:17
  • 1
    Thank you, that sentence you said: "The MOS 65xx and 85xx family of 8-bit microprocessors used hardware circuitry to decode and execute their instructions." is what i meant with no microcode. Many say, that the 6510 is nearly the same as the 6502 it has only some extensions, so that also answers my question. – Coder Jul 18 '23 at 22:13
  • @Coder Does it really answer? Or I guess it depends on what you consider as microcoe. Because if the high level opcodes are translated by any black box to the control signals that decode and execute the opcode, does it matter if it comes from a hard wired logic gates or PLA or ROM, as the translation is exactly identical. As any translation from opcodes to some internal primitives is a definition of microcode. The microcode is just hardwired, a hardwired ROM is also a hardwired logic and even ROMs are made with hardwired logic. – Justme Jul 19 '23 at 08:50
  • Considering all the new additions mentioned above, the hint that the 6510 also uses a PLA and not an inbuilt ROM like the 8086 is good enough for me. – Coder Jul 19 '23 at 09:14