desendant of the 6502

[intvnut]

The notion of "register" in that environment is really just opcode compression.

 

The RISC vs. CISC distinction largely centers around the question of whether to have instructions of a fixed length that is somewhat longer than optimal, in the interest of facilitating pipelining, or whether to have variable-length instructions for purposes of reducing code size (and in some cases memory bandwidth). The 6502's fairly simple state machine does avoid the idle bus cycles that are common on many CISC architectures, but the fact that very few instructions are one machine word long precludes its being called a RISC.

The Advanced RISC Machines' (aka. ARM) Thumb mode raises an eyebrow at you. :-)

 

While fixed-length, highly regular encoded opcodes are a hallmark of many RISC machines, that doesn't preclude compression in the context of a RISC machine, if decompression can be pipelined efficiently.

 

The architectural aspects that most often get cited as "RISC-like" in my experience are:

• Operations other than "move" are register to register.
  
• Registers are strongly distinct from memory, due to relative latency of access. That is, registers are cheap and "in the CPU." Memory is more expensive. (Combine this with the first bullet, and you arrive at the term "load/store architecture" for RISC, as distinguished from a "memory/register architecture" (808x), or a "memory/memory architecture.")
  
• Operations are kept simple, with a focus on pipelining. If you can't do something with single-cycle throughput, break it up into multiple instructions. Single-cycle throughput is different than single-cycle latency. Latency is ok--you can mange it with interlocks or exposed delay slots.
  
• Instruction decoding is also kept simple, to enable pipelining. Simple does not mean there can be no compression, or that all opcodes are the same width/format. It just means that the process is high throughput and easily pipelined.
  

The focus on operations that could be pipelined limits the complexity of the instructions one could consider. For example, you can't pipeline "string compare," (e.g. 8086's REP CMPSB) because you don't know string lengths a priori. You can pipeline multiply, though, because its latency is bounded by the argument size, despite being complex. Also, disassociating memory reads and writes from computation instructions limits the "addressing" modes associated with computation to a couple modes: "register to register," and occasionally "immediate constant to register." All of your memory addressing modes are associated with your load and store instructions. Your computation instructions just focus on reading/writing registers and the occasional immediate constant.

 

So, my main beef with 8051 and 6502 as "RISC" CPUs is that they don't embody "load/store" architecture, and they don't pipeline a darn thing. They're thoroughly memory-to-register machines. (And in the case of the 8051, rather often memory-to-memory. The 6502-with-T-bit crosses into the memory-to-memory territory also.) If the 6502 were to integrate its zero-page on-chip as a register file, you start to get close to what RISC was about, but it's still rather iffy. The indexed-indirect addressing mode--(zero-page, X)--is the real killer there. :-)

 

(And I apologize. I called that mode (ZP, Y) when it's (ZP, X). Oops. It's been a few years since I've written 6502 code regularly. Where the ",X" and ",Y" go sometimes get flipped in my mental stack.)

 

If you were to integrate the zero-page on chip, eliminate the ability to address it in memory through normal reads and writes, eliminate the indexed-indirect addressing mode, then I can start to feel the RISC vibe. Pipeline the machine, and then I think you'd capture what Hennessy and Patterson were going for when they built MIPS and SPARC. But, go in the direction malducci described with the 'T' bit and indirecting through 'X', and I think you end up in quirky microcontroller territory, not RISC machine territory.

Edited November 18, 2008 by intvnut

[+poobah]

Yup. The 65x has 128 16bit wide Address Registers - or 256 8bit data registers. Located in ram or not, they're processor registers. It's not the only processor with registers based in external memory VS internal die.

 

If you want to see a CPU with a really weird setup, look at the RCA 1802 (RCA Studio II, Voyager space probes). I also find Harvard Architecture hard to mentally visualize.

 

Harvard's not so bad. The Microchip PICs and Atmel Mega's are Harvard, and they are fairly straightforward. I tend to see the UController memory as a big register file. (to a point)

[supercat]

Harvard's not so bad. The Microchip PICs and Atmel Mega's are Harvard, and they are fairly straightforward. I tend to see the UController memory as a big register file. (to a point)

 

Harvard architecture is quite logical for devices that will be executing programs from a read-only code store. Particularly on machines with a fixed instruction size, it makes sense to think of each code address as holding an instruction, rather than a number. From a programming standpoint, it doesn't generally doesn't matter whether instructions are twelve bits, or fourteen, or sixteen, unless one is reading code memory as data (which some controllers allow and some don't). Incidentally, I'm disappointed by Microchip's design for the code memory readout on the PIC18F series. To read a byte (half a word) of code memory, one has to load the address, then do a table-read instruction, then read one byte from a register. I wonder why they didn't provide a means of reading two bytes at once?

[+poobah]

Harvard's not so bad. The Microchip PICs and Atmel Mega's are Harvard, and they are fairly straightforward. I tend to see the UController memory as a big register file. (to a point)

 

Harvard architecture is quite logical for devices that will be executing programs from a read-only code store. Particularly on machines with a fixed instruction size, it makes sense to think of each code address as holding an instruction, rather than a number. From a programming standpoint, it doesn't generally doesn't matter whether instructions are twelve bits, or fourteen, or sixteen, unless one is reading code memory as data (which some controllers allow and some don't). Incidentally, I'm disappointed by Microchip's design for the code memory readout on the PIC18F series. To read a byte (half a word) of code memory, one has to load the address, then do a table-read instruction, then read one byte from a register. I wonder why they didn't provide a means of reading two bytes at once?

 

Haven't used the 18s much, Used 16F627A and its brethren a lot, then I switched religions, and started using the Atmel Mega8 and friends.

 

They all seem to frown on reading from code memory, but that is sorta the point of Harvard.

[malducci]

If you were to integrate the zero-page on chip, eliminate the ability to address it in memory through normal reads and writes, eliminate the indexed-indirect addressing mode, then I can start to feel the RISC vibe. Pipeline the machine, and then I think you'd capture what Hennessy and Patterson were going for when they built MIPS and SPARC. But, go in the direction malducci described with the 'T' bit and indirecting through 'X', and I think you end up in quirky microcontroller territory, not RISC machine territory.

 

The AVR is considered RISC and it shares a lot in common with the 65x. Memory mapped registers just like ZP. Even the I/O registers are memory mapped in what would the ZP location, just like how 2600 mapped external ports to half the ZP address range. That's a huge advantage that a lot of other manufactures failed to take advantage of IMO.

Edited November 22, 2008 by malducci

[dendawg]

Is there a modern equivalent to the 6502 CPU?

 

Kinda like how the x86 is based on the 8088 CPU for the IBM PC?

 

IIRC, I think the SNES CPU, the Ricoh 5A22, would be the newest descendant, as it is based around a 65c816 core.

[malducci]

Is there a modern equivalent to the 6502 CPU?

 

Kinda like how the x86 is based on the 8088 CPU for the IBM PC?

 

IIRC, I think the SNES CPU, the Ricoh 5A22, would be the newest descendant, as it is based around a 65c816 core.

 

The current WDC versions of the 65816 have all the missing instructions that the original 65816 and SNES version are missing, that the R65C02 introduced (SMB/TRB,etc). That'd be the newest version if I'm not mistaken.

Edited November 29, 2008 by malducci