On 23/09/2019 20.45, Peter Maydell wrote: > On Mon, 23 Sep 2019 at 19:09, Thomas Huth <th...@redhat.com> wrote: >> However, there's one thing I currently don't quite understand in this >> code (since I'm not an ARM guy, sorry) : There are references to "v8" in >> m_helper.c, too. Is that related to a separate CPU type, ie. should the >> v8 code also be available when CONFIG_ARM_V7M is disabled? Or can the >> code in m_helper.c be disabled completely if CONFIG_ARM_V7M is not set? > > QEMU's naming conventions here is a bit confusing, for > historical reasons. > > Architecturally what we have is: > * "M-profile" -- this is the flavour of Arm architecture for > microcontrollers; it has some big differences from A and R > profile (eg the exception mechanism is different and it has > a built-in NVIC interrupt controller). All the Cortex-M<anything> > CPUs are M-profile > * "Arm-v7M" -- this is the v7 flavour of the M-profile > architecture, eg Cortex-M3. > * "Arm-v6M" -- this looks like it ought to mean "v6 flavour > of M-profile", but if you look at what features it has it's > more like "cut down version of v7M" (fewer instructions, cut > down exception model, etc, but some things which on A-profile > don't appear until v7A are present in v6M). Cortex-M0 and -M1. > * "Arm-v8M" -- v8 flavour of M-profile. The big change here > is support for TrustZone. Cortex-M33. v8M comes in two > sub-profiles: "mainline", which has all the features like v7M, > and "baseline", which is cut-down in the same way v6M is a > cut-down v7M. > > In QEMU, we implemented Cortex-M3 first, and then added -M0 and > -M33 later. So mostly our function naming convention uses > "v7m" when it means "any M-profile"; a few v8M-specific > functions use a "v8m" prefix. Everything in m_helper.c is > M-profile specific; most of it is used by all M-profile cores, > and a few bits are v8M-only or v7M-and-v8M-mainline only. > > From a CONFIG switch point of view I don't think it's > worth being able to #ifdef out the various flavours of > M-profile individually.
Ok, thanks a lot for the explanation! It's much clearer to me now. So I think it likely would be best to disable the whole m_helper.c code instead of introducing a new file like v7m.c (but that likely requires a stub file instead or some #ifdeffing in translate.c). It also sounds like CONFIG_ARM_V7M should rather be renamed to CONFIG_ARM_MPROFILE or something similar? Thomas
