Call ,goto and Bra any differences? - Page 1
Forum section: electronics / general

author: tahmod
author_rank: Contributor
timestamp: April 07, 2013, 02:07:15 pm
content: What is the difference between Call ,goto and Bra?I think they do the same thing, go to a place.

author: andersm
author_rank: Super Contributor
timestamp: April 07, 2013, 02:24:37 pm
content: Is this homework? Read about jumps and subroutine calls.

author: 8086
author_rank: Super Contributor
timestamp: April 07, 2013, 02:26:34 pm
content: Look at the datasheet for the device you're using to see more info.The instruction set is usually in there with examples.

author: mark-r
author_rank: Contributor
timestamp: April 07, 2013, 02:38:11 pm
content: All I know is don't goto the bra on a first date or she won't return your call.

author: Noize
author_rank: Regular Contributor
timestamp: April 07, 2013, 03:06:03 pm
content: Quote from: mark-r on April 07, 2013, 02:38:11 pmYou know you're gonna be a good engineer if you can undo a bra with one hand.

author: gxti
author_rank: Frequent Contributor
timestamp: April 07, 2013, 07:20:16 pm
content: BRA is a relative jump, e.g. "jump forward 20 instructions" or "jump back 80 instructions". On architectures like PIC16 that have segmented flash that means you can jump around short distances without worrying about whether you're crossing a page boundary.GOTO is absolute but on PIC16 for example does not have enough bits to reach the entire address space. So you may have to fix the segment register first. There's an assembler macro to make it easier but I ditched PIC16 a long time ago so I don't recall what it is.CALL is just like GOTO but it pushes the current address onto the stack first so that the thing you called can RETURN back to whence it came.All three are written the same way in assembler, it's the assembler program's job to translate "bra some_label" into the actual relative jump once everything is translated. Most of the time you will want CALL to call functions and BRA to jump within a function. GOTO is only for "long jumps" in odd scenarios where CALL isn't appropriate, e.g. a bootloader jumping to the loaded application.I probably got at least one thing wrong, so your task will be to read up on the details and figure out which it was.

author: Skimask
author_rank: Super Contributor
timestamp: April 07, 2013, 08:04:51 pm
content: Quote from: gxti on April 07, 2013, 07:20:16 pmI don't think that's going to happen.

author: lemmegraphdat
author_rank: Frequent Contributor
timestamp: April 07, 2013, 10:04:16 pm
content: Quote from: Noize on April 07, 2013, 03:06:03 pmIt always works in the simulation.

author: westfw
author_rank: Super Contributor
timestamp: April 08, 2013, 01:33:09 am
content: A CALL is something you make with a cellphone, a GOTO is a C statement to be avoided, and a BRA is a bounce prevention device.

author: blewisjr
author_rank: Frequent Contributor
timestamp: April 09, 2013, 04:32:26 pm
content: Indeed. Call pushes onto the stack so you must return so you don't overflow the stack. Each call must have a corresponding return. Goto is a unconditional branch. On PIC16 goto can only access memory in the same page and modifies the program counter. On PIC18 goto can access all memory and modifies the program counter but takes twice the space as a bra. Bra is a relative branch meaning it jumps relative to where the program counter is at. Depending on the chip bra can only jump so far backwards or forwards. On PIC16 bra can jump across page boundaries. On PIC18 it can again access any memory within it's range and takes 1/2 the space as a goto.If your programmer has debugging capability you can debug a program that uses each method and you can step through the code and see how each effects the program counter etc... Each has it's own use.

author: gautamdamodar
author_rank: Contributor
timestamp: April 09, 2013, 05:50:11 pm
content: Implications will depend on the processor/controller or the language you are using. selection of keyword should be for optimum performance. Eg. never use a call for subroutines that wont return. Better read from books than getting confused.

