when shd i use a "call" and a "goto"? wh - Electronic Circuits Projects Diagrams Free

picboy · 2nd March 2005, 09:24 PM

Dear all,

when shd i use a "call" and a "goto"? what is the diff?
In what cases shd we use them correctly?

Thanks

dak246 · 2nd March 2005, 09:29 PM

I think the only difference is that "call" loads the return address right when you call it and then goes to the address, while "goto" simply goes to the address.

**Jay.slovak** · 2nd March 2005, 09:32 PM

Yes, Call is used to CALL subroutines, which are ended with RETURN instruction. GOTO will just change PC address and the program will jump to the label you are calling with no return.

Desert Leo · 3rd March 2005, 07:55 AM

"goto" is stupid command. Use "call" instead. This is required fron the "good practice" in programming.

**Nigel Goodwin** · 3rd March 2005, 09:19 AM

Quote:

Originally Posted by Desert Leo

"goto" is stupid command. Use "call" instead. This is required fron the "good practice" in programming.

That only applies to high level languages, in assembler (particularly on a RISC processor like the PIC!) GOTO is one of the most used instructions - you can easily write a program without CALL, there's no way you can write anything meaningful without using GOTO.

But certainly using CALL is important as well, structuring your program as subroutines is very good practice and allows you to reuse many of the subroutines in other programs.

As for the high level languages, their compilers will certainly generate plenty of GOTO instructions, regardless of the processor used.

bmcculla · 4th March 2005, 07:06 PM

In C every if/else and case statement generates a goto (jump) assembly instruction. In case statements the break statement coresponds to a jump/goto instruction. Function calls generate a Call instruction.

The goto instruction is used to direct the flow of the program.

The CALL instruction is used to build sections of code that will get used in more than one place in the code.

BF9000 · 4th March 2005, 08:21 PM

In general, call should be used when performing operations on a set of data, polling inputs, sending a structured set of output data, or performing a routine that controls peripherals. In general, goto should be used to return to the top of a loop and to conditionally skip over sections of code. Each instruction holds 11 bits of the address. When you use call this adress is pushed onto the stack. Remeber it is only 8 words deep so be careful when calling within functions. There must be a return opcode after every subroutine that is called or else the stack will likely overflow. These are just general guidlines and actual use will vary depending on how your program is structured, but this should give you a basic idea.

**Nigel Goodwin** · 5th March 2005, 09:32 AM

Quote:

Originally Posted by bmcculla

In C every if/else and case statement generates a goto (jump) assembly instruction. In case statements the break statement coresponds to a jump/goto instruction. Function calls generate a Call instruction.

The goto instruction is used to direct the flow of the program.

Here's a section of PIC code generated by a C compiler, you will see what I mean about the poor code produced by compilers!. This five goto's in a meaningless row is the worst example, but the code is littered with goto's jumping just to the next line.

Code:

            XORLW   0x32
            BTFSS   STATUS    , Z
            GOTO    Label_0027
            GOTO    Label_0029
Label_0029  GOTO    Duration_32
Label_0027  GOTO    Label_002B
Label_002B  GOTO    Try_Dur_16

Duration_32 MOVLW   0x20

I'm currently 'reverse engineering' the code, to produce a decent assembler version - the assembly code was produced by my WinPicprog disassembler from the HEX file.

samcheetah · 5th March 2005, 04:21 PM

Quote:

Originally Posted by Nigel Goodwin

Here's a section of PIC code generated by a C compiler, you will see what I mean about the poor code produced by compilers!. This five goto's in a meaningless row is the worst example, but the code is littered with goto's jumping just to the next line

which C compiler generated this code????

**Nigel Goodwin** · 5th March 2005, 04:33 PM

Quote:

Originally Posted by samcheetah

Quote:

Originally Posted by Nigel Goodwin

Here's a section of PIC code generated by a C compiler, you will see what I mean about the poor code produced by compilers!. This five goto's in a meaningless row is the worst example, but the code is littered with goto's jumping just to the next line

which C compiler generated this code????

According to the website it came from, it was compiled with HiTech PICC, the site is http://www.beyondlogic.org/pic/ringtones.htm.

samcheetah · 5th March 2005, 06:21 PM

oh so you are working on that ringtone generator which is based on a 16F877

are you going to write a tutorial about this or not????

**Nigel Goodwin** · 5th March 2005, 06:49 PM

Quote:

Originally Posted by samcheetah

oh so you are working on that ringtone generator which is based on a 16F877

are you going to write a tutorial about this or not????

Possibly, at the moment I'm just having fun :lol:

**Nigel Goodwin** · 6th March 2005, 03:36 PM

Following on from the horrible row of goto's in the HEX file I disassembled, I've downloaded the free limited version of the Hi-Tech compiler - PICC Lite.

