Although the 8080 and Z80 don't care about alignment, a compiler that targets the 8080 could benefit somewhat from knowing that pointers to 16-bit and 32-bit objects will be aligned. For example, consider the code necessary to process *p += 1;
if p
is an int*
. If p
is known to be aligned, a compiler could generate [Z80 opcodes shown]
ld hl,(p)
inc (hl)
jnz noHighByte
inc l
inc (hl)
noHighByte:
If a compiler didn't know that p will be 16-bit aligned, it would need to generate an "inc hl" instruction instead of "inc l", which would take an extra two cycles to execute. The extra cost is small enough that none of the 8080/Z80 compilers I've seen made any effort to avoid it, but if a language required that objects be aligned in that fashion it could have offered some benefits.
Interestingly, the benefits would be even larger if small arrays could be guaranteed not to straddle page boundaries, but languages don't offer ways of specifying such constraints. If, e.g., one has a pointer to a char[16];
which is known to be 16-byte aligned, evaluation of p[i]++
could be:
ld hl,(p)
ld a,(i)
add a,l
ld l,a
inc (hl)
instead of something like either:
ld hl,(p)
ld a,(i)
ld e,a
ld d,0
add de,hl
inc (hl)
or
ld hl,(p)
ld a,(i)
add a,l
ld l,a
jnc noCarry
inc h
noCarry:
inc (hl)
with the latter version being bigger, but leaving DE unaffected. Note that the last version is bigger than the middle one, but faster, since "ADD HL,DE" is a very slow instruction.
In order to exploit things like the latter speed up, a compiler would have to know that indexing p
by i
wouldn't cross a page boundary, and no languages I know of would generally provide any way of telling a compiler that.