This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Which unit gives destination register number which is updating by execution unit

Note: This was originally posted on 4th January 2010 at http://forums.arm.com

Hi,
  If i want to update my destination register,i have to pass register number and data value which is updating that register.which unit  will give the register number to register bank unit? Is it execution unit or decoder unit? If answer is execution unit then why?
  • Note: This was originally posted on 5th January 2010 at http://forums.arm.com

    Could you give some more context, please? Which processor are you using? Is this regarding the main ARM CPU or a coprocessor? Is this software or hardware?


    Hi Ellis,
             I am talking about general ARM processor. When decoder unit in processor find the destination register number in which it has to update value processed by execution unit it has to give register  number and its content to register file unit so it will update the value of the register value. The data is coming from execution unit that's fine but what about register number. Is it coming from decoder unit or execution unit? Actually in execution unit there is no requirement to pass destination register number. So i am confused at this point which unit will give register file unit the value of register number, which it has to update?
  • Note: This was originally posted on 6th January 2010 at http://forums.arm.com

    The destination register is in the instruction encoding, and order constraints of a sequence of instructions will be enforced at the logical issue stage (although what this means in terms of when a register file is actually updated in a real implementation varies).

    This is really "micro architecture" - i.e. something which is decided by a specific implementation., and which is purposefully hidden from the programmer because it changes for different power or performance targets needed for a particular processor design. Even actually defining what a register file is an interesting problem ... there are likely to be multiple versions of the same register in existence at the same time, representing different temporal states - either in a physical register file or in different stages in the execution pipeline or forwarding paths. There may be the logical concept of a "register bank unit", but in high performance implementations reality is rarely that simple.

    Why do you need to know?

    Iso



    Hi isogen74,
             I am just thinking at design level. What is the responsibility of each unit? Here general purpose  registers are in register file unit or u can say it register bank and has only one copy of that. Have u know which unit will provide that register number and is it same for all processor for design point of view or anything else. I just want to know perfect answer if possible.
  • Note: This was originally posted on 5th January 2010 at http://forums.arm.com

    The destination register is in the instruction encoding, and order constraints of a sequence of instructions will be enforced at the logical issue stage (although what this means in terms of when a register file is actually updated in a real implementation varies).

    This is really "micro architecture" - i.e. something which is decided by a specific implementation., and which is purposefully hidden from the programmer because it changes for different power or performance targets needed for a particular processor design. Even actually defining what a register file is an interesting problem ... there are likely to be multiple versions of the same register in existence at the same time, representing different temporal states - either in a physical register file or in different stages in the execution pipeline or forwarding paths. There may be the logical concept of a "register bank unit", but in high performance implementations reality is rarely that simple.

    Why do you need to know?

    Iso
  • Note: This was originally posted on 4th January 2010 at http://forums.arm.com

    Could you give some more context, please? Which processor are you using? Is this regarding the main ARM CPU or a coprocessor? Is this software or hardware?