Messages in this thread | | | Date | Wed, 19 Jan 2000 08:26:52 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Recent change in tcp_output.c is surely wrong |
| |
Jamie Lokier <lkd@tantalophile.demon.co.uk> >GCC and probably most C compilers do that but it is not guaranteed by C >in general. Maybe all known x86 compilers use sar. However, I am sure >there have been C compilers that donn't use arithmetic shifts. If only >I could remember which ones :-)
SGI for one Sun E10K compilers for another Cray SV1 for a third (I also tested a "unsigned short", which didn't work on the SV1 - sizeof(unsigned short) was 8 bytes and the assignment masked off the high order bits...) Cray T3E for a fourth (although it did say an "unsigned short" was 8 bytes too, and did work - the actual storage for unsigned short was 64 bits - the assignment did not mask off the high order bits...) The CPU for T3 is 450Mhz Alpha chips.
It does point out some of the data size portability problems though.
I did modify the program slightly:
#define INT_TYPE unsigned short #define BITS (sizeof(INT_TYPE)*8-1) int main() { INT_TYPE xxx = 1;
printf("bits=%d\n",BITS); printf("%08x (%d)\n", xxx, xxx); xxx <<= BITS; printf("%08x (%d)\n", xxx, xxx); xxx >>= BITS; printf("%08x (%d)\n", xxx, xxx); return 0; }
Just to see what the differences would be.
Intel Pentium (Linux 2.0.33) bits=15 00000001 (1) 00008000 (32768) 00000001 (1)
SGI (Irix 6.5.3) bits=15 00000001 (1) 00008000 (32768) 00000001 (1) Sun E10K (Solaris 2.7) bits=15 00000001 (1) 00008000 (32768) 00000001 (1) Cray SV1 bits=63 ---- (surprise...) 00000001 (1) 00000000 (0) ---- correct results given 63 bit shift 00000000 (0) ---- of a 16 bit value
Cray T3E bits=31 ---- small surprise 00000001 (1) 80000000 (2147483648) ---- surprise - incorrect results given 63 bit 00000001 (1) ---- shift of 16 bit value
------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |