6502.org

On the 6502 article on Wikipedia : I think this is comple ******** made up by someone.
The 6502 has :
- Variable length instructions
- No register banks
- Instruction set which is not orthogonal at all (each registers does very different things)
- About 10 addressing modes available for all complex functions (RISCs should have only about 2-3 adressing modes)
- Hardware supported stack
- Decimal mode

Which makes it 100% CISC all the way. There is no way the 6502 can ever be considered "the original RISC" or any ******** like this.
Just the existance of instructions like adc ($xx),Y alone make it CISC (this would require ~3 instructions on a RISC CPU).

Well, the Wikipedia article didn't claim that the 6502 is RISC, it merely wrote that a Byte article at one point mentioned it. On the contrary, the Wikipedia article argues against it, so the subject of this thread is quite misleading. In any case I find RISC vs CISC discussions pointless.

-Tor

There's been many threads about this argument here. Where's kc5tja when you need him.

Sure, but they said it has a "neraly orthogonal instruction set" which is completely wrong.

I can do lda $abcd,X but I can't do ldx $adbcd,A => the instruction set is not orthogonal at all.
I'll have to agree. Basically they just threw anything that is not RISC as a "CISC" as if there were only one architecture which is not RISC... apparently this worked since nowadays everyone believes RISCs are superior to everything else.

I have to disagree with that - instead I would argue that the whole RISC/CISC discussion died many years ago, the waters are now so muddled as to what's RISC and CISC that the terms can't be slapped on any modern CPU anymore. So I for one won't walk into that minefield, consider this my last post in this thread

-Tor

OK I admit it was dumb of me to make this pointless thread... I apologize for spamming.

I wouldn't argue that the 6502 is RISC
I would argue that it's more RISCish than
it's contemporaries.

Tor says it's become muddled. I'd say it
has always been muddled. Most of what you
argue has become associated with RISC
since RISC moves stuff out of the hardware
and into the compiler and most of what
you list (seems to me) is about making
it easier for a compiler.
But it's really only tangential to RISC.

I think it might have been more salient
to point to the read-modify-write than
indirect indexed.

To me it's always been about how atomic
the instruction set is and I don't think
that can be well defined. Depends too much
on the hardware.

I mean suppose you put in a hardware multiply.
If it's micro coded presumably that's not
RISC but what if it's a full Wallace tree?
Does that mean it's not RISC because you
could have devoted those resources to more
registers and done it in software?
I think even obviously RISC processors do
stuff like that (for ARM one example I've
often seen is barrel shifts)

I've seen it argued that the 6502 must be
RISC because it's not micro-coded
I've seen it argued that 6502 can't be RISC
because it IS micro-coded
Or it can't be RISC because it's not
Princeton architecture.
Or because it's not (truly) pipelined
(a pipeline has to be 30 deep right?)

One argument is that RISC trys to have
lots of on chip registers because they're
fast, but they've built discrete processors
that used special ram for the registers
and called them RISC, where does that put
the 6502?

So the arguments generally are pointless.

I just think of the 6502 as sort of in between
but a big step in the right direction.

The Byte magazine reference was valid at the time it was written (I vaguely recall the article), as the 6502 was more RISCish than contemporary competitors like the Z80 and 8080. However, a basic RISC philosophy, that arithmetic and logical operations are to be confined to registers—read-modify-write operations like INC MEM would not implemented—obviously wasn't followed, plus, as Bregalad noted, the instruction set isn't orthogonal. However, the 6502 had a higher throughput at any given clock rate than the others, so I suppose the RISC comparison wasn't totally off-base. Also, the 65xx family has very low interrupt latency, substantially better than its contemporaries. Even the 65C816 excels in that area. Compare its interrupt performance to the Motorola 68K...

Anyhow, this CISC vs. RISC jihad should be buried. All computer hardware embodies compromises. At the time of its development, RISC promised and produced higher performance at the clock frequencies then in use. Who could have anticipated the x86 architecture being scaled to the core frequencies in use today. When AMD pushed the x86 architecture past 1 GHz nearly 13 years ago it was apparent that the RISC hardware would not stay around. Now we have x86-64 hardware running at several times that speed and achieving throughput that was unimaginable when the Athlon first surpassed 1 GHz, despite the general inefficiencies of the x86 architecture.

I have on the test bench right now an AMD Opteron quad-core uniprocessor server that we built for a client to replace an older AMD Athlon MP dual processor unit that we installed in 2004. The new server has a computed bogoMIPs rating of 20802 (this is on SuSE Linux 11 SP2 with the 3.0 kernel) vs. 2116 for the old MP box (dual MPUs). The nearly 10:1 speed up is largely due to higher MPU throughput, better cache algorithms and a faster memory subsystem. Would a pure RISC processor run any faster? We'll likely never know. Commodity hardware is so cheap relative to its performance there is no good reason to continue with the proprietary RISC hardware.

BTW, try to imagine a 65C816 being scaled up to a Ø2 frequency of 2.6 GHz, which is what the new Opteron server is running.

Edit: Fixed a typo..."efficiencies" should have been "inefficiencies".

The x86 runs so fast because internally it is running RISC micro instructions. The incoming x86 instructions are translated on the fly. This is actually a very nice solution because it allows for a compact instruction set (improving i-cache efficiency), and it also keeps the internal architecture hidden which allows Intel/AMD to make improvements while maintaining backwards compatibility at the same time.

Can't let that stand! Billions of ARMs are shipped. I have two ARM tablets, an ARM storage device, an ARM ebook reader and an ARM phone. And an ARM lego controller! Of course you probably meant PC and workstation hardware - but let's see what happens with ARM64 from next year. You can buy an ARM Chromebook today.

(This whole thread is somewhat pointless, based as it is on a misreading.)

Cheers
Ed

But then again, one could argue that modern ARM devices hardly qualify as RISC.

Really? The ISA is pretty much load/store isn't it? Are there horrendous instructions and irregularity? For sure, the implementations become pipelined and speculative, out of order and registers are renamed... but that's not a description of the architecture. The ISA being simple makes the front end of the machine simpler.

Take a look at Cortex. You have mixed 16/32 bit instructions with irregular decoding, and mixed access to registers. Some instructions can access all 16 registers, some only a subset. Sure, at the heart is still load/store, but to call it 'reduced' is really stretching it.

RISC was originally introduced to simplify instruction decoding allowing a faster process. Nowadays, the bottleneck is the memory interface, and efficient superscalar execution. Complexity of instruction decoding isn't really a concern when you have billions of transistors at your disposal, and much more difficult problems to solve.

Isn't it still true that high-performance x86 machines spend a lot of transistors on the frontend? They even have to run parallel decoders over overlapping windows of a cache line because they don't know where the instruction boundaries are! Or at least, some did.

I think RISC was originally to make a machine which clocked faster - not just the instruction decode. They certainly succeeded in making chips with smaller transistor count, more replication and much less person power.

Now, once you try to get above the one-cycle-or-a-bit-more and the 4-or-5 stage pipeline, it gets hairy, for both styles - I agree. But the frontend remains problematic - it's complex and it's power-hungry.

Cheers
Ed