<p>How do preprocessors of the assemblers for processors which have &quot;near jump&quot; and &quot;far jump&quot; instructions of different length (like x86) calculate the addresses of the labels? Isn't it a chicken-and-an-egg problem? To calculate how long some JUMP instruction will be, you need to know how far away the label it is jumping to is. But you cannot know that before you know the address of the label. And the address of the label might change depending on whether that jump is far or near. How can that problem be solved?</p>
<p>Thus far, I've only made an assembler for PicoBlaze, and every instruction in PicoBlaze is 18 bits long, and the preprocessor my assembler can determine the address of the labels simply by looping through the nodes in the abstract syntax tree of the depth 1, and increase the address for each mnemonic by 1, and for each label set the address simply to the counter. <a href="https://github.com/FlatAssembler/PicoBlaze_Simulator_in_JS/blob/a724e188d09cb1d295a650e93b70fc8db61fdd2d/preprocessor.js#L40C1-L95C6" rel="nofollow noreferrer">You can see that part of preprocessor here</a>. But doing something like that is not an option for processor architectures in which different opcodes have different lengths.</p>

<assembly>
How do the assemblers for processors which have "near jump" and "far jump" instructions of different length calculate the addresses of the labels?
CC BY-SA 4.0
2024-11-25T15:10:56.973Z
LaTeX has this problem with references. The text calling out a reference ("see page 42") may send the reference to a different page than was calculated in the previous pass. There's no solution (AFAIR), but it's infrequent.
Pablo H
CC BY-SA 4.0
2024-11-26T03:03:35.393Z
@PabloH With LaTeX cross-references, you might get stuck on cycles ("see page 40" makes the target overflow to the next page, so it gets changed to "see page 41" which with proportional numerals takes up slightly less space so the target moves to page 40, and so on), the problem of jump instructions always has at least one stable solution: use far jumps only. Figuring out the optimal solution can be tough (I think NP-complete in the most general case), but it's always possible to find _a_ solution.
Jasmijn
CC BY-SA 4.0
2024-11-28T01:58:46.540Z
On my 68k assembler, I would assume short branches, and make them longer if they didn't reach.  That is a cyclic process, since elongating one branch may require elongating another, but the code quality result is better than assuming long branches and shortening the ones that don't need to be long.  So these opposing approaches are a trade off of runtime benefit (code size/speed) vs. compile time performance.  (RISC V is using linker relaxation which may be of interest in this regard, by enabling the linker to make branch instruction size decisions.)
Erik Eidt
# How do the assemblers for processors which have "near jump" and "far jump" instructions of different length calculate the addresses of the labels?
Posted by: username_0 on 2024-11-24
How do preprocessors of the assemblers for processors which have "near jump" and "far jump" instructions of different length (like x86) calculate the addresses of the labels? Isn't it a chicken-and-an-egg problem? To calculate how long some JUMP instruction will be, you need to know how far away the label it is jumping to is. But you cannot know that before you know the address of the label. And the address of the label might change depending on whether that jump is far or near. How can that problem be solved?

Thus far, I've only made an assembler for PicoBlaze, and every instruction in PicoBlaze is 18 bits long, and the preprocessor my assembler can determine the address of the labels simply by looping through the nodes in the abstract syntax tree of the depth 1, and increase the address for each mnemonic by 1, and for each label set the address simply to the counter. [You can see that part of preprocessor here](https://github.com/FlatAssembler/PicoBlaze_Simulator_in_JS/blob/a724e188d09cb1d295a650e93b70fc8db61fdd2d/preprocessor.js#L40C1-L95C6). But doing something like that is not an option for processor architectures in which different opcodes have different lengths.
**Tags:** assembly
> **Comments:**
> **username_1**: LaTeX has this problem with references. The text calling out a reference ("see page 42") may send the reference to a different page than was calculated in the previous pass. There's no solution (AFAIR), but it's infrequent.  
> **username_2**: @PabloH With LaTeX cross-references, you might get stuck on cycles ("see page 40" makes the target overflow to the next page, so it gets changed to "see page 41" which with proportional numerals takes up slightly less space so the target moves to page 40, and so on), the problem of jump instructions always has at least one stable solution: use far jumps only. Figuring out the optimal solution can be tough (I think NP-complete in the most general case), but it's always possible to find _a_ solution.  
> **username_3**: On my 68k assembler, I would assume short branches, and make them longer if they didn't reach.  That is a cyclic process, since elongating one branch may require elongating another, but the code quality result is better than assuming long branches and shortening the ones that don't need to be long.  So these opposing approaches are a trade off of runtime benefit (code size/speed) vs. compile time performance.  (RISC V is using linker relaxation which may be of interest in this regard, by enabling the linker to make branch instruction size decisions.)  
---
## 0 answers
