Also, the instruction encoding is optimized for total memory usage. In most practical applications, the caches and on-chip memories are much bigger than the core, so making the core a bit more complex in return for smaller program size is often a win. The x86, with its complex instruction decoding had the same advantage of producing rather compact binaries, which increases overall performance when dealing with a fixed size cache.

I've worked with Cortex M0 through M4 processors in the recent past, but only at the C level. Personally, I don't care to do assembly language programming on any RISC-based processor if it can possibly be avoided (and in my experience, it almost always can be).

My point was only that with cheap and ubiquitous FPGAs today, the 6502 can go through the same evolutionary steps that other processors enjoyed, like the x86 and the 68K, but without the billion-dollar expense that was required in the past. The time commitment is still significant, however, and that is what stops me from attempting the path myself. I'm still interested, and occasionally inspired by other people's work in this area, though.

Was just reading something earlier this year about how some recent processor architectures are using register stacks instead of register files. Apparently, when combined with a couple of other tricks, this leads to some significant performance gains. But imagine trying to program (in assembly) a processor where the contents of the registers are constantly changing in response to every instruction processed. Sounds like something only a compiler could do well.

You might be referring to The Mill, which is very left-field. But if not, you might enjoy trying to get your head around it:
http://millcomputing.com/docs/
"the Mill, a clean-sheet rethink of general-purpose CPU architectures"

It is fun to think about CPU design on FPGA, and how to make 6502-like processors which have some interesting enhancements. There are several threads hereabouts: try searching for M65C02 and RTF65002, which are currently active projects. I think there's mileage in a design with 16 bit paths to on-chip memories for stack and zero page, but I don't think we've yet seen one implemented. This thread was near the topic - it also mentions, I think, a wider instruction buffer allowing single-cycle decode of multi-byte instructions. Certainly that idea has been discussed, but again I don't think I've seen one implemented. Nor a design with on-chip cache. The 6502 ISA is not very amenable to pipelining because of the complexity of some addressing modes: breaking into microops is a possibility, but probably quite difficult.

Every time I've thought about this, I came to the conclusion that it would be much more efficient to start with a fresh design, and keeping an eye on the strong and weak points of the FPGA. For instance, small register files are really cheap, whereas muxes (esp in the memory path) are slow and expensive. Getting rid of (ZP), Y addressing, and replacing it with wide index registers is almost certainly a big win on FPGAs. The problem is that you quickly lose all semblance to the original 6502.


My first attempt at making a CPU on an FPGA did that too. Programming with multiple stacks avoids a lot of useless stack shuffling that you get with a single stack. The question is, do you make small stacks or big ones ? Small stacks have the advantage that you can use multiple distinct ones, saving on muxes, and allowing multiple use in the same cycle. On the other hand, small stacks can overflow rather easily, and who wants to keep detailed track of multiple stack usage across (possibly unrelated) subroutine calls ?

I agree with you.

There appears to be little doubt that building hardware which is capable of maximum performance involves tradeoffs that make it less suitable for assembly language programming. So, just as the original designers of the 65816 must have known that the requirements placed on their design would ultimately limit its performance, we'll also have to accept that in order to make something which gives the look and feel of a 6502, we'll probably have to sacrifice a lot of performance potential. But surely you agree that there is a lot more performance potential even while remaining true to the 6502 look and feel? Here are a few random ideas, unrelated to the obvious ones about increasing register sizes and memory width.

• Keep the CISC architecture (e.g. variable length instructions, powerful addressing modes). Going to a RISC architecture will, IMHO, make it feel alien to a 6502 programmer.
• Switch to a Harvard Memory Architecture. Interface it to external memory with a cache subsystem. This facilitates some other optimizations as well.
• Consider a pipelined architecture. Originally, these were exclusive to RISC processors, but then Intel and AMD showed the world you could (with enough logic) make them work with CISC processors as well. The Harvard memory architecture makes this easier to do efficiently. Of course you'll still have more pipeline stalls than a pure RISC processor, but the more powerful addressing modes will at least partially offset this.

Perhaps one key to success is to not try to go from a 1970s design to a 2010s design in one iteration, but rather to make incremental changes, evaluate them, and then apply what has been learned in the next iteration.

A 50 MHz 16-bit 6502-like processor on an FPGA which executed nearly 1 instruction per clock cycle (50 MIPS) would be a very impressive start.

