From 7540944539973515074 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,fea2c3a38bda88aa X-Google-Attributes: gidf78e5,public From: "Paul D. DeRocco" Subject: Re: memcmp source Date: 1997/12/13 Message-ID: <34921798.9351A27@ix.netcom.com>#1/1 X-Deja-AN: 298032161 References: <01bd073a$216f93e0$245b9b26@GMorris.dallasmfg.com> X-Original-Date: Sat, 13 Dec 1997 00:05:28 -0500 Organization: The Booboisie X-NETCOM-Date: Fri Dec 12 9:07:07 PM PST 1997 X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBNJOJ7ky4NqrwXLNJAQGhFgIAiWkJoiJoCXu9tl9tiYqkk2pZQE8T01Ev FwY+0QVli9SYv/gKIDH6ACZcjHXRWUqdebpU1FlnEGg92kSFsrCEZA== =QCsL Newsgroups: comp.std.c++ Originator: austern@isolde.mti.sgi.com Glenn Morris wrote: > > Can anyone tell me how memcmp() would be implemented under most systems? > Specifically, would it be implemented in C or assembler? A good compiler will recognize that particular library function, and turn it into carefully optimized inline code. On Intel processors, there's a repeated string op that can do the comparison without bothering to fetch the comparison instruction over and over again. This is what Borland compiles it into. It could also be implemented as a call to a library routine which is hand coded in assembler, which would provide even greater optimization opportunity, at the cost of a call. A really aggressive implementation might compare up to three bytes until one of the operands is dword aligned, and then do the bulk of the comparison a dword at a time to conserve bus bandwidth. However, since most uses of memcmp are probably on short strings, I doubt it would be worth the setup overhead. -- Ciao, Paul --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]