It actually simplifies things a bit which I think is probably a win. I'm
most of the way through implementing it right now. This way, the ISA is
the only thing responsible for ISA level semantics which I'd say is also
a win. I like the idea of having fewer parts, namely a single constant
instea
At least for Alpha ALU ops, all the ones with a dest reg of r31 should get
decoded to "nop". The original code for zeroing out the "zero register" was
inherited from SimpleScalar (believe it or not), which did not handle r31
destinations specially and thus needed to reset the reg to zero before ev
I just ran the regression by hand and it still fails.
Gabe
Ali Saidi wrote:
> There was a change that Ke Meng sent that fixed some problems with O3
> in Alpha deadlocking. That fixed quite possibly fixed this as well.
>
> Ali
>
> On Aug 24, 2008, at 12:24 PM, Gabe Black wrote:
>
>
>> I'm pre
Yes, but I don't know if it'd be a good idea. If you specialize the
instruction itself, then you end up with bunches of variations of the
instructions which bloats the decode function, slows down compile time,
and kills our decode cache and the host I cache. If you override the
register index r
Register flattening happens all the time as of today. In Alpha it could
handle the shadow PAL registers, but I don't think anyone's done that.
In x86 it helps deal with all the wacky register widths and indexing
rules. I think it would actually make things -more- efficient, because
the way it w
Actually, you could also handle this in the decode of the instruction,
right? i.e. generate a different static instruction type if this is
going on.
Nate
On Sun, Aug 24, 2008 at 7:47 PM, nathan binkert <[EMAIL PROTECTED]> wrote:
> This seems like a laudable goal and a reasonable plan, my main
This seems like a laudable goal and a reasonable plan, my main
question is, how much does the register flattening cost, and are you
going to make anything we already do more expensive? Register access
is certainly on the critical path.
Nate
On Sun, Aug 24, 2008 at 7:35 PM, Gabe Black <[EMAIL P
I went and thought some more, and I think a better solution would be to
rely on the register flattening stuff put in place for SPARC. If there's
a constant register like a zero register (or a pi register, or a 1
register, or...), then that register is initialized to that value. To
preserve it,
I'm working on eliminating as many occurances of THE_ISA == X as is
reasonable, and one place it comes up is figuring out whether or not to
zero the floating point zero register. I think we discussed this before,
but would it make more sense for the register file to maintain that
semantic b
>I'm making a patch which is supposed to remove hwrei from the cpu
> models, and it seems to work. One thing that makes me a little nervous,
> though is that ozone is doing something with locks that the other CPUs
> aren't. I was hoping the regressions would help me figure out what the
> deal w
I'm making a patch which is supposed to remove hwrei from the cpu
models, and it seems to work. One thing that makes me a little nervous,
though is that ozone is doing something with locks that the other CPUs
aren't. I was hoping the regressions would help me figure out what the
deal was wi
Oh, that's right. I was dealing with StaticInstPtr before. It'd be nice
to be able to separate that as well.
Gabe
Ali Saidi wrote:
> PacketPtr and PacketReq aren't reference counting. We just starting
> using them incase we wanted reference counting pointers. Looking at
> the code we do a re
PacketPtr and PacketReq aren't reference counting. We just starting
using them incase we wanted reference counting pointers. Looking at
the code we do a reasonably job of using PacketPtr everywhere, but
RequestPtr is used maybe 40% of the time.
Ali
On Aug 24, 2008, at 3:20 PM, Gabe Black wr
nathan binkert wrote:
>> Is there a way to forward declare a typedef? We used PacketPtr and
>> RequestPtr all over the place in header files which requires including
>> packet.hh and request.hh. However, in many cases the only reason we
>> need to include the header files is because of the typedef.
> Is there a way to forward declare a typedef? We used PacketPtr and
> RequestPtr all over the place in header files which requires including
> packet.hh and request.hh. However, in many cases the only reason we
> need to include the header files is because of the typedef.
There is no way to forwa
I asked myself this same question a while ago for the same reasons, but
I never figured it out. I think the typedef isn't happy with an
incomplete type, and you can't get a reference counting pointer without
ending up including the whole deal behind it since it needs the
incrementing and decrem
Is there a way to forward declare a typedef? We used PacketPtr and
RequestPtr all over the place in header files which requires including
packet.hh and request.hh. However, in many cases the only reason we
need to include the header files is because of the typedef.
Ali
_
Because the machines were busy, which meant that the jobs timed out.
Ali
On Aug 24, 2008, at 12:45 PM, Gabe Black wrote:
> We should also figure out why the "all" regressions failed completely
> last night.
>
> Gabe Black wrote:
>> I'm pretty sure that perlbmk bug is still there and we just got
The changeset that caused this was:
changeset: 5520:cf280b3621cf
user:Steve Reinhardt <[EMAIL PROTECTED]>
date:Sun Aug 03 18:13:29 2008 -0400
summary: Make default PhysicalMemory latency slightly more
realistic.
It must be a latent bug that was exposed when Steve changed th
There was a change that Ke Meng sent that fixed some problems with O3
in Alpha deadlocking. That fixed quite possibly fixed this as well.
Ali
On Aug 24, 2008, at 12:24 PM, Gabe Black wrote:
> I'm pretty sure that perlbmk bug is still there and we just got rid of
> the regression. It might have
We should also figure out why the "all" regressions failed completely
last night.
Gabe Black wrote:
> I'm pretty sure that perlbmk bug is still there and we just got rid of
> the regression. It might have gone away on it's own, but I don't think
> anyone actively tried to fix it.
>
> Gabe
>
> A
I'm pretty sure that perlbmk bug is still there and we just got rid of
the regression. It might have gone away on it's own, but I don't think
anyone actively tried to fix it.
Gabe
Ali Saidi wrote:
> From the release notes the following are still outstanding for a 2.0
> release. I don't reall
changeset 3bd1fa125989 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=3bd1fa125989
description:
IGbE: Patches I neglected to apply before pushing the previous igbe
changeset
diffstat:
2 files changed, 2 insertions(+)
src/dev/i8254xGBe.cc |1 +
src/dev/i8254xGBe.hh
From the release notes the following are still outstanding for a 2.0
release. I don't really care about the Cygwin problems and I'm not
sure that anyone else does, so I move to strike those. Additionally,
we made the repository public so that one is gone.
I think the three things that need
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this: - Ali Saidi (saidi)
Attached to Project - M5 Bugs
Summary - Add statistics to bus
Task Type - Bug
Category - Memory System
Status - New
Assigned To -
Operating System - All
Se
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this: - Ali Saidi (saidi)
Attached to Project - M5 Bugs
Summary - Clean-up CPU statistics
Task Type - Bug
Category - CPU
Status - New
Assigned To -
Operating System - All
Severity -
Everyone should hold off pushing patches to the dev tree for the next
two weeks so we can create a new stable release. Please only push
fixes to known problems and test the repository in the next two weeks.
Thanks,
Ali
___
m5-dev mailing list
m5-dev
scons: *** [build/ALPHA_SE/libm5_fast.a] Error 1
scons: *** [build/ALPHA_FS/libm5_fast.a] Error 1
scons: *** [build/MIPS_SE/libm5_fast.a] Error 1
scons: *** [build/SPARC_SE/libm5_fast.a] Error 1
scons: *** [build/SPARC_FS/libm5_fast.a] Error 1
scons: *** [build/X86_SE/m5.fast] Error 1
See /z/m5/re
28 matches
Mail list logo
