ASM Code - this is weird...

CannibalRobotics

OK, I'm up to my chin in my first assembly language project. I'm running into a weird problem. I have seen this in the 8085·world but I don't know if my diagnosis would apply here.
Situation: I've got two blocks of code, "transmit" and "receive". Both work great and have been extensively tested.
Now I'm trying to call them alternately so I set up a call loop:

MainLoop··············· CALL·· #transmit
······················· CALL···#receive
······························ ' little bit of code
······························ ' ...
······························ '
······················· JMP··· #MainLoop

transmit··············· CALL·· TxON
······························ ' lots of code
·······························' ...
······························ '
transmit_ret
······················· ret

receive················ CALL·· RxON
······························ ' lots of code
······························ ' ...
······························ '
receive_ret
······················· ret

This loops in MainLoop and executes the transmit segment completely then·the very top CALL in the receive routine (RxON) which turns on the reciever. The scope verifies the receiver is getting turned on.·The program·then jumps back to the very top of the MainLoop.
If I restructure the program to tell transmit to jump to the top of receive then vice versa, it works.

MainLoop··············· NOP
MainLoopT·············· JMP···· #transmit
MainLoopR·············· JMP···· #receive
······················· JMP···· #MainLoop
·
transmit··············· CALL··· TxON
······························· ' lots of code
······························ ·' ...
······························ ·'
transmit_ret
······················· JMP···· #MainLoopR
·
receive ··············· CALL··· RxON
······························· ' lots of code
······························· ' ...
································'
receive_ret
·········· JMP··· #MainLoopT


The second layout is unaccepateble as I need to do some bit setting between transmit and recieve and the CALLs to them will need to be conditional. Anyway, the problem seems to lie in the CALL statements - it is as if the return address is not getting pushed properly onto the pointer stack.

Is there some limit on how many calls can be nested in an assembly language program?
When compiling, where is the·stack pointer and how do I know if I have·left enough space to push·nested call return addresses 3 or 4 deep?
In the 8085 world one can use POP PSW to look at the processor status and pointer but I don't know how to proceed on debugging this one.
Any suggestions?
Thanks,
Jim-

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent, only $1.
Send cash and signature to CannibalRobotics.

BradC

mmmm. There is no stack with the cog. The act of the call stores the return address at the _ret jmp site. Outwardly there is nothing obviously wrong with your code, but be mindful as there is no stack that call/ret combinations are NOT re-entrant. You've omitted a lot of code (' lots of code) so we don't _really_ know what goes on behind the scenes there.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

Ale

The call has no '#'... is that intentional ?

CannibalRobotics

If you don't put it in there the compiler kicks it out and says somthings like "Expected a '#'".

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent, only $1.
Send cash and signature to CannibalRobotics.

CannibalRobotics

Brad, that finally·explains the necessity for the "_ret" syntax. The CALLs are not reentrant but they are nested something like this. Is the _ret address permanently·set at compile or does it get adjusted with each CALL

Main
········· CALL #A
········· JMP·· #Main
A
········· CALL #B
A_ret···· ret

B
········· CALL #C
B_ret·····ret

C
C_ret···· ret

I know not posting the code is problematic but it's on my shop machine and I'm at home today.
Jim-


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent, only $1.
Send cash and signature to CannibalRobotics.

BradC

No, that should work. The calls are set at runtime. The call instruction stores PC+1 at the _ret address.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

CannibalRobotics

Ah HA!
The receive_ret instruction is the problem.
I've been looking at as just another label and I was doing some house cleaning before departing the routine. ie:

receive_ret·········MOV···· ComState,#1··· ' Set to transmit
····················ret··················· ' Done with recieve

This would put the address in the wrong place and cause all sorts of weird behaviors.

Thanks,

Jim-

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent, only $1.
Send cash and signature to CannibalRobotics.

BradC

I love it when a plan comes together.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.