Hi, On Thu, Oct 17, 2019 at 8:43 PM Rugxulo <rugx...@gmail.com> wrote: > > With the new [NASM 16-bit] build(s), I tried rebuilding the FD kernel. > It seems the TCPP101 version ran out of memory on KERNEL.ASM!
It was actually only because I was using WmakeR (real mode) instead of the (386 pmode) Wmake executable. Not sure if WmakeR can swap out (apparently not, no mention in Tools documentation), haven't checked 2.0-pre. So that's the only reason. With Wmake [sic], it will happily assemble the kernel files with no problem. N.B. TC++ 1.01's Make 3.0 has -S (and .SWAP) and Dmake 4.00pl2 has % prefix for commands to swap out to disk, saving 50k or 100k RAM, respectively. WmakeR uses like 140 kb while (CWSTUB'd) Wmake only uses 40 kb. BTW, the only reason I was preferring WmakeR was to avoid any extender incompatibilities (CWSDPMI vs. DOS32A or WDOSX or whatever). But, AFAIK, Causeway (CWSTUB.EXE copied or renamed as DOS4GW.EXE) seems to play nicely (e.g. successfully runs NASM or UPX compiled by DJGPP). I already have scripts to (natively, in DOS) build various 32-bit NASMs via DJGPP (0.98.39 or 2.13.03) or OpenWatcom (2.09.10). So we don't need to forcibly rely on a 16-bit NASM binary just to rebuild the kernel. So it's not really a problem, just confusing. > Is that a tradeoff for using Huge model? Probably not, but you can't compile for Large model (anymore) without trimming out extraneous instructions ... so I decided to do that! (I call this "nasmlite".) I stripped out CYRIX/MMX/3DNOW and all SSE[123] stuff from insns.dat, re-ran "perl insns.pl", used "-d" (merge duplicate strings), and now that "lite" version compiles as (TC++ 1.01) Large model just fine. It saves about 50 kb .EXE space (or about 10 kb UPX'd). Trying to rebuild the kernel under WmakeR [sic] works fine (except for COUNTRY.SYS, which can be assembled manually later and isn't as high priority, obviously). * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/ Note that I made it so you don't need (abandoned, bloated) DJGPP Perl to rebuild this, only Sed, which is much smaller and has 16-bit builds. (I guess it's possible that 16-bit Perl 4 would work, but I highly doubt it and didn't try. Old NASM 0.97 had a .BAS to alternatively do it, but I guess it wasn't kept working, so I didn't try that here either.) I also didn't want to include three entire (regenerated) source files just for this when a simple script would avoid that dependency. > Should it use halloc() or overlays?? faralloc() ? Probably not. (You can rebuild with -DLOGALLOC to write statistics to malloc.log [big!], but that's not quite what I wanted to know.) Overlays? Still haven't read up on it (though I played a bit with Turbo Pascal overlays, for fun, kinda interesting.) Just FYI, for comparison. _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
