From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MdiEm-00076T-9K for qemu-devel@nongnu.org; Wed, 19 Aug 2009 06:17:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MdiEh-00075D-Lt for qemu-devel@nongnu.org; Wed, 19 Aug 2009 06:17:47 -0400 Received: from [199.232.76.173] (port=35158 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MdiEh-000754-Ew for qemu-devel@nongnu.org; Wed, 19 Aug 2009 06:17:43 -0400 Received: from mail-gx0-f211.google.com ([209.85.217.211]:37786) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MdiEh-0008RU-4r for qemu-devel@nongnu.org; Wed, 19 Aug 2009 06:17:43 -0400 Received: by gxk7 with SMTP id 7so5593172gxk.8 for ; Wed, 19 Aug 2009 03:17:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Artyom Tarasenko Date: Wed, 19 Aug 2009 12:17:17 +0200 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: target-sparc/TODO List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel 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] = 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? >>> - 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 %l1, %g4, %g0 may behave other than on a real hw. >>> - 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?