This is starting to sound somewhat like the 65Org32 development of ideas topic. Some related links from my links page are:

• 6502 origins
• 65816 origins, 6516, 65032, 65832 (This one is unavailable at the moment, and I can't find if the page was moved to another location. If you figure it out, let me know.)
• 65CE02 improvements over the 65c02
• 6516 (Synertek) 16-bit pseudo-6502 for Atari 400/800 computers, never made it to market
• 65020 double-wide 6502 proposal
• 6502EX (6502 extended to 32 bits)
• Chuck Peddle gives reasons for design decisions on the 6502

There are more of course. ElEctric_EyE, Rob Finch, Michael Barry, and maybe another one or two here on the forum are working on their own 16- and 32-bit versions.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Indeed I was thinking of the Mill architecture -- had just forgotten the name.

Thank you BigEd and Garth for the references to the (many) 6502-derived architectures that are out there. It seems that many people have different ideas they are trying out which is great. Although only a small evolutionary change from the 6502, I especially liked the 65CE02 and would be inclined to implement it on an FPGA in the future sometime if someone hasn't beat me to it. Harvard memory architectures, memory caches, and pipelining would require more time and effort than I have at the moment so I'll leave those to someone more ambitious than me.

Garth you mentioned the difficulty in pipelining a 6502 because of the addressing modes. Doesn't the 8086 have something like 17 addressing modes? I'm not really an x86 programmer, but didn't the 32-bit i386 architecture keep many of those addressing modes, including the offset indirect modes like the 6502 is known for? Anyway, the 386 and later Intel processors all had instruction pipelines so I don't see any reason not to do the same thing with an '02 derivative. The i386 had 275,000 transistors on it -- that's small enough to fit on even a modest FPGA like a Spartan 6 or Cyclone IV with plenty of room left over (assuming you don't use one of the smaller variants). Despite that, the most ambitious CISC processor I've seen in open source form is an 80186 (http://opencores.org/project,next186) -- though it will blow away any 80186, 80286, and perhaps 80386 ever produced. Obviously the level of effort required is considerable and people with the skills necessary to make it happen are probably more likely to use them to earn a living than to pursue a hobby.

Gentlemen, this topic is supposed to be about the 65C816 and why someone might not like it.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It seems to have disappeared from archive.org, which is a bit disturbing. I thought once it was there, it was safe (as we know, a couple of image files from Jorge's site never found their way to the archive and appear to be lost forever. The rest ended up there though - until now).
For what it's worth, I have a copy of that 65xxx.txt document in case anyone wants it.

EDIT: This is the exact same document: from mirrors.apple2.org: 65xxx.chronology

Re. 68c816 quirks, one thing the doc. (originally published in something called '// Technical', impossible to search for) mentions is that the original 65c816 had an "improved" bus design, but as the Apple II relied on certain 6502 quirks for its disk drives to work they forced WDC to redesign the 65c816 to include those same quirks. I believe this may have been mentioned on this forum before btw.

EDIT2: From the same place: 65xxx.dreams

and continues with suggestions about how the WDM opcode could be used for improved instructions.

-Tor

I can't imagine what the author of that article found difficult about the 65C816. I have had very little trouble getting it to do what I want.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes, the author described the 8086 segmented memory architecture as being quite good.. and superior to the 65C816. I think that was coloured by the time it was written. Later, at the end of the eighties and the early nineties it had become painfully obvious that the segmented 80x86 memory architecture was a severe limitation. What a relief when that could be disabled with the '386.

Segmented is still better than banked, because you can set a segment at the start of big objects, and then index into the object without fuss (for object <= 64KB). With banking, even a small object can straddle two banks.

This was the idea behind the 32-bit "bank" bytes of the 65Org32; you could for example set the start of a "bank" at the start of big objects, but it still allowed the entire 4gigalongword space.


Same here. I've said it before: I find the '816 to be easier to program in assembly language than the '02.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I've been running through ideas for the obvious quick conversion of my 65c02 Tali Forth to the 65816, and even in scribbled code fragments, it's amazing how much easier, smaller, and faster things become. Even if you just use it for 64k, I must say: The 65816 is the better 6502. I can't really see going back.

Anyway, I'm glad we stopped talking about broccoli. That was freaking me out .