Article View: comp.sys.amiga.tech
Article #6787Re: C compilers code generation
From: Matthew Dillon
Date: Sat, 17 Nov 1990 18:22
Date: Sat, 17 Nov 1990 18:22
63 lines
3439 bytes
3439 bytes
In article <1990Nov15.170810.5868@sisd.kodak.com> jeh@sisd.kodak.com (Ed Hanway) writes:
>dillon@overload.Berkeley.CA.US (Matthew Dillon) writes:
>> Well, actually, while the built-in stuff is cute it is also pretty
>> useless in most cases. For example, the code for a 'full' version of
>> setmem()/memset(), movmem()/memmov(), etc.... is pretty big, but also
>> can be a hell of a lot faster (using MOVEM's or at least long ops
>> instead of char ops). I think the only real builtin function that
>> is useful is, maybe, strlen().
>
>__builtin_strlen() is definitely useful. SAS/C evaluates
>strlen("string constant") at compile time. I don't know how good the
>builtin versions of the other functions are, but if the compiler knows
>anything about arguments to the function at compile time, it can
>use different versions of the move/set code for small/large size,
>aligned/unaligned, etc. If no information is available, it can always
>call the general routine.
Uh, I NEVER use strlen() on a string constant. That's the most
ridiculous thing I've ever heard of in my life!
I use (sizeof("string-constant") - 1). And, if you are worried about
things looking 'neat', simply write a little preprocessor macro to do
it.
No, I was thinking strlen() is useful as a builtin function -- one of
the few -- because it takes just a little more code than the equivalent
call (push/jsr/addq.l#4,sp) would take.
>Also, because the compiler knows about any side-effects of the builtin, it
>can optimize the code around the builtin more than if it was just an arbitrary
>function call.
About the only thing the compiler can optimize are the stupid mistakes
either it or the programmer makes ... useless, because only relatively
good programmers are worried about such trivial optimizations and they
do not make the mistakes in the first place.
Many optimizations fall into that category .. reading the description
makes you feel good because your compiler is 'optimizing' but the
reality is that they do not do a pittling thing. Inexperienced
programmers do not code well enough for them to make much of a
difference, and experienced programmers code well enough that they do
not make much of a difference either. Of course, there are many, many
optimizations that *do* do major good things, but a small plethora of
'built in' functions is not one of them. Really a huge waste of time;
As far as I can, lattice would have spent their time better on other
optimizations.
-Matt
>--
>Ed Hanway --- uunet!sisd!jeh
>Some of the trademarks mentioned in this product are for identification
>purposes only. All models are over 18 years of age.
--
Matthew Dillon dillon@Overload.Berkeley.CA.US
891 Regal Rd. uunet.uu.net!overload!dillon
Berkeley, Ca. 94708
USA
Technical Details
Message-ID:
<dillon.7260@overload.Berkeley.CA.US>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!overload!dillonReferences:
<1990Nov12.164804.5490@agate.berkeley.edu> <26893.273fe96d@kuhub.cc.ukans.edu> <dillon.7256@overload.Berkeley.CA.US> <1990Nov15.170810.5868@sisd.kodak.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: C compilers code generation Message-ID: <dillon.7260@overload.Berkeley.CA.US> Date: 17 Nov 90 18:22:25 GMT References: <1990Nov12.164804.5490@agate.berkeley.edu> <26893.273fe96d@kuhub.cc.ukans.edu> <dillon.7256@overload.Berkeley.CA.US> <1990Nov15.170810.5868@sisd.kodak.com> Lines: 63