desendant of the 6502

[klokwrkblu]

Is there a modern equivalent to the 6502 CPU?

 

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

[carlsson]

Well, you have the 16-bit 65816 from WDC but it isn't really modern. Other than that I don't think you can find any direct links. The 8088 already was a 16-bit CPU stripped down to a 8-bit bus. Commodore themselves who owned MOS moved on, first planned to use Z8000 then bought the Amiga Lorraine project using 68000.

[supercat]

Is there a modern equivalent to the 6502 CPU?

 

I don't think so. There are some microcontrollers in modern production which are derived from the Motorola 6800, which is a predecessor to the 6502, and the 68HC05 series is a little reminiscent of a stripped-down 6502 (no Y register, no ability to manipulate the stack pointer except by loading $FF, no indirect addressing modes, etc.) but with a few added goodies (instructions to set/clear a zero-page bit, or to test a zero-page bit and jump if set/clear). Curiously, the 6800 uses big-endian addressing which slows things down a little compared to the 6502 (e.g. ABS,x addressing mode always takes an extra cycle IIRC).

 

In many ways, IMHO, the best-designed instruction set is that of the 14-bit PIC series (16xx). The 16-bit series (18xx) has some new instructions and features, but many of them don't seem to be well thought-out, IMHO.

 

As for CPU's with an 8-bit instruction set, I think the 8032 is surprisingly good. There are some definite quirks in its instruction set, but overall the instruction set tends to be quite practical for projects that don't need to access a lot of data tables. For applications that need a lot of data tables, the 6502 rules.

[mos6507]

The ARM chips are the descendants of the 6502.

 

"The design team worked in secret to create a chip which met their requirements. As described earlier, these were for a processor which retained the ethos of the 6502 but in a 32-bit RISC environment, and implemented this in a small device which it would be possible to design and test easily, and to fabricate cheaply."

 

ARM

 

The ARM has to be the most successful processor family outside of X86.

Edited October 13, 2008 by mos6507

[JamesD]

I know people love to refer to the 6502 as RISC but there is more to RISC philosophy than a reduced instruction set. It also includes the use of several general purpose registers... something the 6502 doesn't do but the ARM does.

 

The ARM is not a direct descendant of the 6502 but I suppose you could call it as much of a descendant of the 6502 as the Ford GT is of the Model T.

[+poobah]

I know people love to refer to the 6502 as RISC but there is more to RISC philosophy than a reduced instruction set. It also includes the use of several general purpose registers... something the 6502 doesn't do but the ARM does.

 

The ARM is not a direct descendant of the 6502 but I suppose you could call it as much of a descendant of the 6502 as the Ford GT is of the Model T.

 

Actually, all of zero page are technically 6502 registers. They were not on chip because it was cheaper to use external RAM.

[mos6507]

I know people love to refer to the 6502 as RISC but there is more to RISC philosophy than a reduced instruction set. It also includes the use of several general purpose registers... something the 6502 doesn't do but the ARM does.

 

The ARM is not a direct descendant of the 6502 but I suppose you could call it as much of a descendant of the 6502 as the Ford GT is of the Model T.

 

People were surprised at how few registers the 6502 had when it came out. They didn't know you could actually write fully fledged programs with only the accumulator, X, and Y. (The coding style that evolved to work with the limited 6502 instruction set could be seen as a validation for what could be done with RISC.) That being said, today's RISC processors still have a lot more registers than the old CISC processors so there is no way you'd ever be able to directly compare the two. It has to be compared at a more abstract level.

Edited November 15, 2008 by mos6507

[intvnut]

I know people love to refer to the 6502 as RISC but there is more to RISC philosophy than a reduced instruction set. It also includes the use of several general purpose registers... something the 6502 doesn't do but the ARM does.

 

The ARM is not a direct descendant of the 6502 but I suppose you could call it as much of a descendant of the 6502 as the Ford GT is of the Model T.

 

Actually, all of zero page are technically 6502 registers. They were not on chip because it was cheaper to use external RAM.

 

Hmmm.... I'm not sure I buy that. Most CPUs don't have the equivalent of "($xx, Y)" addressing mode, where you select which CPU register to indirect through based on the value of another register. Especially not RISC CPUs. ARM certainly doesn't seem to have that mode.

[+batari]

I know people love to refer to the 6502 as RISC but there is more to RISC philosophy than a reduced instruction set. It also includes the use of several general purpose registers... something the 6502 doesn't do but the ARM does.

 

The ARM is not a direct descendant of the 6502 but I suppose you could call it as much of a descendant of the 6502 as the Ford GT is of the Model T.

 

Actually, all of zero page are technically 6502 registers. They were not on chip because it was cheaper to use external RAM.

