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.psycopathicteen wrote:The 68000 would've had a head start with compilers.
Was ARM originally cheaper than 68000?
Moderator: Moderators
Re: Was ARM originally cheaper than 68000?
Re: Was ARM originally cheaper than 68000?
Of course code size in memory is still a problem, particularly instruction cache, L2 cache, and L3 cache.
Re: Was ARM originally cheaper than 68000?
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 .tepples wrote:Of course code size in memory is still a problem, particularly instruction cache, L2 cache, and L3 cache.
This why modern CPUs are crisc and not cisc only .
-
- Posts: 271
- Joined: Sun Mar 27, 2011 10:49 am
- Location: Victoria, BC
Re: Was ARM originally cheaper than 68000?
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.
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.
Re: Was ARM originally cheaper than 68000?
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.RISC chips have gradually turned into CRISC chips, in large part due to code density issues.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Was ARM originally cheaper than 68000?
I would like to see how a 68000 expert would pull off "add r0, r1, r2, asl #8" in one cycle.
Re: Was ARM originally cheaper than 68000?
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.
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.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Was ARM originally cheaper than 68000?
There's no way it's just 20% faster at the same megahertz speed.
Re: Was ARM originally cheaper than 68000?
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.
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.
Re: Was ARM originally cheaper than 68000?
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?
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Was ARM originally cheaper than 68000?
Dhrystones can't measure how fast a collision detection routine written in assembly code is.
Re: Was ARM originally cheaper than 68000?
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.
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.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Was ARM originally cheaper than 68000?
I never said MIPS was accurate.
Re: Was ARM originally cheaper than 68000?
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.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Was ARM originally cheaper than 68000?
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.
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.