Re: SV: [Qemu-devel] ARM CPSR and conditional instructions

[Justin Fletcher]

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
>
> address@hidden
> 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: address@hidden
> > [mailto:address@hidden För
> > Torbjörn Andersson
> > Skickat: den 21 november 2006 22:16
> > Till: address@hidden
> > Ä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
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> 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. ]