Hi Ayaz, Thanks for your reply. You are right that they do get renamed and are assigned a different destination physical register for each instruction. But, as you see below, IMPLICIT(0) and IMPLICIT(1) are both source and destination for IMUL_R_R instruction. So each instruction is still waiting for the previous instruction to complete and write to previous physical registers that are then used as sources, creating a chain of dependencies.
setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, INTREG_IMPLICIT(0))); setDestRegIdx(_numDestRegs++, RegId(IntRegClass, INTREG_IMPLICIT(0))); setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, INTREG_IMPLICIT(1))) setDestRegIdx(_numDestRegs++, RegId(IntRegClass, INTREG_IMPLICIT(1))); Including a trace from rename stage for just implicit(0) register 16665750: system.cpu.rename: [tid:0] Processing instruction [sn:34990] with PC (0x400c0f=>0x400c13).(1=>2). 16665750: system.cpu.rename: [tid:0] Looking up IntRegClass arch reg 32, got phys reg 54 (IntRegClass) 16665750: system.cpu.rename: [tid:0] Register 54 (flat: 54) (IntRegClass) is not ready. 16665750: system.cpu.rename: [tid:0] Renaming arch reg 32 (IntRegClass) to physical reg 10 (10). ... 16665750: system.cpu.rename: [tid:0] Processing instruction [sn:34992] with PC (0x400c13=>0x400c17).(0=>1). 16665750: system.cpu.rename: [tid:0] Looking up IntRegClass arch reg 32, got phys reg 10 (IntRegClass) 16665750: system.cpu.rename: [tid:0] Register 10 (flat: 10) (IntRegClass) is not ready. Does that make sense? Regards, Mohit _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
