On at 2026-06-02 15:54:52 -0400, Jerome Shidel via Freedos-devel <[email protected]> wrote: > > >> On Jun 2, 2026, at 1:58 PM, Rugxulo via Freedos-devel >> <[email protected]> wrote: >> >> Hi, >> >>> On Mon, Jun 1, 2026 at 10:14 AM Jim Hall via Freedos-devel >>> <[email protected]> wrote: >>> >>> Mathias Eberle on the Facebook group shared this announcement, which I >>> am re-sharing here: >>> >>>> I fulfilled myself a little 90s childhood dream and created a single-pass >>>> self-compiling BASIC compiler for DOS, targetting 8086/8088 and size >>>> optimized COM files as output! >>>> >>>> The compiler itself generates NASM-compatible code. But since NASM >>>> usually generates 386+ code, I have also included a special assembler >>>> written in BASIC, so that the toolchain is complete. >> >> This sounds very cool, but I haven't tried it yet. >> >> Not sure what he means about NASM. I guess he means the default >> binaries for modern NASM require 386 (and DPMI) from DJGPP. >> >> If his code doesn't require modern NASM preprocessor tricks, if it can >> assemble with old 0.98.39 (from 2005), then we have 8086 builds of >> that version (TurboC or OpenWatcom). >> > >While I do not recall the default CPU target, NASM does not “usually” generate >such code. > >This is because it is always a good practice to tell NASM your target with a >keyword in the source file. Then you get a binary compatible which the >processor you want to target.
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. 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.) Regards, ecm [1]: https://stackoverflow.com/questions/79929484/can-nasm-behave-like-an-8086-assembler-it-accepts-32-bit-addressing-modes-even#comment141043553_79929484 [2]: https://pushbx.org/ecm/download/nasm/3392664%20%e2%80%93%20_mov%20al,%20byte%20%5bedx%5d_%20does%20not%20cause%20error%20when%20_cpu%208086_%20is%20in%20effect.html [3]: https://pushbx.org/ecm/download/nasm/3392656%20%e2%80%93%20_mov%20fs,%20ax_%20does%20not%20cause%20error%20when%20_cpu%208086_%20is%20in%20effect.html _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
