Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
If #2 didnt exist, then that would make more sense to me. That would make an instruction HAVE to use the threadContext interface to access any CPU facilities. That would also remove the CPU pointer from the instruction object as well. If that were the solution, I would be OK with it, because then the CPU would be appropriately encapsulated away from an instruction's commands... It turns out that I had forgotten about the relationship between ThreadContext, ExecContext, and registers. I had a chance to discuss this with Steve and Gabe today and Gabe has agreed to write something up to describe how to solve this problem cleanly across the CPU models. I think that part of the problem is that the register file shouldn't really be defined in the ISA, and the ExecContext needs a consistent way for accessing registers. We'll probably end up with new functions for accessing registers from other threads instead of modifying the existing ones. Hopefully one of the things that will fall out of this work is consistent, working thread support across the various CPU models. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
I'm not sure I all the way understand why the register file shouldnt be defined in the ISA... I could see maybe there being one standard integer and floating point register file thats totally generic however, the system/miscellaneous registers are pretty ISA dependent so those register probably need to be defined in some custom manner. Anyway, I was just about to rearrange everything so that all accesses to registers use the ThreadContext instead of directly going through the CPU (for the InOrder model at least). I'll assume that I should hold off on that for now? On Mon, Feb 16, 2009 at 11:17 PM, nathan binkert n...@binkert.org wrote: If #2 didnt exist, then that would make more sense to me. That would make an instruction HAVE to use the threadContext interface to access any CPU facilities. That would also remove the CPU pointer from the instruction object as well. If that were the solution, I would be OK with it, because then the CPU would be appropriately encapsulated away from an instruction's commands... It turns out that I had forgotten about the relationship between ThreadContext, ExecContext, and registers. I had a chance to discuss this with Steve and Gabe today and Gabe has agreed to write something up to describe how to solve this problem cleanly across the CPU models. I think that part of the problem is that the register file shouldn't really be defined in the ISA, and the ExecContext needs a consistent way for accessing registers. We'll probably end up with new functions for accessing registers from other threads instead of modifying the existing ones. Hopefully one of the things that will fall out of this work is consistent, working thread support across the various CPU models. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
I'm not sure I all the way understand why the register file shouldnt be defined in the ISA... I could see maybe there being one standard integer and floating point register file thats totally generic however, the system/miscellaneous registers are pretty ISA dependent so those register probably need to be defined in some custom manner. Anyway, I was just about to rearrange everything so that all accesses to registers use the ThreadContext instead of directly going through the CPU (for the InOrder model at least). I'll assume that I should hold off on that for now? I think at this point, we need more discussion and less action. If you think you know how to make the ThreadContext stuff work right, please write up a description of how it will work. I think I was mistaken in saying that we could do it that way. Please also make sure that whatever you propose is consistent across the CPU models. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
Gabe, I plan to work on developing WIKI documentation for the in-order model on m5sim.org next week. The short story is that the in-order model functions on three main concepts: PipelineStage, Resource, and an Instruction Schedule. - The Pipeline stage is a generic version of the pipeline stages in the O3 model such that you can add an arbitrary # of stages to your in-order design. -The concept of a resource is to encapsulate any object that an instruction wants to interact with within a pipeline stage. Things like the Cache, a Branch Predictor, a decoder, etc. are considered resources that an instruction has to request use of during each given pipeline stage. - Each instruction generates an instruction schedule that details what resources a given instruction needs on any given stage. When an instruction enters a stage, it looks to it's instruction schedule and tries to satisfy all the resource requests it needs before it can go on to the next stage. - Lastly, stages are processed from backwards to forwards (stage 4, stage 3, stage 2,...) instead of forwards to backwards like O3 does it. On Thu, Feb 12, 2009 at 3:53 AM, Gabe Black gbl...@eecs.umich.edu wrote: nathan binkert wrote: changeset 09ab46bfa914 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=09ab46bfa914 description: InOrder: Import new inorder CPU model from MIPS. This model currently only works in MIPS_SE mode, so it will take some effort to clean it up and make it generally useful. Hopefully people are willing to help make that happen! Awesome! I've looked at this code quite a bit, and it's a great start, but I do think we need to put some effort into it to make it work well along with the other CPU models. My biggest concern is how registers, thread ids, and thread contexts are handled. This is different from other models. I'd really love it if we could have a call among people that really understand the CPU models so we can discuss what needs to be done to get things working. Unfortunately, I can't write huge amounts of code in this area because HP lawyers won't let me, but I can review patches, help tweak things, and in general give advice. My first inclination is that the InOrder model and MIPS should do threads the way the other ISAs and O3 do them, in that each hardware thread has a separate register file (as opposed to the unified register file done for MIPS), but we should certainly discuss the pros and cons of this. In general, I think our thread support is probably lacking, so coming up with a coordinated vision is a good thing. Anyone interested? Gabe? Kevin? Korey? Steve? I know that Daniel is interested in using the model. Anyone else out there want to pitch in? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev Hi Korey. For those of us who don't really know what this model is all about other than I guess that it's in order, could you please describe at a high level how it works algorithmically, how it's implemented, what's in what file, etc? I'd like to help out, but I'd also like to skip the blind-stumbling-in-the dark part of the learning curve. Thanks! Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
Instead of this, couldn't you do the cross thread thing by looking up the appropriate thread context in the cpu object and then calling the register access function for that thread context? This would work more in line with the other CPU models. I've been looking into this and it seems that the difference between the In-Order model and the O3 is that an instruction accesses the register file by directly calling the CPU object rather than through using the Thread Context. I'm guessing if I re-adjust all InOrder code to make sure it uses the Thread Context to interface with a CPU's regfile then we would probably be back to full compatibility... The question I'm trying to figure out in my mind again is: what is the advantage of using the thread context to access the CPU instead of letting an instruction directly access it? What flexibility are we gaining? Currently, it just seems like an indirect step... -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
2009/2/13 Korey Sewell ksew...@umich.edu Instead of this, couldn't you do the cross thread thing by looking up the appropriate thread context in the cpu object and then calling the register access function for that thread context? This would work more in line with the other CPU models. I've been looking into this and it seems that the difference between the In-Order model and the O3 is that an instruction accesses the register file by directly calling the CPU object rather than through using the Thread Context. I'm guessing if I re-adjust all InOrder code to make sure it uses the Thread Context to interface with a CPU's regfile then we would probably be back to full compatibility... The question I'm trying to figure out in my mind again is: what is the advantage of using the thread context to access the CPU instead of letting an instruction directly access it? What flexibility are we gaining? Currently, it just seems like an indirect step... I haven't looked at this particular issue closely, but aren't you answering your own question? The thing you gain by accessing the CPU via the ThreadContext interface is that all of the CPU models present a consistent and compatible interface to the instruction objects... Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
I haven't looked at this particular issue closely, but aren't you answering your own question? The thing you gain by accessing the CPU via the ThreadContext interface is that all of the CPU models present a consistent and compatible interface to the instruction objects... Hey Steve, I agree that accessing through the ThreadContext Interface buys you a consistent way to access the CPU register file...However, because all the CPUs are derived off of the BaseCPU object anyway, then it forces all the CPUs to already have the same consistent interface without using the ThreadContext in the first place. My toy example of this is say I want to read a integer register from an instruction. I could either go: (1) inst-threadContext-readIntReg() or (2) inst-cpu-readIntReg() In the threadContext object, there is just some redundant call to cpu-readIntReg() anyway. So you end up calling (1) and (2) instead of just directly calling (2). So unless there is some important preprocessing done in the threadContext's readIntReg() function that can't be done in the cpu object's readIntReg() function, I'm not exactly sure that we arent just stacking redundant compatibility on top of each other. But, I could be missing something (especially the FS implications) -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
My toy example of this is say I want to read a integer register from an instruction. I could either go: (1) inst-threadContext-readIntReg() or (2) inst-cpu-readIntReg() In the threadContext object, there is just some redundant call to cpu-readIntReg() anyway. So you end up calling (1) and (2) instead of just directly calling (2). I think that's a holdover from before we had thread support. I'd argue that #2 shouldn't exist. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
If #2 didnt exist, then that would make more sense to me. That would make an instruction HAVE to use the threadContext interface to access any CPU facilities. That would also remove the CPU pointer from the instruction object as well. If that were the solution, I would be OK with it, because then the CPU would be appropriately encapsulated away from an instruction's commands... On Fri, Feb 13, 2009 at 11:16 PM, nathan binkert n...@binkert.org wrote: My toy example of this is say I want to read a integer register from an instruction. I could either go: (1) inst-threadContext-readIntReg() or (2) inst-cpu-readIntReg() In the threadContext object, there is just some redundant call to cpu-readIntReg() anyway. So you end up calling (1) and (2) instead of just directly calling (2). I think that's a holdover from before we had thread support. I'd argue that #2 shouldn't exist. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
changeset 09ab46bfa914 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=09ab46bfa914 description: InOrder: Import new inorder CPU model from MIPS. This model currently only works in MIPS_SE mode, so it will take some effort to clean it up and make it generally useful. Hopefully people are willing to help make that happen! Awesome! I've looked at this code quite a bit, and it's a great start, but I do think we need to put some effort into it to make it work well along with the other CPU models. My biggest concern is how registers, thread ids, and thread contexts are handled. This is different from other models. I'd really love it if we could have a call among people that really understand the CPU models so we can discuss what needs to be done to get things working. Unfortunately, I can't write huge amounts of code in this area because HP lawyers won't let me, but I can review patches, help tweak things, and in general give advice. My first inclination is that the InOrder model and MIPS should do threads the way the other ISAs and O3 do them, in that each hardware thread has a separate register file (as opposed to the unified register file done for MIPS), but we should certainly discuss the pros and cons of this. In general, I think our thread support is probably lacking, so coming up with a coordinated vision is a good thing. Anyone interested? Gabe? Kevin? Korey? Steve? I know that Daniel is interested in using the model. Anyone else out there want to pitch in? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
Thanks for the helping in pushing this out Nate. There is a short and long version of the thread support in MIPS and why it varies. I'll give the short version here: MIPS was implemented ot use the MT ISA extension which requires the ability to read/write registers from other threads. I designed the register file to be on size fits all. It can be instantiated multiple times as a per-thread register file (Simple-CPU) OR it could be used as one big physical register file to allow threads communicate with each other (InOrder model). This differs since O3 defines it's own physical register file instead of the pre-defined one in the src/arch folder. There is one patch that I need to send out that merges the two solutions together where I add a thread-ID to all the thread-context functions cpu/thread_context.* and then defaulted that value to 0. This in effect allowed the other ISAs (ALPHA/SPARC/etc.) to compile and run unaffected by the changes I made. I'm not sure the other ISAs will ever care about communicating between register files so I though that was an OK solution. (Well, I guess that version wasnt so short!) On Tue, Feb 10, 2009 at 7:12 PM, nathan binkert n...@binkert.org wrote: changeset 09ab46bfa914 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=09ab46bfa914 description: InOrder: Import new inorder CPU model from MIPS. This model currently only works in MIPS_SE mode, so it will take some effort to clean it up and make it generally useful. Hopefully people are willing to help make that happen! Awesome! I've looked at this code quite a bit, and it's a great start, but I do think we need to put some effort into it to make it work well along with the other CPU models. My biggest concern is how registers, thread ids, and thread contexts are handled. This is different from other models. I'd really love it if we could have a call among people that really understand the CPU models so we can discuss what needs to be done to get things working. Unfortunately, I can't write huge amounts of code in this area because HP lawyers won't let me, but I can review patches, help tweak things, and in general give advice. My first inclination is that the InOrder model and MIPS should do threads the way the other ISAs and O3 do them, in that each hardware thread has a separate register file (as opposed to the unified register file done for MIPS), but we should certainly discuss the pros and cons of this. In general, I think our thread support is probably lacking, so coming up with a coordinated vision is a good thing. Anyone interested? Gabe? Kevin? Korey? Steve? I know that Daniel is interested in using the model. Anyone else out there want to pitch in? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
I'll give the short version here: MIPS was implemented ot use the MT ISA extension which requires the ability to read/write registers from other threads. I designed the register file to be on size fits all. It can be instantiated multiple times as a per-thread register file (Simple-CPU) OR it could be used as one big physical register file to allow threads communicate with each other (InOrder model). This differs since O3 defines it's own physical register file instead of the pre-defined one in the src/arch folder. There is one patch that I need to send out that merges the two solutions together where I add a thread-ID to all the thread-context functions cpu/thread_context.* and then defaulted that value to 0. This in effect allowed the other ISAs (ALPHA/SPARC/etc.) to compile and run unaffected by the changes I made. I'm not sure the other ISAs will ever care about communicating between register files so I though that was an OK solution. Instead of this, couldn't you do the cross thread thing by looking up the appropriate thread context in the cpu object and then calling the register access function for that thread context? This would work more in line with the other CPU models. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
