🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #6787

Re: C compilers code generation

#6787
From: Matthew Dillon
Date: Sat, 17 Nov 1990 18:22
63 lines
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!dillon
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>

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