On 21 June 2015 at 09:17, Liviu Ionescu <i...@livius.net> wrote: > while studying the details of cortex-m cores, I ran into the > many differences between existing revisions, especially for > cortex-m3, which are numerous and some significative, like > stack alignment. for example for m3, the changes from r0p0 to > r1p0/r1p1 are one full page of details
Our usual approach is "implement a recent revision". We don't attempt to accurately emulate the foibles of earlier revs, and definitely don't try to emulate the errata. Similarly, we often emulate to an "architecturally correct" level rather than "match the IMPDEF behaviour of a particular implementation". > for this I'm considering extending the naming scheme for > cortex-m cores, to include the revision, like "cortex-m3-r2p1", > which will define the fields in CPUID correctly. I think these should probably be cpu object properties, if we do them at all. Non-buggy guest code should not care whether it is running on an r2p1 or an r2p0, so mostly trying to provide lots of rev/patchlevel variations just means we get an accumulation of very similar CPUs, which we then don't actually emulate to a level of accuracy that would mean they make a difference to the guest. Do you have real-world guest code that breaks? thanks -- PMM
