[gem5-users] Instruction trace address for ARM architecture
Hi all, I used Gem5 to obtain instruction accesses for ARM processor. I used -marm option to generate code. arm-linux-gnueabihf-gcc -static -marm fibcall.c I believe that only 32-bit ARM instructions are generated using this option. But the result is shown below: command line: ./build/ARM/gem5.opt --debug-flags=Exec configs/example/se.py -c tests/test-progs/malardalen/a.out Global frequency set at 1 ticks per second REAL SIMULATION info: Entering event queue @ 0. Starting simulation... 0: system.cpu T0 : @fini+15: mov.w fp, #0 : IntAlu : D=0x 500: system.cpu T0 : @_start+3: mov.w lr, #0 : IntAlu : D=0x 1000: system.cpu T0 : @_start+7: ldmstm 1000: system.cpu T0 : @_start+7.0 : ldr_uop r1, [sp, #0] : MemRead : D=0x0001 A=0xbe00 1500: system.cpu T0 : @_start+7.1 : addi_uop sp, sp, #4: IntAlu : D=0xbe04 2000: system.cpu T0 : @_start+9: mov r2, sp : IntAlu : D=0xbe04 2500: system.cpu T0 : @_start+11: ldmstm 2500: system.cpu T0 : @_start+11.0 : str_uop r2, [sp, #4] : MemWrite : D=0xbe04 A=0xbe00 3000: system.cpu T0 : @_start+11.1 : subi_uop sp, sp, #4: IntAlu : D=0xbe00 3500: system.cpu T0 : @_start+13: ldmstm 3500: system.cpu T0 : @_start+13.0 : str_uop r0, [sp, #4] : MemWrite : D=0x A=0xbefffefc 4000: system.cpu T0 : @_start+13.1 : subi_uop sp, sp, #4: IntAlu : D=0xbefffefc 4500: system.cpu T0 : @_start+15: ldr.w r12, [pc, #16] : MemRead : D=0x9039 A=0x88d8 5000: system.cpu T0 : @_start+19: str.w r12, [sp, #-4]! 5000: system.cpu T0 : @_start+19.0 : str.w r12, [sp, #-4]! : MemWrite : D=0x9039 A=0xbefffef8 5500: system.cpu T0 : @_start+19.1 : subi_uop.w sp, sp, #4 : IntAlu : D=0xbefffef8 6000: system.cpu T0 : @_start+23: ldr r0, [pc, #12] : MemRead : D=0x8a4c A=0x88dc ... We can see that at 2000, _start+9 is used, which is 2 bytes from _start+7. So I think a 16-bit instruction is used. Why is it so? Why is it not 32-bit? Besides, does anyone know what _start+7.0 and _start+7.1 mean? Why do I have two different instructions with the same memory address? Thanks in advance. -- Chao Chen, PhD Student MIST Lab - mistlab.ca École Polytechnique de Montréal ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] Alpha ROB, IQ, LSQ overflow, or something related to cpu->instcount <= 1500' failed
Hi, I am using the up-to-date gem5 version (repo.gem5.org/gem5). and run the ALPHA arch with FS mode. The system have many stalls due to lack of free ROB, IQ or LSQ, although the simulation still procedes slowly. I increase the ROB and IQ to 4048 entries each, but the stalls didn't disappear. I increase the Load Queue to 4048 (I know it may be not reasonable), but I cannot increase Store Queue to more than 128 entries, the simulation would halt. I tried to debug with gem5.debug. The simulation is aborted for "void BaseDynInst< >::initVars() [with Impl = O3CPUImpl]: Assertion `cpu->instcount <= 1500' failed." This was ignored when using gem5.fast earlier. I see the other posts that it means the in flight instructions increases beyond a reasonable limit I have some questions I cannot understand. 1. Is it reasonable that the in flight instructions increases while I use large ROB and IQ size? I was expecting in-flight instructions didn't increase and the stalled caused by lack of buffer would disappear. 2. I tried to debug it myself, and find that some instructions are not destroyed after committing. It seems they are never destroyed, and kept somewhere in some queue (I don't know which queue). For most (regular) instructions, when "instList.erase(removeList.front())" is called in o3/cpu.cc, the instruction would be destroyed. For some instructions, they are not destroyed properly after calling instList.erase. I debug to find the reason is the reference counter of the instruction object does not reach zero, and the system would destroy the instruction object while nobody is still referencing (using) this instruction. According to my understanding, there must be somewhere in the pipeline that didn't decrease the reference correctly, or some special operations (like squash) didn't call functions to remove the reference. 3. I am not sure how this would cause the ROB and IQ to overflow (no matter how big I set the values of these buffers). Is there anyone see this kind of issues before? Is it really a bug or did I do something wrong? If it is a bug, can you give me some hint to detect which part may not have decrement the reference counter of the instruction object? Any suspect? Thanks, Chao ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Periodically generating checkpoints based on instructions executed
Hi, I think your code "testsys.cpu[i].max_insts = checkpoint_inst" only changes the configuration file. Since you have instantiate the C objects with configuration file, any changes to the configuration file would not affect the generated C objects. I would suggest define your own setMax() functions in the following files ./python/m5/SimObject.py ./sim/sim_object.cc ./sim/sim_object.hh ./cpu/simple/base.hh And use "testsys.cpu[i]._ccObject.setMax(max_inst) in Simulation.py It would then change the parameters in the C objects directly. Hope it will help you. Chao ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] Multi-Level Cache coherence
Hi, I find that in cache_impl.hh, when a cache receives a read request, it would forward to upper level caches to check if they want to handle it. But I see the memInhibit flag is not forwarded. (not copied from original packet to the forwarded packet) In my simulation, L2 of core 0 sends out a read request. L2 of core 1 process it and set memInhibit flag. L2 of core 2 forward the request to L1s of core2, but the forwarded request has memInhibit flag not set. L1s of core2 respond the request again. Such problem triggers the assert in cache_impl.hh. Could any one help me how should I change to avoid the problem? Thanks, chao ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] cache coherence
Hi, When I simulate full system (gem5.debug), I got a assertion error, caused by "assert(!alreadyResponded);" in cache_impl.hh file. Thus I tried to debug with trace. I find when a L2 cache forward the snoop packet to upper level (L1s), it didn't copy the memInhibit flag from the original packet to the forwarded packet. If the original packet has been responded by another L2 (memInhibit is set), and you don't forward that flag to upper level, how could you let upper level cache know data respond is needed (has been served)? This is my confusion after reading through the codes while I debug it. Please let me know if I make some misunderstand your codes. Thanks, Chao ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] Halt not implemented
Hi, We I run m5 in FS mode, I got the following error: panic: Halt not implemented! @ cycle 2416905206000 [halt:build/ALPHA_FS/cpu/o3/cpu.hh, line 388] Have anyone see such error before? Is there any solution for that? Thanks, Chao ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] halt in cpu.hh
Hi, I got an error when I use m5. It happens in o3/cpu.hh "panic: Halt not implemented!" This error happens very occasionally. Can I anyone help explain when would "halt" be used? Is there any hint of solving the problem? thanks, chao ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] benchmark compile issue
Hi, I am trying to compile eembc benchmarks to run on alpha in FS mode. I got the following error when runing the compiled exe files .A.exe: /lib/libc.so.6.1: version `GLIBC_2.4' not found (required by A.x) When I cross-compile it, I am using gcc-4.3.2, glibc-2.6.1 (NPTL,x86/32) downloaded from gem5 website. The Linux disk is also from gem5 website and I add the cross-compiled files into the disk. I use --static with the cross-compiler. Seems like a glibc version issue, but I don't how to solve it. Can anyone help? Or is it some other errors? Thanks, Chao ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
