> On Jun 2, 2026, at 4:57 PM, E. C. Masloch via Freedos-devel
> <[email protected]> wrote:
> [..]
> That's a "cpu 8086" directive. Indeed, it avoids allowing many 186+, 286+, or
> 386+ instructions.
>
> More importantly, if a conditional jump needs to be widened to address a near
> target (if it isn't in range of a short jump) then without any "cpu"
> directive recent NASM versions will use the 0Fh-prefixed, 386+
> single-instruction form of a near conditional jump. With "cpu 8086" it
> instead encodes a two-instruction workaround in which the first jump is short
> and conditional on the inverted condition, and the second jump is near and
> unconditional.
Hmm. I wonder if there is a way to turn off that “double jump” feature. I would
much rather prefer NASM to not try and be “helpful” in this case and simply
generate an error if it encounters an instruction for a short jump which is too
far. I would much prefer it only encode the instructions I tell it to use.
After all, this is assembly and not some abstracted HLL.
Such things tend to be more trouble than they are worth and create extreme
problems when debugging. As someone who has pushed NASM’s macros and advanced
features past the breaking point several times in DOS related programming,
these types of “features” lead to many headaches and sleepless nights.
> So even if you seemingly use only 8086-clean code, NASM may generate these
> 386+ forms of conditional jumps. You need either "cpu 8086" or to override
> every conditional jump (except loopxx/jcxz) with a "short" keyword to force
> an error rather than using the non-8086 instruction forms.
>
>> No different than specifying the offset of the code for things like COM
>> files by using “org 0x100”
>>
>> So, that statement about it usually generates 386+ code makes no sense to
>> me. Unless, the statement is in regards to running NASM. Then because NASM
>> is huge, you would be limited to compiling using a 386+.
>
> Yes, I believe that's what Rugxulo means. As the assembler was developed, it
> got trickier (if not impossible) to compile the assembler itself as an
> 8086-compatible application. I know I tried that at some point too, and I
> don't think I succeeded then.
>
> Writing of the 8086 cleanliness of NASM output, though, even "cpu 8086"
> doesn't always save the day. Some 386 addressing modes and registers are
> allowed despite the selected machine level. I recently commented about this
> on a stackoverflow question [1] in which I also cited earlier NASM bug
> reports that I had submitted, namely an "[edx]" a32 address is assembled
> despite "cpu 8086" [2] and an "fs" segreg operand (not as a prefix) is also
> assembled where it shouldn't be. (The links lead to mirrored copies on our
> server as the old NASM bugzilla is down more often than not lately.)
>
True. But, I would consider such things a compiler “bug”. However, if you use
the “cpu 8086” directive and write 8086 code, it generates 8086 code.
:-)
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
