From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ikiha-0007Tr-5M for qemu-devel@nongnu.org; Wed, 24 Oct 2007 12:03:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IkihW-0007Rp-Cd for qemu-devel@nongnu.org; Wed, 24 Oct 2007 12:03:25 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IkihV-0007Rd-ST for qemu-devel@nongnu.org; Wed, 24 Oct 2007 12:03:22 -0400 Received: from miranda.se.axis.com ([193.13.178.8]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IkihV-0008KC-1o for qemu-devel@nongnu.org; Wed, 24 Oct 2007 12:03:21 -0400 Received: from axis.com (edgar.se.axis.com [10.92.151.1]) by miranda.se.axis.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9OG3I3G025616 for ; Wed, 24 Oct 2007 18:03:18 +0200 Date: Wed, 24 Oct 2007 18:03:18 +0200 From: "Edgar E. Iglesias" Subject: Re: [Qemu-devel] qemu-2007-10-24 build error Message-ID: <20071024160318.GA28359@edgar.underground.se.axis.com> References: <20071024003602.0000F11F01F20261@mail6.dreamwiz.com> <1193222005.16781.225.camel@rapid> <20071024123619.GG13076@edgar.underground.se.axis.com> <20071024153349.GB6666@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071024153349.GB6666@networkno.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thiemo Seufer Cc: "J. Mayer" , qemu-devel@nongnu.org, hys545@dreamwiz.com On Wed, Oct 24, 2007 at 04:33:49PM +0100, Thiemo Seufer wrote: > Edgar E. Iglesias wrote: > > On Wed, Oct 24, 2007 at 12:33:24PM +0200, J. Mayer wrote: > > > On Wed, 2007-10-24 at 09:36 +0900, Hwang YunSong(?????????) wrote: > > > > > > > > gcc32 -g -o qemu-system-cris vl.o osdep.o readline.o monitor.o pci.o > > > > console.o loader.o isa_mmio.o cutils.o block.o block-raw.o block-cow.o > > > > block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o > > > > block-bochs.o block-vpc.o block-vvfat.o block-qcow2.o > > > > block-parallels.o irq.o i2c.o smbus.o scsi-disk.o cdrom.o lsi53c895a.o > > > > usb.o usb-hub.o usb-linux.o usb-hid.o usb-ohci.o usb-msd.o usb-wacom.o > > > > eeprom93xx.o eepro100.o ne2000.o pcnet.o rtl8139.o etraxfs.o ptimer.o > > > > etraxfs_timer.o etraxfs_ser.o gdbstub.o sdl.o x_keymap.o vnc.o d3des.o > > > > slirp/cksum.o slirp/if.o slirp/ip_icmp.o slirp/ip_input.o > > > > slirp/ip_output.o slirp/slirp.o slirp/mbuf.o slirp/misc.o slirp/sbuf.o > > > > slirp/socket.o slirp/tcp_input.o slirp/tcp_output.o slirp/tcp_subr.o > > > > slirp/tcp_timer.o slirp/udp.o slirp/bootp.o slirp/debug.o slirp/tftp.o > > > > libqemu.a -lm -lz -lgnutls -L/usr/lib -lSDL -lpthread -lrt -lutil > > > > libqemu.a(helper.o): In function `do_interrupt': > > > > /usr/src/Haansoft/BUILD/qemu/target-cris/helper.c:137: undefined > > > > reference to `__builtin_clz' > > > > libqemu.a(translate-op.o): In function `dyngen_code': > > > > /home/hys545/qemu/cris-softmmu/op.h:1566: undefined reference to > > > > `__builtin_clz' > > > > libqemu.a(op.o): In function `op_lz_T0_T1': > > > > /usr/src/Haansoft/BUILD/qemu/target-cris/op.c:1009: undefined > > > > reference to `__builtin_clz' > > > > collect2: ld returned 1 exit status > > > > > > It does not seem to be a good idea, imho, to use gcc builtins directly > > > from micro-ops. But your compiler should implement __builtin_clz. As far > > > > Hi, > > > > I submitted a patch that at compile-time fallbacks to clz code without builtins. Do you see any additional issues with using the builtins? > > > > I think the speed-up with GCC ports implementing fast builtin variants of operations like clz would be significant enough to justify their use but if there is disagreement I'll send in a new patch removing the builtin_clz alltogether. > > If the builtin ends up calling into libgcc (this can happen depending > on the host / host compiler), then the dynamic code generation breaks. > > It is safer not to force the compiler to use builtins. Right, if calls are made things could break. Thanks for clarifying that. Here's a new patch to remove the builtin altogether. When building the system simulator for CRIS I found another one which will cause build problems with older GCC's so I replaced that one aswell. Best regards -- Edgar E. Iglesias Axis Communications AB diff --git a/target-cris/helper.c b/target-cris/helper.c index 3db3bea..43fcdd1 100644 --- a/target-cris/helper.c +++ b/target-cris/helper.c @@ -87,6 +87,32 @@ static void cris_shift_ccs(CPUState *env) env->pregs[SR_CCS] = ccs; } +static int cris_clz(uint32_t x) +{ + int n; + /* Binary search for leading zeros. */ + + n = 1; + if ((x >> 16) == 0) { + n = n + 16; + x = x << 16; + } + if ((x >> 24) == 0) { + n = n + 8; + x = x << 8; + } + if ((x >> 28) == 0) { + n = n + 4; + x = x << 4; + } + if ((x >> 30) == 0) { + n = n + 2; + x = x << 2; + } + n = n - (x >> 31); + return n; +} + void do_interrupt(CPUState *env) { uint32_t ebp, isr; @@ -135,7 +161,7 @@ void do_interrupt(CPUState *env) } irqnum = 31 - - __builtin_clz(env->pending_interrupts); + cris_clz(env->pending_interrupts); irqnum += 0x30; ebp = env->pregs[SR_EBP]; isr = ldl_code(ebp + irqnum * 4); diff --git a/target-cris/op.c b/target-cris/op.c index 3ce9888..12188b4 100644 --- a/target-cris/op.c +++ b/target-cris/op.c @@ -1006,7 +1006,28 @@ void OPPROTO op_lz_T0_T1 (void) if (T1 == 0) T0 = 32; else - T0 = __builtin_clz(T1); + { + /* Binary search for leading zeros. */ + + T0 = 1; + if ((T1 >> 16) == 0) { + T0 = T0 + 16; + T1 = T1 << 16; + } + if ((T1 >> 24) == 0) { + T0 = T0 + 8; + T1 = T1 << 8; + } + if ((T1 >> 28) == 0) { + T0 = T0 + 4; + T1 = T1 << 4; + } + if ((T1 >> 30) == 0) { + T0 = T0 + 2; + T1 = T1 << 2; + } + T0 = T0 - (T1 >> 31); + } RETURN(); }