From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gnj06-0000tu-Sa for qemu-devel@nongnu.org; Fri, 24 Nov 2006 16:54:26 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gnj01-0000hm-I6 for qemu-devel@nongnu.org; Fri, 24 Nov 2006 16:54:26 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gnj01-0000hL-Eo for qemu-devel@nongnu.org; Fri, 24 Nov 2006 16:54:21 -0500 Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Gnj01-0003sC-CC for qemu-devel@nongnu.org; Fri, 24 Nov 2006 16:54:21 -0500 Received: from [194.217.242.91] (helo=anchor-post-33.mail.demon.net) by mx20.gnu.org with esmtp (Exim 4.52) id 1GnJHW-0000Ya-Jg for qemu-devel@nongnu.org; Thu, 23 Nov 2006 13:26:43 -0500 Received: from dyn-62-56-111-177.dslaccess.co.uk ([62.56.111.177] helo=buttercup.gerph.org) by anchor-post-33.mail.demon.net with esmtpa (AUTH gerph) (Exim 4.42) id 1GnJFJ-000BlC-BP for qemu-devel@nongnu.org; Thu, 23 Nov 2006 18:24:26 +0000 Received: from localhost (localhost [127.0.0.1]) by buttercup.gerph.org (Postfix) with ESMTP id E03154BEAB for ; Thu, 23 Nov 2006 18:22:59 +0000 (GMT) Date: Thu, 23 Nov 2006 18:22:59 +0000 (GMT) From: Justin Fletcher Subject: Re: SV: [Qemu-devel] ARM CPSR and conditional instructions In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463786496-2037948005-1164305163=:4391" Content-ID: Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463786496-2037948005-1164305163=:4391 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Thu, 23 Nov 2006, Wolfgang Schildbach wrote: > I very much doubt there is any problem with the CPSR. The ARM emulation > has correctly run hundreds of millions of instructions coming from many > different compilers and hand-written assembly. Can you be more precise in > what the effect is that you see? There's definately is a 'problem' with the CPSR, but it's one that's known= =20 about. Within the system I was working the emulation could not get past=20 MMU initialisation before hanging due to the problem. The CPSR only has 3 of the 4 condition flags emulated fully. The 4th is=20 derived from another. For code which uses the regular comparison=20 instructions this will not cause any problems because there is no way to=20 generate a failure case. However, if you directly manipulate the CPSR (eg= =20 by MSR) then you will find that the flags do not operate as expected. This was one of the first things I raised on the mailing list and Fabrice= =20 Bellard responded thus (message posted around 9th September 2006) : > Regarding the N and Z flags, there should be a discussion in the mailing > list. I feel your solution is not more satisfactory than the current one. > Maybe slowing down QEMU a bit would be acceptable by using different > variables for Z and N. (and I quite agree with that - my solution is really no better, but just=20 happens to work for me) Specifically, consult target_arm/cpu.h function cpsr_write which provides= =20 the implementation of the flags. From this you should be able to see that of the NZCV flags, only C and V are independant. N and Z are effectively=20 tied together. N, meaning 'negative', and Z, meaning 'zero' cannot under normal circumstances be set together. If I've remembered correctly, the Z flag will be effectively set whenever= =20 N flag is clear and Z are set. The problem, for the system I was working on, was that in order to change= =20 code the sequences similar to this (26bit ARM code which was being converte= d=20 to 32bit ARM code) : MOV r14, pc TEQP r14, #Z_bit ; toggle Z bit It is necessary to do this (32bit ARM code) : MRS r14, CPSR EOR r14, r14, #Z_bit MSR CPSR_f, r14 which won't work in qemu because the Z bit is tied to the N bit. My solution was to make a small modification to the emulator specifically= =20 to support this case. This (mostly) allowed the system to be emulated to=20 the point at which user interaction was possible. The change in cpsr_write which I made was thus : ----- (function cpsr_write) /* NOTE: N =3D 1 and Z =3D 1 cannot be stored currently */ if (mask & CPSR_NZCV) { /* JRF: The N=3D1,Z=3D1 problem makes for real pain when the system is dire= ctly modifying the PSR values without regard for this particular case -= it is quite common to directly manipulate the PSR to set Z, ignoring that N is already set (because, well, the ARM doesn't care). This change forces the Z flag to over-ride the N flag. If Z is set, N becomes clear. This should just get things working which were attempting to modify just the Z flag. Modifying the N flag through the PSR operations is rarer, and seldom expected - HOWEVER it migh= t happen and this limitation of the emulator just has to be accepted= =2E */ if (val & (1u<<30)) /* Z set ? */ val &=3D ~(1u<<31); /* if so, no N */ /* Of course, we could raise a warning here, but the results would be so spamtastic that I really don't think it's wise. */ /* End JRF */ env->NZF =3D (val & 0xc0000000) ^ 0x40000000; env->CF =3D (val >> 29) & 1; env->VF =3D (val << 3) & 0x80000000; } ----- Within the code I was working on the Z flag is quite often manipulated=20 like this (or with an explicit MSR CPSR_f, #value) but the N flag is seldom cared about in these circumstances. At one point I worried about=20 the case of negative-zero in the floating point environment being=20 transferred to the ARM PSR, but it was outside the work I needed to do and FP code was less used so I decided to not think about it any more - it might not even be a true issue. The reason that this isn't a problem all that often is that people don't tend to directly manipulate the ARM PSR and thus the case is not common. > - Wolfgang > > qemu-devel-bounces+wolfgang.schildbach=3Dcodingtechnologies.com@nongnu.or= g > wrote on 22.11.2006 22:13:01: > >> I?m sorry for spamming you mailing list with my duplicate posts. I >> had some problems sending my mail. >> >> /Torbj=F6rn >> >> Fr=E5n: qemu-devel-bounces+tobbe.tt_home.se=3Dspray.se@nongnu.org >> [mailto:qemu-devel-bounces+tobbe.tt_home.se=3Dspray.se@nongnu.org] F=F6r >> Torbj=F6rn Andersson >> Skickat: den 21 november 2006 22:16 >> Till: qemu-devel@nongnu.org >> =C4mne: [Qemu-devel] ARM CPSR and conditional instructions >> >> Hello qemu developers! >> >> I=B4m using QEMU for some ARM debugging and I have som questions >> regardning the CPSR register. I get the feeling that the CPSR >> condition code bits, representing the results from the ALU, are not >> maintained at all points. Is the JIT in QEMU tailored in any way >> towards GCC output? (Resulting in issues with the output of other >> compilers that make use of the conditional execution of instructions > etc.) >> >> What I want to do is to try to verify QEMU maintains the CPSR >> register and if not fix it. However, it is not trivial identify >> where the updates should be placed. The relationship between >> translate.c and op.c is not trival I must say :) >> I would be happy I anyone here could give me some pointers on how >> the updates of the CPSR register is done today and what the strategy >> is. I guess there are plenty of performance ideas here as in the rest of > qemu. >> >> Does anyone have any reflection on this topic or can anyone give me >> some pointers? >> >> Torbj=F6rn >> _______________________________________________ >> Qemu-devel mailing list >> Qemu-devel@nongnu.org >> http://lists.nongnu.org/mailman/listinfo/qemu-devel > > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > --=20 Gerph [ All information, speculation, opinion or data within, or attached to, this email is private and confidential. Such content may not be disclosed to third parties, or a public forum, without explicit permission being granted. ] ---1463786496-2037948005-1164305163=:4391--