From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wm3ZG-0000Be-2o for qemu-devel@nongnu.org; Sun, 18 May 2014 12:04:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wm3Z8-000701-JE for qemu-devel@nongnu.org; Sun, 18 May 2014 12:04:06 -0400 Received: from mout.gmx.net ([212.227.17.20]:50409) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wm3Z8-0006zG-9R for qemu-devel@nongnu.org; Sun, 18 May 2014 12:03:58 -0400 Message-ID: <5378DA7A.2070902@caramail.com> Date: Sun, 18 May 2014 18:06:18 +0200 From: Olivier Danet MIME-Version: 1.0 References: <5378AC30.9090900@ilande.co.uk> In-Reply-To: <5378AC30.9090900@ilande.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] target-sparc has inverse cwp logic for SAVE/RESTORE? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland , qemu-devel Cc: Blue Swirl , Richard Henderson On 18/05/2014 14:48, Mark Cave-Ayland wrote: > Hi all, > > I've been working on debugging a window-related OpenBIOS issue and noticed that the cwp register logic in QEMU appears to be backwards according to the SPARCv9 specification. From sections 6.3.6.1 and 6.3.6.2: > > "The SAVE instruction allocates a new register window and saves the caller’s register window by incrementing the CWP register." > > "The RESTORE instruction restores the previous register window by decrementing the CWP register." > > In target-sparc/win_helper.c the logic in helper_save() and helper_restore() is inverted, i.e. executing SAVE decrements cwp while executing RESTORE increments cwp. > > The surprise here was that executing SAVE when cwp == 0 changed cwp to 7 rather than 1. AFAICT there should be no functional difference, but it would make things less confusing when debugging window traps if the logic from the specification was followed. Does anyone know why this is currently done this way? > > > ATB, > > Mark. > The problem may be related to the fact that the 32bits SPARCv8 and 64bits SPARCv9 work in opposite directions ! SparcV9 standard, page 360/399 : The SPARC-V9 CWP register is incremented during a SAVE instruction and decremented during a RESTORE instruction. Although this is the opposite of PSR.CWP’s behavior in SPARC-V8, the only software it should affect is a few trap handlers that operate in privileged mode, and that must be rewritten for SPARC-V9 anyway. This change will have no effect on nonprivileged software. Olivier