On Tue, Apr 11, 2017 at 7:06 AM, Mateusz Viste <mate...@nospam.viste.fr> wrote:
> That's nice of you to provide the explanation. I didn't read it
> completely (too lazy), nor understand it fully (too stupid), but the
> other clueless guy might find it interesting that he was only half wrong.
Just to clarify, I'll quote from the A86 text manual:
NOTE that for A86, LONG will have effect only on the operand to
an unconditional JMP instruction; not to conditional jumps. That
is because conditional jumps farther than 127 bytes are available
only on the 386 and later processors. If you run into this
problem, then chances are your code is getting out of
control--time to rearrange, or to break off some of the
intervening code into separate procedures. If you insist upon
leaving the code intact, you can replace the conditional jump
with an 'IF cond JMP'.
> At the end of the day, I will keep using "JZ SHORT" anyway, 'cause that
> just works for me.
My problem with always explicitly saying "short" is that it's both
unnecessary and verbose. But I (reluctantly) agree that here it's your
best option for safety. (Though I would still hide it behind a
preprocessor macro or whatever, for brevity.)
What disassembler are you using here? I erroneously thought it was
NDISASM. I also misremembered NDISASM as saying "jz near" (only) for
386+ jumps. I also misremembered such near/long jumps as being five
bytes when they are, in fact, only four.
I halfway remembered that the 386+ jz opcode started with 0Fh (sorry,
Tom) but wasn't sure offhand without checking. But here your
disassembler apparently put two jumps on one line, as if only one,
which is weird. I know it's a common idiom, but I didn't think a
literally disassembler would use that! (I double-checked, latest
NDISASM still decodes as two separate instructions.)
0Fh is actually the opcode to (discontinued, 8086-only) "POP CS". Both
FASM and NASM apparently support that (why?), but A86 apparently
Part of the confusion also lies with NASM. In the old days, you had to
explicitly enable -O3 to enable this 8086 conditional jump workaround,
e.g. 0.98.39 (by looking at old code of mine). NASM 2.09 started
enabling -Ox [sic] by default. However, it appears that even with -O0
nowadays, if you're using "cpu 8086", it will still extend your
conditional jumps in this manner. It didn't use to do that
automatically, nor for -O0.
The simple answer is that code size is rarely as important as
programmer convenience. Sure, if you're trying to squeeze every last
byte, you'll maybe accidentally be bit by this. But most people, by
far, don't care about code size and only care about functionality. I'm
only guessing, but that's my impression as to why NASM would always do
this by default nowadays.
P.S. http://stevemorse.org/8086/ is also an interesting read.
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Freedos-user mailing list