Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bu.edu!dartvax!eleazar.dartmouth.edu!anarch
From: anarch@eleazar.dartmouth.edu (The Anarch)
Newsgroups: comp.sys.apple2
Subject: Re: Computer capabilities
Keywords: Do not meddle in the affairs of wizards: it makes them soggy and hard
Message-ID: <1990Dec31.233636.24004@dartvax.dartmouth.edu>
Date: 31 Dec 90 23:36:36 GMT
References: <325@generic.UUCP>
Sender: news@dartvax.dartmouth.edu (The News Manager)
Organization: Patagonian Relativist's Guild
Lines: 44

In article <325@generic.UUCP> ericmcg@pnet91.cts.com (Eric Mcgillicuddy) writes:
>Assembly language on the 65816 edges out the 8088 at almost half the clock
>rate?
>
>I may not have majored in computer science, but doesn't both a compiler and an
>assembler generate machine language? Logically both generate the same code for
>the same problem solution. Therefore a given instruction that is good for
>Assmebler should also be good for Compiler.

Whoa!  Take it from a comptuer science major, it doesn't work like that.
Unfortunately.  The problem is that the flexibility and ease of use
(relatively speaking, of course) of a compiler comes at a cost of decreased
efficiency, due to its rigidity of implementation; the compiler has one fully
generalized way to translate, for example, "for i:=a to b do begin ... end"
which it uses even when circumstances would permit simplification of the
structure (optimizing compilers, yes, I know, but I'm trying to keep this
basic).

>Needless to say, I know little about compiler design, but I have hand compiled
>C code on the 65816 and much of the syntax is directly translatable to
>assembly on a line for line basis (derefencing handles is an exception). 

Syntactically, the structures may be similar and easily mappable, but it is
reliance on this characteristic that leads to the problem above: the more
simple and general your syntactic rules are, the more inefficient the
translation is, but the more refined your syntax becomes, the trickier it is
to make your computer understand it, i.e. write the compiler.

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.  You *could*
write a C program without using any such functions, and it would end up
syntactically very similar to a assembly language program.  But then you're
skipping the best parts of using a high-level language, and you might as
well have written it in assembly anyway.

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!