So I've been doing some experiments with it - if you set 'full optimisation' ON during the compiling process it doesn't produce the nasty multiple goto's. The entire code ends up considerably smaller as well - makes you wonder why all the C generated HEX files I've ever looked at haven't been generated like that?.

I've also compiled the ringtone software for both 18 pin (16F627) and 8 pin (12F629/12F675) - with just very minor changes. This gives a rather useful little 8 pin chip which can play a Nokia monophonic ringtone when you apply power to it! - could make an interesting audible alarm?.

bmcculla · 7th March 2005, 09:53 AM

Turning off the optimisations can make it easier to debug code. Compiler optimisations will also remove software delay loops and rearange sections of code that can make optimising a bit confusing for beginers. Also be careful to use the volatile keyword when nessesary - one of my professors in school spent 4-5 hours trying to debug code that was being optimised out because he forgot to make a variable volatile. The down side to turning off the optimiser is that the compiler generates really bone-headed code.

**Nigel Goodwin** · 7th March 2005, 10:42 AM

Quote:

Originally Posted by bmcculla

Turning off the optimisations can make it easier to debug code. Compiler optimisations will also remove software delay loops and rearange sections of code that can make optimising a bit confusing for beginers. Also be careful to use the volatile keyword when nessesary - one of my professors in school spent 4-5 hours trying to debug code that was being optimised out because he forgot to make a variable volatile. The down side to turning off the optimiser is that the compiler generates really bone-headed code.

Yes, fair enough for debugging, but why release HEX code like that?, there's no need (or use!) for debugging code in the HEX file released to users.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

2nd March 2005, 09:24 PM	#1
picboy	when shd i use a "call" and a "goto"? wh Dear all, when shd i use a "call" and a "goto"? what is the diff? In what cases shd we use them correctly? Thanks

2nd March 2005, 09:29 PM	#2
dak246	I think the only difference is that "call" loads the return address right when you call it and then goes to the address, while "goto" simply goes to the address.

2nd March 2005, 09:32 PM	#3
Jay.slovak	Yes, Call is used to CALL subroutines, which are ended with RETURN instruction. GOTO will just change PC address and the program will jump to the label you are calling with no return. __________________ "I share, thus I am" Jay.slovak Read this! ICD2 Clone Best PIC/DsPIC Bootloader Read my Inchworm ICD2 review!

3rd March 2005, 07:55 AM	#4
Desert Leo	"goto" is stupid command. Use "call" instead. This is required fron the "good practice" in programming.

4th March 2005, 07:06 PM	#6
bmcculla	In C every if/else and case statement generates a goto (jump) assembly instruction. In case statements the break statement coresponds to a jump/goto instruction. Function calls generate a Call instruction. The goto instruction is used to direct the flow of the program. The CALL instruction is used to build sections of code that will get used in more than one place in the code.

4th March 2005, 08:21 PM	#7
BF9000	call vs goto In general, call should be used when performing operations on a set of data, polling inputs, sending a structured set of output data, or performing a routine that controls peripherals. In general, goto should be used to return to the top of a loop and to conditionally skip over sections of code. Each instruction holds 11 bits of the address. When you use call this adress is pushed onto the stack. Remeber it is only 8 words deep so be careful when calling within functions. There must be a return opcode after every subroutine that is called or else the stack will likely overflow. These are just general guidlines and actual use will vary depending on how your program is structured, but this should give you a basic idea.

5th March 2005, 06:21 PM	#11
samcheetah	oh so you are working on that ringtone generator which is based on a 16F877 are you going to write a tutorial about this or not????

6th March 2005, 03:36 PM	#13
Nigel Goodwin	Following on from the horrible row of goto's in the HEX file I disassembled, I've downloaded the free limited version of the Hi-Tech compiler - PICC Lite. So I've been doing some experiments with it - if you set 'full optimisation' ON during the compiling process it doesn't produce the nasty multiple goto's. The entire code ends up considerably smaller as well - makes you wonder why all the C generated HEX files I've ever looked at haven't been generated like that?. I've also compiled the ringtone software for both 18 pin (16F627) and 8 pin (12F629/12F675) - with just very minor changes. This gives a rather useful little 8 pin chip which can play a Nokia monophonic ringtone when you apply power to it! - could make an interesting audible alarm?. __________________ PIC programmer software, and PIC Tutorials at: http://www.winpicprog.co.uk

7th March 2005, 09:53 AM	#14
bmcculla	Turning off the optimisations can make it easier to debug code. Compiler optimisations will also remove software delay loops and rearange sections of code that can make optimising a bit confusing for beginers. Also be careful to use the volatile keyword when nessesary - one of my professors in school spent 4-5 hours trying to debug code that was being optimised out because he forgot to make a variable volatile. The down side to turning off the optimiser is that the compiler generates really bone-headed code.