to make an assembly routine clearer to read, I want to indicate which of the 2 dptrs are used in each instance. One is fetch, another is store. So, to achieve that, I insert the following:
fptr equ dptr sptr equ dptr
movx a,@fptr mov r7,a inc fptr inc auxr1 movx a,@sptr orl a,r7 movx @sptr,a inc sptr inc auxr1
"inc dptr" is a unique instruction with its own opcode. EQU lets you set values for an address, which winds up turning into an "inc <addr>" instruction. I expect the assembler is unhappy because the equates don't resolve to an actual address. You can equate symbols to A and R0-R7, but not DPTR for some reason. No doubt DPTR's 16-bit width plays into the rationale. The AX51 asssembler has a "LIT" directive that sounds like what you might want: literal text substitution of short strings rather than blocks of code, more like the C #define macro. fptr LIT 'dptr' sptr LIT 'dptr'
"The AX51 asssembler has a "LIT" directive that sounds like what you might want: literal text substitution of short strings rather than blocks of code, more like the C #define macro." Doesn't AX51 handle C-like #define macros? I seem to recall reading about that facility in the manual. Anyway, if it doesn't or if like me, you use A51 (w/o the 'X'), there are a number of "standalone" preprocessors that would do the trick.
Also the current A51 release handles C Macro definitions.
If you want to improve on this, I think what you really need would be a set of *four* macros:
RDP0 WDP0 RDP1 WDP1
TO_DPTR a
inc DPS
dec DPS
If you want to improve on this, I think what you really need would be a set of *four* macros: I specifically stated that that was not what I were looking for. Using 4 macros will not give the ability to do a global search on the use of one of the dptrs. Erik
Using 4 macros will not give the ability to do a global search on the use of one of the dptrs. You were talking about a different type of "clarity" than I was, then. Anyway, I don't think I see the relevance. Would you insist on being able to do a global search for all references to r7 or the accu, too, then? Values in DPTR don't usually survive any long time before the same DPTR is needed for something else. Global searches thus won't be very useful, IMHO. Search for the (hopefully) named constants you load into those DPTRs, and adhere to a rigid comment convention that has every routine document all assumptions about main scratch register contents it makes, including any DPTRs it uses.
"Also the current A51 release handles C Macro definitions." Excellent! That does what the OP asked for. That'll also take one source translation step out of my builds.
Would you insist on being able to do a global search for all references to r7 or the accu, too, then? yes, within a subroutine a list of r7 uses very often pinpoint the troublespot. Values in DPTR don't usually survive any long time before the same DPTR is needed for something else. Global searches thus won't be very useful, With a dual dptr, I have a 2000 line module in assembler where the only change of the dptr is flipping AUXR1. rigid comment convention that has every routine document all assumptions about main scratch register contents it makes, including any DPTRs it uses. That's plain ol' standard. The problem is not between routines, it is within a routine. Erik
I wonder why you would call a search within a subroutine a global one. To me, the latter would mean a project-wide search over all source files. With a dual dptr, I have a 2000 line module in assembler where the only change of the dptr is flipping AUXR1. You should consider yourself a lucky person, then. More often than not, I have to juggle around with about 4 pointers... Even so, I really don't see what you're trying to achieve that a 4-macro (or maybe two-macros-with-parameters) solutions can't handle elegantly. A macro that actually checks/sets AUXR is certainly better than your proposal, which only documents which of the two DPTRs a given instruction is meant to use, but doesn't actually ensure that that's the one it does use. I.e. your sptr/fptr idea may well make things worse instead of better by spreading a false impression. If you want more mnemonic meanings, you could always call them R_FPTR and W_FPTR and so on, too.