Backward long jump

[Yuri]

There seems to be no way to force GoAsm to code a backward jump as long. It always decides whether to do so or not. Sometimes it can be a problem. Suppose you have an array of functions and want all of them to be the same size, so you could use an index to access the one you need. If there is a backward jump in each of them to some common label, the distance will vary and so will the size of the jump instruction and the size of the functions.

If I want an automatically adjustable jump, I can use the short one, so I think it would be more logical if the long jump was fully controlled by the programmer, as the forward long jump is.

[dedndave]

if you have to, you can hard-code it   :P

[Yuri]

Yes, I know. And if you had to, you could still use Abacus 1.0.  ;)

[dedndave]

it's not that bad - lol

Code: [Select]

        db      0E9h
lpLabel dd      BranchToAddress-(lpLabel+sizeof lpLabel)

[wjr]

In keeping with the aim of trying to make the smallest possible code, I do like the backward short jump for the case of locally scoped and unscoped labels, which tend to be nearby.

However, in tracing through the case of a backward jump to a unique label (generally further away), I have tested the addition of two lines of code (able to 'easy-code' it :-) which would force a backwards long jump if specified. Note that this unique label would then alter the scope for locally scoped labels placed afterwards, and any references that would jump across either way would need the correct full Unique.LocallyScoped symbol name (or use the unscoped labels). Would this be a reasonable compromise to include in the next GoAsm update?

[Yuri]

Would this be a reasonable compromise to include in the next GoAsm update?

Yes, it would give us a way out, thanks! Still, if I understand you correctly, < and << would be synonyms for non-unique labels? But, if so, why would you ever use the latter? Why type two characters if one would do the job? Actually even < is optional in most cases, so << looks absolutely redundant here. Therefore, why not assign some useful functionality to it, i.e. make it produce long jumps for such labels as well?

Of course, if it requires some messy changes to the code, only you can decide if it's worth your time. I appreciate your help anyway.

[Yuri]

it's not that bad - lol

Code: [Select]

        db      0E9h
lpLabel dd      BranchToAddress-(lpLabel+sizeof lpLabel)

Yes, that is what I was trying to do when it turned out that GoAsm couldn't calculate the offset because it didn't see the target label.

[wjr]

As documented, rule number 3 throws things off by ignoring the long specification. It also does not quite mention automatically coding a long jump if needed for a locally scoped label (but not an unscoped label). The above fix actually also affected locally scoped labels.

I have a vague recollection from the early days that to reduce the number of short jump errors, the backwards jump automatic handling was introduced. Currently < can be long, and << wouldn't be in much use (except for unscoped, and then usually because long was needed), so yes, it seems like no harm in making it useful for the rest. Just a few more line adjustments also fixed unscoped labels giving the following rearranged clearer rules:

- GoAsm will always code a long jump if specified (for those instructions that support this).
- For backward jumps to unique and also locally scoped labels, GoAsm will automatically code a short jump if possible, if not a long jump.
- For backward jumps to unscoped labels, GoAsm will code a short jump.
- For forward jumps to locally scoped and also unscoped labels, GoAsm will code a short jump.
- For forward jumps to unique labels, GoAsm will code a long jump.

[Yuri]

So, if I get things right:
- << and >> are always long for all labels
- For unscoped labels, < and > are always short
- For locally scoped labels, < is variable, and > is short
- For unique labels, < is variable, and > is long

If I am correct, that's fine. :icon_cool: The only thing I am curious about is why should forward jumps to unique labels be always long?

[wjr]

Yes, that is the long and short of it.

Although the forward long to unique label cuts down on short jump errors, I think it has always been this way. A unique label sets up new scope and tends to be further away, so most likely a longer jump anyways. This along with a forward jump for a one-pass assembler needing to set up a forward reference for the label and make a decision on the size of the current jump instruction before proceeding... long was chosen (and we should stick with it since altering at this point would introduce a mix of shorter jumps, short jump errors, and possibly throw off code that depended upon this - similar to what you mention in this backward long request).