That sounds plausible. In general, when you write to a register in x86, you may be doing a partial write where the old data in the register needs to be preserved. For instance, if %rax has 0x0123456789abcdef in it, and you want to write 0x1 to %al, then you need both the old value and the value you're writing to create 0x0123456789abcd01. I think there are some mechanisms in place which avoid bringing in a register as a source if, for instance, you're writing 32 or 64 bits which either zero fill the upper 32 bits, or just plain overwrite all the bits, although I don't remember the specifics. It could be that this is not being applied to ProdHi or ProdLow for some reason.
In any case, since ProdHi and ProdLow are just temporary holding spots for the output of the multiplier, it doesn't make sense to use partial writes to them ever, even if the output size was 8 or 16 bits. You'll never need to know what was in the other bits of ProdHi or ProdLow, even if you need to know what was in the upper bits of whatever architectural register you're ultimately writing their values into. It's a little confusing due to the overloaded terminology, but I think if you look for "predicated" or something like that in the x86 ISA description's operands definitions, you should find what I'm talking about. I have some changes which I think are still pending (mabye?) which significantly rework how operands for x86 microops are handled and make them much more precise in how they're applied, how the instructions are disassembled, etc. Part of that also had to do with when/if registers are "picked", aka only a part of their value is used, or "merged", aka partially written, I think. Sorry I can't be more specific than that, I wrote those changes months ago. I think they went in, although I'm not completely certain of that. I think I also got rid of the INTREG_IMPLICIT method, so it looks like you're using a slightly older version of gem5 as well. Gabe On Wed, Jul 21, 2021 at 10:58 AM mohit.gambhir84--- via gem5-users < gem5-users@gem5.org> wrote: > 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 >
_______________________________________________ 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
