[m5-dev] Predecoder Re-Write?
In reference to src/arch/*/predecoder.hh: I really think that somehow this predecoder code needs to be generalized since if you look at the predecoder.hh for alpha,mips,arm, sparc they are 90% the same code. The difference for those ISAs is just the moreBytes function which is still pretty much the same across the board. The only ISA this seems to really matter for is x86 which seems to have some real functionality for. So my question is, why can't there be a generic Predecoder base class which the ISAs just derive from. The ISAs can just override the one function that they change (moreBytes()) and then x86 can pretty much override the whole thing... That way, we dont have to have pretty much the exact same code sitting in a few spots... -- -- 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] Predecoder Re-Write?
They are mostly the same code because otherwise you've got virtual functions, and for something that performance critical that would be bad news. There are lots of other places (lots in the CPUs) where there is duplicated code for the same reason. That would be at most a reorganization anyway, not a rewrite. Gabe Korey Sewell wrote: In reference to src/arch/*/predecoder.hh: I really think that somehow this predecoder code needs to be generalized since if you look at the predecoder.hh for alpha,mips,arm, sparc they are 90% the same code. The difference for those ISAs is just the moreBytes function which is still pretty much the same across the board. The only ISA this seems to really matter for is x86 which seems to have some real functionality for. So my question is, why can't there be a generic Predecoder base class which the ISAs just derive from. The ISAs can just override the one function that they change (moreBytes()) and then x86 can pretty much override the whole thing... That way, we dont have to have pretty much the exact same code sitting in a few spots... -- -- 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Predecoder Re-Write?
I guess I dont understand why the in-depth specialization and functions when only x86 seems to really use the predecoder and the only function that mildly vary is the moreBytes. Also, the process and reset functions literally have no code there so I guess they are harmless since the compiler will ignore it, but just seems unnecessary. Is there no better solution then to duplicate that code across all ISAs? Gabe is right in that that has happened in some of the CPU models as well as maybe throughout the ISAs a bit so if there's no better way to do that without virtualization (or maybe typedef'ing) then that's fine with me. On Mon, Apr 20, 2009 at 1:45 PM, Gabe Black gbl...@eecs.umich.edu wrote: They are mostly the same code because otherwise you've got virtual functions, and for something that performance critical that would be bad news. There are lots of other places (lots in the CPUs) where there is duplicated code for the same reason. That would be at most a reorganization anyway, not a rewrite. Gabe Korey Sewell wrote: In reference to src/arch/*/predecoder.hh: I really think that somehow this predecoder code needs to be generalized since if you look at the predecoder.hh for alpha,mips,arm, sparc they are 90% the same code. The difference for those ISAs is just the moreBytes function which is still pretty much the same across the board. The only ISA this seems to really matter for is x86 which seems to have some real functionality for. So my question is, why can't there be a generic Predecoder base class which the ISAs just derive from. The ISAs can just override the one function that they change (moreBytes()) and then x86 can pretty much override the whole thing... That way, we dont have to have pretty much the exact same code sitting in a few spots... -- -- 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 ___ 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
[m5-dev] Configuration files/tables for/in the simulated guest.
Anybody?
Quoting Gabe Black gbl...@eecs.umich.edu:
I reordered my patches so that I could push this, and now all of the
remaining ones are dependent on or are hacks that force there to be two
CPUs. In order to push these last ~5 patches, I need to know how many
CPUs there are when I'm constructing the BIOS tables on the python side
of things.
First, I think it would be useful to have a mechanism that will allow
enumerating a simobjects children that are also simobjects. That way you
could, for instance, go through and gather up all the CPUs to count
them, assign an ISA level ID to them, etc. There are potential
complications where you might leak into some other system, not be able
to follow certain configurations correctly, not make the jump over
ports, etc that might make this more complicated. There may also be CPUs
you don't want to count that you'll, for instance, switch over to later.
Besides CPUs, these tables also tend to have information about caches,
and at least on the x86 side they expect to be identified by depth.
There would need to be some way of identifying how far a particular
cache is from a particular CPU in order to label it the, for instance,
L2. I think you may also need to know what CPUs are connected to a
particular cache so you can call it shared, etc. These sorts of names
may not make sense in whatever crazy configuration somebody sets up.
Another issue is determining bus topology and interrupt assignment. In
x86 each bus needs to be identified with a particular technology, and
all interrupts need to be described as far as who generates them, what
bus they originate on, and where they ultimately end up. Linux gets
confused when at least the interrupt information is wrong and things get
lost.
I think it's important for this to be automated as much as possible
because I will attest it can be tricky to get everything right. Having a
system in place which automatically builds up a semi-qualitative
description of whatever whacky configuration people want to throw at it
is going to be very challenging, though, because it might not always be
clear what the right thing to do is when setting things up manually, and
fixing a generated configuration may actually be harder than building it
yourself.
How this works has the potential to introduce a lot of problems, and if
we get it wrong it could take a major effort to fix an entrenched
system. I see this primarily as an infrastructure, config sort of issue,
so if Nate and Steve and whoever else does the python stuff could please
start a discussion about this that would be the first step.
Gabe
Gabe Black wrote:
changeset 860df2c586a3 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=860df2c586a3
description:
X86: Fix the functions that manipulate large bit arrays in the local
APIC.
diffstat:
1 file changed, 3 insertions(+), 3 deletions(-)
src/arch/x86/interrupts.hh |6 +++---
diffs (26 lines):
diff -r a61ac4a3591d -r 860df2c586a3 src/arch/x86/interrupts.hh
--- a/src/arch/x86/interrupts.hh Sun Apr 19 13:17:35 2009 -0700
+++ b/src/arch/x86/interrupts.hh Sun Apr 19 13:47:15 2009 -0700
@@ -172,19 +172,19 @@
void
setRegArrayBit(ApicRegIndex base, uint8_t vector)
{
-regs[base + (vector % 32)] |= (1 (vector 5));
+regs[base + (vector / 32)] |= (1 (vector % 32));
}
void
clearRegArrayBit(ApicRegIndex base, uint8_t vector)
{
-regs[base + (vector % 32)] = ~(1 (vector 5));
+regs[base + (vector / 32)] = ~(1 (vector % 32));
}
bool
getRegArrayBit(ApicRegIndex base, uint8_t vector)
{
-return bits(regs[base + (vector % 32)], vector 5);
+return bits(regs[base + (vector / 32)], vector % 5);
}
void requestInterrupt(uint8_t vector, uint8_t deliveryMode,
bool level);
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
