Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Comparing strings...
Message-ID: <1990Oct15.223716.10793@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <11486@alice.att.com> <3343@idunno.Princeton.EDU> <1990Oct15.042851.18595@zoo.toronto.edu> <3353@idunno.Princeton.EDU>
Date: Mon, 15 Oct 90 22:37:16 GMT

In article <3353@idunno.Princeton.EDU> pfalstad@dry.Princeton.EDU (Paul John Falstad) writes:
>You're right, I forgot to convert back to int; but no, it doesn't
>matter where you do the `conversions,' as you call them, though that
>word implies that the compiler is generating instructions to actually
>convert the data from signed to unsigned.  What it is really doing is
>generating different instructions to handle c and d as unsigned chars.

On *some* machines, it generates different instructions, and if you're
lucky, there is no speed difference.  But on many machines, there is
only one kind of character-access instruction, and if what you ask
for isn't what it delivers, then yes, the compiler really does have
to generate instructions to do the conversion.  Since signed-char
machines considerably outnumber unsigned-char machines, and only the
latest architectures give you a choice, the odds are pretty good that
those conversions to unsigned will cost you.

The reason why there is a "char" type, with no promises made about whether
it is signed or unsigned, is precisely that making the right choice
*makes a big difference to speed* on a lot of machines.

>In fact, I tried both ways, compiling with gcc -O -S; doing the
>conversions outside the loop actually generated more instructions on my
>SPARCstation...

I'm afraid this sounds like you are either a believer in "proof by example"
or a victim of Sun propaganda.  Most machines are not SPARCs.
-- 
"...the i860 is a wonderful source     | Henry Spencer at U of Toronto Zoology
of thesis topics."    --Preston Briggs |  henry@zoo.toronto.edu   utzoo!henry