To add my own two pence, although I'm not sure if it's related or not.

Some architectures are very limited in how far a conditional jump can branch compared to an unconditional jump (e.g. the offset might only be a signed byte).  I ran into this problem on certain ARM platforms when developing my recent cross-platform jump optimisations.

Jump pads are one means to avoid assembler errors by ensuring the conditional jump stays within range.  The other one, which seems more common in FPC, is to (in assembler form), change a conditional jump to @1 to "If not condition then goto @2; jump @1; @2:", thereby ensuring the conditional jump is within range by having it only jump across one instruction (the unconditional jump).

The problem is that it is not always easy to determine if a jump is in range during compilation - the problem might be NP-hard, not sure - even on architectures like ARM where each machine code instruction is the same length.  For example, if you have a procedure where a conditional jump to some future label is in range, but only just, and a 2nd conditional jump in between is not in range and requires changing to the "if not condition" construct described above, the addition of the new jump instruction may be enough to cause the 1st jump to become out of range.  Jump pads (I like that term, even if it sounds like it belongs in a Sonic the Hedgehog game!) suffer from a similar problem depending on where they are inserted.

Gareth aka. Kit

On 20/04/2020 21:11, Florian Klämpfl wrote:
Am 20.04.20 um 16:44 schrieb Martin:
FPC sometimes generates jump instructions as follows. (Not always bound to "IF" but that is the example I found

IF something then begin {long code} end;

The conditional asm jump does not jump all the way to the code after the "end". Instead it points to an unconditional jump, that (according to line info) is at the end of some other line.

This might be some artifact introduced by the optimizer. Problem is, the jumps are generated at a certain point and then the optimizer starts to "mess" with them. During this, it might be that line info is mixed up.


Such "jump pads" (?) seem common (gdb seems to know about them).

I try to detect them in fpDebug.
Which assumptions are reasonable?

- How long can a series of such "jump forwarders" be.
   Can the unconditional jump, go to another unconditional jump, before eventually hitting the line that the pascal code would go to?
   How many to expect max, before getting suspicious?

Unlimited in theory.


- If such jumps are within line info, they should not be at the start of a line?

Do you have some example code which shows this (together with the needed optimizer switches)?
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to