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
Freedos-user mailing list

Reply via email to