6502 has the fastest and most convenient way to handle BCD. It uses the decimal mode which about twice as fast as its BCD correction analogues for 8080, 6800, z80, 6809, 80x86. 680x0 uses 5 special instructions for this type of data - such a waste of the code space.
IMHO the support of BCD data is redundant. The only advantage for BCD for 6502 is fast decimal data input from text and output to text. However the division and the multiplication for BCD are twice slower than for binary data. It is because

must be replaced by the sequence

BCD allow fast multiplication only by 10 and fast division only by 10 and 5. It is common to use the division and the multiplication much more often than the input/output operations which usually work with the slow peripheral devices. So it is generally much faster to use binaries as the main type and to convert it to decimal only for input and output.

It is possible to dream what could be made instead of these redundant operations?... I'd like to see the second accumulator like at 6800 or/and a block memory copy instruction like at 65816.

It is curious why BCD are supported even at 80x86 or 680x0 which have hardware multiplication and division? The modern CPU architectures like x86-64 or ARM have no hardware BCD support at all. It is worth to note that DEC CPU architectures also had no such support even at 70s or 80s. However DEC architectures had a lot of other redundancies.

The other redundant feature of 6502 IMHO is the overflow flag. The discussion at http://www.stardot.org.uk/forums/viewtopic.php?f=4&t=11543 shows that almost all programs do not use it. This flag is usable only to catch the errors which are not even considered as the errors in the modern programming languages by default. IMHO it would be better to have odd/even flag (bit 0 of result) instead of V-flag.

The question: are there other 6502 redundancies?

_________________
my blog about processors

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

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

I have to fix my previous post. BCD multiply and divide are 3 and even more times slower than the binary because BCD data occupy about 50% more bytes. The addition and the subtraction are about 50% slower for the same reason.



Thank you very much for valuable information and the links.

I agree that ARM and 6502 are not RISC. IMHO these words RISC, CISC, ARA are kind of meaningless slogans. The wiki's page about ARM based Acorn Archimedes (https://en.wikipedia.org/wiki/Acorn_Archimedes) has "information": "since the 68000 is a CISC and ARM2 is a RISC architecture, the 68000 could execute more complex instructions in one step, while the ARM2 must do it in several steps. So, depending on the task and the code, the 68000 may outperform the ARM2 in several cases". IMHO 68000 can outperform ARM2 only with BCD operations. And I can add that a lot of ARM instructions are so complex that 68000 has to use 2-5 its instructions to emulate them.



The decimal mode of 6502 consumes only two opcodes but also some of silicon space which may be used for ONE or TWO additional instruction(s)...



I've checked the tables, 68000 DIVU instruction takes 144 cycles. The best known 6502 division routine (32 bits dividend and 16 bits divisor) takes about 700 cycles and occupies about 1 KB of memory. Its version with loops is about 100 bytes in size but about 850 cycles in time. Is there any problem in the interrupt delay for 144 cycles for 8 MHz 68000?



Any proof? I'm aware of http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=120687, IMHO it gives very odd results close to absurd like z80 is faster than 80188. It uses different algorithms, multi-level emulation and other things that make the objective compare almost impossible.
I worked with Amstrad CPC (z80 at effective 3.2 MHz) and PCW models. I have to say that Amstrad CPC ROM Basic is 2-3 faster than Commodore Basic (with 1.1 MHz 6502). I have the evidences of commercial game programmers from USA who made the codes for 6502 and z80 that 6502 is generally about 2.2-2.4 times faster. My project http://litwr2.atspace.eu/xlife/retro/xlife8.html shows about the same ratio.



My measurements show that 65816 in 16 bit mode is less that 50% faster with arithmetic, 100% with the memory block transfer (due to MVN/MVP), 0% with branches. 65816 has powerful stack addressing modes. So for stack based Forth it should give the significant speed boost maybe even more that 100%. This boost with the smaller scale will be applied to the programming languages which use subroutines with the formal parameters and the local variables. However the work with byte tables is faster in 8-bit mode and 68516 has no any advantages over 6502 in this area.

IMHO 65816 was realized a bit extensive like a bit ugly z80. It might be faster with instructions like CLC, TXA, ... like later 4510/65CE02. XBA, MVP, ... might also be faster.

I want to find opportunity to study 32016, the first 32-bit CPU... B-em, BBC Micro emulator has some support for it. I doubt in its accuracy though.



It is better to have ADDQ and SUBQ from 68000.



