Quick Version: How (if possible) can I tell if an assembly instruction will access unaligned memory on a Rabbit 6000, and thus correctly determine the number of clocks an ISR will take up.
Details:
If you look at the cycle requirements for the various assembly instructions which can be used in Dynamic C, you’ll see that unaligned access can nearly double the clocks required for some operations. I’m using 4 serial ports on an RCM6600W, and trying to determine safe speed caps for baud rates. I’d like to push one of the rates up to about 10^6, and assume the others will never go higher than 115200 (while simultaneously using the ethernet and wifi). Depending on whether access is generally aligned or unaligned, I may need to write a custom ISR for the high speed port to shave off some clock cycles, or lower the baud rate for that port.
You can use the “align” assembly directive to tweak the alignment of your assembly routines by inserting NOP opcodes at compile time. Placing an “align 2” before your ISR definition would ensure that it starts at an even address. But it will be extremely tricky to keep track of your alignment as you hand-tune your ISR. Are there instances where executing a NOP before an opcode that prefers alignment is still faster than an unaligned access?
That starting on an even address is what counts as “aligned” is exactly what I needed to know.
LD BCDE,(ps+HL) would be one example. 9 clocks aligned vs 15 unaligned. If I’m understanding correctly and it’s just a single NOP (2 clocks) to align it.
I think the bigger issue is a series of unaligned accesses which could be corrected with a single NOP.
It actually doesn’t sound that hard to keep everything aligned. Just have to weigh if that’s more painful, or if writing an entirely separate ISR for the high speed port is more painful.