GARTHWILSON wrote:
However, I don't remember ever having to page-align anything in 65c02 anyway. The only use I can think of for page alignment is if something had to be cycle-exact for timing a loop or process, . . .
Reasons I have seen for alignment on (NMOS) 6502:
- Branching in cycle-exact code -- timing only
- Table access in cycle-exact code (outside ZP) -- timing only
- Keeping indexed tables within ZP --a must, not about timing
- Interfacing with other code that assumes whole-page alignment (passing only the page, supplying 00 as the low byte) -- also not optional
- Boundaries relating to ROM or RAM areas... but this is more a matter of locating segments correctly, not about the code requiring alignment for correct execution.
Maybe others, but I think that's about it.
Yes, it's probably not a
great idea to trust a tool to make correct choices relating to cycle-exact code, I'd have to consider that more closely. It is already so detail-oriented that the care around aligning it should be as great. I chose page alignment as an example because it is relatively easy to understand, and was similar to the OP's premise.
GARTHWILSON wrote:
. . . and the extra cycle taken by branching or indexing across a page boundary would be a problem.
Not necessarily... The cycle-exact part could be fully contained in the aligned segment, and the timing to get there is not critical. If the timed code
does (or more aptly
could) cross between the segments, then it depends on the type of alignment... if it is "fit within page", then it's possible the branch timing could vary... but if it is "start of page", then the extra cycle is a given, and is already accounted for.
Login
Register
FAQ
Search
