6502.org

My intent here is *not* to start a processor war, but rather to discuss applying 6502 programming skills to the (8-bit) AVR architecture. Some inexpensive and accessible (DIP-packaged) versions are available which are ideal for simple projects.

The AVR instruction set seems to have been influenced in part by the 6502. Many instruction mnenomics are similar, or even identical. But from a programming standpoint, the AVR has some differences:

1. Half the branch length as 6502 (-64 to +63).
2. No real indexing modes, must use an indirect register. However after initialization, these can auto-increment or auto-decrement.
3. Modified Harvard architecture, separate instructions are required to read from RAM and ROM.
4. A more complete instruction set (but also more to remember).
5. No zero-page, but 32 registers which can be used in a similar fashion.
6. Better support for signed branches and comparisons.

Because the AVR can only act upon registers, a little more strategy is required. I tend to keep a few often-used constants in registers (like 0, 1, 255, etc). The penalty for loading an immediate from memory is only one extra cycle, but judicious use of the register file can make the code faster and more readable.

(Out of time, will try to add more later. I hope this was interesting so far.)

I have some comments. Surprise, all processors work with an ALU and have opcodes for arithmetic and logic operations supported by that ALU. They all need to control program flow. So they have conditional branches, jumps, subroutine calls and returns. I can't see anything 6502 specific in the AVR instruction set but agree, that they have common roots with all central processing units ever designed. The flash ROM is addressed as 16-bit words. So the actual branch range in bytes is the same. Only load and store is supported, no ALU ops. IO registers have their own IN, OUT, SBI, CBI, SBIS & SBIC instructions, but are also mapped together with GPRs and RAM and can be reached by load and store to and from the RAM address space.. More important: You cannot execute instructions from RAM! Again, they have an ALU with similar capabilities. However, Atmel chose to supply redundant mnemonics for the same machine operation. For example: ORI is also SBR (set bits in register), CLR is an EOR self, status bits can be set and branched on by bit # or function...
Immediate ops have their own mnemonic instead of an operand modifier (#). They occupy most of the 16-bit instructions: immediate operand = 8 bits, 16 registers addressable = 4 bits and of the remaining 4 bits for the ALU operation 5 of the 16 codes (ANDI/CBR, CPI, LDI, ORI/SBR, SUBI) are used. No room is left for EORI or ADDI. They are true accumulators and support all ALU operations. Most ops accu to accu and immediate to accu take only 1 cycle!

It looks like the 6502 has more in common with the STM8 CPU, including an accumulator and X/Y registers. May be a fun processor for those familiar with 6502.

http://www.st.com/st-web-ui/static/acti ... 161709.pdf

This was probably a half-baked idea for a thread, my apologies.

The point I was trying to make was that my experience with the 6502 transferred over to this processor very well, because the syntax was similar enough and easy to remember.

A friend gave me an STM8 dev board years ago but I never got around to learning it. Will have to do that soon.

I want to second the ST7/8 similarities to the 6502
as the chip design is licensable as an IP core, you can get lots of configurations of 65xx series/family chips in different combinations that appear as other chips. once you change a few things, its harder to see the resemblance.

one thing that is kinda unique about 65xx vs 'a lot of ' other architectures, is you dont have a bunch of user definable general purpose registers. The 6502 is more of a 'stack machine' than a 'register processor' the way the AVR or 8041/8051 are. $0.02