This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Gordon Matzigkeit wrote: > > Hi! > > >>>>> "Gord" == Gordon Matzigkeit <gord@trick.fig.org> writes: > >>>>> Karl M Hegbloom writes: > > KMH> ... Why does it first << 8 and then right away do >> 8, > KMH> recompute and compare like that? How could the value change? > > Gord> (x << 8) >> 8 == x with the top 8 bits cleared > > KMH> Ok, so wouldn't it be faster to use (x & 0xff)? > > Only if X is a 16-bit variable. For a long on a 32-bit machine, you'd > want (x & 0xffffff), so ideally you'd make the compiler do all that > dirty work for you: (x & (((unsigned long) -1) >> 8)). > > But there's one more complication: sign extension. When you > right-shift a signed quantity that is negative, the new high bits get > set rather than cleared. Um, is this necessarily true? I searched all the C/C++ reference books I can find on my bookshelf, and although the newest one I have is from 1991 (Stroustrop, "The C++ Programming Language", 2.ed), they all say: "The value of E1 >> E2 is E1 right-shifted E2 bits. The right shift is guaranteed to be logical (0-fill) if E1 has an unsigned type or if it has a non-negative value; otherwise the result is implementation dependent." I ran t.c through all the compilers I could find (HP-UX, SOLARIS, Digital UNIX, AIX, Visual C++); they all generated arithmetic right shifts for the signed long value. Did the standard get amended somewhere along the line? Greetings, Jim -- =================================================================== James S. Rauser rausejme@kou3.ina.de Ina Werk Schaeffler KG/Abt. KOU3 +49 9132 82 32 43 Industriestrasse 1-3 91074 Herzogenaurach, Germany