68000 can also use tables. I had a surprising result with R800 (the fast version of z80 for MSX turboR, it is about 3-4 times faster than the original z80). R800 has fast hardware multiplication (36 cycles for 16 bit multipliers) but with a 768 bytes table I could get 35 cycles multiplication with a constant factor.
IMHO the fastest division is achievable via logarithmic tables. I suspect that 80186 uses them.



I have just browsed all these topics. Thanks again. IMHO LSR4 instruction would be worth to mention too. 6502 requres 4 LSR to get the higher nibble. The lower nibble can be get by AND #15. So what's the purpose of SWN (swap nibbles)? It is better to have z80 RLD which allows to make fast 4-bit shift of the sequence of bytes.

I have another a bit ignoramus question. Why JMP ($xxFF) is often considered as a 6502 bug? IMHO it is very good to work with tables. It allows for jump tables to occupy exactly one page. For example, the next code provides jumps for 128 odd values



the table divjmp occupies one page for 6502 but requires an ugly misaligned page for 65C02/65816...

_________________
my blog about processors

(Thanks Garth - you picked up a thread not previously present in my index.)

For realtime it would be. And there was one particular device that was very realtime back then, and that was the floppy drive. Realtime in this case means that it has to be fast enough, but if it is, then it doesn't matter if it is even faster. So, the question is really: How long does it take to process 144 cycles? Acorn dismissed both the National Semiconductor and the Motorola offerings for that reason. Steve Furber explicitly mentions the NS one in this interview: http://cacm.acm.org/magazines/2011/5/10 ... r/fulltext

Sophie Wilson has elsewhere mentioned that the 68k had slower interrupt handling than the 6502. Back in the eighties I wrote software for a very realtime bird-monitoring system, lots of interrupts from many sources. The Apple II, or rather, the 6502, had no problems with that.

Garth in the past has, I think, mentioned audio as being very sensitive to jitter - regular interrupts need to be regular. If not audio, then other data acquisition. There will be other applications where it doesn't matter, of course.

If the NMOS 6502 (and others, such as the 6510) encounters JMP ($xxFF), it will incorrectly load PC with the contents of $xxFF and $xx00, failing to increment the most significant byte (MSB) of the operand to get the MSB of the target address. This error was corrected in the 65C02 and 65C816.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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

Bear in mind that different Basics can have quite different performance. Mallard Basic on the Z80 seems especially good.
http://www.retroprogramming.com/2010/01 ... marks.html

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

I just thought I would mention that the Z80(8088) and 68000 aren't as slow as they might seem if one looks only at the clock frequency. Both of these processors use multiple clock cycles to interface to the bus. For instance a Z80 uses four clock cycles per machine cycle when reading instructions, so it's really only running at a 1MHz rate, the same as the 6502. The 68000 uses four clock cycles minimum per bus cycle (reading instructions) while running at 8MHz so it's really only running at a 2MHz instruction fetch rate. It's not really the instruction set that slows things down, but the implementation (bus interface). There are a couple of implementations of the 68000 done in an FPGA for instance that gain back performance by using a simpler single clock bus cycle. These cores get a 4x speedup effectively. Later versions of the 68x series shortened the bus interface to three cycles and gained 25% in performance.

_________________
http://www.finitron.ca

Same thing is true of Z80 on FPGA. Actually, I think it's also true of commodity Z80 these days. For old-school comparisons, I can think of two fair ways to compare
- the fastest part you can reasonably buy
- a part running with memory of a reasonable speed

For newer comparisons, probably a benchmark is the only way, as the CPI (clocks per instruction) will vary between implementations.

It might be worth noting that the original design goals of the ARM led to a 32-bit wide memory and maximum use of paged mode accesses, to get best performance without the benefit of cache (which would have been too expensive).

I wonder why it used 4 cycles per memory access. 2 cycles is common because of adress and data multiplexing on the chip, but 4?

I think in fact it's sometimes 3 and sometimes 4. It allows for refresh in the 4-cycle case but it turns out the timing is tighter in the 3-cycle case. See
http://www.piclist.com/techref/mem/dram/slide4.html

A possible reason for the design choice is that the designers could see ways to make the chip clock faster than currently available memory. Famously, the Z80 has only a 4-bit ALU which therefore needs two ticks to perform a byte wide operation. So that will save some transistors - it's already a big chip so that helps. (The designers also wanted to avoid patent trouble with Intel, so being different was a virtue.)