author: nctnico
author_rank: Super Contributor
timestamp: April 09, 2013, 11:06:10 pm
content: Quote from: westfw on April 08, 2013, 01:33:09 amNot really. Goto is often used to jump to the end of a function so memory can be released when something goes wrong. The Linux kernel is swamped with gotos for this purpose. It prevents having to use obfustigated constructions with IF statements.

author: Kremmen
author_rank: Super Contributor
timestamp: April 11, 2013, 08:23:16 am
content: Quote from: nctnico on April 09, 2013, 11:06:10 pmLike almost everyone, I too have a personal opinion of the GOTO. Do you want to hear it? Never mind, i'll say it anyway %-B.There might be a disciplined way or ways to use GOTOs but all of those that i am aware of are trivially handled by more "proper" constructs that ensure more controlled, maintainable and surprise free control flow.That GOTOs are used does not mean they are a "good" idea. They of course work as specified but that is not my point in avoiding them. My point is that a GOTO completely breaks the structure of a piece of code and in my book that mostly reflects the programmer's inability to properly formulate the structure in the first place. More modern languages such as java don't even have a goto and that seems to be no problem. In fact, i have never used a single GOTO in C or C++ either.So at least for me the GOTO is a risky and irrelevant remnant of a bygone era. Others may disagree.

author: Unknown
author_rank: Unknown
timestamp: April 11, 2013, 08:54:15 am
content: Modern languages like Java have exceptions for error handling, though. This is essentially a structured GOTO. Not so in C, your only option is long if statements.

author: Kremmen
author_rank: Super Contributor
timestamp: April 11, 2013, 09:02:20 am
content: Exceptions in java but in C++ as well. They may be GOTO statements on one level, but then so is the machine code. Since that is handled by the "unerring" compiler one doesn't have to worry about things on that level. The point being that exceptions are well structured constructs.As to C, no exceptions available but i think a long IF statement is not by any means the only alternative to a GOTO. There are semi-structured constructs such as break statements, possibly combined with labeled loops and suchlike.

author: Unknown
author_rank: Unknown
timestamp: April 11, 2013, 10:30:38 am
content: I'm not arguing against the advantage of exceptions, but C lacks them, and exceptions are often lacking or poorly implemented in C++ compilers for small micro-controllers. Last time I checked, AVR gcc claimed not to support them, for example.

