qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Simulating a composite machine


From: Peter Maydell
Subject: Re: [Qemu-devel] Simulating a composite machine
Date: Tue, 21 Aug 2018 09:57:55 +0100

On 20 August 2018 at 19:29, Martin Schroeder
<address@hidden> wrote:
> Ok so FPU support is not there. What would it take for me to add it? I
> would very much like to add it if I get some guidance as to what needs
> to be done and where I can find information on how to do it. I see
> there is some code in fpu/softfloat.c but I guess it is not enough?

As I say, it's mostly the exception handling parts (and also some
things like M profile having memory mapped registers for the FPU
ID registers). The instructions themselves are the same as the
A-profile FPU.

My summary breakdown of this task looks like:
 * check which instructions we need to enable and which parts
   of the current FP implementation are A/R specific and need
   "not if M" conditionals
   (this is going to involve some comparison-of-specifications
   between the M-profile architecture spec manual and the A-profile
   one. The answer is probably going to wind up being "the
   A-profile-style FPU status and control register accesses
   need to be disabled", but there might be more. You can assume
   that the actual behaviour of each instruction is the same, though.)
 * implement the status and ID registers that M profile wants
   (mostly wiring up register accessors in hw/intc/armv7m_nvic.c
   to existing CPU state fields, I think)
 * exception model changes for FP (new exception frame layout, etc)
   -- this is all code in target/arm/helper.c which now needs to
   handle the possibility of an FPU. The pseudocode in the ARMv7M
   and v8M manuals will help in identifying where changes need
   to be made.
 * make sure co-processor enable/disable is wired up right
   (the coprocessor access is handled via a memory-mapped register)
 * implement lazy saving of FP registers (complicated; when the
   CPU status registers indicate that lazy-state-preservation is
   in effect, we need to arrange that attempting to execute an
   FP insn causes us to first stop and save the FPU state to the
   stack, and then do the instruction. The best way to do this is
   going to be to add a TB flag for "lazy state preservation required",
   and if that flag is set then when we encounter an FP insn we
   generate code for "raise a lazy-stacking exception". We can
   then deal with the exception by "do the lazy-stacking, then
   resume execution".
 * turn this on for Cortex-M4, Cortex-M33 and test

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]