I'm not a hardware engineer, so take this with a grain of salt:
The 6502 doesn't have a cache, only external memory. So performance would probably be much worse than naively expected (except perhaps for workloads that fit in CPU registers, edit -not even those due to the lack of a code cache as well). Memory latencies haven't improved nearly as much as CPU speeds have, which is why modern CPUs have big caches.
The CPU would be idly waiting for memory to respond most of the time, which completely kills performance.
That's because on (most) modern systems, main RAM is combined (shared memory space) and external from CPU, connected through fat but high-latency pipe.
A solution is to include RAM with each CPU core on-die. Afaik this is uncommon approach because semiconductor fabrication processes for RAM vs. CPU don't match well? But it's not impossible - IC's like this exist, and eg. SoC's with integrated RAM, CPU caches etc are a thing.
So imagine a 'compute module' consisting of 6502 class CPU core + a few (dozen?) KB of RAM directly attached + some peripheral I/O to talk to neighbouring CPU's.
Now imagine a matrix of 1000s of such compute modules, integrated on a single silicon die, all concurrently operating @ GHz clock speeds. Sounds like a GPU, with main RAM distributed across its compute units. :-)
Examples:
GreenArrays GA144
Cerebras Wafer Scale Engine
(not sure about nature of the 'CPU' cores on the latter. General purpose or minimalist, AI/neural network processing specialized?)
Afaik the 'problem' is more how to program such systems easily / securely, how to arrange common peripherals like USB, storage, video output etc. in a practical manner as to utilize the immense compute power + memory bandwidth in such a system.
> Now imagine a matrix of 1000s of such compute modules, integrated on a single silicon die, all concurrently operating @ GHz clock speeds. Sounds like a GPU, with main RAM distributed across its compute units. :-)
Sounds like a new version of the Connection Machine (the classic / original one).
The 6502 didn't need cache because its clock speed was slower than the DRAM connected to it. That made memory accesses very inexpensive.
The Apple II took advantage of the speed difference between CPU and DRAM and designed the video hardware to read from memory every other memory cycle, interleaved with CPU memory access.
> The Apple II took advantage of the speed difference between CPU and DRAM and designed the video hardware to read from memory every other memory cycle, interleaved with CPU memory access.
Same for the C64. Sometimes it was necessary to read slightly more than that for video display though, so the VIC (video chip) had to pause the CPU for a bit sometimes, resulting in so called "badlines".
Both were faster. DRAM was a little cheaper, but required more circuitry to handle refresh on most CPUs making it a wash cost-wise on some designs. Typical woz engineering got the cost of the refresh circuitry down to where DRAM made sense economically on the Apple ][.
Interestingly Z80s had DRAM refresh circuitry builtin which which was one reason for their prevalence.
And for the Z80: also that it only needed GND and 5V. The 8080 also needed 12V. And the Z80 only needed a single clock phase -- the 8080 needed two. The 6502 also only needed 5V and a single clock input (the 6800 needed two clock phases). The 6502 and Z80 were simply a lot easier to work with than most of the competition.
You'd probably want to add at least a small cache, sure. Putting the zero page (256 bytes) on-die on each core (because it's typically used as "extra registers" of sort in 6502 code) plus a small additional instruction cache could do wonders. But you probably still wouldn't get anywhere near enough performance for it to be competitive with a more complex modern architecture.
It'd be a fun experiment to see someone do in an FPGA, though.
I don't think CPU caches were much of a thing back then, at least in the segments involved.
AFAIK Intel wouldn't get on-die cache until the 486 (the 386 did support external L1, I think IBM's licensed variants also had internal caches but they were only for IBM to use).
The most distinguishing feature of the 6502 is that it had almost no registers and used external memory for most of the working set (it had shorter encodings for the first page, and IIRC later integrators would use faster memory for the zero page).
> I don't think CPU caches were much of a thing back then
Indeed, because memory was fast enough to respond within a single cycle back then. Or alternatively, CPU cycles were slow enough for that to happen depending on how you want to look at it :)
6502 systems had RAM that ran at system speed. Everything was so much slower then so this was feasible... plus, some systems (like the Commodore VIC-20) used fast static RAM.
The 6502 even had an addressing mode wherein accesses to the first 256 bytes of RAM -- the "zero page" -- were much faster due to not needing address translation, to the point where it was like having 256 extra CPU registers. Critical state for hot loops and such was often placed in the zero page.
Do not presume to apply principles of modern systems to these old systems. They were very different.
The saving for the zero page is only the more compact encoding which saves one cycle for memory access (for the non-indexed variants, anyway)
E.g. LDA $42 is encoded as $A5 $42, and so takes 3 memory accesses (two to read the instruction, one to read from address $42). LDA $1234 is encoded as $AD $34 $12, and so takes 4 cycles: to read $AD $34 $12, and one to read the contents of address $1234. Same for the other zeropage vs. equivalent absolute instructions.
Now I have to wonder whether it would be possible to build a cache around an unmodified 6502. I.e. a component that just sits between the (unmodified) CPU and memory and does caching.
I don’t think an unmodified 6502 would get faster; it assumes memory is fast enough for its clock speed, and won’t, for example, prefetch code or data.
Also, if you add a modern-sized cache, you won’t need the memory at all in a single-CPU system; the cache would easily be larger than the addressable memory.
It'd only benefit if the latency of the external memory is bad enough to keep the cores waiting, sure, and certainly you're right regarding a single-CPU system. I think this fantasy experiment only "makes sense" (for low enough values of making sense) if you assume a massively parallel system. I don't think it'd be easy (or even doable) to get good performance out of it by modern standards - it'd be a fun weird experiment though.
If I were to build a system with lots of 6502s, I think I would build something transputer-like, so that each CPU has its own memory, and the total system can have more than 64 kB of RAM.
The alternative of a massively parallel system with shared memory, on 6502, would mean all CPUs have 64 kB or memory, combined. I think that will limit what you can do with such a system too much.
These were intended to get to 4k cores (but 32 bit), w/32K on-die memory, but the ability to read from/write to other cores. A 6502 inspired variant would be cool, but to not get killed on the cycle cost of triggering reads/writes you'd probably want a modified core, or maybe a 65C816 (16-bit mostly 6502 compatible).
Should be, the 6502 has a RDY signal, to insert wait states in case accesses aren't ready yet. You'll need some way to configure the cache for address ranges and access types, but that would presumably just be more mmio.
The 6502 doesn't have a cache, only external memory. So performance would probably be much worse than naively expected (except perhaps for workloads that fit in CPU registers, edit -not even those due to the lack of a code cache as well). Memory latencies haven't improved nearly as much as CPU speeds have, which is why modern CPUs have big caches.
The CPU would be idly waiting for memory to respond most of the time, which completely kills performance.