This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

clarity of dual dptr code

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

And these lines error out.

and below it could be

 movx a,@fptr
mov r7,a
inc fptr
inc auxr1
movx a,@sptr
orl a,r7
movx @sptr,a
inc sptr
inc auxr1

Obviously I can do two macros FETCH and STORE, That, however would not support the identical name when mov dptr,# is there, and as seen in the above 3 macros (or 4 or 5) would be needed.

Is there a way to do this other than the above?

Erik

PS the actual code is far more complicated than the above example.

Parents
  • If you want to improve on this, I think what you really need would be a set of *four* macros:

    	RDP0
    	WDP0
    	RDP1
    	WDP1

    where each of these either "R"eads or "W"rites DPTR #0 or #1, respectively, and a fifth one

    	TO_DPTR a

    that switches over to use of DPTR #0 or #1 depending on the argument passed.


    The tricky bit is to teach these macros which DPTR is the currently selected one, so they can generate

    	inc DPS
    or
    	dec DPS

    (or what ever your architecture uses to select one DPTR) if and only if they're needed. You'ld need a status variable to control this, and make sure you have a TO_DPTR after every entry point callable from the outside.

    In my experience, this is typically not worth the effort --- just write a comment explaining which DPTR you're actually referring to in a given instruction, and religiously use the distinction between inc DPS and dec DPS to indicate which direction a DPS change is meant to take.

Reply
  • If you want to improve on this, I think what you really need would be a set of *four* macros:

    	RDP0
    	WDP0
    	RDP1
    	WDP1

    where each of these either "R"eads or "W"rites DPTR #0 or #1, respectively, and a fifth one

    	TO_DPTR a

    that switches over to use of DPTR #0 or #1 depending on the argument passed.


    The tricky bit is to teach these macros which DPTR is the currently selected one, so they can generate

    	inc DPS
    or
    	dec DPS

    (or what ever your architecture uses to select one DPTR) if and only if they're needed. You'ld need a status variable to control this, and make sure you have a TO_DPTR after every entry point callable from the outside.

    In my experience, this is typically not worth the effort --- just write a comment explaining which DPTR you're actually referring to in a given instruction, and religiously use the distinction between inc DPS and dec DPS to indicate which direction a DPS change is meant to take.

Children
  • 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.

  • 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.