Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: Computer capabilities
Message-ID: <14809@smoke.brl.mil>
Date: 10 Jan 91 17:06:02 GMT
References: <325@generic.UUCP> <1990Dec31.233636.24004@dartvax.dartmouth.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 31

In article <1990Dec31.233636.24004@dartvax.dartmouth.edu> anarch@eleazar.dartmouth.edu (The Anarch) writes:
>Still, you are right to say that C is not to difficult to translate
>structurally.  However, what's going to kill you, as far as code efficiency
>goes, are the predefined functions that C gives you to make your job easier,
>like the I/O and mathematical functions.  These get translated into code that
>is massive and ugly next to what you could do with assembly.

This is simply not true.  If you in fact need the full support of buffered
stream I/O, C's standard I/O facilities (at least when properly implemented)
are a reasonably efficient and clean solution.

As to math functions, practically always they are implemented as function
calls, and the functions to perform them are implemented efficiently, too.

The real overhead penalty is in the more "routine", direct programming
language support.  If you inspect the code generated by available IIGS C
compilers, you should see that it is much less efficient in typical cases
that a specially hand-tailored assembly-language implementation would be.
This is primarily due to the poor match between the 65816 architecture
and what a compiler really needs for effective run-time support.

>To see the effect of using these functions, a good experiment is to get out
>your favorite C compiler, write up the famous "Hello world" program and
>compile to an executable.  How big a file do you end up with?  Now fire up
>the mini-assembler and put together a program that accomplishes the same
>thing.  I would be shocked if it took you more than two dozen bytes, data
>included.  printf(), though, is a *big* function!

C was not designed for the production of trivial programs.  If you
investigate a typical real application, you'll find that most printf()
features are exploited; thus it is not overkill for typical applications.