On Thu, Oct 10, 2019 at 10:00 PM Rugxulo <[email protected]> wrote: > > ia16-elf-gcc -mcmodel=small -Os -mregparmcall -mnewlib-nano-stdio \ > > tinyasm.c ins.c -o tinyasm.exe > > What is the resulting size of the .EXE with your build? (He said it > uses at least 128k RAM, right?) At least for development and > debugging, he should use a more comfortable toolset. Bootstrapping > (using 8086 host-friendly tools) can be important, too, but .... (Hey, > he didn't even UPX the 30 kb .EXE! Maybe that was intentional??)
Er, how much do we actually *care* about EXE size on disk? Even folks going old skool and trying to run on 808X CPUs are likely to have decent HDs.. (Is *anyone* still trying to run DOS (MS/PC or FreeDOS) and DOS apps entirely off of 360K floppies?) In that case, UPX may provide an advantage because it will be faster to decompress the EXE into memory once it's loaded from disk than to load the uncompressed one from disk. If you have a decent HD, the space taken on disk is far less of a concern, and there is unlikely to be a load speed advantage loading a compressed executable from disk.) If you can think of reasons why UPX provides an advantage, I'll sit corrected, but the more likely concern is the amount of RAM required, and any magic that must be done to load as much as possible high. ______ Dennis _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
