From 6cd14bd920572709324f57e58d57753bcc7aeca4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ciro=20Santilli=20=E5=85=AD=E5=9B=9B=E4=BA=8B=E4=BB=B6=20?= =?UTF-8?q?=E6=B3=95=E8=BD=AE=E5=8A=9F?= Date: Tue, 15 Oct 2019 00:00:00 +0000 Subject: [PATCH] gem5 vs qemu: better logging --- README.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/README.adoc b/README.adoc index b1749f7..0d83735 100644 --- a/README.adoc +++ b/README.adoc @@ -10437,6 +10437,7 @@ 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 ** gem5 ARM at least appears to implement more low level CPU functionality than QEMU, e.g. QEMU only added EL2 in 2018: https://stackoverflow.com/questions/42824706/qemu-system-aarch64-entering-el1-when-emulating-a53-power-up See also: xref:arm-exception-levels[xrefstyle=full] +** gem5 offers more advanced logging, even for non micro architectural things which QEMU models in some way, e.g. <>, because QEMU's binary translation optimizations reduce visibility * disadvantages of gem5: ** slower than QEMU, see: xref:benchmark-linux-kernel-boot[xrefstyle=full] +