6502.org

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/viewto ... =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?

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 ... ead=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...

(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.

As Tor said, yes, for realtime applications it's critical.  I've run over 100,000 interrupts per second on a 5MHz 65c02, up to 140,000, IIRC, although it's seldom more than 24,000.  One thing I've done many times is sampling audio based on interrupts from a 65c22 timer.  It's not just a matter of being able to do it quickly enough.  The accuracy of the timing affects the noise and distortion, as Ed mentioned.  The instruction that's executing when the interrupt hits is allowed to finish, and there's a couple of cycles' time of RMS jitter.  I have a discussion of it at http://wilsonminesco.com/6502primer/potpourri.html#JIT .


That comes from Jack Crenshaw, an embedded-systems engineer who wrote regularly in Embedded Systems Programming magazine, who said in the 9/98 issue that he still couldn't figure out why, in BASIC benchmark after benchmark, the 6502 could outperform the Z80 which had more and bigger registers, a seemingly a more powerful instruction set, and ran at higher clock rates.


Forth always handles cells of 16 bits.  Data are passed on a data stack which is separate from the return (hardware) stack.  This solves various problems, and has several advantages over trying to pass data on the return stack.  The data stack typically goes in ZP (or DP on the '816).  Yes, you could have 8-bit cells when you don't need 16, but it would be a nightmare to try to navigate a mix of cells sizes on the data stack.  So it's basically all 16-bit gulps, which the '816 handles far more efficiently.  From an earlier post:

• • Quote:

    Could you say which aspects of the 65816 give you that advantage?
    It's primarily that the '816 is so much more efficient at handling the 16-bit cells than the '02 which has to take 8 bits at a time and increment addresses or indexes in between and such.  Here's the simple example of @ (pronounced "fetch"), which takes a 16-bit address placed on the top of the data stack and replaces it with the 16-bit contents of that address.
    
    First for 6502:

    Code: Select all

           LDA  (0,X)
           PHA
           INC  0,X
           BNE  fet1
           INC  1,X
    fet1:  LDA  (0,X)
           JMP  PUT
    ; and elsewhere, PUT which is used in so many places is:
    PUT:   STA  1,X
           PLA
           STA  0,X

    For the '816, the whole thing is only:

    Code: Select all

           LDA  (0,X)
           STA  0,X         ; For the '816, PUT is only one 2-byte instruction anyway, so there's no sense in jumping to it.
    

    @ was given such a short name because it's one of the things used most.  You can see the difference in the code length, 2 instructions versus 10.

So although the '816 may only give a 50% improvement in performance for certain general-purpose assembly-language applications, the difference is much larger in Forth, and I suspect is a lot of other HLLs.


True, but then you won't need the the hardware instructions.  The tables additionally cover several things that would take a lot of MUL's and DIV's to calculate though.


My tables (linked earlier) include logs too, in various forms, to get the desired accuracy over a wider range.


Perhaps SWN was one of the things Chuck and Bill considered when designing the '02 and decided it wouldn't get used enough to be worth the silicon real estate.  Although I have wished for it, or for an LSR4, it's clear that they did a good job in deciding what to put there, and Bill in the later 65c02 and '816.  [Edit, later:  I posted a SWN routine that takes only 8 bytes and 12 clocks, at http://6502.org/source/general/SWN.html .]


The addressing mode is a good one.  The problem is that in the NMOS 6502, it doesn't work right if the low byte of the operand if FF.  As BDD said, that, and all NMOS bugs, were fixed in the CMOS version.

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

Again nothing new here for the forum veterans, but I'll pound this out anyway.  Hopefully I can make it somewhat concise.

What I should have added above is that one of the reasons the '816 performs so much better than the '02 in Forth is that it makes it practical to write more of the system "words" in assembly, rather than defining so many of them in terms of other words.  (Everything in Forth is a "word," whether it's a subroutine, a variable (because there's code to put its address on the data stack), a constant, array, your top-level main program, whatever.)  A word written in assembly is called a "primitive," or "code definition."  One written in terms of other Forth words is called a "secondary," or "colon definition" (because the colon starts a word definition and turns on the compiler).

On the '02, it simply takes too much program memory to write hundreds of words as primitives.  It cannot handle 16 bits at once, so things need to be pieced together using more assembly-language instructions, making the primitive take more program memory, often more than you can justify, so you limit the primitives to the lowest-level stuff.

Simplifying it almost to the point of lying, compiled code (for secondaries) is usually a list of addresses of other routines.  For the 65 family, these come typically in byte pairs, ie, 16-bit addresses.  There's an inner "loop" (not really a "loop") that handles these addresses and sends the program pointer to the right code for each routine.  It's called NEXT.  NEXT has several instruction in it, so yes, it takes time.  (Nested definitions, using the words nest and unnest, add further overhead.)  If you can write a word as a primitive, it will avoid running NEXT lots of times in the process of executing that word (and maybe nest and unnest too).

My experience on the '816 was that when I wrote hundreds of words, I found that when they're re-written as primitives, they not only executed a lot faster (of course), but in many cases even took less memory than the normal secondary version, meaning that the '816 wiped out the the 6502's prohibitive program memory penalty, now justifying using the faster method.  In many cases they were even easier to write.

Another factor:  When you take a word that is normally written as a secondary, and re-write it as a primitive, there are often some stack gymnastics that can be eliminated, further speeding things up.

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.

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.)