author: westfw
author_rank: Super Contributor
timestamp: April 11, 2013, 06:23:17 pm
content: Geez... try to make a joke and it derails the whole conversation.Here's a more serious answer:Modern CPUs typically have an internal register that hold the address of the next instruction to be executed, so that the hardware can go out to memory and fetch that instruction. This is usually called the "Program Counter (PC)" or "Instruction Pointer", and it normally is incremented automatically by however many bytes or words were in the last instruction executed.In order to implement programming constructs like looping and conditionals, there are usually some instructions that manipulate the PC in a manner other than simple "do the next instruction" modes. Collectively, these are call "branch" instructions.There are three common classes of instructions to do this:1) Unconditional branch instructions. These will set the PC to a new value, causing the next instruction to be fetched from the new address that was provided or calculated. Unconditional branches can implement infinite loops.2) Conditional branch instructions. These will set the PC to a new value, IF and only if some condition is met. Which conditions can be tested, and exactly how they're tested, are architecture dependent. Conditional branches can implement IF statements and conditional loops.3) Subroutine linkage instructions. These set the PC to a new value, but somehow "save" the old value so that code at the new location can resume execution just after the branch when it is "done." This allows the implementation of subroutine and function calls.There are some other special cases that are common enough to be worth mentioning.Conditional SKIP instructions. Some architectures (especially those with a fixed instruction size) implement some or all of their conditional branching using instructions that simply skip the next instruction if some condition is true or false. A larger conditional branch would be implemented by conditionally skipping over a non-conditional branch. This is used on the older Microchip PIC 8-bit chips (PIC16 series), and the DEC PDP-10, for instance, and Atmel AVR has "some" skip intstructions as well.Conditional execution. Some architectures allow any instruction's execution to be conditional. This is especially popular on high performance RISC architectures, where preventing an actual branch can improve performance in pipelines and cache memory and such. ARM is famous for having conditional execution.Direct Access to the PC register. On some architectures, the PC is implemented as a user-accessible register, capable of being accessed by all the usual instructions. So you can implement an unconditional branch by moving a new value to the PC register. This is particularly useful for dealing with tables of destination addresses.Now, the exact NAMES of the instructions for each of these classes of branch are arbitrary, and seem to be chosen randomly by chip vendors to make them look different than other chip vendors. "Jump" and "Branch" are popular, in various abbreviations (B, BR, BRA, J, JMP, JUMP.) It is common for conditional branches to use a suffix indicating the condition in effect (BNZ = branch if not zero, JNE = Jump if not Equal.) It is somewhat common to use one prefix (Jxx or Bxx) for unconditional branches and the other for conditional branches."CALL" is popular for subroutine linkage, but JSR (jump to subroutine) shows up. The relatively complex behavior of a typical stack-based CALL are not well-liked by RISC architectures, so ARM has (for example) "BL" (Branch and Link), where the old PC value is put in a register. The venerable 8080 had conditional call instructions that match the conditional jumps (and conditional returns, as well.)The other issue that shows up frequently is that many architectures have "relative" branch instructions. These will add or subtract a value from the current PC, rather than loading it with a brand-new values. This has a couple of advantages. One is that code using relative branches is "position independent"; it can be moved in memory and it will still work. Another is that a relative branch instruction can usually be shorter and faster than a full-range branch instruction. If your CPU has a 32 bit address space, a full-range branch would require an instruction longer than 32 bits. But a relative branch that could go +/-8k (for example) would allow most loops, and only require "more than 14 bits." Some architectures name their relative branches "branch" and their full-range branches "jump." Or the other way around. It's pretty common for conditional branches to ALWAYS be relative on such systems.So let's look at a few examples:Microchip PIC:PIC16 unconditional branch: GOTOPIC16 conditional: skip instructionsPIC16 subroutine: CALL (HW stack)PIC18 unconditional: GOTO (full range) and BRA (short range.)PIC18 conditional: skip instructions + BccPIC18 subroutine: CALLAtmel AVR:AVR Unconditional: JMP (full range), RJMP (relative)AVR conditional: BRcx, some skip instructionsAVR subroutine: CALL (uses memory-based stack.)TI MSP430:MSP Unconditional: JMP (relative), BR (user access to PC reg)MSP Conditional: JccMSP subroutine: CALL (memory based stack)ARM: (um. Slightly different for ARM vs THUMB vs THUMB2?)ARM Unconditional: BARM Conditional: Bcc (also, conditional execution of all or some instructions, IT (If-Then) instruction.)ARM subroutine: BL (branch, store PC in link register (r14))x86:x86 unconditional: JMPx86 conditional: Jccx86 subroutine: CALL (memory based stack.)

author: Kremmen
author_rank: Super Contributor
timestamp: April 11, 2013, 06:46:33 pm
content: Quote from: westfw on April 11, 2013, 06:23:17 pmWe are the Men in Black - we don't have a sense of humor that we are aware of.

author: nctnico
author_rank: Super Contributor
timestamp: April 11, 2013, 08:01:47 pm
content: But the difference between me and you is that I make a GOTO look good!

author: tahmod
author_rank: Contributor
timestamp: April 12, 2013, 06:36:14 pm
content: -Call can be used in delays instruction, so we can call it many time we want-Goto and Bra are unconditional branch, so can be used interchangeably, but Bra must be between within +1023 and -1024 locationsThis is correcT?

author: nctnico
author_rank: Super Contributor
timestamp: April 12, 2013, 07:53:11 pm
content: Bra is a generic mnemonic so there is no way to tell what the limits are -if there are any limits-. Most CPUs have a relative and absolute jump. How far a relative jump can go depends largely on the architecture.