Related articles |
---|
Re: Reduced Machine Description (long) harvard!cs.washington.edu!pardo (1989-02-25) |
Re: Reduced Machine Description (long) henry@zoo.toronto.edu (1989-03-06) |
From: | henry@zoo.toronto.edu |
Date: | Mon, 6 Mar 89 23:37:03 EST |
Newsgroups: | comp.compilers |
In-Reply-To: | <3411@ima.ima.isc.com> |
References: | <3365@ima.ima.isc.com> |
>* The `strcpy' C function is supported directly in hardware by many
> machines. For most string move invocations, the function-call
> overhead is larger than the cost of the string copy, so it very
> nearly ``doesn't matter'' how you implement the strcpy() function.
> The general ``problem'' here is that `strcpy' isn't part of the
> *language*, so there's no way that the compiler can legitimately
> recognize it...
Actually, one can debate the extent to which C's libraries are, or are
not, part of the language. Certainly the necessity to do printf and
longjmp has influenced things like stack-frame design fairly frequently.
X3J11, the ANSI C committee, has resolved this in favor of making the
more basic items in the library part of the language. Yes, a modern C
compiler *can* legitimately recognize and optimize strcpy, although
certain details have to be done right.
Henry Spencer at U of Toronto Zoology
uunet!attcan!utzoo!henry henry@zoo.toronto.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.