[fpc-devel] Internal jump instructions for longer conditional jumps

[J. Gareth Moreton]

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 at 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