No, technically they are not registers. However, given their faster access and addressing modes, they are kind of like registers.

[+poobah]

Well, we can toss around the exact definition of registers, and there are points to be made for either case.

 

But as far as the CISC vs RISC thing, I've read interviews with the 6502's designers, and their intent clearly has a RISC flavor. They specifically state they used the zero page bit because outboard ram was fairly cheap, and saved them vast amounts of die space, which would have cost them tremendously in terms of yield and actual cost per cpu.

If it wasn't cheaper to do otherwise, page zero (or more correctly, the functionality of page zero) would have been on die.

 

Using a 6502 without treating zero page as a large register bank is possible, but painful.

 

Still an amazingly cool CPU (and the first one I cut my teeth on).

[malducci]

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.

Edited November 16, 2008 by malducci

[intvnut]

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.

 

It seems a bit weird to have more registers than you can fit on the stack. (Zero Page, A, X, Y, P and PC take up 262 bytes, but the stack is only 256 bytes large...)

 

While small pools of zero page locations make up for the lack of a large internal register file, and the 6502's addressing modes use the ZP much like other processors use registers (the (ZP, Y) mode notwithstanding), the fact of the matter is that the zero page as a whole didn't get used exactly like a register file. Nobody pushes the zero page on the stack in response to an interrupt, for instance.

 

I do agree that the faster cycle time of zero page addressing gives it some "register-like" qualities, but don't confuse it with CPUs like the TMS9900 family, where R0 - R15 were in RAM, but they really were treated much more like registers than the 6502's zero page, including how calling conventions treat them and so on.

[mos6507]

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.

[intvnut]

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 Architecture isn't all that complex. It just means that you have separate program and data buses. If you look inside any reasonably modern CPU, they have a Harvard architecture at least as far as their L1 caches go. The level 1 program and level 1 data caches are separate, with the program fetch pipeline separate from the data access pipeline. Now, once you get beyond the level 1 controllers, things typically unify onto a shared bus. This is the so-called Modified Harvard Architecture.

 

The RCA 1802 is definitely a weird beast. I have a coworker that programmed them once upon a time. He mentioned building up call/return on top of the "any register could be the program counter" methodology. IIRC, it went something like this: Use one register as your "primary PC", and then two others point to your "call" and "return" subroutines. To make a call, you'd switch your PC register to the "call" function. That function would read the address to jump to and save off the primary PC register on a stack. It'd then set the primary PC register to point to the called function. And then the tricky bit: The call function would branch to one instruction ahead of its entry point that switches the PC register back to the primary PC. The result is that the "call PC" register is left pointing at the entry point, and execution resumes at the called function. The return path worked similarly, except it popped the new PC from the stack.

 

Pretty clever if you ask me, although I'd rather just have normal call/return instructions.

Edited November 17, 2008 by intvnut

[malducci]

(Zero Page, A, X, Y, P and PC take up 262 bytes, but the stack is only 256 bytes large...)

 

I don't see any relevance in that. It's a 'fast interrupt' system (if I may borrow the term from the 6809) - you push what you want for your routine. I could just image the overhead if all the regs were pushed on the stack (if it was large enough) like the 68k - lol. You know, iirc, there is a variant of the 65x with a 16bit stack (not the 65816). Hell - there are a lot a variants of that chip

 

Nobody pushes the zero page on the stack in response to an interrupt, for instance.

 

Well - nobody pushed X or Y directly on the stack until the CMOS version came along. Yeah ok, that was rather lame It's not the same thing. Anyway, such a large set of registers, there's no need to push them onto the stack. If they were located on the die, I still wouldn't push them onto the stack. Just curious, but do you know about the T flag and the ZP registers for some 65x variants?

[intvnut]

(Zero Page, A, X, Y, P and PC take up 262 bytes, but the stack is only 256 bytes large...)

 

I don't see any relevance in that. It's a 'fast interrupt' system (if I may borrow the term from the 6809) - you push what you want for your routine. I could just image the overhead if all the regs were pushed on the stack (if it was large enough) like the 68k - lol. You know, iirc, there is a variant of the 65x with a 16bit stack (not the 65816). Hell - there are a lot a variants of that chip

