From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MdoGI-0001v9-OQ for qemu-devel@nongnu.org; Wed, 19 Aug 2009 12:43:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MdoGI-0001uj-4l for qemu-devel@nongnu.org; Wed, 19 Aug 2009 12:43:46 -0400 Received: from [199.232.76.173] (port=59370 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MdoGH-0001ua-RZ for qemu-devel@nongnu.org; Wed, 19 Aug 2009 12:43:45 -0400 Received: from fg-out-1718.google.com ([72.14.220.153]:16175) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MdoGE-0007QF-TP for qemu-devel@nongnu.org; Wed, 19 Aug 2009 12:43:44 -0400 Received: by fg-out-1718.google.com with SMTP id d23so1253565fga.8 for ; Wed, 19 Aug 2009 09:43:41 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Wed, 19 Aug 2009 19:43:21 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: target-sparc/TODO List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: qemu-devel On Wed, Aug 19, 2009 at 1:17 PM, Artyom Tarasenko wrote: > 2009/8/17 Blue Swirl : >> On Mon, Aug 17, 2009 at 1:52 PM, Artyom >> Tarasenko wrote: >>>> - Global register for regwptr, so that windowed registers can be >>>> accessed directly >>> >>> looks like it's already implemented? >> >> No, this means that a global register (TCG_AREG1) would be designated >> as regwptr, so that the window registers (%o, %l, %i) would be defined >> with: >> >> cpu_wregs[i] =3D tcg_global_mem_new(TCG_AREG1, offsetof(...), name). >> >> This would need some changes to cwp handling to support TCG_AREG1, >> maybe also to TCG prologue. >> >> Before TCG, this was difficult because the registers were taken by >> cpu_T0, cpu_T1 and cpu_T2. >> >> But it's not clear if this gives any performance gain, because >> although window registers accesses may get faster (this is also not >> certain because CPUstate should reside in cache), there is one host >> register less available and that may mean more host memory accesses. > > So, it's only about performance, otherwise the current implementation > is complete? Yes. Sparc64/V9 side is less complete. >>>> - Synthetic instructions >>> Is it still open? >> >> We already handle 'clr' and 'mov'. Code generation is not optimal, for >> example arithmetic ops with constants/%g0 or things like wrpsr which >> always does a XOR of the parameters even if they are constants or %g0. > > Would the synthetic ops with %g0 produce wrong results? > Particularly I'm interested if > > jmp =C2=A0 =C2=A0 %l1, %g4, %g0 > > may behave other than on a real hw. No, if rd is %g0, the current PC will not be written anywhere (not by real HW either). This is handled by translate.c:4041 call to gen_movl_TN_reg(), which suppresses the move if rd is zero. Likewise for other rd writeback. This class of instructions ("op %x, %y, %g0") should be close to optimal except for degenerate cases like "and %g1, 1, %g0" which should not generate any code at all. "andcc %g1, 1, %g0" should and it does. I meant that "wrpsr %g1, 0" (or %g0) should suppress the useless XOR of %g1 and 0. >>>> - Hardware breakpoint/watchpoint support >>> Is it still open? >> >> I think support for these was only found in a few CPU models, so they >> are not used much. Nobody has also shown any interest or provided a >> test case. > > > On OBP start-up I see some "write breakpoint reg" messages in the > debug log. Do they have to do with hardware breakpoint support? > Yes, or they could also be MMU breakpoint registers.