Assembly CALL strange behaviour

Wurlitzer

 RankLoop
              add RankCounter, #1
              mov testloopcounter, RankCounter
              call #testloop 
              cmp RankCounter, #16 wc,wz, nr
              if_a jmp #MainLoop                'If greater than 16 jump to main loop                            
              mov NoteCounter, #0             
              mov HUB_KeyAddrPtr, HUB_RAM_StartAddr  'Address in Main Ram for HUB access
              mov tmpKBImage_W1, #0             'Clear the 3 temporary keyboard image words
              mov tmpKBImage_W2, #0
              mov tmpKBImage_W3, #0
              call #GetStopBytes                 'Get 2 Stop bytes for this rank
              
NextNote
              add NoteCounter, #1
              cmp Notecounter, #61 wc,wz, nr
              if_a jmp #RankLoop                'If > 61 then done with this rank go to next rank         
              call #GetKeyByte                  'Get next note image from keyboard
              cmp tmpNote,#0 wz
              if_z jmp #NextNote                'Value = 0 no need to process get next byte
              call #ProcessByte                 'Note value not zero process it
              jmp #NextNote              
             
 GetKeyByte              
              rdbyte tmpNote,HUB_KeyAddrPtr wz      'Get next note data from HUB           
              add HUB_KeyAddrPtr, #1            'Increment HUB address pointer
              add NoteCounter, #1               'Increment Note Counter
 GetKeyByte_Ret
 
 GetStopBytes
              add StopCounter, #1              
              rdbyte tmpStopByte_1,HUB_StopAddrPtr wz             
              add HUB_StopAddrPtr, #1
              add StopCounter, #1
              rdbyte tmpStopByte_2, HUB_StopAddrPtr wz    
 GetStopBytes_Ret
'!!!!!!!!!!!!! PROBLEM SEEMS TO BE BELOW!!!!!!!!!!!!!!
 ProcessByte                                   'For each Keyboard note, check stop words to see if bits must be set
              {cmp tmpStopByte_1, #0 wz
              if_z jmp #Skip_1     
              cmp tmpStopByte_2, #0 wz
              if_z jmp #Skip_1
              nop}
              'mov tmp, #1
               {mov testloopcounter, RankCounter
              call #testloop}
 Skip_1       'nop
 ProcessByte_Ret
     
              jmp #mainloop

The code {snip} above works fine until I place any active code in the "ProcessByte" routine. I have a test loop which flashes an LED X number of times depending upon testloopcounter.
This ProcessByte routine is called 7 lines below the "NextNote" label and the strange thing is even if that "CALL" is remarked out, if any code is contained in ProcessByte, the program immediately jumps to "MainLoop" {not shown}. I have even tried "NOP's". If I remark out all code but leave the labels, the routine is called, returns and the processing is as expected.
The code is obviously underdevelopment but worked as espected until I added the ProcessByte routine.
If I just do a JMP #ProcessByte, and replace the ProcessByte_Ret with a JMP #NextNote it also works fine. I can leave this with the jumps but I have a feeling I will trip over this again.
I believe the code shown should only be doing 1 CALL at a time and no Called routine has JMPs out of their respective routines.
Code size seems to be fine and I do have a FIT statement at the bottom.
It appears that the code is just blowing by the ProcessByte_Ret label and hitting the JMP #MainLoop which I am not expecting it to do.

Any thoughts?

Ale

A ret instruction after the GetStopBytes_Ret, is needed... if not.. it will not return

hippy

Wurlitzer said...

  GetStopBytes_Ret 

'!!!!!!!!!!!!! PROBLEM SEEMS TO BE BELOW!!!!!!!!!!!!!! 

 ProcessByte                                   'For each Keyboard note, ...
 

Shouldn't there be an actual RET instruction after GetStopBytes_Ret ? Currently a call to GetStopBytes stomps on the first instruction of ProcessByte.

The same for GetKeyByte_Ret.

Added : Like what Ale said, who seems to be a faster typist or quicker analyst

Post Edited (hippy) : 12/12/2007 3:20:31 PM GMT

Wurlitzer

Ouch, any body have some aspirin for my headache after I slapped my forehead?

I missed the RET for both previous called routines yet the code SEEMED to work right but bit me on the 3rd call.

Thank guys!

Baggers

You might want to put one on ProcessByte_ret too as you seem to have it doing a jmp #mainloop instead

Phil Pilgrim (PhiPi)

The jmp to #mainloop is harmless, since a return is nothing more than a jump anyway. When Process_Byte is CALLed (using a JMPRET), the source field of the instruction (jmp #) at ProcessByte_ret is replaced with the return address. But, yeah, for the sake of readability, I'd fix it.

-Phil

Nick Mueller

And if you want to risk strange effects, always use global labels/register names.
The default should be locals, but you have to add ":". 8-/


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Baggers

Phil, Yeah, I know the jmp #mainloop is harmless, as it gets overwritten by the call, but like you say, it was for clarity of reading, as his problem was his code wasn't acting the way it should, scrub that, I mean the way he thought it should [noparse]:)[/noparse]