Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

rebuilding NASM 0.98.39 (2005) for 16-bit 8086 host (Developers)

posted by Rugxulo Homepage, Usono, 14.03.2020, 08:13

> > (Remember I rebuilt old NASM 0.98.39 with Turbo C++ 1.01?
> > I assume NASM's preprocessor would make a great overlay
> > since you only need it at the beginning.
 >
> Actually, the NASM preprocessor is run on each pass of the assembler.
> That's why my sources won't work with nasm -E (preprocess-only mode).
As you've noticed, the official build of 0.98.39 for 16-bit DOS was 186 only (using "ENTER" instruction). Not only is it pointless (not much size or memory savings), and 4x slower on modern machines, but some emulators hate it (Fake86, 8086tinyplus). Your 8086tiny fork fixes that bug, among other things.

Newer NASM 2.xx versions since 2007 have x64 support and require a C99 compiler, so they don't build for anything less than (386+?) pmode. I do have some .BATs to build some NASM 2.x versions in native DOS with DJGPP (GCC 3.2.3 or newer), but I haven't finalized the 2.13.03 one due to other priorities. I dislike the idea of only cross-compiling it.

Here are my two .EXEs and makefiles for 8086 (0.98.39), once with freeware Turbo C++ 1.01, once with (OSI) OpenWatcom 1.9. The former needed to switch from Large to Huge model just to build correctly (no /Ff switch?), which I assume makes it waste more precious RAM than Large does. (Or is their malloc inefficient?). Since these are using conventional memory only, they probably further need more fixes (overlays, optional EMS, or more trimming). I did only enable bin and obj output support, but that wasn't quite enough. Probably I need to go in (insns.pl??) and disable anything past 586. (Why bother with SSE2 in such a limited environment?) It does reassemble PSR Invaders, but that's very small and simple, so it's not a good test.

Rebuilding the FreeDOS kernel ran out of memory (Turbo C++ build only), but apparently it works when not run under WmakeR. So the bloody Make program is eating too much (scarce) conventional RAM! On the one hand, I definitely didn't want to forcibly rely on an obsolete 16-bit NASM to build the kernel due to other problems. So I was using WmakeR just to avoid "extender" mixups (DOS4GW vs. CWSDPMI used by NASM or UPX). But you can use CWSTUB renamed as DOS4GW and then use WMake (386 pmode version), and then apparently it doesn't waste as much conventional memory, so it can successfully reassemble those files needed by the kernel (tested only patched 2041, set NASMENV=-O9 first).

So I don't necessarily need to delve further, especially since you can just use the 386 DJGPP (or older 386 OpenWatcom) build of NASM. Hey, OpenWatcom itself needs 386, so who cares? Still, I feel like a 16-bit build shouldn't be so hampered. Also, it's annoying that it doesn't even tell you how much memory was free, how much was used, nor how much was unsuccessfully (mis)allocated. I haven't checked closely to see what debug hooks or instrumentation they included in the (old, outdated) 0.98.39 sources.

> As noted there, this made the assembly take more than 2 minutes.
> Therefore I disabled this option
Even FASM has noticeable slowdowns with complex macros. But fasmg is even slower since it's all interpreted (although his recent CALM additions have sped it up a lot).

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 193 users online (0 registered, 193 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum