Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!mailrus!umix!uunet!mcvax!ukc!its63b!aiva!jeff
From: jeff@aiva.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.sys.m6809
Subject: Re: Don't use Scanf()
Keywords: C, Lisp, compilers, optimization
Message-ID: <314@aiva.ed.ac.uk>
Date: 2 Apr 88 19:09:19 GMT
References: <2401@ihwpt.ATT.COM> <320@c10sd1.StPaul.NCR.COM> <1185@ucsfcca.ucsf.edu> <9241@sunybcs.UUCP> <960@micomvax.UUCP> <2108@svax.cs.cornell.edu>
Reply-To: jeff@uk.ac.ed.aiva (Jeff Dalton)
Organization: Dept. of AI, Univ. of Edinburgh, UK
Lines: 45

In article <2108@svax.cs.cornell.edu> belmonte@sleepy.cs.cornell.edu
(Matthew Belmonte) writes:
] 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.

] 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.

It turns out that Lisp compilers do make such optimizations.  Since
just about everything is a function call in Lisp, the only way to get
anything done in-line (adding numbers, say, or extracting a record
field) is to compile some code that doesn't call the functions that
appear to do these operations.  And as long as you're doing that, you
might as well make some simplifications when possible.

As a result, it is difficult to make the distinction between the
language and the standard library as sharp as it is in C: Lisp doesn't
just say that all functions are library.  However, not all functions
can be optimized in this way, only ones that are allowed to be
compiled in-line.  The programmer often has some control over this,
but details vary from Lisp to Lisp.  In Common Lisp, you can declare
something NOTINLINE.

] 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.

The problem is that you need to know when the library routine is
called and when it isn't, and this rule has to be simple and
nonrandom.  C does not solve this problem completely, because the user
may depend on aspects of standard functions that are not part of the
compiler's contract.  For example, the user may want printf to provide
formatted output in a certain way, not just to have certain argument
and result types.

-- Jeff

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton