'Goto & Call'
Can somebody tell me when I should use a Call or Goto instruction?? Pro and
I also have a problem that when I use Goto and Call instruction, that
reaches a Routine at the bottom of my code it doesnt work, but works with a
routine at the begining of the code, ?4m really confused.How is this
Thanks for your time
At 12:54 AM 20/03/99 -0300, you wrote:
It sounds as though you are going thru page boundaries with setting the
right page bits (see status word RP0). I use a CALL when I want to use a
routine more than just once. A GOTO I use when I want to go to a different
section of code, usually because of a condition being met or not being met.
|Actually, this is more of a fundamental programming subject, than the
pros/cons of using goto over call (IMHO).
This is my take on it:
CALL should ONLY be used for subroutines. Subroutines do not necessarily
have to be generic math routines or the like. They should simply be parts
of code that execute a given function and return. granted, their
operation could be a little difference depending on passed arguments, but
they still always return.
GOTOs should only be used for program branching (system is in a different
I avoid the use of GOTOs within a CALLed subroutine (other than local
jumps). Obviously, there are exceptions to the rule.
One thing you must keep track of when using CALLs is your stack space.
Depending on the PIC you're using, you may be limited to the number of
nested CALLs. Overflowing the stack is a BAD thing and ususally, the
program will never recover properly.
Just my two cents.
> At 12:54 AM
20/03/99 -0300, you wrote: >
Theta Digital Corp.
| ____ ____ |
|/| | | | | |\|
| | |/| |\| | |
| | | | | | | |
| |_/ | | \_| |
| | | | | |
|_/ /___\ \_|
|When programming with a processor that allows a reasonable size stack, I prefer
CALLs. But most PICs have a very small stack size and I find I have to be carefu
not to exceed it.
For this reason, when working with PICs I have adopted the following rules for
Whenever a routine will actually "return" to a single, fixed location, use a GOT
access the routine, and use a GOTO to "return" from the routine. Note that you c
save two GOTO's by simply coding the routine in-line in the first place. However
it is often useful (for the sake of your sanity) to write some sections of code
this way, as it makes the underlying structure of the main program easier to
follow. This is a matter of personal preference, of course. If you later discove
you need to save a few bytes of code space, then you can always move the
code to in-line form and remove the accompanying GOTOs. But during initial
coding it is very handy to compartmentalize sections of code.
Whenever a routine will need to "return" to one of *several* possible calling lo
use a CALL to access the routine, and a RETURN instruction to terminate it. It i
good programming style to have a comment header at the beginning of a subroutine
that tells what parameters are being passed, whether they are in W or in file
registers, what ACTION is performed by the subroutine, and what return values
there are, and how they are being returned (in W or in file registers).
That being said, there are some sneaky things you can do to create a sort of
subroutine that does not use the usual CALL/RETURN instruction set. To implement
this method requires the use of a file register to hold the "return" address. Ac
it is more like a "goto" address! Here is a short (stupid) example just to show
the method works:
Assume a file register has been assigned the name GOTOHERE
**** "CALLING" routine
movlw RETURNHERE ;set up "return" address
movwf GOTOHERE ;save it in file register
goto PSEUDOSUB ;run "subroutine"
returnhere ;"return" label.
.... ;this is "return" address!
..... ;continue with user program..
--------------- "CALLED" routine
PSEUDOSUB ;label for "subroutine"
..... ;instructions that make up "s
..... ;etc., etc., etc....
movf GOTOHERE,w ;recover "return" vector
movwf PCL ;now it is in the Program Counter
and that's all there is to it, because the PIC will now execute the instruction
pointed to by the contents of PCL!
Hope this helps.
Fr. Tom McGahee
A "goto" is mainly an action caused by a decision.
Kind of: Is this painted? If not, Goto Paint Routine.
A "call" is a temporary subfunction for any routine.
Kind of: Call the Paint Routine - Color Selection Screen.
A very common way to build an easy to understand
programming sequence is build a master loop, with
very few instruction lines, as a dispatcher, checking
parameters and deciding what to do, then calling the
respective routines to do it, and returning to the
start of the master loop.
If you build your programs in a way where you can
easily see where it starts and where it ends, anyone
can understands it, including you two years later.
Wagner Lipnharski wrote:
> build a master loop, with very few instruction lines, as a dispatcher,
> checking parameters and deciding what to do, then calling the
> respective routines to do it, and returning to the start of the master
... Calling *and* returning with a GOTO, that is.
|The main difference between the goto and call instruction is that the call
instruction places the Program counter on the stack.
This has two side effects, it expands the storage requirements for the
stack, and it allows the program to return to the original code the next
statement after the call instruction.
Where possible, I suggest using the GOTO rather than the call, if only
because PIC processors use intentionally under-implimented stacks and can
easily get stack saturation with nested calls.
The goto, because it cannot return, to the original code, requires a
return label to return to...
Which believe it or not allows much more flexibility. But requires more
intelligence at the programmer level, and creates what is affectionately
known as "Spaghetti" Code, code that is virtually impossible to maintain
because it is to involuted for mental tracking.
Most programmers today are taught NOT to use "GOTO" statements in their
code, in order to protect their employers investment in software.
Luckily the PIC's are so small that even with spaghetti code, there is a
small chance you will be able to track down all the involutions of your
code. When, ten years later, after someone else has rewritten it six or
more times, someone asks you why it will no longer work.
That is why you have BOTH goto, and Call statements... and why most
programmers are not happy about the limitations of the 16c5x family...
(along with a few other limitations that are nothing to sneeze at.)
GRAEME SMITH email: freenet.edmonton.ab.cagrysmith
Address has changed with little warning!
(I moved across the hall! :) )
Email will remain constant... at least for now.
On Sat, 20 Mar 1999, Javier wrote:
Thanks to everybody who answered my mail!!
The thing is that I4m using a PIC 16F84 and when using the goto or call
instruction I don4t have to care about the page boundaries, is that
I also simulated it and worked Ok, it jumps to the desired label, but in
Practice this doesn4t occur.
De: Peter Grey <OZEMAIL.COM.AU> martech
Para: MITVMA.MIT.EDU < PICLISTMITVMA.MIT.EDU> PICLIST
Fecha: Sabado 20 de Marzo de 1999 01:37 a.m.
Asunto: Re: Goto & Call
>At 12:54 AM 20/03/99 -0300, you wrote:
>It sounds as though you are going thru page boundaries with setting the
>right page bits (see status word RP0). I use a CALL when I want to use a
>routine more than just once. A GOTO I use when I want to go to a different
>section of code, usually because of a condition being met or not being met.
>>Can somebody tell me when I should use a Call or Goto instruction?? Pro
> The thing is that I4m using a PIC 16F84 and when using the goto or call
That's correct, you do not have to worry about page boundaries for GOTO
and CALL instructions.
You do though, for PCL changes.
PicNPoke - Multimedia 16F84 Beginners PIC Tools.
At 02:01 AM 23/03/99 -0300, you wrote:
You may have to post some of the code so peopel can take a look.
Gotta watch those page bits! Try using lcall (I think that's the
built-in macro for a long call) or lgoto.
Also, on calls, watch out for limited stack depth. It's gotten me
On Sat, 20 Mar 1999 00:54:14 -0300 Javier <CVTCI.COM.AR> writes: grijalba
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]
|But if a I simulate it and works I shoudn4t bother??
Or is it possible that when simulating it doesn4t simulate that precisely??
The code looks like this (see above) I added a small swith to RA3 (this
part of the soft works because I tested with 2 leds) and the two routines
Tel and P2 work !!
The strange is that when I use them together only the one that is first
the other not.It seems that it doesn4t jump to the Tel routine :-((
Thanks for all your time
__CONFIG 3FFBH ;RC,resto OFF
bank0 ;Select Bank 0
GOTO Telint ;en"1" o con continuidad
GOTO p2int ;esta en "0" o sin continuidad
p2int CALL SIGUE ;vector de Interrupcion del P2
Telcoint CALL L004E
;Choose wich soft to use according to the switch
START bank0 ;Select Bank 0
CALL Tel ;en"1" o con continuidad
GOTO P2 ;Sigue de largo y arranca el P2
P2 bank1 ;Select Bank 1
movlw 0xE8 ;Should be changed
! Here you find about 230 lines
;----The other soft---------
Tel BSF STATUS,005H ;A
!Here you find about 150 lines
De: Harold Hallikainen <JUNO.COM> haroldhallikainen
Para: MITVMA.MIT.EDU < PICLISTMITVMA.MIT.EDU> PICLIST
Fecha: Martes 23 de Marzo de 1999 03:44 a.m.
Asunto: Re: Goto & Call
|Assume a file register has been assigned the name GOTOHERE
|**** "CALLING" routine
| movlw RETURNHERE ;set up "return" address
| movwf GOTOHERE ;save it in file register
| goto PSEUDOSUB ;run "subroutine"
|RETURNHERE ;"return" label.
| .... ;this is "return" address!
| ..... ;continue with user program...
|--------------- "CALLED" routine
|PSEUDOSUB ;label for "subroutine"
| ..... ;instructions that make up "subroutine"
| ..... ;etc., etc., etc....
| movf GOTOHERE,w ;recover "return" vector
| movwf PCL ;now it is in the Program Counter
|and that's all there is to it, because the PIC will now execute the |instructio
n pointed to by the contents of PCL!
I use a couple slightly different structures:
 Similar to above...
Near the start of the code, I'd put
Then for the call,
[clrf PCLATH] -- If applicable
This allows for routines to be called from places outside the first 256
bytes and yet still return as they should. Note that I've never had to
use anything like that for the 14-bit parts; only the 2-deep stack of the
12-bit parts is too small for normal CALL/RETURN.
 For pseudo-tasking:
I often like to use a mini pseudo-multitasker like this:
... do some stuff, then
... do some more stuff, then
What is wonderful about this approach is that each call to DoSomething [or
execution of those three statements] will cause a little bit to be done on
my task. The task itself can do whatever it wants subject to only a few
 The whole thing should fit in a page; if not, use page-zero springboards
as in the pseudo-return example.
 If the task makes any CALLS, those calls must return before the task can
yield control of the CPU (note that pseudo-calls as above can be useful
 If anything changes PCLATH, it must be made to point back at the appro-
 A task-yield may be combined with a GOTO by doing an RETLW of the des-
ired location. If my task does an "retlw foo", then when the system
next runs my task it will resume execution at "foo".
On Fri, 26 Mar 1999, John Payson wrote:
> Cute, eh?
Always, John. :)
If you want to see some convoluted code that takes this indirect branching
to an extreme, then check out:
These are all software pwm routines that use state machines along with the
'movwf pcl' trick to determine where the code will execute.
More... (looser matching)
- Last day of these posts
- In 1999
, 2000 only
- New search...