We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm looking to optimize an ISR written in C and wondered why version 6.21 pushes both DPTR when it doesn't use them both?
No, look at your own posting. There is no "MOV DPS,#00H" in the single DPTR case.
Yes I know. I meant in the "use dual dptr" case. Now I see you were talking about the other case. Ok, so you're right about that, and I'm right that there is no reason to push the other dptr in the "use dual" case because it isn't used in the ISR. :)
I aggree that pushing the the 2nd dptr is unneccessary, if you do not use the 2nd dptr. Just as a general comment, Dual DPTR's are very over rated. Unless you move large blocks of data around, I would stick with the single DPTR option.
Well I'm planning on using it, but it seems I'm going to have to use it by dealing with inline assembler. I'm surprized Keil doesn't try to use it more often. In fact, I'm looking at the ASM listing for memcpy and I see something that is mildly disturbing. To switch back and forth between the DPTRs, they are incrementing the DPS (at addr 0x86) repeatedly. In the current revision of silicon, only the LSB is used, but what happens down the road if some of those other bits are used. All this code will just blow up??
I have a good contact at Cypress and he was one of the people that developed the EZUSB 8051 based devices. He told me (for the record): "I believe it's safe, since the "INC DPS" technique is recommended in the Dallas literature (Dallas invented the 4-clock cycle 8051 and added the second data pointer). The Synopsys 8051 core we used in EZ-USB is based on the Dallas architecture." So I guess my fears are put to rest!
I think some variants do have more than 2 DPTRs