Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!kodak!sisd!jeh From: jeh@sisd.kodak.com (Ed Hanway) Newsgroups: comp.sys.amiga.tech Subject: Re: C compilers code generation Message-ID: <1990Nov15.170810.5868@sisd.kodak.com> Date: 15 Nov 90 17:08:10 GMT References: <1990Nov12.164804.5490@agate.berkeley.edu> <26893.273fe96d@kuhub.cc.ukans.edu> Sender: news@sisd.kodak.com Organization: Printer Products Division Eastman Kodak Lines: 23 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. 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. -- 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.