diff options
Diffstat (limited to 'results/classifier/105/instruction/1721275')
| -rw-r--r-- | results/classifier/105/instruction/1721275 | 100 |
1 files changed, 100 insertions, 0 deletions
diff --git a/results/classifier/105/instruction/1721275 b/results/classifier/105/instruction/1721275 new file mode 100644 index 00000000..d5dbab8e --- /dev/null +++ b/results/classifier/105/instruction/1721275 @@ -0,0 +1,100 @@ +instruction: 0.778 +other: 0.733 +device: 0.695 +vnc: 0.673 +semantic: 0.609 +assembly: 0.600 +graphic: 0.575 +boot: 0.559 +socket: 0.533 +mistranslation: 0.506 +network: 0.449 +KVM: 0.415 + +Support more ARM CPUs + +Hi, + +This is an enhancement request, rather than a bug report. + +After some discussions/presentations during the last Linaro Connect (SFO17), I understand that it may be easy to add support for more ARM CPUs in QEMU. I am interested in user-mode, if that matters. + +I'm primarily using QEMU for GCC validations, and I'd like to make sure that GCC doesn't generate instructions not supported by the CPU it's supposed to generate code for. + +I'd like to have: +cortex-m0 +cortex-m4 +cortex-m7 +cortex-m23 +cortex-m33 + +cortex-a35 +cortex-a53 +cortex-a57 + +Is it possible? +Is it the right place to ask? +Should I file separate requests for each? + +Thanks + +M0 is hard, because it's v6M which we don't support. M4 we already have (but only the no-fpu variant). M7 we don't currently have -- what would be the differences from M4? M33 is in the works (it's v8M). M23 is harder, because it's v8M-baseline which is the v8M equivalent to v6M. A53 and A57 we already have. How would A35 differ from A53/A57 ? + + +PS: in general I wouldn't unconditionally trust that QEMU emulating CPU X definitely does not implement any instructions that CPU X doesn't have -- no real world code will notice, and we don't have any mechanism to automatically verify that we didn't accidentally forget to conditionalize an instruction on an architecture feature. + + +Thanks for PS, I thought QEMU was stricter than that. + +Regarding M7 vs M$ or A35 vs A53/A57, even though there's no functional difference, it would be convenient in Makefiles to have CPU=cortex-a53, and use $(CPU) to expand GCC and QEMU options, without having to guess which CPU I should use for QEMU that would match the one I pass to GCC. + +Regarding v[68]M, are there any plans to add support for these variants to QEMU? + + +On 16 October 2017 at 14:16, Christophe Lyon +<email address hidden> wrote: +> Thanks for PS, I thought QEMU was stricter than that. + +Well, I hope we get it right, and we'll treat cases where +we get it wrong as bugs, but we're not testing... + +> Regarding v[68]M, are there any plans to add support for these variants +> to QEMU? + +v8M we're working on. v6M we have no plans for currently. + +thankns +-- PMM + + +We now support Cortex-M0 (v6M) and Cortex-M33 (v8M mainline). We don't have Cortex-M7, Cortex-M23 (v8M baseline) or Cortex-A35. + +In general, adding an extra CPU to QEMU really requires us to have a decent use-case for it, probably including a board model for it, especially for the M-profile CPUs. There are a lot of CPUs out there and I'm not too keen on adding large numbers of them unless there's a real need. + +I'm going to close this bug report because I don't think it really adds anything to have it sitting open indefinitely. + + +Regarding Cortex-M7, I've noticed that unlike Cortex-M4, it supports double precision floating-point. Is DP supported by qemu? + + +Yes, QEMU supports DP (I actually had to go to some lengths to disable the DP support for the M4 :-)) + + +How do I activate it since --cpu cortex-m7 isn't supported? + +You can't for an M-profile CPU. It would work without any further coding beyond getting the ID register values right if we had a Cortex-M7 model, though. + + +It seemed "easy" to add cortex-m7 based on cortex-m4 (copy m4 description, update ID register values), but I realized that QEMU does not support FPv5 which not only supports DP, but also adds new instructions that QEMU does not handle yet (see section A2.5 of the ARMv7-M ARM). + +* Are there plans to implement them? +* If not, how difficult is it? (for a developer not very familiar with the QEMU code base) + + +They are implemented, because they also appear in A-profile. +We just need to set the corresponding MVFR field to enable them. + +Setting MVFR2.FPMISC = 4 will do the job, I believe. + +Good news, I thought at least some of them were not implemented because for instance I couldn't find where VRINTA is handled (I noticed code for NEON_2RM_VRINTA, but I thought there should be something in vfp.decode for VRINT[ANPM]) + |