Having a seperate table for every attribute in a slot?

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Having a seperate table for every attribute in a slot?

Post by Drew Sebastino » Sat Aug 13, 2016 5:58 pm

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? :lol:

Nicole
Posts: 218
Joined: Sun Mar 27, 2016 7:56 pm

Re: Having a seperate table for every attribute in a slot?

Post by Nicole » Sat Aug 13, 2016 6:11 pm

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.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Having a seperate table for every attribute in a slot?

Post by Drew Sebastino » Sat Aug 13, 2016 6:17 pm

Nicole wrote: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.
I guess I'm not as clever as I thought I was... :lol:

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

User avatar
tokumaru
Posts: 11895
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Having a seperate table for every attribute in a slot?

Post by tokumaru » Sat Aug 13, 2016 7:28 pm

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.

tepples
Posts: 22093
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Having a seperate table for every attribute in a slot?

Post by tepples » Sat Aug 13, 2016 7:32 pm

Espozo wrote:penalty for larger register sizes
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?

adam_smasher
Posts: 271
Joined: Sun Mar 27, 2011 10:49 am
Location: Seattle

Re: Having a seperate table for every attribute in a slot?

Post by adam_smasher » Sat Aug 13, 2016 7:51 pm

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:

Code: Select all

  LD H, ArrayAddress >> 8
  LD L, *index*
  LD A, [HL]
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:

Code: Select all

  LD HL, ArrayAddress
  LD A, *index*
  ADD L
  LD L, A
  JR NC, .nc
  INC H
.nc:
  LD A, [HL]
Which is minimum 44 cycles and 10 bytes.

User avatar
TmEE
Posts: 763
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: Having a seperate table for every attribute in a slot?

Post by TmEE » Sun Aug 14, 2016 4:11 am

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

Post Reply