Xref: utzoo comp.sys.m6809:745 comp.lang.c:8705
Path: utzoo!mnetor!uunet!husc6!bbn!rochester!cornell!svax!belmonte
From: belmonte@svax.cs.cornell.edu (Matthew Belmonte)
Newsgroups: comp.sys.m6809,comp.lang.c
Subject: Re: Don't use Scanf()
Message-ID: <2108@svax.cs.cornell.edu>
Date: 30 Mar 88 20:46:22 GMT
References: <2401@ihwpt.ATT.COM> <320@c10sd1.StPaul.NCR.COM> <1185@ucsfcca.ucsf.edu> <9241@sunybcs.UUCP> <960@micomvax.UUCP>
Reply-To: belmonte@sleepy.cs.cornell.edu (Matthew Belmonte)
Followup-To: comp.sys.m6809
Organization: Cornell Univ. CS Dept.
Lines: 53
Keywords: C stdio library

In article <960@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes:>
>Compilers do not have the ability to understand the functionality of the
>procedures being called and alter the code (and arguments!) accordingly!

What you mean to express by "understand the functionality" appears nebulous to
me.  As I said before, nothing practical prevents one from including the
semantics of standard functions in compilers.  Conversions from one sequence of
statements to another with equivalent semantics can be expressed using
attribute grammars.

>Apart from anything else, the "functionality" of printf and puts is only
>determined at *link* time!

Again, it is unclear to me what you mean by determination of "functionality."
It is true that in a typical compiler, the only optimisations done are
flow-of-control optimisations (e.g. induction variables reduction in strength,
live variable analysis, code motion) and computation and storage optimisations
(e.g. elimination of common subexpressions, copy propagation, constant folding,
register allocation) *within* the code being compiled.  Calls to external
functions  can be treated atomically, as "black boxes" -- but there's no rule
that says they *have* to be.  If a function is part of a standard library, then
rules can be included in the compiler for simplification of those functional
expressions.

To take a simple example, suppose I have a standard function called expt which
takes a floating-point argument and raises it to a power.  Suppose I have a
functional expression "expt(x, 2)".  So rather than calling in my high-powered
expt function it would be much simpler to do a floating-point multiply of x*x.
This is a reduction in strength which encompasses an invocation of a standard
function.  (Suppose I had an exponentiation operator "**" s.t. "x ** y" gives
the value of expt(x, y).  Then there would be no external function involved,
and everything would be straightforward.)

So *why* do we never see semantics of standard functions included in compilers?
Because, in my opinion, it's not worth it.  It makes the compiler dependent on
the standard libraries.  If my compiler's rules assume a particular
implementation of a standard function, then if I change the implementation I'm
liable to have either to change the compiler or to live with inefficient code.

In summary:  There is no inherent limitation of compilers which prevents their
knowing about standard functions.  Despite this, we never see compilers playing
with standard functions, because that would create too much of a tangled mess
of dependencies.  So Fai Lau was being unrealistic in saying that compilers
which don't do this sort of thing are unimaginable.  Yet at the same time, it
is wrong to assert, as Ray Dunn does, that such optimisations are impossible.

Comments are welcome.
-- 
Matthew Belmonte
Internet:	belmonte@sleepy.cs.cornell.edu
BITNET:		belmonte@CRNLCS
*** The Knights of Batman ***
(Computer science 1, College 5, Johns Hopkins CTY Lancaster '87 session 1)