Addressing Modes - What are they worth to you?

[Alarm Siren]

A counterpart to BigEd's Flags - What are they worth to you? thread.

If you could replace any one or two 6502 addressing modes, which two would you replace, what would you replace them with, and why?

I am interested because I'm considering basing a RAMON6 architecture (see RAMON5) on the 6502 instruction set.

For reference, according to the datasheet the addressing modes on the 65C02 are:

1. Absolute a
2. Absolute Indexed Indirect (a,x)
3. Absolute Indexed with X a,x
4. Absolute Indexed with Y a,y
5. Absolute Indirect (a)
6. Accumulator A
7. Immediate #
8. Implied i
9. Program Counter Relative r
10. Stack s
11. Zero Page zp
12. Zero Page Indexed Indirect (zp,x)
13. Zero Page Indexed with X zp,x
14. Zero Page Indexed with Y zp,y
15. Zero Page Indirect (zp)
16. Zero Page Indirect Indexed with Y (zp),y

Additionally, any thoughts on addressing modes which do exist but which you'd like to see extended to extra instructions are also welcome.

---

I'll start the ball rolling, I personally would quite like a JSR (a,x) instruction, as per another topic of mine.

I don't see a great deal of utility to zp,x and zp,y. I'd probably want to replace them with the missing counterparts (zp,y) and (zp),x. Or maybe a couple of stack relative modes.

[BigEd]

I would think ABS,Y is not terribly essential, as we have ABS,X

On the other hand, stack-relative mode, as seen on the '816, is regarded fondly by people who like to put data on the stack.

[BigDumbDinosaur]

Alarm Siren wrote:

A counterpart to BigEd's Flags - What are they worth to you? thread.

If you could replace any one or two 6502 addressing modes, which two would you replace, what would you replace them with, and why?...I'll start the ball rolling, I personally would quite like a JSR (a,x) instruction, as per another topic of mine.

The 65C816 has JSR (<addr>,X).

Quote:

I don't see a great deal of utility to zp,x and zp,y.

I use both of those all the time, although <dp>,X works with more instructions.

BigEd wrote:

I would think ABS,Y is not terribly essential, as we have ABS,X.

I use <addr>,Y a lot. In fact, it's real handy for loading an index from a table into the X-register.

Quote:

On the other hand, stack-relative mode, as seen on the '816, is regarded fondly by people who like to put data on the stack.

One of the most useful addressing modes on the '816, as it opens a whole world of programming possibilities that are all but out of reach with the 65C02.

[barrym95838]

I have been doing a lot of test-coding on my 65m32, and have found that I am comfortable with just four addressing modes: literal, direct, direct with post-increment, and direct with pre-decrement. The twist is that all four are "indexed", even the literal mode. Implied is not necessary, and indirect is one (at most) extra instruction.

Code: Select all

    ady  #30,y          \ double y and add 30
    lda  table,y        \ load indexed value from table
    sty  0,-u           \ save y on user stack
    ldn  0,s+           \ restore instruction pointer from system stack (aka RTS)

This limited (but still very flexible) repertoire is most useful if the system stack pointer and instruction pointer are exposed to the programmer as "regular" registers, a la PDP-11.

Mike B.

[Edit: I guess if you consider each index register as a separate addressing mode, then I have 32, but I don't find it helpful to look at it that way.]

[BigEd]

That's interesting Mike - I think your addressing modes, other than the extra features of pre/post increment/decrement, are the same as the ones we have in our OPC5ls. Our assembly notation is different, but the idea is that the effective value is the sum of a register and an immediate operand. There's a special case in our machine when the immediate operand is zero, in that it can be omitted. As we have an R0 which always zero, and our R15 is the PC, we can do a surprising amount with this one mode - including subroutine call and return. It very much helps that all registers and the operand are the same size as addresses - 16 bits.

One idea behind our machine is to work towards something which addresses Arlet's challenge - what kind of machine can you build with approximately the same resources as the 6502.

[BigEd]

On Alarm Siren's question for this thread, I think another interesting set of modes are those which allow for three-byte pointers, which makes for a neat extension of 6502 to allow for large data sets. (You need rather more machinery to allow also for large programs, so that's a separate question.)

Acorn's super-secret Turbo machine, Apple's Apple III, and WDC's '816, all have their slightly different approaches to three-byte pointers. There was also at least one photo keyfob which did the same: small program, large data, commercial application, low cost.

[White Flame]

For working with data structures, (zp,x),y would be great. I would sacrifice (zp) to get it. Maybe even (zp,x) but that would reduce general purpose use outside of zp datastructure pointers.

