Arrays: Difference between revisions

4,759 bytes added ,  1 year ago
→‎{{header|Z80 Assembly}}: talked about alignment
(→‎{{header|Z80 Assembly}}: talked about alignment)
Line 8,546:
 
The main takeaway from all this is that arrays are handled the same as any other type of memory, and have no "special" syntax, apart from the boilerplate pointer arithmetic of <code>*array = *array + (desired_row_number*row_length*bytes_per_element) + (desired_column_number*bytes_per_element)</code>. This is the case for most assembly languages, even though the methods of offsetting a pointer may vary.
 
==Array Alignment==
One very important topic for arrays in Z80 Assembly is alignment. If you need fast access to the data in an array, you can more than triple your lookup speed by aligning the table ahead of time. If an array of 8-bit data is placed so that its base address ends in 00, you really only need to load half the pointer to the table into the "high register" (B, D, H, IXH, or IYH) and the desired index into the corresponding "low register." Using an <code>org</code> or <code>align</code> directive is the easiest way to accomplish this task. Aligned tables are very important in Z80 Assembly, more so than in other assembly languages, since Z80's index registers are, for a lack of a better term, underwhelming at best. Not only are they slow, you are limited to using constant offsets only (unless you use self-modifying code) and are also signed offsets meaning that you can't index an array longer than 128 bytes without doing additional pointer arithmetic. Having indexing limitations is not unusual for most CPUs but the Z80 is probably one of the worst at it. Thankfully, table alignment can solve nearly all those problems (assuming you have enough padding to spare.)
 
In the example below, we wish to load the 13th (zero-indexed) element from the array MyTable.
 
<lang z80>LD H,>MyTable ;works out to be LD h,4 thanks to our alignment below.
;>LABEL means "the high byte of the address represented by LABEL
LD L,13 ;this was a lot faster than doing LD HL,&0400 and adding the desired index later.
LD a,(HL) ;loads 12 into the accumulator.
 
 
org &0400
MyTable: ;thanks to the ORG statement above, this label's address is guaranteed to be &0400
byte 1,2,3,4,5
byte 2,4,6,8,10
byte 3,6,9,12,15
byte 4,8,12,16,20
byte 5,10,15,20,25</lang>
 
But what if you're working with 16-bit data? If you've got bytes to burn, you can separate your data into two "byteplanes" - a pair of tables, one of which contains the low bytes and the other containing the high bytes, both sharing a common index. Using alignment you can guarantee that they are a multiple of &0100 bytes apart, which simplifies the lookup process greatly. You can get away with loading just the high byte of the pointer to the "low table" and incrementing that half of the pointer to get to the high byte, while leaving the index (which is stored in the low half of your pointer register) intact.
 
That might have been a bit confusing, so let's visualize the concept. Here's a practical example of storing a sine wave pattern. Instead of storing 16-bit data together like you normally would:
<lang z80>org &0400
word &8000,&8327,&864e,&8973,&8c98,&8fba,&92da,&95f7
word &9911,&9c27,&9f38,&a244,&a54c,&a84d,&ab48,&ae3c
word &b12a,&b40f,&b6ed,&b9c2,&bc8e,&bf50,&c209,&c4b7
word &c75b,&c9f4,&cc81,&cf02,&d177,&d3e0,&d63b,&d889</lang>
 
You can instead store it like this:
<lang z80>org &0400
byte <&8000,<&8327,<&864e,<&8973,<&8c98,<&8fba,<&92da,<&95f7
byte <&9911,<&9c27,<&9f38,<&a244,<&a54c,<&a84d,<&ab48,<&ae3c
byte <&b12a,<&b40f,<&b6ed,<&b9c2,<&bc8e,<&bf50,<&c209,<&c4b7
byte <&c75b,<&c9f4,<&cc81,<&cf02,<&d177,<&d3e0,<&d63b,<&d889
org &0500
byte >&8000,>&8327,>&864e,>&8973,>&8c98,>&8fba,>&92da,>&95f7
byte >&9911,>&9c27,>&9f38,>&a244,>&a54c,>&a84d,>&ab48,>&ae3c
byte >&b12a,>&b40f,>&b6ed,>&b9c2,>&bc8e,>&bf50,>&c209,>&c4b7
byte >&c75b,>&c9f4,>&cc81,>&cf02,>&d177,>&d3e0,>&d63b,>&d889</lang>
 
If your assembler is cool like mine is, this will be valid despite looking like I'm trying to declare what is obviously 16-bit data as 8-bit data. Many Z80 assemblers have some sort of "low byte" and "high byte" operator, it might not be the same symbol but most have it. If yours doesn't, I'd recommend using one that does, because it's really necessary for optimizations like these. In addition it makes the code more readable as it communicates to the reader how the data is intended to be interpreted.
 
So let's say we want to read the last entry in "the table".
<lang z80>LD h,&04 ;load high byte of address &0400
LD L,&1F ;desired index
ld a,(hl)
ld c,a
inc h ;LD h,&05. We can keep L the same since the index is the same.
;Effectively we did all the necessary pointer arithmetic for indexing the second table, just with this one instruction!
ld a,(hl) ;now we have the low byte in C and the high byte in A.</lang>
 
That would have taken a lot more instructions had this been a single table of words with more than 128 entries. You'd have to do some bit shifting to offset the pointer to the table by the desired index, and it would have just taken a lot more time. If you're trying to get something done quickly (such as a raster interrupt) you want to spend as little time doing lookups as possible.
 
=={{header|zkl}}==
1,489

edits