nesdev.com

Yes like all modern CPU, but it's not fair to compare code density with an IA64 for exemple which memory size nowadays are not really a problem, but parallelising process or others modern things are,to summarise the code is less dense but more efficient.

Of course code size in memory is still a problem, particularly instruction cache, L2 cache, and L3 cache.

I agree, but code efficiency is more important than code density here,this is not a bottleneck because the huge main RAM is alway here if needed .
This why modern CPUs are crisc and not cisc only .

You have it backwards: CISC ISAs are as CISCy as ever. RISC chips have gradually turned into CRISC chips, in large part due to code density issues.

Modern CPUs are *insanely* good at reordering, parallelizing, and fusing instructions together once they get inside the pipeline. Nothing - *nothing* - a CPU can do internally comes close, performance-wise, to the cost of hitting RAM. When writing tight code (at least on a first pass) I view branchless operations on registers as effectively *free*; my big concerns are always always always branch prediction failures and cache misses.

I do not agree, this is more because the RISC CPUs have a hard time having a high frequency due largely to his reduced pipeline.

I would like to see how a 68000 expert would pull off "add r0, r1, r2, asl #8" in one cycle.

That's literally out of scope? This isn't about "all instructions are faster on ISA X than on ISA Y". It's that the two ISAs provide different instructions and different tasks can be done in different ways. You wouldn't want to do that on 68k unless you were specifically writing an ARM emulator on the 68k.

Comparing a single unique unchanging instruction speed is more or less useless in all contexts. There is literally no context in which that is a useful metric. (This is specifically why MIpS is a useless metric)

8086 IDIV was abominably slow. But you wouldn't claim that the XT ran at 24KIpS as a result, that's just misleading.

There's no way it's just 20% faster at the same megahertz speed.

Your disbelief doesn't change the fact that the recorded Dhrystones per MHz for ARMv1 are only 20% higher than the 68k.

If you want to argue with it, you need to actually dig up the corresponding assembly for the algorithms on the two ISAs. Only then can you make a meaningful comment about the relative performance.

Otherwise... you're just letting your preconceptions blind you.

It might help as a baseline to hand-compile Dhrystone to idiomatic 6502, 65816, LR35902, and Z80 assembly, so they can be compared with GCC and LLVM output for m68k and ARM. Has this been done publicly?

Dhrystones can't measure how fast a collision detection routine written in assembly code is.

Your point being?

A Dhrystone is an arbitrary metric. It is less misleading than pure MIPS. It does not indicate suitability for other tasks other than those measured. It is definitely not a good metric of floating point capabilities, which are explicitly out of scope.

Some things benefit from certain CISC features. (For example: 68k register autoincrement). Sometimes the simplicity gained in early RISC designs outweighs that. Sometimes they don't. But replacing the metric "dhrystones/sec" with the metric "bounding box collisions/sec" doesn't tell you more, it just tells you something different.

The N64 has a very fast RISC CPU. And yet it is completely hamstrung by having high latency and limited bandwidth to main system memory. If you just counted operational cycles without paying attention to memory latency, you'd get a horrifically misleading picture.

The earliest ARM CPUs were only used in Acorn's Archimedes, which had graphical capabilities somewhere between EGA and VGA, and sound capabilities comparable to the Amiga OCS. But when I look at the very few demos that were posted to Pouet and viewable on youtube ... it doesn't even come close to its contemporaries. Is this a fair metric? Who knows, but on top of the other metrics, all I'm hearing is the same thing over and over:
RISC promised us that simpler instruction sets were a key to performance. Other factors have always overwhelmed any resulting gain.

I never said MIPS was accurate.

Then why do you insist that this ARM should be drastically faster than the 68000? It looks like your sole metric for believing so is the relative MIPS of the two.

This 68000 instruction takes 12 cycles:
move.w (a0)+,(a1)+

The ARM needs 2 instructions to perform this:
ldrh r2,(r0),#2
strh r2,(r1),#2

Both of these are 3 cycles, which adds up to 6 cycles, which is still half as many cycles.