diff --git a/README.adoc b/README.adoc index a5bf8fe..10076a0 100644 --- a/README.adoc +++ b/README.adoc @@ -1489,9 +1489,13 @@ GEM5 is a system simulator, much like QEMU: http://gem5.org/ *** do much more realistic performance benchmarking with it, which makes absolutely no sense in QEMU, which is purely functional *** make functional cache observations, e.g. to use Linux kernel APIs that flush memory like DMA, which are crucial for driver development. In QEMU, the driver would still work even if we forget to flush caches. + -It is not of course truly cycle accurate, as that would require exposing proprietary information of the CPU designs: https://stackoverflow.com/questions/17454955/can-you-check-performance-of-a-program-running-with-qemu-simulator/33580850#33580850, but the approximation is reasonable. +It is not of course truly cycle accurate, as that +** would require exposing proprietary information of the CPU designs: link::https://stackoverflow.com/questions/17454955/can-you-check-performance-of-a-program-running-with-qemu-simulator/33580850#33580850[] +** would make the simulation even slower TODO confirm, by how much + -It is used mostly for research purposes: when you are making a new chip technology, you don't really need to specialize enormously to an existing microarchitecture, but rather develop something that will work with a wide range of future architectures. +but the approximation is reasonable. ++ +It is used mostly for microarchitecture research purposes: when you are making a new chip technology, you don't really need to specialize enormously to an existing microarchitecture, but rather develop something that will work with a wide range of future architectures. ** runs are deterministic by default, unlike QEMU which has a special <> mode, that requires first playing the content once and then replaying * disadvantage of GEM5: slower than QEMU, see: <> +