Self modifing code mysteriies

RS_Jim

Hi,
I am trying to write a routine in PASM where i want to replace one variable with another and it does not appear to be working correctly.

          call         sensor         'sensor returns x,y vars
          cmp        x,y   wc       ' compare results from two sensor inputs
if_c     replace   y with new    'if y is greater next call returns new with y results 
if_nc   replace    x with new    ' if x is greater next call returns new with x results
...
...
...
test         cmp       old,new      wc
I have tried: 
 if_c        movs     #test,#x
 if_nc      movs     #test,#y

that doesn't seem to work,
any suggestions?
RS_Jim
.
.

Rayman

One thing is that you need at least one statement (such as NOP) between the movs and #test (due to pipelining)...
I'm not sure if your "..." represents more statements or not...

RS_Jim

Yes there is a substantial amount of code between them. I think I may have seen the problem after I posted my thread. I looked at the listing and it appears that I left the "#" off from in front of the test in the movs.
RS_Jim

Dave Hein

You should post the code you're actually using. The code you posted couldn't possibly work. test is a reserved word, so you can't use that for a label. Also, you should not use the "#" before test in your movs instruction. The compiler should have complained about both problems. Finally, the two instructions you said you tried do not match your comments. The if_c condition should use y and the if_nc condition shoud use x. You have it reversed.

RS_Jim

Dave,
you are correct, I should have attached actual code, was just not on computer with the code. Here is the troublesome code.
Msic_timer1_test1 - Archive [Date 2011.03.03 Time 07.08].zip
Thanks for the help
RS_Jim

kuroneko

Probably one of many issues:

mov     tmp1,#rawx
                        wrlong  tmp1,tldpntr
                        mov     tmp1,#rawy
                        [COLOR="red"]wrlong  tmp1,#rawy[/COLOR]

That said, why would you want to write the register index (instead of content) to hub RAM anyway?

ericball

kuroneko wrote: »

Probably one of many issues:

mov     tmp1,#rawx
                        wrlong  tmp1,tldpntr
                        mov     tmp1,#rawy
                        [COLOR="red"]wrlong  tmp1,#rawy[/COLOR]

That said, why would you want to write the register index (instead of content) to hub RAM anyway?

Actually it's worse than that. That writes the value stored in tmp1 to the HUB RAM address equivalent to the register index of rawy. (The way I remember is RD/WRLONG clkfreq,#0 retrieves the current value of CLKFREQ, which is stored at LONG[0].)

RS_Jim

Kuroneko
In regard to the wrlong tmp1,#rawy step which should be with wrlong tmp1,tlmpntr not #rawy,I was only looking to see what was going to be written in the movd instruction. After dbug, that goes away. My purpose that I should have explained in an earlier post, is to take a vertically mounted MD2125 and use it to measure a slow oscillation. The selfmodifing code was to calibrate which axis of the 2125 is going to be affected by the oscillation. I could eliminate that step and just force the use of one of the axis of the chip and force the chips orentation in the final device. I was using the state steps to determin when the md2125 changed direction at one end of the cycle. Forcing the orentation eleminates one counter and one pin from the final device.
RS_Jim

Dave Hein

RS_Jim,

So the relevant code is as follows:

                        cmp     rawx,rawy       wc            'rawy > rawx set carry
        if_c            movd    acc2,#newacc
        if_nc           movd    acc1,#newacc
                        ...

acc1                    mov     rawx,phsa               'move raw phase A and raw phase B values into their 
                        shr     rawx,#4
acc2                    mov     rawy,phsb               'coresponding variables
                        shr     rawy,#4

Is that the code you're concerned about? This code should work fine once you remove the debug code that could be causing some problems. The only concern would be that you are not performing a "shr newacc, #4". If the shift right is important you should add that to your code.

Dave

RS_Jim

Thanks Dave.
I have not had a chance to get back to the code. I thought that I had gotten the SHR newacc into the code before the return. I will delete the debug code and try it again.
RS_Jim