Searching \ for 'Goto & Call' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=goto+call
Search entire site for: 'Goto & Call'.

Truncated match.
PICList Thread
'Goto & Call'
1999\03\19@230049 by Javier

flavicon
face
Hi
Can somebody tell me when I should use a Call or Goto instruction?? Pro and
Cons??
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
possible??
Thanks for your time
Javier

1999\03\19@234024 by Peter Grey

picon face
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.

Peter
{Quote hidden}

1999\03\20@012450 by Vincent Deno

flavicon
face
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
state).

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.

Regards,

Vincent

> At 12:54 AM
20/03/99 -0300, you wrote: >
{Quote hidden}

--------------
Vincent Deno
Design Engineer
Theta Digital Corp.
http://www.thetadigital.com
spam_OUTdenovjTakeThisOuTspamemail.uc.edu
_____________
| ____   ____ |
|/| | | | | |\|
| | |/| |\| | |
| | | | | | | |
| |_/ | | \_| |
| |   | |   | |
|_/  /___\  \_|

1999\03\20@101442 by Thomas McGahee

flavicon
face
When programming with a processor that allows a reasonable size stack, I prefer
to use
CALLs. But most PICs have a very small stack size and I find I have to be carefu
l
not to exceed it.

For this reason, when working with PICs I have adopted the following rules for
myself:

Whenever a routine will actually "return" to a single, fixed location, use a GOT
O to
access the routine, and use a GOTO to "return" from the routine. Note that you c
an
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
r that
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
cations,
use a CALL to access the routine, and a RETURN instruction to terminate it. It i
s always
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
tually,
it is more like a "goto" address! Here is a short (stupid) example just to show
how
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
ubroutine"
    .....                                         ;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

----------
{Quote hidden}

1999\03\20@201243 by Wagner Lipnharski

picon face
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.

1999\03\21@042759 by paulb

flavicon
face
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
> loop.

 ... Calling *and* returning with a GOTO, that is.
--
 Cheers,
       Paul B.

1999\03\21@171738 by Graeme Smith

flavicon
face
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.)

                               GREY

GRAEME SMITH                         email: .....grysmithKILLspamspam.....freenet.edmonton.ab.ca
YMCA Edmonton

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:

{Quote hidden}

1999\03\23@002201 by Javier

flavicon
face
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
correct!!
I also simulated it and worked Ok, it jumps to the desired label, but in
Practice this doesn4t occur.
Any hints??
Javier


-----Mensaje original-----
De: Peter Grey <EraseMEmartechspam_OUTspamTakeThisOuTOZEMAIL.COM.AU>
Para: PICLISTspamspam_OUTMITVMA.MIT.EDU <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
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.
>
>Peter
>>Hi
>>Can somebody tell me when I should use a Call or Goto instruction?? Pro
and
{Quote hidden}

1999\03\23@003354 by Tony Nixon

flavicon
picon face
Javier wrote:
> 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.


--
Best regards

Tony

PicNPoke - Multimedia 16F84 Beginners PIC Tools.

http://www.picnpoke.com
Email KILLspampicnpokeKILLspamspamcdi.com.au

1999\03\23@012928 by Peter Grey

picon face
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.

Peter

{Quote hidden}

1999\03\23@014634 by Harold Hallikainen

picon face
       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
several times!

Harold


On Sat, 20 Mar 1999 00:54:14 -0300 Javier <RemoveMEgrijalbaspamTakeThisOuTCVTCI.COM.AR> writes:
{Quote hidden}

___________________________________________________________________
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]

1999\03\23@221133 by Javier

flavicon
face
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
works
the other not.It seems that it doesn4t jump to the Tel routine :-((
Thanks for all your time
Javier

#INCLUDE "p16f84.inc"
LIST p=pic16f84
__CONFIG        3FFBH   ;RC,resto OFF



org 0x00
goto START

org 0x04
bank0                       ;Select Bank 0
bcf PORTA,3
BTFSS PORTA,3
GOTO  Telint             ;en"1" o con continuidad
GOTO p2int              ;esta en "0" o sin continuidad

p2int CALL SIGUE      ;vector de Interrupcion del P2
BCF 0BH,1
retfie

Telcoint CALL    L004E
            RETFIE

ORG  0X15
                   ;Choose wich soft to use according to the switch
START bank0   ;Select Bank 0
            bcf PORTA,3
            BTFSS PORTA,3
            CALL Tel  ;en"1" o con continuidad
            GOTO P2   ;Sigue de largo y arranca el P2


P2     bank1    ;Select Bank 1
        CLRF FLAG_DATA
        movlw 0xE8   ;Should be changed
        movwf OPTION_REG
           !
           !  Here you find about 230 lines
           !
;----The other soft---------

Tel     BSF     STATUS,005H     ;A
               CLRWDT
               MOVLW   0E8H
               MOVWF   RTCC
               !
               !Here you find about 150 lines





-----Mensaje original-----
De: Harold Hallikainen <haroldhallikainenEraseMEspam.....JUNO.COM>
Para: EraseMEPICLISTspamMITVMA.MIT.EDU <RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU>
Fecha: Martes 23 de Marzo de 1999 03:44 a.m.
Asunto: Re: Goto & Call


{Quote hidden}

1999\03\26@145812 by John Payson

flavicon
face
|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:

[1] Similar to above...
   Near the start of the code, I'd put

RETURN1J:
       goto    RETURN1

   Then for the call,

       movlw   RETURN1J
       goto    ROUTINE
RETURN1:
       ...

ROUTINE:
       movwf   ReturnAddr
       ...
       movf    ReturnAddr,w
       [clrf    PCLATH] -- If applicable
       movwf   PC

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.

[2] For pseudo-tasking:
   I often like to use a mini pseudo-multitasker like this:

Springboard:
       movwf   PC
DoSomething:
       movf    TaskState,w
       call    Springboard
       movwf   TaskState
       ...

TaskStart:
       ... do some stuff, then
       retlw   $+1
       ... do some more stuff, then
       retlw   $+1
       ... etc.

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
constraints:

[1] The whole thing should fit in a page; if not, use page-zero springboards
   as in the pseudo-return example.

[2] 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
   here...)

[3] If anything changes PCLATH, it must be made to point back at the appro-
   priate page.

[4] 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".

Cute, eh?

1999\03\26@161725 by Scott Dattalo

face
flavicon
face
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:

www.interstice.com/~sdattalo/technical/software/pic/pwm.txt
and
http://www.interstice.com/~sdattalo/technical/software/pic/pwm256.txt

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
- Today
- New search...