Fair enough. My point is that they aren't really managed like register resources in most machines. Could you imagine dedicating a handful of registers in any other CPU to a BASIC interpreter, even if it wasn't running all the time? Dedicating 4 CPU registers to the current text window boundaries? (That's what Apple ][ does!) The fact that the ZP was large and in RAM allowed it to be simultaneously more flexible than traditional registers by being used in completely different ways, and yet still have most of the advantages associated with proper registers. It was managed (or squandered, IMHO) more like RAM than a register file.

 

The ZP is part vector table, part OS configuration, part scratch pad.

 

Nobody pushes the zero page on the stack in response to an interrupt, for instance.

Well - nobody pushed X or Y directly on the stack until the CMOS version came along. Yeah ok, that was rather lame It's not the same thing. Anyway, such a large set of registers, there's no need to push them onto the stack. If they were located on the die, I still wouldn't push them onto the stack.

I'm thinking in terms of context switching, like in a multitasking operating system. If you want to swap between two tasks, you generally have to save off the context of one task and load the context of another. The zero page is part of that context, and so presumably if you're treating it like a register resource, you'd have to swap part of that along with it.

 

One of the CPUs I work with nowadays (the TMS320C64x family) has 64 32-bit registers. That's the size of the entire 6502 zero page. And yes, we swap them all on a context switch. I do get your point about fast interrupts only saving what they need to. We do that too on the C64x devices. I should have been more specific.

 

Just curious, but do you know about the T flag and the ZP registers for some 65x variants?

I haven't programmed the 6502 seriously since 1991, and I never really got into anything beyond the original 6502. I peeked at the 65816, but since I only had access to one Apple IIgs, I didn't bother learning something I couldn't make use of. So, while I know about some of the enhancements on the 65C02, I never even got accustomed to using those, even.

 

I imagine someone must've made a variant that put the ZP on-die, and/or allowed you to change its base address. At one time, I was designing a 6502-based computer that would have done that in external hardware, remapping $0080 - $00FF to any 128-byte page in the system, just to get around the context-switch overhead associated with switching out a large portion of the ZP. Thus, you'd have the stable half of the ZP from $00 - $7F, and the switchable half from $80 - $FF. I was also going to relocate the stack, too. I guess what you're saying is that later 6502 variants did something like this for you.

[gdement]

The 6502 probably doesn't meet a strict definition of a "RISC" design, but that's because the academic convention of RISC is based on modern requirements. If RISC had been a marketing catchphrase in the 70's then I believe the 6502 would have been included.

 

The key point for me is that the 6502 was designed under the KISS principle, in contrast with competing designs. It's philosophically equivalent to a modern "RISC", but it was designed in a different era when requirements weren't the same. Thus the lack of registers - back in the 70's RAM was fast so zero page was a good way to reduce complexity. That would cripple a newer chip.

One difference in the philosophy though, is that a RISC was designed that way for performance, while the 6502 was motivated by cost.

[malducci]

I haven't programmed the 6502 seriously since 1991, and I never really got into anything beyond the original 6502. I peeked at the 65816, but since I only had access to one Apple IIgs, I didn't bother learning something I couldn't make use of. So, while I know about some of the enhancements on the 65C02, I never even got accustomed to using those, even.

 

I started with the C version first (Rockwell variant with even more instructions than the standard C model), then later on worked with the original 02 version (NES coding). I'm not sure if that might have effected how I looked at the processor in comparison. The official dev/assembler reserved a some ZP registers(maybe 16) with Register names. Latter dev units reserved even more ZP slots with register names. They even called the registers with x86 names: AX,BX,CX,DX,SI,AL,AH, etc and then some with Rx names.

 

I always wondered what if the assembler syntax was different. Instead of LDA <$00, you had MOV A,R0 or MOV A,[R1:XI] or MOV A,[R16]:YI, etc. If ZP registers would have still been treated like fastmode ram.

 

Later 6502's had more ZP register interfacing opcodes - like the BBRx/BBSx bit test and branch on condition. Not really related but it's funny to note that NEC's later RISC v8xx line had a 'zero' register like the C02's (STZ <operand>) - though they labeled it R0.

 

Anyway, about the T flag. When the T flag was set (SET), the A register is ignored/untouched and all arithmetic was done register to register - ZP registers to be exact. The value in the X register is the second operand (destination) of the two ZP registers. I would like to think that if the 65x had more evolving stages like the x86, we would have seen more implementation of ZP registers as processor registers in functionality.

[Jess Ragan]

A friend of mine once told me that the Super NES not only used a modern update of the 6502 chip (the 65C02), but that it was set to its 8-bit mode for many releases. Also, it's my understanding that the only thing that makes the Super NES incompatible with the NES is that it lacks an NES cartridge slot.

[malducci]

A friend of mine once told me that the Super NES not only used a modern update of the 6502 chip (the 65C02), but that it was set to its 8-bit mode for many releases. Also, it's my understanding that the only thing that makes the Super NES incompatible with the NES is that it lacks an NES cartridge slot.

 

 

The SNES uses a 65816, not the 65c02. It's the 16bit version of the 6502 but with an 8bit data bus (for backward compatibility and cheaper memory interfacing). I can tell you that the SNES is incompatible with the NES for soo many other reasons than the cartridge port. The architecture is totally different. NES carts contained VRAM or VROM on the cart and often a MMU for VRAM/VROM, the SNES has an isolated VRAM setup. The 65816 used in the SNES is missing some instructions that were latter included in the WDC MCU versions, and thus not compatible with 'C02 code.

[intvnut]

I haven't programmed the 6502 seriously since 1991, and I never really got into anything beyond the original 6502. I peeked at the 65816, but since I only had access to one Apple IIgs, I didn't bother learning something I couldn't make use of. So, while I know about some of the enhancements on the 65C02, I never even got accustomed to using those, even.

 

I started with the C version first (Rockwell variant with even more instructions than the standard C model), then later on worked with the original 02 version (NES coding). I'm not sure if that might have effected how I looked at the processor in comparison. The official dev/assembler reserved a some ZP registers(maybe 16) with Register names. Latter dev units reserved even more ZP slots with register names. They even called the registers with x86 names: AX,BX,CX,DX,SI,AL,AH, etc and then some with Rx names.

 

I always wondered what if the assembler syntax was different. Instead of LDA <$00, you had MOV A,R0 or MOV A,[R1:XI] or MOV A,[R16]:YI, etc. If ZP registers would have still been treated like fastmode ram.

 

Later 6502's had more ZP register interfacing opcodes - like the BBRx/BBSx bit test and branch on condition. Not really related but it's funny to note that NEC's later RISC v8xx line had a 'zero' register like the C02's (STZ <operand>) - though they labeled it R0.

 

Anyway, about the T flag. When the T flag was set (SET), the A register is ignored/untouched and all arithmetic was done register to register - ZP registers to be exact. The value in the X register is the second operand (destination) of the two ZP registers. I would like to think that if the 65x had more evolving stages like the x86, we would have seen more implementation of ZP registers as processor registers in functionality.

 

I have a real hard time calling those "6502." :-) That's more like 8051!

