[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