Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

when shd i use a "call" and a "goto"? wh

Status
Not open for further replies.

picboy

New Member
Dear all,

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

Thanks
 
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.
 
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.
 
"goto" is stupid command. Use "call" instead. This is required fron the "good practice" in programming.
 
Desert Leo said:
"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.
 
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.
 
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.
 
bmcculla said:
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 said:
Nigel Goodwin said:
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 .
 
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?.
 
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.
 
bmcculla said:
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.
 
I think the answer is lazy developers :D - if it works and you have enough flash why bother to make your code good. Of course this sort of thinking will come back and bite you when you try to add features or maintain the code.

Make sure you're careful when turning on optimisations because they can break bad code.
 
I'm agree with you Nigel, but I didn't mean to exclude goto instruction at all.
goto is very usefull in combination with decfsz, incfsz, etc.
But if I can use subroutine in my code, I will "call" it , not goto it.

Gotos generated by compilers of high level languages (C-compilers are good example), as well as another disadvantages - mainly unpredicted code size force me to use assembler only. ... At least till the moment when I will fing a really good compiler.
 
bmcculla said:
I think the answer is lazy developers :D - if it works and you have enough flash why bother to make your code good. Of course this sort of thinking will come back and bite you when you try to add features or maintain the code.

Make sure you're careful when turning on optimisations because they can break bad code.

This is exactly what I used to do when i wrote C programs for the PC. Poor memory management and lazy techniques. Programming pics has taught me alot.
 
dak246 said:
This is exactly what I used to do when i wrote C programs for the PC. Poor memory management and lazy techniques. Programming pics has taught me alot.

I'm currently having fun improving the 'optimised' C code in assembler, although some of it's optimisations I don't like, and I'll probably make some sections longer, but more readable.

One improvement I've just done (very applicable to the title of this thread), it to make one four line piece of code into a subroutine, as it's called 13 times this saves 38 words of memory - and makes the program more readable. I've been doing the same with other multiple pieces of code.
 
With a good compiler you should be able to make the code longer without generating any extra instructions.

You should be able to turn on and off specific optimisations for code segments. #pragma ot(5) is Keil's directive to use optimisation level 5 for the next code segment. The down side is that stuff like this is nonstandard C.

Nigel you really should look at SDCC. Its an open source C compiler. They are in the process of retargeting it to the PIC. Its online manuals have good info about a bunch of different compiler optimisation techniques.
 
Status
Not open for further replies.

Latest threads

Back
Top