In another article, Garth wrote:



I wanted to respond to this, but it was so far off-topic that I decided to start this one.

The reason why most 32-bit "6502s" look and feel different is because they emphasize increased compatibility with higher-level languages. You can only get so much oomph out of an accumulator/memory[1] architecture with a rather baroque set of addressing modes and under-powered PC-relative or indirect modes. High-level languages like C or Pascal (or, for that matter, compiled BASIC) really want orthogonal access to CPU registers, plus a clean and orthogonal set of addressing modes. So, for example, X or Y could be used as an accumulator here, and as an index there, etc.

If all you want is a 32-bit extension to the 6502, you have two ways to achieve it -- one is to redefine your byte to be 32-bits wide, and just go that route (this is Garth's preferred embodiment), or you can retain the 8-bit byte and extend the CPU's instruction set with additional modes and/or prefix bytes to adjust operand size while retaining existing addressing modes. This would be the way WDC would choose if it cared at all about backward compatibility.

The former approach requires less hardware to implement, but opcodes (and almost certainly operands) waste 50% to 75% of the memory space they consume, since they'll still be 8-bits (or 16-bits if you merge direct page references directly into the instruction word). The latter approach yields smaller binaries, but requires greater logic to support (e.g.) 16-bit or 32-bit wide buses with two or four 8-bit lane selects, instruction prefetch queues, etc.

In either case, you're still limited by the memory bus bottleneck. I proposed using a specially-ported, on-chip data cache to relieve the bottleneck and to treat the direct page exactly like your typical internal register set, but it seems this approach isn't favored, and many think it's just easier to add more CPU registers. RISC processors with 32 32-bit registers, for example, provides the equivalent working set as 128 bytes of direct page.

I seriously doubt we'll ever see a real 32-bit 6502 that looks and feels the same as the 6502 or 65816.

_______________
1. An "accumulator/memory" architecture (aka simply "accumulator" architecture) is a CPU design which uses a single accumulator as one ALU input, and external memory fetches for the second ALU input. Note that stack architectures are a proper subset of accumulator architectures. Contrast this with Intel's 80x86 line, which is a "register/memory" architecture, so named because it allows most registers (not just a single accumulator) to be used as ALU inputs. In addition, there exists register/register architectures, where only registers can be used as ALU inputs -- typically, these are RISC-type machines. Memory/memory architectures exist too, such as the TMS9900 processor, and arguably, the 680x0 series too.

_________________
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?

@Garth

It's actually got nothing to do with multitasking or specific types of application. An orthogonal instruction set simply reduces the number of hoops that one needs to jump through in order to express an idea into assembly language for that particular CPU. It makes writing a compiler back-end (for any language) a lot easier, and code for that platform ends up being faster as well because one doesn't need to juggle data to make sure it's in the right place to be used by a given opcode. It's not limited to compilers either, the M68000 had a very orthogonal instruction set and it made programming for it in assembler a pleasure.

OK, so that explanation was probably not very good for someone who's not a programmer... let me give you an example that's closer to the 6502. The reason we say the 6502 does not have an orthogonal instruction set is because while instructions like ADC let you use all addressing modes (the ones that make sense), instructions like JSR are artificially limited - eg JSR abs,x makes sense as an instruction, but it just doesn't exist. If you want to do JSR via a table of pointers you can't just use a simple instruction, you need to either write it yourself or adjust your algorithm so it doesn't require a jump table. In the first place you end up with code that's bigger and slower, in the second you end up with code that isn't as good or as elegant as it could be.

An 8 bit CPU that's a lot like a 6502 and has a reasonably orthogonal instruction set is the M6809. Take a look at its instruction set and you'll see how some things are just easier to express with it (for example, addressing modes that use the X or Y registers work exactly the same way the stack pointer)

Good questions. I'd like to have answers to them myself. In my opinion the 6502 has a limited set of registers only - but it has the great advantage of zeropage addressing that can be leveraged even with larger processors.

(spoiler ahead:)
My 65k will have a prefix opcode modifier to add either the PC or a new base offset register to the address - which allows for flexible re-location of addressing modes, including the zeropage addressing mode. You could set the base offset register to the address of your data structure and then address all fields with zeropage addressing.
(spoiler end)


I hope my 65k will give you that feeling. At least it gives it to me...

I am almost done with the specs (no code yet!). I know, release early and often, but there are some things I still want to finish before I publish it. I hope to get it out next weekend latest.

André

No. This applies just as well to functional, to object-oriented, and to procedural language categories. Because stack architectures are a subset of accumulator architectures, only stack-based languages like Forth categorically prove the exception.



No. C, Java, and numerous other languages of the C-family have been applied to problems as diverse as arcade games to finance to medical imaging to CAD and more.



No. Hand-crafted 2.8MHz 65816 assembly demonstrates a level of graphical performance for the Apple IIgs that competes surprisingly favorably with the Amiga's dedicated blitter hardware running a 3.57MHz[1]. Anyone who has used Deluxe Paint II on the Apple IIgs will prove this point with great facility by grabbing an eighth of a 320x200x16-color screen as a brush, then selecting the spirograph tool, and drawing with the brush. Granted, the Amiga is still faster in practice, but when push comes to shove, the 65816 has sufficient horsepower to alleviate the need for dedicated graphics hardware compared to comparable 68K-based systems.

That being said, it's clear from published benchmarks that compilers for the 68K architecture produces 2x to 3x faster code. How does one explain this performance discrepency? I predict compilers for the 68K family do not have to juggle memory to and from a single accumulator, or tweak word-width flags, or have to constantly reload the Y register for random-access to data structures. Each of these offers a small speed up, but since they all occur in combination, their effects multiply.



Preemptive multitasking is a huge, huge, huge performance booster in practice. Cooperative multitasking is more time efficient only in closed environments such as you'd find in deep-embedded applications. For everything else, cooperative has been shown to be fatally susceptible to poor programming practices (even accidental), to the point of rendering a computer so unresponsive as to require a reboot. C.f. Windows 3.0, OS/2 1.3 and earlier, the Contiki event-driven OS, etc.

Additionally, if your kernel has a well-chosen set of task primitives, you'll find coding for a preemptive multitasking environment quite easy. The Amiga operating system, for example has one, and only one, system call that puts a task to sleep -- Wait(). Now, there exists other blocking system calls, but all of these functions ultimately have to call Wait() in order to put the task to sleep. Conversely, there exists one, and only one, mechanism for waking a task -- Signal().

On top of these basic primitives, AmigaOS provides message queues (called "message ports" in AmigaOS lingo), semaphores, and I think a few other basic primitives. But of all the primitives supplied, take a guess as to which one (and I do emphasize the singular here) is preferred for very nearly everything in the OS?

Whether you're implementing a GUI application, a device driver, or a filesystem implementation, you're going to be working with message queues. It's far simpler than the bullshido you get in PThreads or Win32 Threads, and it essentially mimics how you'd build a real-world, multi-processor embedded application anyway. Oh, and it's also the programming model used for Erlang -- if you've coded an Intuition application for AmigaOS, you already know how to code parallel applications in Erlang even if you don't know how to code in Erlang yet.

The numbers speak for themselves. In 256K of space (mostly generated from a C compiler, at that), Kickstart provides a plurality of device drivers, libraries, and supporting background tasks, all communicating with message queues. Add in the disk-resident software, and that figure goes up to about 1MB or so (Workbench shipped on an 880K floppy, uncompressed binary images). Binaries were kept small, the OS is still considered darn tiny by today's standards, and yet it still relies heavily on preemptive multitasking.

No MMU required -- just brains.



I suspect that without the business imperative (deliver a product on-time and within budget), the need for high-level programming languages would not be as strong. As it is, companies use HLLs with the full knowledge and acceptance that they're trading some fraction of runtime performance for improved programmer productivity. Coding a program faster than your competitor means, automatically, that you can respond to customer desires faster, which earns you a greater market share. You don't use Ruby to write a real-time engine control package. But it works great for delivering a production-ready web application to millions of users in only two months.

Alternatively, now that the market is saturated with HLL coders, it also means you need not spend so much time training new hires, which also reduces overheads for the company.



Like I said in my original post, if all you want is a bigger gulp size, then you can get by with a wider byte. But, even this fundamentally alters the "look and feel" of the CPU.



simply feels a lot different when coding than:



___________________
1. Before people chop my head off for making this statement, if you pick up the Amiga ROM Hardware Reference Manual, you will observe that the blitter can write to RAM no faster than one word every two cycles at 7.15909MHz, assuming all you're doing is filling memory with a fixed value. It runs slower still if you're using it to process one or more source channels.

_________________
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?

This is not a C or Pascal-specific thing.

Why do you prefer to use direct page for stuff? For the same reasons compilers prefer to use CPU registers. A compiler would not have any problem using direct page instead of CPU registers, if the CPU's instruction set provided instructions like:



which would be equivalent to:





I openly challenge you to pit a Rabbit CPU (Z-80 compatible with a much faster bus interface) to a 6502 and see who wins, clock for clock. The Rabbit, like the 6502, has single-cycle bus transactions.



Clock for clock? I'd have to see numbers on this. I suspect they'd be a good match.



But the 68020 does snow the 65816.

And, again, you're conflating bus performance with instruction execution performance. These are NOT the same thing. Not even close!!



Stack architectures achieves this by retiring one instruction per clock cycle, while still keeping the ability to fetch one instruction per cycle as well.



Thus turning your CPU into a memory/memory architecture along the same lines as the TMS9900, and you'll forever be bottlenecked by RAM access speeds.

A larger set of on-chip registers allows the CPU clock to increase faster than your bus speed. When this is permitted to happen, you can (if you're willing to deal with implementing the cache on-die) benefit substantially from it.

You will never get real-time MPEG playback like we have today without it. DVD players could not exist without the kind of complexity you're railing against.

_________________
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?

The 6502's speed over those other CPUs comes from two sources: the fact that 6502s access memory every cycle like kc5tja said, and the 6502's use of little endian byte ordering, which allows many instructions to take one cycle less to execute than they do on a 68xx.

Actually, most of those exist either to compensate for the vast difference in speed between memory and CPU registers, or to compensate for each other (eg branch prediction exists to compensate for a performance hit inherent in pipelining, which in turn exists to compensate for the amount of time it takes a modern CPU to access memory). The 6502 doesn't need any of those for the simple reason that it can access memory on every cycle.

As far as number of registers is concerned, I firmly believe that zero page (or DP on the 816) does a good enough job.

Since we're discussing this, I thought I'd mention my own dream 32bit 6502. I'm not much of a hardware guy (software's my thing), but if any of it inspires the solder jockeys here I'd be quite pleased. If I was given the job of making a 32 bit capable 6502 that is backwards compatible with the 8 bit version, I'd do it like this:
1. Add a new 32 bit accumulator (call it Q for quad)
2. Add LDQ and STQ instructions with the full complement of addressing modes that LDA and STA have
3. Add a new addressing mode that allows 32 bit ALU operations between Q and integers in zero page addresses, eg ADC Q,zp
4. Add another addressing mode that allows 32 bit ALU operations between Q and 32 bit immediate values, eg SBC Q,#$11223344
5. Add two 32 bit index registers (call them V and W) and allow them to be used with the same addressing modes as X and Y (eg LDA offset,w). Also add LDV, STV, etc: the same set of operations that X and Y get. Obviously instead of TAW you'd have TQW and so on.
6. Add JSL and JML instructions that take 32 bit absolute addresses, as well as V and W as targets (and add RTL for 32 bit returns)

That design keeps the feel of 6502 assembler, while keeping compatibility with the 8 bit instruction set and expanding and allowing for 32 bit operations and a 4GB address space. It also does away with messy register width mode bits and bank bytes, which are my pet peeves with the 65816.

Compiler technology isn't simple, but one can write a naive compiler for a register/register architecture that produces quite adequate code without too much difficulty. Remember when I translated Forth code to random-access direct page references, automatically optimizing out all the swaps, drops, nips, and what-not? This would suggest that if you can translate other languages into reverse polish form (trivially done once you have the parse tree available), the code generator can be used for any kind of language you throw at it.



As you worded it, you voiced the concern that a large register set isn't an indicator of processor performance, and cited two processors (Z80 and 68000) with known inferior bus architectures. I claim that this simply isn't a fair comparison to make in the context of the discussion.

The rest of the world indicates clearly the opposite -- once the CPU's instruction retirement rate exceeds the memory fetch capacity (which doesn't take much to do, I might add; 16MHz buses are about the reasonable limit, though through very careful PCB design you can push into the 30MHz regions. Beyond this, you're looking at differential signaling, stupendously wide buses, etc.), on-board registers become one of the determining factors of processor performance.



Yes, but what made it so grand was the all 32-bit infrastructure. 32-bit external data bus, 32-bit internal ALUs, etc. Internally, the microcode and nanocode backing the CPU's instruction set had not differed significantly from the 68010 which preceded it. We didn't see real cause to drool until the 68030 rolled, and the 68040 even more so.



This needs to be measured, as inefficiencies introduced in one area may be more than made up for by vastly improved efficiencies elsewhere. You can't really make a static determination of efficiency based on anticipated cycles consumed for some operation.



Actually, RISC says nothing about the number of registers offered by the architecture. All it says is that the CPU offers a reduction in instruction offerings (and addressing modes), preferably arrived at by studying the instructions generated by theoretically perfect compilers for theoretically perfect computing hardware as well as existing software for existing architectures.

The large register files found in today's RISCs are there because of pressures found when writing compilers. Early RISC architectures, like the CYBER 604, had as few as 4 registers, while the Cray-1 supercomputer had only 8 integer registers (not including FPU and vector registers).

Also, pipelining isn't the sole domain of RISC; CISC mainframes have used pipelining as a means of improving throughput for some time.



I would agree, but this only indicates the inferior instruction set of the PIC16. The ATmega microcontrollers, for example, perform much better, and can keep up with the 65816 (let alone 6502) at most tasks. There are places where it's inconveniently slow (e.g., accessing ROM, or having to work with more than two or three pointers at a time), but on the whole it's quite a zippy little engine.



Which it won't, because of power consumption and physical size limitations. One could expect a 4-bit optical computer to be about the size of those old-school Apollo workstations that used to hold up the end of your desk back in the late 70s/early 80s.



Right, but this is talking about something completely different from what I was addressing.

The topic that spawned this thread is simple, concise, and to the point: 32-bit 6502 spinoffs don't feel like a 6502, and that seems to bum people out. MY argument is equally simple, concise, and to the point: it'll never happen. ANY time you attempt to change the 6502 to support a 32-bit wide computational capability, it WILL change the fundamental nature of the CPU. Just as the 65816 in native-mode feels very different than the 6502, so too will a 32-bit re-imagining of the architecture.

Please also note that I'm not making a value judgment here. I'm not saying that this is a bad thing. I'm merely advocating that one should not expect a 32-bit 6502. The ARM is perhaps as close as you're going to come.

_________________
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?

Don't get me wrong, the 65816 has a pretty nice instruction set overall. I guess I see the banks and width bits as the wart on Mona Lisa's nose

I think one problem here is that everybody thinks about something different what "feels" like a 6502. So I can only speak for myself...

In my opinion the 6502 "feels" like a 6502 because of

- the (small) register set, with a single general purpose register AC and index registers X,Y
- the register/memory architecture.
- zeropage addressing modes, indirect indexed addressing modes
- cycle efficiency (most / almost every cycle has a valid memory access, interrupt efficiency)
- general simplicity

A 32 bit approach for me would still be 6502ish when the above points are fulfilled. So for me it would be ok when the registers are wider than eight bit. But a RISC processor that "by chance" translates 6502 opcodes into its own RISC opcode space is not 6502ish for me (sorry 65GZ032 - but still a great accomplishment). Also just adding more and wider registers would not feel 6502ish - it would just interleave the 6502 basically with another processors.

It seems - I have no experience in writing compilers - that a processor with (many) more general purpose registers would be much better suited for compiler. On the other hand I believe that with offsetting zeropage the processor would get a set of 256 register bytes - more than many other processors - with automatic register window (changing the offset).

Working on my 65k I think I have preserved a lot of 6502ishness, while still providing many modern features. It is an interesting experience I am going through right now. Looking forward to your comments next weekend...

André