DPTR Auto Toggle option in UPSD 3354

i will answer the question bcoz i do it b4 and i know the right answer. and the other people will sometime give a bad answer. i got good grade for my one in the last test.

yes. it is posible. use assembly for the isr.
with the c51 stuff c code for interrupts is for whimps. and it is very badly in efficient.

Ok, I use inline assebly in "c code". But this required "Generate Assembler SRC file" and assembly it. Make algorithm dont't work effective (it translate code every time is executing) and debugger can't view structured data in this moment :-(
I dont't think that efficiency of "c code" is much more worse that ASM. Compiler produce quite optimized code and some extra instruction is not important on this quite fast MCU, I think. But this depends on aplications.

why use inline assemlbler??? a real porgrammer uses assembler and links it so no need to src!!!!

this anser got me 98% in my task :)))))

Parat Matfakamta's solution is correct - whether or not you agree with his/her opinions about "real programmers" and "wimps"

Alternatively, you could write an ISR "wrapper" in assembler, and have that call a 'C' function to do the main "body" of the interrupt handling...

mrs neils answer is not to bad but it is only 89% right.

Mrs Neils would probably prefer to be called Mr Neil :p

That's okay. We're all about welcoming diversity here. If Andy wants to be Mrs. Neils in his off hours, that's fine with me.

Keep in mind that the compiler doesn't generate code to take advantage of dual DPTRs (auto-increment or not). The libraries supplied with the compiler do use dual DTPRs in functions such as memcpy(). I'd expect that a library written just for this part would take advantage of the auto-increment feature. A more generic library might have to settle for the "inc dps" method.

(Perhaps it's also worth mentioning that dual DPTRs don't lend much advantage in most situations, which is probably one reason why the compiler doesn't use them. For most of the generated C code, it's about as easy to reload the DPTR as to switch to an alternate -- and if you have more than three variables, you'll have to reload some DPTR most of the time anyway. The dual DPTRs come in handy when the code has to deal with exactly two buffers at once. memcpy() is a great example. For most other code it doesn't matter. But where you can get some performance benefit, you'll need to resort to assembler to write your own routines to use the dual DPTRs.)

Would you care to clarify the other 11% ?

the method of calcerlating marks is very described in the rukles. it is includes perceeved understanding and interest in her subject. and preveous answers.
if the mark is dispeuted she can appeal. but mark can go down or up!
you wnat to go?

Perhaps it's also worth mentioning that dual DPTRs don't lend much advantage in most situations

maybe 'most', but the throughput advantage for a (lenghty) XDATA to XDATA move is enormous.

Erik

maybe 'most', but the throughput advantage for a (lenghty) XDATA to XDATA move is enormous.

Which of course is exactly why memcpy() is implemented using this feature, in the dedicated Keil runtime libraries for architectures that support it. By extension, that also covers the implied memcpy()s in struct assignments.

But with that base covered, there really isn't much gain left to be had. There is the occasional situation where you're juggling just enough objects that not needing to re-load DPTR all the time actually helps. Been there, done that (in asm, though), on a DS80C390 with 24-bit DPTRs. The difference between flipping DPS and saving/restoring 3 bytes of DPTR would really have hurt.

maybe 'most', but the throughput advantage for a (lenghty) XDATA to XDATA move is enormous.

That's why I said memcpy() is a great example of where the dual DPTRs do come in handy.

Another example might be something like a CRC calculation with a table lookup, where one DPTR can point to the table of pre-calculated partial values, while the other advances through the buffer to be CRC'd.

The extra DPTR is not usually very useful in regular code that mixes accesses to different locals or global tables. MOV DPTR, #data16 is 2 instruction cycles, while the "INC DPS" method for swapping DPTRs is still 1 instruction cycle. It's just about as fast to load the base address of a variable as it is to try to cache it in the other DPTR.

To pay off, you need a routine that very frequently accesses two particular variables, particularly if the pointers retain state by moving through a buffer.

(The CRC example, for instance, isn't as convincing if you're talking about a CRC-32 with a one-byte lookup; that's a 1K table of partial results. So, you'll load the base DPTR, do some math on the index, add it, then fetch the table value with 4 MOVs. Since you change the DPTR, you'll have to reload it. The main advantage to two DPTRS is that you don't have to shuffle the buffer pointer back out. If, on the other hand, your table is small, and you can get away with the MOVC A, @A+DPTR addressing mode, then holding the base table address in the DPTR will pay off even more.)

Thank you for advices. Today I found "C" intrinsic functions :

_push_(DPTC); _push_(DPTM); DPTM=0; DPTC=0;

and

_pop_(DPTM); _pop_(DPTC);

This functions in ISR serve my problem ...