Hi, On Sat, Jun 28, 2014 at 8:58 AM, Zbigniew <zbigniew2...@gmail.com> wrote: > 2014-06-28 15:45 GMT+02:00, Mateusz Viste <mate...@viste.fr>: >> >> About size - you should probably get it down a few KiB by compiling into >> a COM binary. From what I saw, you don't use any memory segments, just >> (plenty of) INT calls, so a COM would fit perfectly. Just add -mt -lt to >> your tcc call. And since you don't use any floats, you might also try to >> pass -f-.
Normally the overhead of an .EXE header isn't very big. So switching to .COM won't save that much. You'd honestly have better luck switching compilers entirely (in some cases)! Which of course isn't that easy (dialects, object formats, architectures). >> +of course try UPXing it - you'r likely to shave off a few KiBs again. Yes, UPX saves anywhere from 30%-60%, which is quite a lot! > Thanks, I'll try the above - well, but I'm rather disappointed about > the TC's output generated by default. TP5 made "better" EXE binary > than TC? Actually I was expecting the opposite. Turbo Pascal has a smartlinker while Turbo C does not. (Most C compilers don't, but most Pascal-y compilers do. But BinUtils on ELF (and not COFF!) does have -ffunction-sections -fdata-sections--gc-sections etc. since a while now (2.16?). But *nix usually dynamically links anyways, so it's less obvious. GCC can do some dead code elimination too.) Without a smart linker, you're pretty much stuck to manually fixing it yourself. Most people just ignore the problem. Others just patch things locally. You're pretty much at the mercy of your main system libraries (here, libc). So if the library (and/or runtime) isn't very fine-grained (with small, independent objects), you're stuck unless you work around it. Even that may not be good enough. Sometimes a few compiler switches can help a small bit, but probably not here. It's fairly interesting how different compilers and environments behave. Even GCC on Linux and DJGPP have different strengths and weaknesses. Of course, if the compiler is the exact same, then the fault lies elsewhere (object format, linker, libraries, ABIs). Check the main program .OBJ with some kind of dump utility (similar to *nix "size"), or just compare its pure .ASM output, or read the linker map. That (main .OBJ, code + data) size compared to the final .EXE should give you an idea of which party is to blame. :-) >> If that's not enough, then you still have the option to rewrite it into >> ASM this time ;) > > Surely it would generate the executable of smallest possible size. But > now I'm going to Forth-ify EMODE first... Well, with assembly, you can (or must?) roll everything yourself. So you have no (mandatory) runtimes, no libraries, no lousy linkers, no accidental linkage of anything, no program-wide calling conventions, etc. With DOS, we have the luxury of doing some things at a very low level. Other OSes aren't always as permissive. ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
