Messages in this thread | | | Date | Fri, 12 May 2006 17:18:11 +0200 (MEST) | From | Jan Engelhardt <> | Subject | Re: www.softpanorama.org: sparc_vs_x86 fun |
| |
>> while on SPARC, it takes 6 instructions (of course, being RISC makes it >> execute differently than x64) >> >> sethi %g1, $some_upper_bits >> or %g1, $next_bitgroup >> (shift-left) >> or %g1, $next_bitgroup >> (shift-left) >> or %g1, $last_bitgroup >> >> BTW, T1 is cool, but that the 1U version only has space for 1 disk is >> pretty limiting :/ > > I have to believe that you can load 64 bit constant data from memory and > don't have to do all this dancing with immediate loads. Therefore this > must be faster or they wouldn't do it this way. Or is this a point that > some unoptimized compiler could generate this code?
gcc 4.1.0 -m64. (Debian unstable) I also tried gcc version 4.0.0 20041019 (Red Hat 4.0.0-0.8sparc) <Aurora SPARC> -m64
generating (`objdump -DS test.o`)
0000000000000000 <main>: #include <stdio.h> int main(void) { 0: 9d e3 bf 40 save %sp, -192, %sp return printf("%lld\n", 0x12345678abcdefULL); 4: 03 00 00 00 sethi %hi(0), %g1 8: 90 10 60 00 mov %g1, %o0 ! 0 <main> c: 03 00 04 8d sethi %hi(0x123400), %g1 10: 82 10 60 56 or %g1, 0x56, %g1 ! 123456 <main+0x123456> 14: 85 28 70 20 sllx %g1, 0x20, %g2 18: 03 1e 2a f3 sethi %hi(0x78abcc00), %g1 1c: 82 10 61 ef or %g1, 0x1ef, %g1 ! 78abcdef <main+0x78abcdef> 20: 92 00 80 01 add %g2, %g1, %o1 24: 40 00 00 00 call 24 <main+0x24>
Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |