Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: C compilers code generation Message-ID: Date: 15 Nov 90 02:08:22 GMT References: <1990Nov12.135444.10739@cs.utwente.nl> <1990Nov12.164804.5490@agate.berkeley.edu> <26893.273fe96d@kuhub.cc.ukans.edu> Lines: 29 In article <26893.273fe96d@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >Dont forget about SAS/Lattice's support for __builtin functions like >memcpy, memset, etc that use inline code rather than function calls. >(By flipping the compiler switch for processor you can also get such >loops to use DBxx loops for 68010 and 32 bit instructions for 68020). 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(). This applies to all processors since a DBxx loop using a BYTE transfer size is still a BYTE transfer loop, even if all the instructions are cached. The DBxx loops are nothing more than a simple optimization in my book, though one that DICE does not currently do. Frankly, I just do not see any advantage and it can be *really* confusing. >-- -Matt Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA