From: admin@nospicedham.127.0.0.1   
      
   On Wed, 24 Nov 2021 16:22:57 +0100   
   Terje Mathisen  wrote:   
      
   > Kerr-Mudd, John wrote:   
   > > On Tue, 23 Nov 2021 07:40:41 +0100   
   > > wolfgang kern  wrote:   
   > >   
   > >> On 22/11/2021 20:16, Nicolae Nasturica posted:   
   > >> ---   
   > >>>>> Can someone please explain why MASM is reporting "Jump out of   
   > >>>>> range by 130(bytes)   
   > >>   
   > >> because the range is a signed byte (+127..-128) and because MASM   
   > >> don't know about long CC-instructions (perhaps it knows with hint   
   > >> "long"):   
   > >>   
   > >> 0F 8x 43 21  jmp cc rel+4+2143   
   > >   
   > > There are also the unconditional jmps   
   > > E9 xx xx     jmp   
   > > EB xx        jmp near[/short]   
   > > has the same +127-128 range, but means a slightly increased jmp   
   > > forward, ability as the jmp is from the address of the next op code.   
   > >>   
   > >> versus short:   
   > >> 7x 12        jmp cc rel+2+12   
   > >>   
   > >> both variants use signed values relative to the address after the   
   > >> jump. __   
   > >> wolfgang   
   > >>   
   > >   
   > > It might be useful to someone here; but Alexei answered Vassone's   
   > > question back in 2000.   
   >   
   > 2000?   
   >   
   > You young wippersnappers! :-)   
   >   
   > This particular issue came up regularly even before the 808x was   
   > invented, the solution was always the same, i.e. use some other   
   > method for the far jump and a short branch past this code to avoid it.   
   >   
   > TASM (maybe around 1986?) had options to handle this automatically:   
   > By starting with the long jump macro at every branch location and   
   > then make one or a couple of passes, nearly all of them could be   
   > converted to the short form.   
   >   
   > By starting with the long form   
   >   
   > Long branch on Greater to target   
   >    jle $+3   
   >    jmp target   
      
   I presume the 2nd jmp is the 3 byte version.   
      
   >   
   > and then for each target checking the offset and if in the -128 to   
   > +127 range, convert to the two-byte form, no previously converted   
   > branch can go out of range, so the process is stable. After 2 or 3   
   > iterations you'll probably find that either all of them are now   
   > short, or that no more can be converted.   
   >   
   > I think there were other assemblers which did the same trick.   
   >   
   Nasm does; if I spot this I try re-ordering my code to remove them.   
   >   
   >   
   > --   
   > -    
   > "almost all programming can be viewed as an exercise in caching"   
   >   
      
      
   --   
   Bah, and indeed Humbug.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)