[Dr Jefyll]

BigEd wrote:

[...] all have their slightly different approaches to three-byte pointers.

As has my KK computer. Comparing speed to that of an '816, KK comes in either 1 cycle faster or 2 cycles slower. That's comparing the '816's LDA [dp] to the KK equivalent -- which may be a two-instruction sequence. (To initially load one of the bank registers from z-pg consumes 3 cycles. If you subsequently reuse the same bank value then those 3 cycles can be skipped.)

White Flame wrote:

For working with data structures, (zp,x),y would be great.

Yup. (zp,x),y is just what the doctor ordered when you have a data stack on which resides a pointer to a multi-byte object. Example: (zp,x),y would be perfect for Forth's @ operation.

KK has a weird, kinda-sorta solution that actually works rather well. You code a two-instruction sequence, and the first of those is a special instruction that triggers a hardware assist allowing the 2nd instruction to simply use (zp),y mode. Compared to a stock 65C02 the speedup for @ is 89%.

/plug

[White Flame]

It's not just stacks that would take advantage of (zp,x),y but plain ol' tables of pointers. A common one I've hit is C64 sprite multiplexers, where each sprite has a number of data elements related to it.

For fixed table applications, we can always "unroll" them such that there are a number of tables each holding 1 bytes. Ie, 32 bytes of X coords, 32 bytes of Y coords, 32 bytes of graphic frame values, etc, and you simply index each table pointer by 0-31 and grab a byte instead of having X,Y,frame, X,Y,frame layout. But this does not work very well when data gets more heterogeneous, or is dynamically allocated.

And yeah, probably the most annoying thing about the existing (zp,x) accesses is when it points to further 16-bit pointers or values. It very quickly gets more efficient to copy out to a fixed zp location for (zp),y instead of dealing with the X-indexed pointer location directly.

[Dr Jefyll]

White Flame wrote:

It's not just stacks that would take advantage of (zp,x),y but plain ol' tables of pointers.

Good point.

Quote:

And yeah, probably the most annoying thing about the existing (zp,x) accesses is when it points to further 16-bit pointers or values. It very quickly gets more efficient to copy out to a fixed zp location for (zp),y

Right. (That's what the KK hardware assist does, but with zero overhead.)

[RichTW]

Maybe surprisingly to some people (particularly if you've come from quite Forth-centric development, where I gather it's very useful), I've barely ever used the (ind,X) addressing mode.

I've just rarely found a situation where I need (essentially) an direct indexed array of pointers. I used it once for some sound code (playing music on three channels), but otherwise I nearly always find myself copying LSB/MSB addresses to a single ZP pair, and using (ind),Y instead.

I could've done with STX abs,Y a whole bunch of times though. (I assume the illegal opcode at $9E was supposed to be a STX abs,Y, but it never worked... did anyone ever figure out the problems?)

[MichaelM]

White Flame wrote:

It's not just stacks that would take advantage of (zp,x),y but plain ol' tables of pointers.

Just wondering how many levels of indirection are typically required? If it just a second level, would it best be implemented as ((zp,X),Y) or ((zp,X)),Y?

[GaBuZoMeu]

I would like ((zp),2X),Y.

[BigDumbDinosaur]

RichTW wrote:

Maybe surprisingly to some people (particularly if you've come from quite Forth-centric development, where I gather it's very useful), I've barely ever used the (ind,X) addressing mode.

I've just rarely found a situation where I need (essentially) an direct indexed array of pointers. I used it once for some sound code (playing music on three channels), but otherwise I nearly always find myself copying LSB/MSB addresses to a single ZP pair, and using (ind),Y instead.

I could've done with STX abs,Y a whole bunch of times though. (I assume the illegal opcode at $9E was supposed to be a STX abs,Y, but it never worked... did anyone ever figure out the problems?)

STX <addr>,Y and STY <addr>,X are unsupported operations. I've always thought this to be odd, since LDX <addr>,Y and LDY <addr>,X are supported. However, I can't recall any time recently when I wished I had STX <addr>,Y and STY <addr>,X available to me.

As for (<dp>,X) addressing, I make extensive use of in my POC unit's DUART driver.

[MichaelM]

GaBuZoMeu wrote:

I would like ((zp),2X),Y

I take it that what you'd like to see is double post-indexed indirect with the first look-up using X (2X) and the second using Y. What kind of data structure requires this type of access?

In relation to this new addressing mode, would ((zp),X),Y be okay if X and Y are 16 bits, or BuGaGa bits, wide.

Edit: forgot to remove the factor of two in the addressing mode immediately above.