* Re: Re: SV: [Qemu-devel] ARM CPSR and conditional instructions @ 2006-11-23 8:05 Torbjörn Andersson 2006-11-23 15:28 ` Paul Brook 0 siblings, 1 reply; 5+ messages in thread From: Torbjörn Andersson @ 2006-11-23 8:05 UTC (permalink / raw) To: qemu-devel [-- Attachment #1: Type: text/plain, Size: 3501 bytes --] We are currently debugging the situation and we are actually not sure about the real reason for our current situation. However, we have seen that the condition bits in CPSR differers compared to one other arm instruction set simulator, running the same binary. This indicate for us that there might be something wrong i QEMU (translate.c op.c for ARM). However, it is not proven yet. However, our understanding for the situation would improve if the strategy for simulating the conditional execution of ARM instructions is understood. Is a conditional ARM instruction treated as a branch-point, an end marker for a TB? If not, jumps qemu within a TB? Is it possible to describe the strategy with a reasonable effort? I would be very greatfull. /Torbjörn > Från: Wolfgang Schildbach <Wolfgang.Schildbach@codingtechnologies.com> > Till: qemu-devel@nongnu.org > Rubrik: Re: SV: [Qemu-devel] ARM CPSR and conditional instructions > Datum: Thu, 23 Nov 2006 08:43:50 +0100 > 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? > > - Wolfgang > > qemu-devel-bounces+wolfgang.schildbach=codingtechnologies.com@nongnu.org > 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örn > > > > Från: qemu-devel-bounces+tobbe.tt_home.se=spray.se@nongnu.org > > [mailto:qemu-devel-bounces+tobbe.tt_home.se=spray.se@nongnu.org] För > > Torbjörn Andersson > > Skickat: den 21 november 2006 22:16 > > Till: qemu-devel@nongnu.org > > Ämne: [Qemu-devel] ARM CPSR and conditional instructions > > > > Hello qemu developers! > > > > I´m 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örn > > _______________________________________________ > > Qemu-devel mailing list > > Qemu-devel@nongnu.org > > <a > href=http://lists.nongnu.org/mailman/listinfo/qemu-devel>http://listsnongnu > .org/mailman/listinfo/qemu-devel</a> > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > <a > href=http://lists.nongnu.org/mailman/listinfo/qemu-devel>http://listsnongnu > .org/mailman/listinfo/qemu-devel</a> Kärlek och hur mycket pengar? Få svar idag om din morgondag! http://horoskop.spray.se/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SV: [Qemu-devel] ARM CPSR and conditional instructions 2006-11-23 8:05 Re: SV: [Qemu-devel] ARM CPSR and conditional instructions Torbjörn Andersson @ 2006-11-23 15:28 ` Paul Brook 0 siblings, 0 replies; 5+ messages in thread From: Paul Brook @ 2006-11-23 15:28 UTC (permalink / raw) To: qemu-devel; +Cc: Torbjörn Andersson > However, we have seen that the condition bits in CPSR differers compared to > one other arm instruction set simulator, running the same binary. This > indicate for us that there might be something wrong i QEMU (translate.c > op.c for ARM). However, it is not proven yet. The only restriction it that you can't set the N and Z bits simultaneously. This never occurs under normal circumstances, only if you directly modify the CPSR value. > However, our understanding for the situation would improve if the strategy > for simulating the conditional execution of ARM instructions is understood. > > Is a conditional ARM instruction treated as a branch-point, an end marker > for a TB? If not, jumps qemu within a TB? > Is it possible to describe the strategy with a reasonable effort? I would > be very greatfull. A TB is terminated at a branch, and at some instructions that modify system state (eg. moves to system registers, and the svc and bkpt instructions). Conditional instructions do not terminate the TB unless they are conditional branches. Paul ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Qemu-devel] ARM CPSR and conditional instructions @ 2006-11-21 21:16 Torbjörn Andersson 2006-11-22 21:13 ` SV: " Torbjörn Andersson 0 siblings, 1 reply; 5+ messages in thread From: Torbjörn Andersson @ 2006-11-21 21:16 UTC (permalink / raw) To: qemu-devel [-- Attachment #1: Type: text/plain, Size: 1000 bytes --] Hello qemu developers! I´m 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örn [-- Attachment #2: Type: text/html, Size: 2888 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* SV: [Qemu-devel] ARM CPSR and conditional instructions 2006-11-21 21:16 Torbjörn Andersson @ 2006-11-22 21:13 ` Torbjörn Andersson 2006-11-23 7:43 ` Wolfgang Schildbach 0 siblings, 1 reply; 5+ messages in thread From: Torbjörn Andersson @ 2006-11-22 21:13 UTC (permalink / raw) To: qemu-devel [-- Attachment #1: Type: text/plain, Size: 1422 bytes --] I’m sorry for spamming you mailing list with my duplicate posts. I had some problems sending my mail. /Torbjörn _____ Från: qemu-devel-bounces+tobbe.tt_home.se=spray.se@nongnu.org [mailto:qemu-devel-bounces+tobbe.tt_home.se=spray.se@nongnu.org] För Torbjörn Andersson Skickat: den 21 november 2006 22:16 Till: qemu-devel@nongnu.org Ämne: [Qemu-devel] ARM CPSR and conditional instructions Hello qemu developers! I´m 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örn [-- Attachment #2: Type: text/html, Size: 5284 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SV: [Qemu-devel] ARM CPSR and conditional instructions 2006-11-22 21:13 ` SV: " Torbjörn Andersson @ 2006-11-23 7:43 ` Wolfgang Schildbach 2006-11-23 18:22 ` Justin Fletcher 0 siblings, 1 reply; 5+ messages in thread From: Wolfgang Schildbach @ 2006-11-23 7:43 UTC (permalink / raw) To: qemu-devel 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? - Wolfgang qemu-devel-bounces+wolfgang.schildbach=codingtechnologies.com@nongnu.org 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örn > > Från: qemu-devel-bounces+tobbe.tt_home.se=spray.se@nongnu.org > [mailto:qemu-devel-bounces+tobbe.tt_home.se=spray.se@nongnu.org] För > Torbjörn Andersson > Skickat: den 21 november 2006 22:16 > Till: qemu-devel@nongnu.org > Ämne: [Qemu-devel] ARM CPSR and conditional instructions > > Hello qemu developers! > > I´m 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örn > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SV: [Qemu-devel] ARM CPSR and conditional instructions 2006-11-23 7:43 ` Wolfgang Schildbach @ 2006-11-23 18:22 ` Justin Fletcher 0 siblings, 0 replies; 5+ messages in thread From: Justin Fletcher @ 2006-11-23 18:22 UTC (permalink / raw) To: qemu-devel [-- Attachment #1: Type: TEXT/PLAIN, Size: 6572 bytes --] 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 about. Within the system I was working the emulation could not get past MMU initialisation before hanging due to the problem. The CPSR only has 3 of the 4 condition flags emulated fully. The 4th is derived from another. For code which uses the regular comparison instructions this will not cause any problems because there is no way to generate a failure case. However, if you directly manipulate the CPSR (eg 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 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 happens to work for me) Specifically, consult target_arm/cpu.h function cpsr_write which provides 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 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 N flag is clear and Z are set. The problem, for the system I was working on, was that in order to change code the sequences similar to this (26bit ARM code which was being converted 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 to support this case. This (mostly) allowed the system to be emulated to the point at which user interaction was possible. The change in cpsr_write which I made was thus : ----- (function cpsr_write) /* NOTE: N = 1 and Z = 1 cannot be stored currently */ if (mask & CPSR_NZCV) { /* JRF: The N=1,Z=1 problem makes for real pain when the system is directly 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 might happen and this limitation of the emulator just has to be accepted. */ if (val & (1u<<30)) /* Z set ? */ val &= ~(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 = (val & 0xc0000000) ^ 0x40000000; env->CF = (val >> 29) & 1; env->VF = (val << 3) & 0x80000000; } ----- Within the code I was working on the Z flag is quite often manipulated 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 the case of negative-zero in the floating point environment being 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=codingtechnologies.com@nongnu.org > 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örn >> >> Från: qemu-devel-bounces+tobbe.tt_home.se=spray.se@nongnu.org >> [mailto:qemu-devel-bounces+tobbe.tt_home.se=spray.se@nongnu.org] För >> Torbjörn Andersson >> Skickat: den 21 november 2006 22:16 >> Till: qemu-devel@nongnu.org >> Ämne: [Qemu-devel] ARM CPSR and conditional instructions >> >> Hello qemu developers! >> >> I´m 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örn >> _______________________________________________ >> 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 > -- Gerph <http://gerph.org/> [ 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. ] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-11-24 23:01 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-11-23 8:05 Re: SV: [Qemu-devel] ARM CPSR and conditional instructions Torbjörn Andersson 2006-11-23 15:28 ` Paul Brook -- strict thread matches above, loose matches on Subject: below -- 2006-11-21 21:16 Torbjörn Andersson 2006-11-22 21:13 ` SV: " Torbjörn Andersson 2006-11-23 7:43 ` Wolfgang Schildbach 2006-11-23 18:22 ` Justin Fletcher
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).