1 files changed, 100 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/105/instruction/1721275 b/results/classifier/zero-shot/105/instruction/1721275
new file mode 100644
index 000000000..d5dbab8e2
--- /dev/null
+++ b/results/classifier/zero-shot/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])
+