ERAM and P2

However, if the compiler generates code using a MOV P2,# followed by a MOVX @R0 this scheme will be screwed up. Is there a way to "tell" the compiler to keep its little fingers off P2 for MOVX.

Uhhh. The Keil C Compiler NEVER changes the value of P2. An effect of the MOVX @R0/R1 instruction is that it obtains the upper address byte from the P2 SFR.

Since the chip you are using has more than 256 bytes of on-chip XDATA (ERAM is what I think Philips calls this) you need to determine if they did anything special to get the upper address byte for MOVX @R0/R1 instructions. I think that they "assume" it is 0 and do not use P2 for that.

If you don't want the compiler to use the MOVX @R0/R1 instructions, don't use the PDATA memory type or COMPACT memory model.

Jon

However, if the compiler generates code using a MOV P2,# followed by a MOVX @R0 this scheme will be screwed up. Is there a way to "tell" the compiler to keep its little fingers off P2 for MOVX.

Uhhh. The Keil C Compiler NEVER changes the value of P2. An effect of the MOVX @R0/R1 instruction is that it obtains the upper address byte from the P2 SFR.

Since the chip you are using has more than 256 bytes of on-chip XDATA (ERAM is what I think Philips calls this) you need to determine if they did anything special to get the upper address byte for MOVX @R0/R1 instructions. I think that they "assume" it is 0 and do not use P2 for that.

If you don't want the compiler to use the MOVX @R0/R1 instructions, don't use the PDATA memory type or COMPACT memory model.

Jon

Jon,
If I understand you correctly, then if I do not use PDATA and use the SMALL memory model, the compiler will NEVER do a MOVX @Ri. Pls confirm

Thanks

Erik

That's right.

"PDATA" could be defined as "memory accessed via MOVX @Ri"

We had similar issues with PDATA on the Triscend E5.

That's exactly right.

Jon