# use of unconditional transfer of control instruction

I did not understand why unconditional transfer of control instruction is used in cpu.So if we already know we have to jump to an instruction and skip some instruction irrespective of any condition then why do we not avoid writing those instruction as they will not be executed and replace them with instruction that will be executed after jump instruction

To implement if-then-else, when you get to the end of the "then" branch, you need to jump unconditionally past the "else" branch. The breaks in a C switch statement are also unconditional jumps.

You could probably also implement tail recursion by replacing "call" instructions with jumps.

• The range of branch instructions can also be less than that of unconditional jumps, so a conditional distant jump may need to be converted to conditionally branching over an unconditional jump. Hot patching can also use unconditional jumps. (There are also unconditional indirect control flow instructions — the target is still dynamically variable as with a conditional branch — but the question is presumably not concerned with those since their utility is more obvious. In ancient times, returns and other indirect jumps were sometimes implemented by self-modifying code changing jump targets.) – Paul A. Clayton May 4 '15 at 13:00
• Another oddball potential use for unconditional jump instructions would be with a unified instruction/data cache and PC-relative loads. Data loaded by a PC-relative load might be in what would be the instruction stream to allow instruction fetch to load the data into the (unified) cache, but the data would need to be jumped over. – Paul A. Clayton May 4 '15 at 13:04

As David Richerby's answer notes, the most common use is for implementing if-then-else, where the unconditional jump hops over the else code.

A related use is when the compiler knows conditional code is rarely executed and places it far from the more common executed code, so that an unconditional jump is used to return to the post-conditional code. This is a code transformation from:

 branch-on-cond-to-LABEL
not-"cond"-code
jump-to-JOIN
LABEL:
"cond"-code
JOIN:

branch-on-cond-to-LABEL
not-"cond"-code

JOIN:

...

LABEL:
"cond"-code
jump-to-JOIN


This can enhance memory system performance by exploiting sequential prefetch and avoiding the fetching and storing of a partial cache block of code that is rarely used. (This is an extreme extension of placing the less frequently executed code of an if/else in the later position. This makes the common case a not taken branch which can avoid using a branch target buffer entry, can exploit simple static prediction (forward branches not taken), and can avoid the fetch redirection penalty in some processor implementations.)

It is common for instruction sets to provide a greater range for unconditional jumps than for conditional branches. This means that a conditional jump with a distant target might have to use a conditional jump (with an inverted condition) over an unconditional jump instruction.

An unconditional jump can also be used for hot patching. An unconditional jump to the next instruction (or other nop of the appropriate size) at the start of a block of code (typically a function) can be atomically changed to an unconditional jump to the new code replacing that block.

Another potential use for an unconditional jump instruction is to jump over inlined data. With a shared instruction and data cache, it might be useful to exploit block-granular retrieval from memory and sequential prefetching by placing data with code. This also allows the use of the program counter as a data address register, potentially avoiding the need to load a base address and slightly reducing register pressure.

In some early instruction sets there were no function return (or general indirect jump) instructions, so an unconditional jump instruction at the end of a function was (partially) overwritten to jump to the return address.