Having a seperate table for every attribute in a slot?

I don't know why I just now thought of this, and it seems other people haven't either. What's the point of having a table with 4 different words (2 bytes) under it instead of having 4 tables with one thing under them? Of course, you'd ask what's the point, but I just thought of how if you're going through a table, instead of doing txa, adc, tax, you'd just do an inx or two. Now, that's a small benefit for kind of being a pain to program with, but I heard that you save a cycle if the index registers are 8 bit instead of 16 bit when using an instruction with them, and that's actually really important, especially considering just about any routine with them is going to be looping repeatedly. Additionally, because there are so few registers in the 65816, you may be able to use the same register in situations that you normally couldn't, as in if the tables you are indexing have different slot sizes but are both being incremented the same number of slots at a time.

You know what's sad? I actually don't know how to get an 8 or 16 bit accumulator with an 8 bit x and y, because I've never done it before. How do you do it?

If you've ever heard people talk about how the 6502 and 65816 are better suited for structs of arrays rather than arrays of structs, this is what they were referring to.

rep #$20 sets A to 16-bit, rep #$10 sets X and Y to 16-bit, rep #$30 sets both (because $20 | $10 == $30). sep will do the opposite.

I guess I'm not as clever as I thought I was...

Wouldn't this go for other processors too though, or do they generally not have a penalty for larger register sizes or have better ways of incrementing them? (I'm pretty sure the 80186 can increment AX, BX, CX, and DX exactly the same so that's not a problem at least. I'm also pretty sure it has a 16 bit data bus too.)

IIRC, indexing on the Z80, for example, favors arrays of structures, instead of structures of arrays like the 6502 does. If I'm not mistaken, indexed operations on the Z80 use 16-bit index registers, and 8-bit offsets as operands. This means you can easily access any byte within a structure of up to 256 bytes anywhere in the 16-bit addressing space just by having the index register point to the start of the structure.

As I understand it: WDC 65816 and Intel 8088 have a penalty for loads and stores of 16-bit registers, as do Zilog Z80 and Sharp "GBZ80" if you consider BC, DE, and HL as 16-bit registers. Motorola 68000 has a penalty for 32-bit ALU operations. 68000, Intel 80386SX, and some ARM7TDMI configurations have a penalty for 32-bit loads and stores.

What tokumaru describes for the Z80 also applies to the 68000, with its 32-bit index registers A0-A7 and 16-bit signed offsets. Does the GBZ80, which lacks IX and IY, even have any indexed modes?

It features an auto-increment/decrement addressing mode for indirect accesses with the HL combined register, which gets you maybe halfway there.

One neat trick GBZ80 coders do is "page" aligning data less than 256 bytes (i.e. starting a table at $xx00) so that an indexed access is just:



Which, depending on where your index is before (register vs immediate), is going to be 20 or 24 cycles and 4 or 5 bytes, versus a more general:



Which is minimum 44 cycles and 10 bytes.

ALIGN 256 is poor man's zero page on the Z80
On 68K you want to Auto Increment though your data because it is free, while all others ops cost you something extra.