FSR Problem

[reash]

Hello.

Anyone have any idea why I would get this in the disassembly listing?

[Ttelmah]

Remember the FSR, also needs the IRP bit set to give a 'full' address.
PADDRESS is an INT16 (hopefully, it _needs_ to be, since the combination of FSR, plus IRP, uses 9bits), so it copies the low byte into the FSR, then takes bit0 of the high byte, and copies this to the IRP (bit 7 of the status register).

The compiler is doing exactly what is needed to use the FSR.

Have a look at figure 2.8 in the data sheet, which shows how the 9bit memory address is constructed for direct addressing, and when using the FSR.

Best Wishes

[reash]

Yes, I know indirect addressing uses both the FSR and the IRP bit. But I didn't think it would _automatically_ try to use anything for the IRP. PADDRESS is just an INT8. The compiler should not automatically try to use the adjacent byte to find the IRP bit. If you want to change the IRP bit, that should be done manually. You shouldn't have to make an INT16 just for the sake of the IRP bit. Regardless, my solution was just to force the IRP bit back to 0 in the following instruction. After all, when writing this code directly in assembly, you would write to the FSR and IRP directly. I was just curious as to why they would assume the next byte would contain the IRP bit, especially when my variable 'PADDRESS' was already defined as INT8. Very unexpected.

[Ttelmah]

You can.
If you just declare the FSR as a #byte but use a different name, you can write the byte to it without touching the IRP.
CCS treats FSR as a reserved word, for the _entire_ register.
So: