From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Md67G-0007Wd-Fm for qemu-devel@nongnu.org; Mon, 17 Aug 2009 13:35:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Md67F-0007WD-J4 for qemu-devel@nongnu.org; Mon, 17 Aug 2009 13:35:30 -0400 Received: from [199.232.76.173] (port=42561 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Md67F-0007W4-D7 for qemu-devel@nongnu.org; Mon, 17 Aug 2009 13:35:29 -0400 Received: from fg-out-1718.google.com ([72.14.220.158]:26842) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Md67E-0001eU-Vo for qemu-devel@nongnu.org; Mon, 17 Aug 2009 13:35:29 -0400 Received: by fg-out-1718.google.com with SMTP id d23so805498fga.8 for ; Mon, 17 Aug 2009 10:35:27 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Mon, 17 Aug 2009 20:35:07 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Artyom Tarasenko Cc: qemu-devel 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. >> - 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. >> - 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.