>>>> - cycles fed into advance_ccount may (and on real hardware actually >>>> do) depend on executed commands/pipeline/cache hits. Most of this >>>> stuff may be counted at the translation time; >>> >>> Since CCOUNT, as seen by any one thread of execution, on real hw depends >>> on cache hits, interrupts, and other asynchronous stuff, then don't bother >>> trying to account for it on a per-instruction basis. Just define a clock >>> that runs at a given rate and be done. No need to advance it manually. >> >> It means no cycle-accurate emulation. This was one of my goals, maybe >> not closest one. Is it acceptable to have two simulation modes -- fast >> functional and slower cycle-accurate? > > Huh. Given that you're not modeling the caches, I don't see how you could > hope for true cycle accuracy. As for whether a mostly-cycle-accurate mode > should be a goal... I'll have to defer to other QEMU maintainers.
I'm going to model them finally, as well as pipeline and TCM/external memory. Just need a stable basis to start with (: -- Thanks. -- Max
