---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
changeset 0421e52a57af in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=0421e52a57af
description:
scons: Allow GNU assembler version strings with hyphen
Make scons a bit more forgiving when determining the GNU assembler
version.
diffstat:
SConstruct | 12
changeset 119cfadf2203 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=119cfadf2203
description:
mem: Fix snoop packet data allocation bug
This patch fixes an issue where the snoop packet did not properly
forward the data pointer in case of static
please lend a hand !
Thanks
2015-06-04 15:38 GMT+02:00 Andreas Hansson andreas.hans...@arm.com:
Hi Asngar,
There are two options:
1 (the easy one) - Use another ISA. I would suggest ARM, ALPHA or X86.
2 (the one requiring work) - Provide an implementation for this syscall.
Andreas
in the
summary).
- Andreas Hansson
On June 5, 2015, 4:02 p.m., Matthias Jung wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2866
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2866/#review6472
---
Ship it!
Ship It!
- Andreas Hansson
On June 5, 2015, 4:05 p.m
Hi Asngar,
There are two options:
1 (the easy one) - Use another ISA. I would suggest ARM, ALPHA or X86.
2 (the one requiring work) - Provide an implementation for this syscall.
Andreas
On 04/06/2015 03:36, ESPERANCE ASNGAR esperance.asn...@gmail.com wrote:
Hello Everyone
I'm runnig under
Hi guys,
I do not think the solution is to remove delays (as Brad suggested).
Rather, I suggest we do the same as in the classic memory system, which is
to enforce order for all responses and snoop requests sent towards the CPU.
Andreas
On 01/06/2015 13:13, Brad Beckmann brad.beckm...@amd.com
On May 30, 2015, 3:21 p.m., Andreas Hansson wrote:
Ship It!
Thanks for the patch by the way. I think the summary is 65 char. Perhaps:
mem: Restore address on AddrMapper retry
- Andreas
---
This is an automatically generated e-mail
/2842/#comment5525
Yes, hack! :-)
Surely this should be done as part of the hitCallback rather?
- Andreas Hansson
On May 21, 2015, 7:27 p.m., Marco Elver wrote:
---
This is an automatically generated e-mail. To reply, visit
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2864/#review6437
---
Ship it!
Ship It!
- Andreas Hansson
On May 30, 2015, 2:33 p.m
On May 28, 2015, 11:01 p.m., Brad Beckmann wrote:
The modifications to packet queue have been removed from this patch. Can
the rest of this patch be checked in as is? There seems to be no consensus
on the clk domain issue. Once we check in this patch, perhaps someone who
feels
On May 29, 2015, 12:52 a.m., Brad Beckmann wrote:
Have you looked at the implications of cache hit latencies greater than 1?
In our experience, a hit latency greater than 1 causes consistent pipeline
bubbles and significant performance degradation. The O3 model does not
perform
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2754/#review6434
---
Ship it!
Ship It!
- Andreas Hansson
On May 6, 2015, 1:32 p.m
Hi Cliff,
We have quite a few internal simulation configurations of a similar nature
(multiple clusters of cores with private and/or shared L2s), and before
diving into the details, could you elaborate on how you connect the
clusters to the L3. Surely you need a CoherentXBar to accomplish this?
On May 25, 2015, 5:21 p.m., Andreas Hansson wrote:
I am not familiar with the Ruby caches, but on the classic side of things
we have recently _added_ cache parameters, for misses, forwarding, snopping
etc. I am mostly surprised to see that Ruby only has a single parameter
changeset 30bbc9b60a8c in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=30bbc9b60a8c
description:
ruby: Deprecation warning for RubyMemoryControl
A step towards removing RubyMemoryControl and shift users to
DRAMCtrl. The latter is faster, more
changeset 5312e4cb6547 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=5312e4cb6547
description:
base: Allow multiple interleaved ranges
This patch changes how the address range calculates intersection such
that a system can have a number of
with the changes suggested.
- Andreas Hansson
On May 3, 2015, 3:45 p.m., omar naji wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2750
-related timings by leaving them
as a responsibility of the cache?
- Andreas Hansson
On May 21, 2015, 4:05 p.m., Joel Hestness wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2841
/#comment5495
Well spotted.
I'll change it before pushing.
- Andreas Hansson
On May 8, 2015, 1:11 p.m., Andreas Hansson wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2768
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting
On May 13, 2015, 9:33 p.m., Andreas Hansson wrote:
src/mem/ruby/system/RubyPort.cc, line 423
http://reviews.gem5.org/r/2776/diff/1/?file=45140#file45140line423
In the crossbar we only send a single retry at a time. It used to look
like this, but imho it makes no sense. Once one
On May 13, 2015, 9:33 p.m., Andreas Hansson wrote:
src/mem/ruby/system/RubyPort.cc, line 298
http://reviews.gem5.org/r/2776/diff/1/?file=45140#file45140line298
I'd suggest to always send a retry, simply to comply with the timing
protocol. This is extra important these days
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting
changeset 9b424e7adac5 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=9b424e7adac5
description:
arm: Identify table-walker requests
This patch ensures all page-table walks are flagged as such.
diffstat:
src/arch/arm/table_walker.cc | 16
changeset d4b162a57400 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=d4b162a57400
description:
misc: Appease gcc 5.1
Three minor issues are resolved:
1. Apparently gcc 5.1 does not like negation of booleans followed by
bitwise AND.
changeset a4a2ba97a654 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=a4a2ba97a654
description:
config: Use null memory for DRAM sweep script
Do not waste time when we do not care about the data.
diffstat:
configs/dram/sweep.py | 6 ++
1 files
Hi,
Why not use gprof in the simulated system?
Andreas
On 12/05/2015 22:09, ESPERANCE ASNGAR esperance.asn...@gmail.com wrote:
Hello
Could you please explain me how can i modify the function_trace parameter
in order to profile my application in full system mode using ARM isa.
I like to get
On May 13, 2015, 9:36 p.m., Andreas Hansson wrote:
I do not understand the livelock scenario based on the description. Is the
patch trying to allow multiple loads/stores per cycle, or is it fixing an
issue?
Yasuko Eckert wrote:
This patch fixes a performance issue. It does
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting
/#comment5343
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting this needs to recondiser how
it deals with flow control
- Andreas Hansson
On May 11, 2015, 10:28 p.m., Tony Gutierrez wrote
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2783/#review6153
---
Ship it!
Ship It!
- Andreas Hansson
On May 11, 2015, 10:18 p.m
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2785/#review6154
---
Ship it!
I'd suggest to make it ruby:
- Andreas Hansson
On May 11
---
On May 8, 2015, 1:10 p.m., Andreas Hansson wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2766/
---
(Updated May 8
,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
.
Diffs
-
src/cpu/minor/execute.cc fbdaa08aaa42
Diff: http://reviews.gem5.org/r/2769/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
fbdaa08aaa42
Diff: http://reviews.gem5.org/r/2768/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
-
src/base/addr_range.hh fbdaa08aaa42
Diff: http://reviews.gem5.org/r/2767/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
potentially still dirty, or always came from Exclusive, i.e. Readable |
Writeable?
src/mem/packet.hh (line 107)
http://reviews.gem5.org/r/2691/#comment5326
Do we need the actual LockedRMW... or could if just be a flag on the
existing read and write req/resp?
- Andreas Hansson
changeset 581fb2484bd6 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=581fb2484bd6
description:
mem: Snoop into caches on uncacheable accesses
This patch takes a last step in fixing issues related to uncacheable
accesses. We do not separate
changeset 7f5467f2f8b8 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=7f5467f2f8b8
description:
stats: Update stats to reflect cache changes
diffstat:
tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-minor/stats.txt
| 738 +-
changeset 404b2b015a17 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=404b2b015a17
description:
mem: Add missing stats update for uncacheable MSHRs
This patch adds a missing counter update for the uncacheable
accesses. By updating this counter we
changeset b3b9097f44a9 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=b3b9097f44a9
description:
mem: Tidy up BaseCache parameters
This patch simply tidies up the BaseCache parameters and removes the
unused two_queue parameter.
diffstat:
changeset 2e8abe3bbe32 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=2e8abe3bbe32
description:
mem: Pass shared downstream through caches
This patch ensures that we pass on information about a packet being
shared (rather than exclusive), when
changeset 1e38e545823b in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=1e38e545823b
description:
arm: Add missing FPEXC.EN check
Add a missing check to ensure that exceptions are generated properly.
diffstat:
src/arch/arm/isa/insts/neon.isa | 10
changeset c6189a9b8cd7 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=c6189a9b8cd7
description:
stats: Bring regression stats in line with actual behaviour
diffstat:
tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3-dual/stats.txt
| 14
changeset e2a283400c43 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=e2a283400c43
description:
arch, cpu: Do not forward snoops to table walker
This patch simplifies the overall CPU by changing the TLB caches such
that they do not forward snoops to
changeset 46b6043bd32c in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=46b6043bd32c
description:
cpu: Work around gcc 4.9 issues with Num_OpClasses
This patch fixes a recent issue with gcc 4.9 (and possibly more) being
convinced that indices outside
/#comment5322
const
- Andreas Hansson
On April 2, 2015, 3:47 p.m., Steve Reinhardt wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2726
in
favour of DRAMCtrl and the fact that we already have a proper integration with
DRAMPower for the latter.
- Andreas Hansson
On Nov. 14, 2013, 11:56 a.m., shivam agarwal wrote:
---
This is an automatically generated e-mail. To reply
On May 4, 2015, 4:12 p.m., Nilay Vaish wrote:
SConstruct, line 403
http://reviews.gem5.org/r/2752/diff/1/?file=44838#file44838line403
What happens differently here? Just looking at the code, I would assume
that the operator [] behaves same as get() function.
Ruslan Bukin
Hi all,
With changeset: dac26eb4cb64 cpu: o3: replace issueLatency with bool
pipelined”, gem5 fails to compile:
build/ARM/cpu/o3/fu_pool.cc:91:38: error: array subscript is above array bounds
[-Werror=array-bounds]
maxOpLatencies[i] = Cycles(0);
^
:13 p.m., Andreas Hansson wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2711/
---
(Updated April 29, 2015, 9:13 p.m.)
Review
On April 15, 2015, 10:49 p.m., Andreas Hansson wrote:
Thanks for the fix. I'm ok with this going in, but I have a simplification
that I think we should consider instead. Let me post if and see what you
think.
Andreas Hansson wrote:
http://reviews.gem5.org/r/2746/
Let
e6b20e6b5cf9
src/cpu/o3/fu_pool.cc e6b20e6b5cf9
src/cpu/op_class.hh e6b20e6b5cf9
Diff: http://reviews.gem5.org/r/2751/diff/
Testing
---
Compiles with gcc 4.6.3, 4.8.2, 4.9.1, 5.1.0 without issues.
Thanks,
Andreas Hansson
___
gem5-dev
This seems to solve the issue:
http://reviews.gem5.org/r/2751/
My guess is that it’s a gcc bug.
Andreas
On 30/04/2015 08:58, Andreas Hansson andreas.hans...@arm.com wrote:
Hi all,
With changeset: dac26eb4cb64 cpu: o3: replace issueLatency with bool
pipelined”, gem5 fails to compile:
build
without issues.
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
April 2015 14:07
To: Default gem5-dev@gem5.orgmailto:gem5-dev@gem5.org, Andreas Hansson
andreas.hans...@arm.commailto:andreas.hans...@arm.com
Subject: Re: Review Request 2711: mem: Remove templates in cache model
Looking over this patch one last time, another question occurred to me
this is right.
src/mem/DRAMCtrl.py (line 437)
http://reviews.gem5.org/r/2750/#comment5302
I'd say this is a fair assumption for a highly optimised DRAM with low bank
count per rank.
- Andreas Hansson
On April 28, 2015, 2:04 p.m., omar naji wrote
://reviews.gem5.org/r/2711/#review6095
---
On April 23, 2015, 9:36 a.m., Andreas Hansson wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2711
/tags/base.hh df2aa91dba5b
src/mem/cache/tags/base_set_assoc.hh df2aa91dba5b
src/mem/cache/cache.cc df2aa91dba5b
src/mem/cache/cache_impl.hh df2aa91dba5b
Diff: http://reviews.gem5.org/r/2711/diff/
Testing
---
Thanks,
Andreas Hansson
On April 29, 2015, 6:03 a.m., Amin Farmahini wrote:
src/mem/DRAMCtrl.py, line 385
http://reviews.gem5.org/r/2750/diff/1/?file=44803#file44803line385
Did you mean 4GB? HMC v2 defines 4GB and 8GB devices. or may be you
mean 4Gb per layer and a total size of 2GB? or just an array?
getting rid of
the template and also the WrappedBlkVisitor typedef below. The new class
could use either name.
Andreas Hansson wrote:
Not possible since the block cannot include the Cache. The template
parameter is really just there to break the circular dependency.
Steve
/tags/lru.cc df2aa91dba5b
src/mem/cache/tags/random_repl.hh df2aa91dba5b
src/mem/cache/cache_impl.hh df2aa91dba5b
src/mem/cache/tags/base.hh df2aa91dba5b
Diff: http://reviews.gem5.org/r/2711/diff/
Testing
---
Thanks,
Andreas Hansson
---
On April 2, 2015, 9:31 a.m., Andreas Hansson wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2724/
---
(Updated April 2, 2015, 9
/#comment5315
No comma (sorry for nitpicking)
- Andreas Hansson
On April 29, 2015, 6:14 p.m., omar naji wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2750
/#comment5310
I suspect this should go under Amin's line below, and thus not include the
first paragraph.
- Andreas Hansson
On April 29, 2015, 4:59 p.m., omar naji wrote:
---
This is an automatically generated e-mail. To reply, visit:
http
of this
kind? Is it not generic enough to be used with any memory system?
- Andreas Hansson
On April 27, 2015, 7:23 p.m., Nilay Vaish wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2749
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2741/#review6085
---
Ship it!
Ship It!
- Andreas Hansson
On April 24, 2015, 5:45 p.m
Hi all,
With the recent removal of the old InOrderCPU, I’d suggest we proceed and
rename MinorCPU to InOrderCPU. This will mark the final step in the transition.
Let me know if you disagree or think it is too early.
A follow-on issue is that the status matrix is horribly out of date, and I
On April 24, 2015, 10:54 a.m., Andreas Hansson wrote:
src/arch/arm/freebsd/freebsd.hh, line 9
http://reviews.gem5.org/r/2741/diff/9/?file=44708#file44708line9
Should we stick to the normal format, or is there a good reason to
keep this as is?
Ruslan Bukin wrote:
what
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2733/#review6066
---
Ship it!
Ship It!
- Andreas Hansson
On April 9, 2015, 8:46 p.m
and Y 1?
- Andreas Hansson
On April 20, 2015, 4:49 p.m., Nilay Vaish wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2745
(line 282)
http://reviews.gem5.org/r/2741/#comment5277
virtual
src/arch/arm/system.cc (line 254)
http://reviews.gem5.org/r/2741/#comment5276
I'd even suggest to leave these in the header for now and make them
one-liners.
,
- Andreas Hansson
On April 24, 2015, 10:45 a.m., Ruslan
On April 24, 2015, 10:54 a.m., Andreas Hansson wrote:
src/arch/arm/freebsd/freebsd.hh, line 9
http://reviews.gem5.org/r/2741/diff/9/?file=44708#file44708line9
Should we stick to the normal format, or is there a good reason to
keep this as is?
Ruslan Bukin wrote:
what
On April 24, 2015, 10:54 a.m., Andreas Hansson wrote:
src/arch/arm/freebsd/freebsd.hh, line 9
http://reviews.gem5.org/r/2741/diff/9/?file=44708#file44708line9
Should we stick to the normal format, or is there a good reason to
keep this as is?
Ruslan Bukin wrote:
what
On April 24, 2015, 10:54 a.m., Andreas Hansson wrote:
src/arch/arm/freebsd/freebsd.hh, line 9
http://reviews.gem5.org/r/2741/diff/9/?file=44708#file44708line9
Should we stick to the normal format, or is there a good reason to
keep this as is?
Ruslan Bukin wrote:
what
On April 24, 2015, 10:54 a.m., Andreas Hansson wrote:
src/arch/arm/freebsd/freebsd.hh, line 9
http://reviews.gem5.org/r/2741/diff/9/?file=44708#file44708line9
Should we stick to the normal format, or is there a good reason to
keep this as is?
Ruslan Bukin wrote:
what
ignore these cases and opt for speed.
Diffs
-
src/mem/dram_ctrl.hh df2aa91dba5b
src/mem/dram_ctrl.cc df2aa91dba5b
Diff: http://reviews.gem5.org/r/2746/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5
On April 15, 2015, 10:49 p.m., Andreas Hansson wrote:
Thanks for the fix. I'm ok with this going in, but I have a simplification
that I think we should consider instead. Let me post if and see what you
think.
http://reviews.gem5.org/r/2746/
Let me know what you think.
- Andreas
changeset df2aa91dba5b in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=df2aa91dba5b
description:
misc: Appease gcc 5.1 without moving GDB_REG_BYTES
This patch rolls back the move of the GDB_REG_BYTES constant, and
instead adds M5_VAR_USED.
diffstat:
changeset 1e8e6c141372 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=1e8e6c141372
description:
misc: Appease gcc 5.1
This patch fixes a few small issues to ensure gem5 compiles when using
gcc 5.1.
First, the GDB_REG_BYTES in the RemoteGDB
and not really needed.
Steve
On Thu, Apr 23, 2015 at 10:47 AM, Andreas Hansson andreas.hans...@arm.com
wrote:
changeset 1e8e6c141372 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=1e8e6c141372
description:
misc: Appease gcc 5.1
This patch fixes a few
876341add7be
src/dev/dma_device.cc 876341add7be
src/mem/cache/base.hh 876341add7be
src/cpu/o3/cpu.cc 876341add7be
Diff: http://reviews.gem5.org/r/2717/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
Hi all,
I’d like to get the following patches pushed in the next week or so. Please let
me know if there are any further comments or you need more time. All
outstanding issues are resolved.
# Cache fixes and cleanup
http://reviews.gem5.org/r/2711/ (Steve, please check)
/mem/cache/tags/base_set_assoc.hh 74e3c7359393
src/mem/cache/base.cc 74e3c7359393
src/mem/cache/blk.hh 74e3c7359393
src/mem/cache/cache.hh 74e3c7359393
Diff: http://reviews.gem5.org/r/2711/diff/
Testing
---
Thanks,
Andreas Hansson
It does indeed seem suspicious. I got the impression there were only three
x86 regressions that did not match?
For ARM valgrind is happy and gcc 4.9 UBSan has nothing to report besides
some MiscRegIndex vs IntRegIndex enum mismatches. For x86 there are tons
of issues spotted by UBSan (and even
this whole list seems like
unnecessary overhead. I guess what we really need is the C++ equivalent of
python generators...
Andreas Hansson wrote:
It is only used as part of flushing and checkpointing so it should not be
a performance issue. Perhaps leave it as is for now?
Steve
changeset 378b344385a8 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=378b344385a8
description:
cpu: Remove the InOrderCPU from the tree
This patch takes the final step in removing the InOrderCPU from the
tree. Rest in peace.
The MinorCPU is
changeset e94c22bd9ef1 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=e94c22bd9ef1
description:
config: Remove memory aliases and rely on class name
Instead of maintaining two lists, rely entirely on the class
name. There is really no point in
Hi all,
I plan to push the following patches in the next few days:
# I2C device support
http://reviews.gem5.org/r/2700/
# NAND Flash and UFS device support
http://reviews.gem5.org/r/2708/
http://reviews.gem5.org/r/2709/
Let me know if you have any feedback and/or need more time.
Thanks,
generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2725/#review6019
---
On April 2, 2015, 9:31 a.m., Andreas Hansson wrote:
---
This is an automatically generated e-mail
Hi Lokesh,
gem5 does indeed currently only capture the delay in the transition, and
still “clocks” the components that are affected. A more detailed model of
the PMIC and voltage regulators, battery etc can definitely be added, the
transitions refined etc. The question is how much it matters, and
a simplification that
I think we should consider instead. Let me post if and see what you think.
- Andreas Hansson
On April 9, 2015, 8:48 p.m., Rizwana Begum wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5
this and turn it
into an iterator (c++11 style).
- Andreas Hansson
On Feb. 6, 2015, 10:03 p.m., Brandon Potter wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2641
801 - 900 of 3340 matches
Mail list logo
