Announcement

Collapse
No announcement yet.

SHORT jumps

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • SHORT jumps

    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)?
    Bernard Ertl
    InterPlan Systems

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

    Kind regards
    Eddy

    Comment


    • #3
      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!
      Bernard Ertl
      InterPlan Systems

      Comment


      • #4
        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.

        Comment


        • #5
          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.

          Comment


          • #6
            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?
            Bernard Ertl
            InterPlan Systems

            Comment


            • #7
              Bern,
              the following program fails as expected when the short jump tries to jump too far:
              Code:
              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

              Comment


              • #8
                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. ???
                Bernard Ertl
                InterPlan Systems

                Comment


                • #9
                  Bern,
                  try and calculate the distance by adding a label at the JMP instruction and use CODEPTR() to find its value:
                  Code:
                  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.

                  Comment


                  • #10
                    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.
                    Bernard Ertl
                    InterPlan Systems

                    Comment


                    • #11


                      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.

                      Bernard Ertl
                      InterPlan Systems

                      Comment

                      Working...
                      X