Because I want to simulate performance variations of different core sizes, I
tried changing issue width, commit width, and some other parameters, but this
does not work. The job is terminated.
# system under test can be any CPU
(TestCPUClass, test_mem_mode, FutureClass) = Simulation.setCPUClass(options)
TestCPUClass.clock = '2GHz'
DriveCPUClass.clock = '2GHz'
Above is the part of the original fs.py, I added below part:
TestCPUClass.issueWidth = 16
TestCPUClass.fetchWidth = 16
TestCPUClass.decodeWidth = 16
TestCPUClass.renameWidth = 16
TestCPUClass.dispatchWidth = 16
TestCPUClass.wbWidth = 16
TestCPUClass.RASSize = 32
TestCPUClass.LQEntries = 64
TestCPUClass.SQEntries = 64
TestCPUClass.numIQEntries = 128
TestCPUClass.numROBEntries = 384
issueWidth, fetchWidth...are defined in src/cpu/o3/O3CPU.py.
I am not sure what is wrong with it.
Thanks,
________________________________________
From: [email protected] [[email protected]] on behalf of
[email protected] [[email protected]]
Sent: Friday, April 27, 2012 2:22 PM
To: [email protected]
Subject: gem5-dev Digest, Vol 60, Issue 100
Send gem5-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://m5sim.org/mailman/listinfo/gem5-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of gem5-dev digest..."
Today's Topics:
1. Re: Review Request: ISA Parser: Decide source register
indices at runtime (Gabe Black)
2. Re: x86 spec06 patches from Vince Weaver (Gabe Black)
3. Re: Review Request: ISA Parser: Decide source register
indices at runtime (Nilay Vaish)
4. Re: x86 spec06 patches from Vince Weaver (Steve Reinhardt)
5. Re: Review Request: ISA Parser: Decide source register
indices at runtime (Gabe Black)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 Apr 2012 10:53:25 -0700
From: Gabe Black<[email protected]>
To: [email protected]
Subject: Re: [gem5-dev] Review Request: ISA Parser: Decide source
register indices at runtime
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/27/12 07:02, Nilay Vaish wrote:
On Wed, 25 Apr 2012, Nilay Vaish wrote:
On Wed, 25 Apr 2012, Gabriel Michael Black wrote:
Quoting Steve Reinhardt<[email protected]>:
On Wed, Apr 25, 2012 at 11:00 AM, Gabriel Michael Black<
[email protected]> wrote:
Quoting Nilay Vaish<[email protected]>:
Two things that I want to say in response --
a. With respect to memory usage, it would go down if we do what Gabe
suggested in his review i.e. introduce members for each of the
registers
instead of using an array. This would also remove the
indirection. I'll get
performance numbers from some of the regression tests to carry out a
performance comparison.
b. The aim for these set of patches is remove the RAW dependence on
condition code register in x86. Current approach is to figure out
at run
time whether or not the CC register needs to be read. We require
this
dynamic map to correctly read the registers. In ARM ISA
description, some
thing similar has been done. At runtime, if a certain condition
is true,
the CC register is reda, otherwise register 0 is read. IIRC, no
instruction
can write to reg 0 in a RISC isa. Hence, there is no RAW
dependence. Can we
do this in x86 as well? May be a register that is only visible to
the
microcode.
I agree, at a high level, that keeping the existing _srcRegIdx[]
array and
just dealing with the fact that it may have gaps in it seems like an
alternative that's at least worth exploring.
We could also have a special register index like -1 that just means
invalid
so that we don't rely on piggybacking on some potentially ISA-specific
characteristics to make it work.
That's essentially what the index constant ZeroReg does currently.
The special handling of the zero register is actually somewhat
annoying.
The CPU has to check for it and treat it specially, and, last I
recall, the
way it holds its zero value is to be rewritten with zero over and
over and
over to squash any errant updates. I would like to get rid of this
mechanism if possible, so my gut reaction is not to build more on
top of
it. That said, the zero register behavior isn't going away so it
has to
keep working somehow anyway. That may be a viable way to avoid adding
storage to the StaticInst classes.
With Alpha, the decoder generates a no-op for any instruction whose
destination is the zero register, regardless of the opcode. In
theory,
this should make rewriting the zero value every cycle unnecessary.
I don't
know if some cases were missed, or if it's still needed for other
ISAs, but
that's the direction I'd want to go to get rid of that aspect. We
could
always just replace the overwrite with an assertion and see how far
we get.
On the input side, it would seem that instructions that read the zero
register could be decoded into StaticInsts that act as if it were an
immediate zero operand.
So I'd think it's at least theoretically possible to make the current
zero-register implementation go away.
Also, PowerPC has funky semantics in which the zero register
actually holds
a value, and whether you get that value or 0 depends on the
opcode. I'm
not sure how that's implemented in gem5, but we can't assume that the
zero-register behavior is universal.
Steve
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
That's not necessarily feasible because you'd end up with lots of
variations of everything where one or more sources and/or one or
more destinations are replaced in some way. It's also not desirable
to turn them into nops because you may still want side effects like
setting condition codes. This is how at least the cmp instruction is
implemented as microcode in x86.
A long time ago I proposed using our index flattening mechanism to
flatten dests that had magical zero properties to a dead register,
and I think that would still make sense. There would be a little bit
of overhead because sources will still read from a zero register and
dests will still write to a /dev/null register, but renaming sorts
of operations would be minimal.
Gabe
Seems like the main discussion is getting side tracked. So do people
think that we should do this? The zeroth micro int register is
defined to be the ZeroReg. Does that mean if the operand is ZeroReg,
it would map to 0? Also, where are these micro int registers being
used? There aren't many places where INTREG_MICRO() is in use.
--
Nilay
I went through some of the code. It seems that the 't*' registers used
in the microcode would map to the MicroInt registers. I think it is
possible to do a zero register. We can introduce a new register that
does the job. Or else we can reuse one of the micro int registers.
t13/t14 are not in use at all. So they can be used. But we will have
to maintain a discipline of not using these any where else.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
Don't use t13 or t14. t0 is already defined as the zero register.
Gabe
------------------------------
Message: 2
Date: Fri, 27 Apr 2012 10:55:41 -0700
From: Gabe Black<[email protected]>
To: [email protected]
Subject: Re: [gem5-dev] x86 spec06 patches from Vince Weaver
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/27/12 07:46, Steve Reinhardt wrote:
So we've had these patches outstanding for over a year, and now we've got
people on the gem5-users list swapping tips about which syscalls you have
to change to get spec06 to work (by changing "fatal" to "warn" in some
cases). We should really get those patches pushed.
It seems like they're mostly OK. There are a few minor issues that would
be nice to clean up. Unfortunately no one "owns" these patches, so the
cleanup isn't happening. I'm not sure where Vince went, but clearly he's
doing other things. Lisa did the favor of posting them to reviewboard, but
I don't think she ever intended to take full responsibility, and even if
she did, she's still on maternity leave.
Does anyone want to step up and make this happen? I think the overhead is
pretty low if you've already got the spec06 x86 binaries and infrastructure
around (which I don't).
If not, at this point I'd rather see them go in than continue to not commit
them because of minor issues that no one is willing to fix.
The easiest way I've found is just go to Lisa's page and look for the ones
with "Vince Weaver" in the title:
http://reviews.gem5.org/users/hsul/
Steve
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
If I recall, there were real problems with at least some of those
patches. The last time we brought them up we acknowledged at least a
problem with the ioctl patch(es) but I don't think they were ever addressed.
Gabe
------------------------------
Message: 3
Date: Fri, 27 Apr 2012 13:01:05 -0500 (CDT)
From: Nilay Vaish<[email protected]>
To: gem5 Developer List<[email protected]>
Subject: Re: [gem5-dev] Review Request: ISA Parser: Decide source
register indices at runtime
Message-ID:<[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 27 Apr 2012, Gabe Black wrote:
On 04/27/12 07:02, Nilay Vaish wrote:
On Wed, 25 Apr 2012, Nilay Vaish wrote:
On Wed, 25 Apr 2012, Gabriel Michael Black wrote:
Quoting Steve Reinhardt<[email protected]>:
On Wed, Apr 25, 2012 at 11:00 AM, Gabriel Michael Black<
[email protected]> wrote:
Quoting Nilay Vaish<[email protected]>:
Two things that I want to say in response --
a. With respect to memory usage, it would go down if we do what Gabe
suggested in his review i.e. introduce members for each of the
registers
instead of using an array. This would also remove the
indirection. I'll get
performance numbers from some of the regression tests to carry out a
performance comparison.
b. The aim for these set of patches is remove the RAW dependence on
condition code register in x86. Current approach is to figure out
at run
time whether or not the CC register needs to be read. We require
this
dynamic map to correctly read the registers. In ARM ISA
description, some
thing similar has been done. At runtime, if a certain condition
is true,
the CC register is reda, otherwise register 0 is read. IIRC, no
instruction
can write to reg 0 in a RISC isa. Hence, there is no RAW
dependence. Can we
do this in x86 as well? May be a register that is only visible to
the
microcode.
I agree, at a high level, that keeping the existing _srcRegIdx[]
array and
just dealing with the fact that it may have gaps in it seems like an
alternative that's at least worth exploring.
We could also have a special register index like -1 that just means
invalid
so that we don't rely on piggybacking on some potentially ISA-specific
characteristics to make it work.
That's essentially what the index constant ZeroReg does currently.
The special handling of the zero register is actually somewhat
annoying.
The CPU has to check for it and treat it specially, and, last I
recall, the
way it holds its zero value is to be rewritten with zero over and
over and
over to squash any errant updates. I would like to get rid of this
mechanism if possible, so my gut reaction is not to build more on
top of
it. That said, the zero register behavior isn't going away so it
has to
keep working somehow anyway. That may be a viable way to avoid adding
storage to the StaticInst classes.
With Alpha, the decoder generates a no-op for any instruction whose
destination is the zero register, regardless of the opcode. In
theory,
this should make rewriting the zero value every cycle unnecessary.
I don't
know if some cases were missed, or if it's still needed for other
ISAs, but
that's the direction I'd want to go to get rid of that aspect. We
could
always just replace the overwrite with an assertion and see how far
we get.
On the input side, it would seem that instructions that read the zero
register could be decoded into StaticInsts that act as if it were an
immediate zero operand.
So I'd think it's at least theoretically possible to make the current
zero-register implementation go away.
Also, PowerPC has funky semantics in which the zero register
actually holds
a value, and whether you get that value or 0 depends on the
opcode. I'm
not sure how that's implemented in gem5, but we can't assume that the
zero-register behavior is universal.
Steve
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
That's not necessarily feasible because you'd end up with lots of
variations of everything where one or more sources and/or one or
more destinations are replaced in some way. It's also not desirable
to turn them into nops because you may still want side effects like
setting condition codes. This is how at least the cmp instruction is
implemented as microcode in x86.
A long time ago I proposed using our index flattening mechanism to
flatten dests that had magical zero properties to a dead register,
and I think that would still make sense. There would be a little bit
of overhead because sources will still read from a zero register and
dests will still write to a /dev/null register, but renaming sorts
of operations would be minimal.
Gabe
Seems like the main discussion is getting side tracked. So do people
think that we should do this? The zeroth micro int register is
defined to be the ZeroReg. Does that mean if the operand is ZeroReg,
it would map to 0? Also, where are these micro int registers being
used? There aren't many places where INTREG_MICRO() is in use.
--
Nilay
I went through some of the code. It seems that the 't*' registers used
in the microcode would map to the MicroInt registers. I think it is
possible to do a zero register. We can introduce a new register that
does the job. Or else we can reuse one of the micro int registers.
t13/t14 are not in use at all. So they can be used. But we will have
to maintain a discipline of not using these any where else.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
Don't use t13 or t14. t0 is already defined as the zero register.
Gabe
But t0 is use in lots of places. Are you fine with changing those to
t13/t14?
--
Nilay
------------------------------
Message: 4
Date: Fri, 27 Apr 2012 11:12:30 -0700
From: Steve Reinhardt<[email protected]>
To: gem5 Developer List<[email protected]>
Subject: Re: [gem5-dev] x86 spec06 patches from Vince Weaver
Message-ID:
<CAHgMoh9=fmc49pe9i92qhdlmioutqe+x1wqsgxk930szqzf...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Apr 27, 2012 at 10:55 AM, Gabe Black<[email protected]> wrote:
If I recall, there were real problems with at least some of those
patches. The last time we brought them up we acknowledged at least a
problem with the ioctl patch(es) but I don't think they were ever
addressed.
The problems have not been addressed, no. How significant they are is a
matter of opinion. Ideally someone would step up and address them and we'd
be done with it. I'm saying that if no one is going to do that, we should
consider just committing them anyway, with comments indicating what needs
to be fixed, rather than forcing users to work around their absence for
years to come.
Steve
------------------------------
Message: 5
Date: Fri, 27 Apr 2012 11:22:18 -0700
From: Gabe Black<[email protected]>
To: [email protected]
Subject: Re: [gem5-dev] Review Request: ISA Parser: Decide source
register indices at runtime
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/27/12 11:01, Nilay Vaish wrote:
On Fri, 27 Apr 2012, Gabe Black wrote:
On 04/27/12 07:02, Nilay Vaish wrote:
On Wed, 25 Apr 2012, Nilay Vaish wrote:
On Wed, 25 Apr 2012, Gabriel Michael Black wrote:
Quoting Steve Reinhardt<[email protected]>:
On Wed, Apr 25, 2012 at 11:00 AM, Gabriel Michael Black<
[email protected]> wrote:
Quoting Nilay Vaish<[email protected]>:
Two things that I want to say in response --
a. With respect to memory usage, it would go down if we do what
Gabe
suggested in his review i.e. introduce members for each of the
registers
instead of using an array. This would also remove the
indirection. I'll get
performance numbers from some of the regression tests to carry
out a
performance comparison.
b. The aim for these set of patches is remove the RAW
dependence on
condition code register in x86. Current approach is to figure out
at run
time whether or not the CC register needs to be read. We require
this
dynamic map to correctly read the registers. In ARM ISA
description, some
thing similar has been done. At runtime, if a certain condition
is true,
the CC register is reda, otherwise register 0 is read. IIRC, no
instruction
can write to reg 0 in a RISC isa. Hence, there is no RAW
dependence. Can we
do this in x86 as well? May be a register that is only visible to
the
microcode.
I agree, at a high level, that keeping the existing _srcRegIdx[]
array and
just dealing with the fact that it may have gaps in it seems like an
alternative that's at least worth exploring.
We could also have a special register index like -1 that just means
invalid
so that we don't rely on piggybacking on some potentially
ISA-specific
characteristics to make it work.
That's essentially what the index constant ZeroReg does currently.
The special handling of the zero register is actually somewhat
annoying.
The CPU has to check for it and treat it specially, and, last I
recall, the
way it holds its zero value is to be rewritten with zero over and
over and
over to squash any errant updates. I would like to get rid of this
mechanism if possible, so my gut reaction is not to build more on
top of
it. That said, the zero register behavior isn't going away so it
has to
keep working somehow anyway. That may be a viable way to avoid
adding
storage to the StaticInst classes.
With Alpha, the decoder generates a no-op for any instruction whose
destination is the zero register, regardless of the opcode. In
theory,
this should make rewriting the zero value every cycle unnecessary.
I don't
know if some cases were missed, or if it's still needed for other
ISAs, but
that's the direction I'd want to go to get rid of that aspect. We
could
always just replace the overwrite with an assertion and see how far
we get.
On the input side, it would seem that instructions that read the
zero
register could be decoded into StaticInsts that act as if it were an
immediate zero operand.
So I'd think it's at least theoretically possible to make the
current
zero-register implementation go away.
Also, PowerPC has funky semantics in which the zero register
actually holds
a value, and whether you get that value or 0 depends on the
opcode. I'm
not sure how that's implemented in gem5, but we can't assume that
the
zero-register behavior is universal.
Steve
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
That's not necessarily feasible because you'd end up with lots of
variations of everything where one or more sources and/or one or
more destinations are replaced in some way. It's also not desirable
to turn them into nops because you may still want side effects like
setting condition codes. This is how at least the cmp instruction is
implemented as microcode in x86.
A long time ago I proposed using our index flattening mechanism to
flatten dests that had magical zero properties to a dead register,
and I think that would still make sense. There would be a little bit
of overhead because sources will still read from a zero register and
dests will still write to a /dev/null register, but renaming sorts
of operations would be minimal.
Gabe
Seems like the main discussion is getting side tracked. So do people
think that we should do this? The zeroth micro int register is
defined to be the ZeroReg. Does that mean if the operand is ZeroReg,
it would map to 0? Also, where are these micro int registers being
used? There aren't many places where INTREG_MICRO() is in use.
--
Nilay
I went through some of the code. It seems that the 't*' registers used
in the microcode would map to the MicroInt registers. I think it is
possible to do a zero register. We can introduce a new register that
does the job. Or else we can reuse one of the micro int registers.
t13/t14 are not in use at all. So they can be used. But we will have
to maintain a discipline of not using these any where else.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
Don't use t13 or t14. t0 is already defined as the zero register.
Gabe
But t0 is use in lots of places. Are you fine with changing those to
t13/t14?
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
No. t0 is already the zero register, and yes it's used in a lot of
places. Nothing about the registers needs to change. Every ISA in gem5
has a zero register already because Alpha has one (which is somewhat
unfortunate), and its index is specified with the ZeroReg constant.
Gabe
------------------------------
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
End of gem5-dev Digest, Vol 60, Issue 100
*****************************************
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
