[gem5-users] Re: Why there is miss prediction of non-control instructions

Yes, because not all the squashes are caused by control instructions. Another source of squash is memory violations (IEW::SquanshDueToMemOrder). There, the squash bit toCommit->squash is set, but toCommit->mispredictInst is set to NULL. Thus, when the reason for the squash is later checked in C

[gem5-users] Re: Page Walker: Where the PTE hits in the memory hierarchy

Hi Abdelrahman, I have done something similar with ruby enabled. Hope this helps. Basically you need to set your own message flags in the pagetable walker and checks that flag in the SLICC code when a cacheline hits. Below is an example of how to do it in the L1 and L2. in request.hh ``` bool i

[gem5-users] Re: Fixed I/O Address Range in x86

Hi Sam, ''scons build/x86/out/m5 --verbose'' shows ``` g++ -o build/x86/out/m5 -no-pie -static build/x86/call_type/inst.o build/x86/call_type/addr.o build/x86/args.o ... ``` So I guess in your case either ``` gcc -o test test.c -I./include -I./util/m5/src -L./util/m5/b

[gem5-users] Re: Microcode_ROM Instruction and fetchRomMicroop() Function

Hi, The ROM contains predefined micro-code routines for purposes such as apic interrupt handler (arch/x86/isa/insts/romutil.py). If you are simulating a full system then basically the interrupt is triggered by 8254 timer (dev/x86/i8254.py) and when it is triggered the core fetches instr

[gem5-users] Re: Squashing Instructions after Page Table Fault

Hi Robin, The "Page-Fault" message is printed out on the constructor of a fault, so gdb that line and move up frames can help. By the way, a page fault can also be generated during page walks (see here

[gem5-users] Re: Squashing Instructions after Page Table Fault

Hi Robin, If I understand it correctly, a Page Table Fault instruction is not squashed but *not executed*. The instruction generating a fault is marked ready to commit. Then, during the commit phase, the fault generated by the instruction is handled. To explain this in more detail let m