SHORT jumps

[Bern Ertl]

The code I was supposedly testing above was wrapped in #IF 0 / #ENDIF tags. No wonder the compiler never complained when the jumps were obviously out of range.

[Bern Ertl]

I copied the !db lines from Paul's test code and pasted it into the DLL code (between the label and the jump) and it still compiled without error.

I'd try your suggestion, but the function I'm writing/testing is in a DLL and not 100% complete yet, so I can't really test it out in that fashion yet.

[Paul Dixon]

Bern,
try and calculate the distance by adding a label at the JMP instruction and use CODEPTR() to find its value:

FUNCTION PBMAIN () AS LONG

!jmp short target    'try a short jump to a distant target
JumpFrom:

'127 bytes follow
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

'!nop     'the 128th byte. Uncomment this line and the compile will fail

target:
PRINT HEX$(CODEPTR(JumpFrom)),HEX$(CODEPTR(target))
PRINT "Distance of jump=";CODEPTR(Target)-CODEPTR(JumpFrom)

WAITKEY$
END FUNCTION

Or add a !INT 3 instruction immediately ahead of the jump and, if you have a debugger installed such as OllyDBG, then the program will halt on the breakpoint and you'll see the exact JMP instruction compiled.

Paul.

[Bern Ertl]

OK. Your sample code does generate a compile time error on my end as well. My (DLL) application code where I tested originally has a jump instruction on line 2,709. The target is on line 3,240. In between is a ton of assembly code + Macros. I can't believe that it would be less than 128 bytes compiled, yet the compiler does not complain when I add SHORT to the jump.

Another example, !jmp on line 3,056. target is on line 2,345. In between is PB code, Macros and assembly code. I add SHORT and it compiles without error. ???

[Paul Dixon]

Bern,
the following program fails as expected when the short jump tries to jump too far:

FUNCTION PBMAIN () AS LONG

!jmp short target    'try a short jump to a distant target
'127 bytes follow
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

'!nop     'the 128th byte. Uncomment this line and the compile will fail

target:

END FUNCTION

[Bern Ertl]

I ran some tests compiling code where I included SHORT in my jump instructions and the compiler never complained no matter how far away the target was. Is PB ignoring SHORT altogether or just when it's not applicable? Does PB include SHORT automagically when appropriate?

[John Gleason]

I've noticed that programs which compile fine to an executable with short jumps inserted, sometimes give a fix-up error when run in the debugger. So you may have to remove some short jumps to use the debugger, and then add them back when finished.

[Paul Dixon]

Bern,
the compilers used to assume short jumps for all conditional jumps and if they turned out to be out of range at compile time you had to specifically make them far jumps in order to get the code to compile.
This did cause problems when trying to debug as extra code was inserted and would push jump targets out of the 128byte range and the compiler would report a "Fix-up error".

Later compilers defaulted to long jumps for all so the difference when debugging is no longer important but if you want to make a short jump then you have to code it specifically as a short jump and if the jump is too far then the compiler will complain and you have to change it back to a far jump.

Usually it's best to just accept the default far jumps and, when coding is finished and debugged, if you think you might gain a little extra from having short jumps instead then you put them in by hand.

Paul.

[Bern Ertl]

lol... I guess I've always erred on the side of caution, so I haven't noticed that the compiler would complain if the label was outside the range. D'oh!

[Eddy Van Esch]

Keep it simple: try a SHORT. If the compiler complains .... remove the SHORT ..

Kind regards

[Bern Ertl]

How do you know if a jump can be labeled SHORT or not? Some labels are obviously within the -128/127 byte range, but others might be close to the edge. Is there a good rule of thumb for approximating this (ie. assume an average of 3 bytes per instruction)?