View Full Version : Assembly Variable Unable to Increment

02-07-2007, 12:54 AM
Assembly Experts:

I am stumped again. This time by why I cannot properly increment a variable except in very special circumstances. It the code below, there is a variable "t2" that is incremented and tested. When it gets to 5 the program goes into an endless loop. (Along the way t2 is printed out so I can see what is happening.) The code below works as expected: it loops through Main_Loop 5 times and stops.

BUT, if the "mov t2, #0" line is put back in at the top of the program, t2 never gets past 1, and the program stays in Main_loop instead of falling out into the test_5 loop.

My question is: Why does it make a difference whether or not the "mov t2, #0" is used???

For reference, I also tried it with t2 declared with the "res" command, and get the same thing. Also for reference in the code below, DVALID is a signal line from an A-D part, that goes high at 512 Hz.


Jim C

entry org
' mov t2, #0
Main_Loop test DVALID, ina wz
if_nz jmp Main_Loop ' if Test zero, keep looping
add t2, #1
cmp t2, #5 wc
if_c jmp #Main_Loop

test_5 nop
jmp #test_5
t2 long 0

't2 res 1

02-07-2007, 01:09 AM
You just made a very simple mistake.

you did "entry org"
where you should be doing

entry ...

The weird org causes your jumps to be offset in an unforunate manner, which causes the JMP mainloop thing to branch back to the mov
instruction rather than the test one.

02-07-2007, 02:07 AM

Thanks for your idea. I made the change you suggested, but unfortunately, the problem persists. Below is code that does not work unless the "mov t2, #0" line is commented out. (See the first post in this thread for full explanation of problem)

Any other possibilities you can think of?

Jim C

entry mov flag_addr, par
or outa, txmask
or outa, DXMIT
andn outa, DCLK
or dira, PortBits
mov t3, #20
mov t2, #0

02-07-2007, 02:13 AM
THis would be much easier to debug if I had the full dump. Chances are, you're some how clobbering the DVALID value by writting to the t2 value. Are you 100% sure all your RES commands are located at the end of the assembly block?

02-07-2007, 04:37 AM

Attached is the whole file. It may be a little confusing because it fits into a larger program that calls it.

There is really no way for another cog to be stepping on t2 as far as I can tell. But there may be something in the attached program that I am missing.


Jim C

Mike Green
02-07-2007, 12:06 PM
I can't see what the problem is. I followed the code down to Main_output and can't see any thing that would explain it. It gets kind of hard to follow beyond that.

02-07-2007, 09:30 PM
I'll see if I can simplify things, and still get the problem to occur.


02-08-2007, 05:04 AM

OK. After much work, I have condensed the problem into something easier to digest. It's the same question as noted above, only the code has been shrunken greatly.

Start in the object Test_2. In that, you will notice a variable t22. This variable is correctly incremented only you do not include the "MOV T22, #0" statement at the top of the object. In that case, the output is 1 2 3 4 . If this statement is included, the output shows 0 1 2 0 1 2 0 1 2 0 1 2........... So the question is, how does including the MOV statement screw up the incrementing of T22?

There is a "clocks" object also required to create this wierd behavior. It creates a signal of approx 1 Khz, and the Test_2 object waits for this signal before it increments T22.

Any ideas are welcome.

Jim C

Mike Green
02-08-2007, 10:14 AM
I suspect the "clocks" object will have something to do with this. (I haven't looked at it yet.) I suspect also that substituting any other instruction for the MOV T22,#0 (like a NOP) will also cause the problematic behavior because the issue is the time relationship between the two cogs which is dependent on the number of instructions from the entry point to Main_Loop, not what kind of instruction is used. Given that one cog cannot directly affect the memory of another cog and I see nothing in this code that would "stomp" on the value in T22, that is the only conclusion I can come to. Your "transmit" routine has a weird wait loop (:bit and :wait) that's a bit too complicated for my befuddled mind to grasp without a bit more explanation, particularly the use of a signed compare and adding in "bitticks".

Mike Green
02-08-2007, 10:33 AM
I don't see anything obvious in "clocks". Do try putting a "NOP" instead of the "MOV T22,#0".