Pe miercuri, 19 aprilie 2000, la 10:00:00 UTC+3, Alexei A. Frounze a scris:
> Conditional jumps such as JZ or JNC, etc are limited to 127/128 bytes. You cant
> jump over 127 or 128 bytes backward or forward.
> If you had:
> ------8<-------
> JZ label1
> ------8<-------
> you should make it like this:
> ------8<-------
> JNZ label2
> JMP label1
> label2:
> ------8<-------
> this solves your problem.
> Good Luck
> Alexei A. Frounze
> -----------------------------------------
> Homepage: http://alexfru.chat.ru
> Mirror: http://members.xoom.com/alexfru
> vassone wrote:
> >
> > Can someone please explain why MASM is reporting "Jump out of range by
> > 130(bytes)
> >
> > What does this means?
> >
> > Any help would be very much appreciated..
> >
> > Vassone
> >
> > mailto:vas...@hotmail.com
> >
I like your games :)

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

versus short:
7x 12 jmp cc rel+2+12

both variants use signed values relative to the address after the jump.
__
wolfgang

On Tue, 23 Nov 2021 07:40:41 +0100
wolfgang kern <nowhere@nospicedham.nevernet.at> 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.

--
Bah, and indeed Humbug.

Kerr-Mudd, John wrote:
> On Tue, 23 Nov 2021 07:40:41 +0100
> wolfgang kern <nowhere@nospicedham.nevernet.at> 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

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.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Wed, 24 Nov 2021 16:22:57 +0100
Terje Mathisen <terje.mathisen@nospicedham.tmsw.no> wrote:

> Kerr-Mudd, John wrote:
> > On Tue, 23 Nov 2021 07:40:41 +0100
> > wolfgang kern <nowhere@nospicedham.nevernet.at> 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.
>
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"
>

--
Bah, and indeed Humbug.