[supercat]

If RISC had been a marketing catchphrase in the 70's then I believe the 6502 would have been included.

 

I don't think so. In a RISC, the vast majority of instructions--if not all--fit in a single aligned machine word. There is no expectation of optimizing instructions longer than a single machine word such that they will execute in less time than two single-word instructions. Further, RISC architectures are designed to minimize data memory bus traffic. Can't exactly say that about the 6502.

 

The 6502's instruction set is somewhat more orthogonal than some other CPU's, but with rather a surprising number of peculiarities. As I've noted before, I'm curious how it evolved. It would have seemed easy to partition the instruction set into two groups: (1) instructions which are allocated opcodes for eight addressing modes, and (2) instructions with a single addressing mode. Opcodes whose two MSB's are 00 are in the latter group; all others would be in the former.

 

Had things been laid out that way, there would have been no need to have instructions like BIT, CPX, and CPY located in weird spots in the opcode map and restricted to only a few addressing modes. All "multi-mode" instructions would support addressing modes abs abs,x abs,y zp zp,x (zp,x) (zp),y along with accumulator (for six) or immediate (for the other eighteen) modes. I wonder if anyone counted up opcodes and figured they'd all fit?

 

BTW, I wonder whether LAX is used more often to load the accumulator and the X register, or whether it's used more often just to load the X register, but the accumulator comes in the ride (and/or gets in the way)?

[supercat]

I have a real hard time calling those "6502." :-) That's more like 8051!

 

The 8051's internal RAM is on a separate bus from the code store, so there is no speed penalty for instructions that use it. On the 6502, LDA zp is faster than LDA abs, but it's still slower than LDA #imm. By contrast, on the 8051, MOV A,direct is the same speed as MOV A,#imm.

[intvnut]

I have a real hard time calling those "6502." :-) That's more like 8051!

 

The 8051's internal RAM is on a separate bus from the code store, so there is no speed penalty for instructions that use it. On the 6502, LDA zp is faster than LDA abs, but it's still slower than LDA #imm. By contrast, on the 8051, MOV A,direct is the same speed as MOV A,#imm.

 

I was just referring to the style of programming, where you have 128 or 256 bytes of RAM that you can access directly, indirectly, or as registers, and you have lots of memory-to-memory operations on that space. The notion of "register" in that environment is really just opcode compression. Combine that with the bit test/set operations, and the parallels are striking. Make a version of this "6502 w/ T bit" with the zero page on the die and a dedicated bus, eliminating the penalty you highlight, and you're a stone's throw from 8051.

 

I don't think anyone would accuse 8051 of embodying RISC principles. :-)

Edited November 18, 2008 by intvnut

[supercat]

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.