[gem5-dev] Re: Design doc for partial rework of instruction execution mechanism

2021-02-23 Thread Jason Lowe-Power via gem5-dev
Thanks for the effort here, Gabe! I'm excited to dive in.

Just FYI, I will probably not have the bandwidth to deeply look at this for
at least a few weeks. Between remote teaching and trying to get the release
out of the door, I'm completely swamped for the near term.

Cheers,
Jason

On Tue, Feb 23, 2021 at 12:00 AM Gabe Black via gem5-dev 
wrote:

> Oh, also, while implementing everything in this new doc would/will be a
> pretty big undertaking, I think forcing operands in the ISA descriptions to
> be explicitly sources or destinations but not both would be a major
> improvement. For most registers that should be pretty trivial (they are
> already called things like "Dest" or "Src1"), and for the rest the change
> should just be a lot of find/replace style changes. That could be a first
> step towards what's in the doc and could be done immediately, independent
> of anything else.
>
> Gabe
>
> On Mon, Feb 22, 2021 at 11:57 PM Gabe Black  wrote:
>
>> Hey folks.I have a design doc for a moderate in scope but significant in
>> impact rework of how instruction execution and tracing work in gem5. This
>> is something I've been thinking about for a while, but threw together just
>> now to get it out there:
>>
>>
>> https://docs.google.com/document/d/1IqxBYr_arZq5G51oqmXoL5I9HiiwWMQ_t-rvHA78YPE/edit?usp=sharing
>>
>> This is strongly informed by an earlier design doc I wrote about how
>> registers are handled here:
>>
>>
>> https://docs.google.com/document/d/1O_u_Xq14TgreYThuZcbM3kuXFCrKvaFHA2O9poCeHSk/edit#heading=h.r067bn3rmydo
>>
>> It is a lot more narrowly scoped though, focusing only on operands and
>> instruction execution at the StaticInst level, but also extends beyond what
>> was described in that original doc.
>>
>> I'm biased of course, but I think there's a lot of value in reworking
>> things as described in the doc. Please take a look at let me know what you
>> think.
>>
>> Gabe
>>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: python: Add find function to pystats groups

2021-02-18 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/41603 )



Change subject: python: Add find function to pystats groups
..

python: Add find function to pystats groups

The `find` function allows users to "search" for a statistic or group
within a group. For instance, you might want to find all of the groups
within the system which have the name "cpu{i}". This is useful for
aggregate statistic values across multiple components.

Example:
total_instruuctions = sum([cpu.exec_context.thread_0.numInsts.value
   for cpu in simstat.system.find('cpu')])

The find functino matches based on substring. If the name given the find
function is a substring of the stat name or the group name the
stat/group will be returned. I considered making this perform the same
as the `like` operator in SQL or as a full regex, but decided this
simple implementation will cover almost all use cases.

Change-Id: I31c2a029d8a6b1d97225ab4efa34a4d13147ea32
Signed-off-by: Jason Lowe-Power 
---
M src/python/m5/pystats/group.py
1 file changed, 26 insertions(+), 2 deletions(-)



diff --git a/src/python/m5/pystats/group.py b/src/python/m5/pystats/group.py
index 0316d23..b72ab2f 100644
--- a/src/python/m5/pystats/group.py
+++ b/src/python/m5/pystats/group.py
@@ -24,7 +24,7 @@
 # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-from typing import Dict, List, Optional, Union
+from typing import Dict, Iterator, List, Optional, Union

 from .jsonserializable import JsonSerializable
 from .statistic import Scalar, Statistic
@@ -53,6 +53,30 @@
 for key,value in kwargs.items():
 setattr(self, key, value)

+def find(self, name: str) -> Iterator[Union["Group", Statistic]]:
+""" Find all stats that match the name
+
+This function searches all of the "children" in this group. It  
yields
+the set of attributes (children) that have the `name` as a  
substring.

+The order of the objects returned by the generator is arbitrary.
+
+```
+system.find('cpu') -> [cpu0, cpu1, cpu2, cpu3, other_cpu, ...]
+```
+
+This is useful for performing aggregates over substats. For  
instance:

+
+```
+total_instruuctions = sum([cpu.exec_context.thread_0.numInsts.value
+   for cpu in simstat.system.find('cpu')])
+```
+"""
+for attr in self.__dict__:
+if name in attr:
+obj = getattr(self, attr)
+if isinstance(obj, Group) or isinstance(obj, Statistic):
+yield obj
+
 class Vector(Group):
 """
 This Vector class is used to store vector information. However, in gem5
@@ -66,4 +90,4 @@
  type="Vector",
  timeConversion=None,
  **scalar_map,
-)
\ No newline at end of file
+)

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/41603
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I31c2a029d8a6b1d97225ab4efa34a4d13147ea32
Gerrit-Change-Number: 41603
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: removing partial linking hurts simulator performance, locality suspected

2021-02-10 Thread Jason Lowe-Power via gem5-dev
This is interesting! My takeaway: we need bigger i-caches to run gem5 ;).

Is the binary about the same size for the two conditions? Could it be
simply that the instruction working set is bigger when not using partial
linking?

That said, a 3% performance difference isn't a big problem, in my opinion.
This analysis also gives us some interesting directions for future
optimizations. I wonder how much the library version of pybind will help
since that will significantly reduce the instruction footprint.

Jason

On Tue, Feb 9, 2021 at 10:56 PM Gabe Black via gem5-dev 
wrote:

> I did some measurements before and after, and I noticed a few things.
> First, the iTLB-load-misses stat drops form 0.25% all the way down to
> 0.02%. The frontend and backend stall cycles went down from 1.72% => 1.27%
> and 13.90% => 10.62% respectively. The L1-icache-load-misses went *up* from
> 1.74% => 2.77%.
>
> So it looks like performance is generally about the same or a little
> better in most metrics, but for some reason icache hit rate drops.
>
> Performance measurements with partial linking:
>
> 429,882.68 msec task-clock:u  #1.000 CPUs utilized
>
>  0  context-switches:u#0.000 K/sec
>
>  0  cpu-migrations:u  #0.000 K/sec
>
>145,986  page-faults:u #0.340 K/sec
>
>  1,830,956,683,109  cycles:u  #4.259 GHz
>(35.71%)
> 31,472,946,642  stalled-cycles-frontend:u #1.72% frontend
> cycles idle (35.71%)
>254,440,746,368  stalled-cycles-backend:u  #   13.90% backend
> cycles idle  (35.71%)
>  4,117,921,862,700  instructions:u#2.25  insn per
> cycle
>   #0.06  stalled
> cycles per insn  (35.71%)
>773,059,098,367  branches:u# 1798.303 M/sec
>(35.71%)
>  2,775,345,450  branch-misses:u   #0.36% of all
> branches  (35.71%)
>  2,329,109,097,524  L1-dcache-loads:u # 5418.011 M/sec
>(35.71%)
> 24,907,172,614  L1-dcache-load-misses:u   #1.07% of all
> L1-dcache accesses  (35.71%)
>  LLC-loads:u
>
>  LLC-load-misses:u
>
>872,678,362,265  L1-icache-loads:u # 2030.038 M/sec
>(35.71%)
> 15,221,564,231  L1-icache-load-misses:u   #1.74% of all
> L1-icache accesses  (35.71%)
> 48,763,102,717  dTLB-loads:u  #  113.434 M/sec
>(35.71%)
> 75,459,133  dTLB-load-misses:u#0.15% of all dTLB
> cache accesses  (35.71%)
>  8,416,573,693  iTLB-loads:u  #   19.579 M/sec
>(35.72%)
> 20,650,906  iTLB-load-misses:u#0.25% of all iTLB
> cache accesses  (35.72%)
>
>  429.911532621 seconds time elapsed
>
>  428.611864000 seconds user
>0.199257000 seconds sys
>
>
> Performance measurements without partial linking:
>
> 444,598.61 msec task-clock:u  #1.000 CPUs utilized
>
>  0  context-switches:u#0.000 K/sec
>
>  0  cpu-migrations:u  #0.000 K/sec
>
>145,528  page-faults:u #0.327 K/sec
>
>  1,907,560,568,869  cycles:u  #4.291 GHz
>(35.71%)
> 24,156,412,003  stalled-cycles-frontend:u #1.27% frontend
> cycles idle (35.72%)
>202,601,144,555  stalled-cycles-backend:u  #   10.62% backend
> cycles idle  (35.72%)
>  4,118,200,832,359  instructions:u#2.16  insn per
> cycle
>   #0.05  stalled
> cycles per insn  (35.72%)
>773,117,144,029  branches:u# 1738.910 M/sec
>(35.72%)
>  2,727,637,567  branch-misses:u   #0.35% of all
> branches  (35.71%)
>  2,326,960,449,159  L1-dcache-loads:u # 5233.845 M/sec
>(35.71%)
> 26,778,818,764  L1-dcache-load-misses:u   #1.15% of all
> L1-dcache accesses  (35.71%)
>  LLC-loads:u
>
>  LLC-load-misses:u
>
>903,186,314,629  L1-icache-loads:u # 2031.465 M/sec
>(35.71%)
> 25,017,115,665  L1-icache-load-misses:u   #2.77% of all
> L1-icache accesses  (35.71%)
> 50,448,039,415  dTLB-loads:u  #  113.469 M/sec
>(35.71%)
> 78,186,127  dTLB-load-misses:u#0.15% of all dTLB
> cache accesses  (35.71%)
>  9,419,644,114  iTLB-loads:u  #   21.187 M/sec
>(35.71%)
>  1,479,281  iTLB-load-misses:u#0.02% of all iTLB
> cache accesses  (35.71%)
>
>  444.623341115 seconds time elapsed
>
>  443.313786000 seconds user
>0.256109000 seconds sys
>
> On Sat, Feb 6, 2021 at 5:20 AM Gabe Black  wrote:
>
>> Out of 

[gem5-dev] Re: Upstreaming power-gem5

2021-02-08 Thread Jason Lowe-Power via gem5-dev
Wow! Thanks for all of the work here! It's cool to see all of the
excitement around POWER support!

Just to be clear, because I think it was a little ambiguous in other
conversations, I'm very supportive of improving the POWER support in gem5
given that there are a significant number of people who want to use it. Not
long ago, there seemed to be little interest in POWER from the community,
which was influencing my push to limit the effort towards that ISA.

A couple of notes:
1. Per Bobby's recent email, we are *planning* (though plans can always
change) to mark a new gem5 release at the end of the month. In **one
week**, we are planning to create the staging branch which is the time that
no new features can be integrated for the release. If there's strong
support in the community, we can hold off for the improved POWER support,
but with all of the changes that need to be reviewed, it seems unlikely to
happen in 1 week. I suggest improved POWER support to be a main feature of
the next release (gem5-21.1 probably sometime in May or June).
2. Since we have a release coming up in 3 weeks, it is unlikely that I or
my team will have much time to look at these changes. With our limited
resources, we need to focus on finishing the features that we have started
and the general stability of gem5.

As I said, I'm very excited to see these improvements to gem5! And, I'm
looking forward to seeing the community grow!

Cheers,
Jason

On Sun, Feb 7, 2021 at 10:32 PM Sandipan Das via gem5-dev 
wrote:

> +CC: Luke
>
> On 08/02/21 10:26 am, Sandipan Das wrote:
> > Hello Boris, Gabe,
> >
> > I have rebased and pushed the changes to gerrit.
> > This is link to the first patch in the series:
> > https://gem5-review.googlesource.com/c/public/gem5/+/40880
> >
> >
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Testlib six dependency

2021-01-26 Thread Jason Lowe-Power via gem5-dev
I don't know... We've had a few discussions about this. There's some
separation between the underlying infrastructure in testlib and the code
that uses it in tests. We could move it to tests/testlib, I guess. It would
make it more clear that there's no upstream version of it.

Either way is fine with me.

Jason

On Tue, Jan 26, 2021 at 9:45 AM Andreas Sandberg 
wrote:

> Hi Jason,
>
> Thanks for confirming that. I have posted an update here:
> https://gem5-review.googlesource.com/c/public/gem5/+/39759
>
> Since there is no upstream for testlib, should we move it into tests/
> somewhere instead of keeping it in ext/?
>
> Cheers,
> Andreas
> On 26/01/2021 16:21, Jason Lowe-Power wrote:
>
> Hi Andreas,
>
> There is no upstream for testlib. It's a purely gem5 project. We should
> fix it in tree.
>
> Jason
>
> On Tue, Jan 26, 2021 at 4:56 AM Andreas Sandberg via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Hi Everyone,
>>
>> I have just posted a series of patches [1] that get rid of 'six' as a
>> dependency in gem5. However, there is still a dependency on six coming
>> from testlib. What's the process there? Should we fix it upstream and
>> backport it or is testlib now effectively a gem5 project?
>>
>> Cheers,
>> Abdreas
>>
>> [1] https://gem5-review.googlesource.com/c/public/gem5/+/39758
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Testlib six dependency

2021-01-26 Thread Jason Lowe-Power via gem5-dev
Hi Andreas,

There is no upstream for testlib. It's a purely gem5 project. We should fix
it in tree.

Jason

On Tue, Jan 26, 2021 at 4:56 AM Andreas Sandberg via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi Everyone,
>
> I have just posted a series of patches [1] that get rid of 'six' as a
> dependency in gem5. However, there is still a dependency on six coming
> from testlib. What's the process there? Should we fix it upstream and
> backport it or is testlib now effectively a gem5 project?
>
> Cheers,
> Abdreas
>
> [1] https://gem5-review.googlesource.com/c/public/gem5/+/39758
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Nightly stuck

2021-01-18 Thread Jason Lowe-Power via gem5-dev
Thanks, Giacomo! We may be a bit slow to respond (it's a holiday here in
the states today and Bobby is off the next couple of days).

I don't think we want to do a global timeout since we have some tests that
take days. The compiler test takes about 3 days, IIRC. I think per-test
timeout is going to be required.

Cheers,
Jason

On Mon, Jan 18, 2021 at 9:43 AM Giacomo Travaglini via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi all,
>
> This has been fixed and it's going to be merged today.
>
> This made me realize we might want to introduce a timeout for our
> regressions. A global, Jenkins level one is easy to add and doesn't require
> any code modifications.
>
> However a per-test timeout is probably the best approach. In this way we
> can:
>
> a) Understand which regression is deadlocking from the output log
> b) Killing the failing test earlier thus saving computational costs:
>
> e.g: I will kill the test after 6 minutes if it is supposed to complete in
> a minute, rather than having a global abort set up after 24 hours.
>
> How to do this is up do debate. This falls within the typical wall-clock
> time vs cpu time issue; setting up a timeout for wall-clock time is
> straightforward with python subprocess, but cpu time is what we would
> really care about...
> Though if we make sure our timing out margin is relatively high (loosening
> the safety net) we can probably get around the intrinsic difference between
> the two metrics and just use wall-clock time.
>
> Does anybody have any thoughts on this?
>
> Giacomo
>
> > -Original Message-
> > From: Giacomo Travaglini
> > Sent: 18 January 2021 10:22
> > To: gem5 Developer List 
> > Subject: Nightly stuck
> >
> > Hi devs,
> >
> > It seems like the following Nightly run #191 is stuck:
> >
> > https://jenkins.gem5.org/job/Nightly/191/
> >
> > I am running those tests locally to understand if it is a tool problem
> or broken
> > long regressions are currently broken Will keep you posted
> >
> > Kind Regards
> >
> > Giacomo
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Re-join debug flags headers

2021-01-18 Thread Jason Lowe-Power via gem5-dev
Thanks for bringing this up, Daniel!

I don't have a strong opinion, personally. I see how this makes things a
little easier for developers. No longer would we have to teach people that
to add a new debug flag you both declare it in the SConscript file and
include the named header file. Given that I've worked with gem5 for a long
time, I don't see that as much overhead, though.

This would increase the compile time (though, hopefully only rarely). And,
we recently found from the gem5 survey that people don't care that much
about the compile time (more info coming soon).

I think the biggest downside would be for those that use gem5 in teaching.
Students in architecture classes are the most likely to have underpowered
computers building gem5, and they are also likely to be adding debug flags.

Cheers,
Jason

On Fri, Jan 15, 2021 at 5:47 PM Daniel Carvalho via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hello all,
>
> I've uploaded a commit that re-joins the debug header files into a single
> one: https://gem5-review.googlesource.com/c/public/gem5/+/39255. This
> means that instead of having to include a different header for each and
> every debug flag used in a file, only one is needed. For example, in
> src/arch/arm/kvm/arm_cpu.cc
>
> #include "debug/Kvm.hh"
> #include "debug/KvmContext.hh"
> #include "debug/KvmInt.hh"
>
> would be replaced by
>
> #include "debug/flags.hh"
>
> Finally, since most of the code using these flags will use DPRINTF or a
> similar macro, this include could be added to base/trace.hh, so that most
> of the times it would be included transitively.
>
> The advantage of this change is that debugging becomes easier/faster: this
> file would behave as a library of supported flags and very few header
> files would suffice for all debugging needs. The disadvantage is that
> every time a commit introduces or removes a debug flag debug/flags.hh will
> be recompiled, which will cause an almost complete build. Luckily, debug
> flags are not frequently modified.
>
> Performance-wise both approaches are similar.
>
> What are your opinions in this matter?
>
> Cheers,
> Daniel
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Testing fail on GCN3_X86 on Arm machine

2021-01-11 Thread Jason Lowe-Power via gem5-dev
Hi all,

It doesn't surprise me at all that GCN3 doesn't build on Arm. Nathanael,
you should be able to ignore those errors. We don't test that combination
of host-target and I have not heard of anyone trying to use that
combination of host-target.

If you're trying to use the GPU model, I'd suggest moving to an x86 host.
Unfortunately, right now the GPU model is intricately tied to the host OS.
Hence why the docker is all but required to get the GPU model working.

Cheers,
Jason

On Mon, Jan 11, 2021 at 10:59 AM Matt Sinclair via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi Nathanael,
>
> I have personally never tested GCN3 on an ARM machine, so I can't say
> definitively if it will work there or not.  But if you are not, I strongly
> recommend testing anything you need to test with GCN3 inside the docker we
> created:
>
> -
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/util/dockerfiles/gcn-gpu/README.md
> - http://www.gem5.org/2020/05/27/modern-gpu-applications.html
>
> Thanks,
> Matt
>
> On Mon, Jan 11, 2021 at 8:42 AM Nathanael Premillieu via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Hi,
>>
>>
>>
>> I’m currently working on some changes in gem5 and before submitting them,
>> I’m using the testing framework as required.
>>
>> However, even without my changes, I get failures when building GCN3_X86
>> (See the trace at the end).
>>
>> I guess it is linked to the fact that I’m working on an Arm machine. Do I
>> need to set up something to make it work?
>>
>>
>>
>> Thanks,
>>
>> Nathanael Premillieu
>>
>>
>>
>> The trace:
>>
>> /scratch/npremill/gem5_public.git/build/GCN3_X86/gem5.opt
>>
>> You may want to run with only a single ISA(--isa=), use --skip-build, or
>> use 'rerun'.
>>
>> MOESI_AMD_Base-dir.sm:220: Warning: Non-void return ignored, return type
>> is 'bool'
>>
>> MOESI_AMD_Base-dir.sm:1052: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:1056: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:1060: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:1064: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:1068: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:1072: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:1076: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:586: Warning: Unused action: l_queueMemWBReq, Write
>> WB data to memory
>>
>> MOESI_AMD_Base-dir.sm:953: Warning: Unused action:
>> mwc_markSinkWriteCancel, Mark to sink impending VicDirty
>>
>> MOESI_AMD_Base-dir.sm:1051: Warning: Unused action: dl_deallocateL3,
>> deallocate the L3 block
>>
>> MOESI_AMD_Base-dir.sm:1087: Warning: Unused action:
>> yy_recycleResponseQueue, recycle response queue
>>
>> MOESI_AMD_Base-dma.sm:187: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dma.sm:191: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-CorePair.sm:325: Warning: Non-void return ignored, return
>> type is 'bool'
>>
>> MOESI_AMD_Base-CorePair.sm:802: Warning: Non-void return ignored, return
>> type is 'Tick'
>>
>> MOESI_AMD_Base-CorePair.sm:806: Warning: Non-void return ignored, return
>> type is 'Tick'
>>
>> MOESI_AMD_Base-CorePair.sm:810: Warning: Non-void return ignored, return
>> type is 'Tick'
>>
>> MOESI_AMD_Base-CorePair.sm:814: Warning: Non-void return ignored, return
>> type is 'Tick'
>>
>> GPU_VIPER-TCP.sm:166: Warning: Non-void return ignored, return type is
>> 'bool'
>>
>> GPU_VIPER-TCP.sm:451: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-TCP.sm:455: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-TCP.sm:385: Warning: Unused action: norl_issueRdBlkOrloadDone,
>> local load done
>>
>> GPU_VIPER-SQC.sm:143: Warning: Non-void return ignored, return type is
>> 'bool'
>>
>> GPU_VIPER-SQC.sm:275: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-SQC.sm:279: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-TCC.sm:168: Warning: Non-void return ignored, return type is
>> 'bool'
>>
>> GPU_VIPER-TCC.sm:551: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-TCC.sm:555: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-TCC.sm:559: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-TCC.sm:583: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> MOESI_AMD_Base-L3cache.sm:196: Warning: Non-void return ignored, return
>> type is 'bool'
>>
>> MOESI_AMD_Base-L3cache.sm:611: Warning: Non-void return ignored, return
>> type is 'Tick'
>>
>> MOESI_AMD_Base-L3cache.sm:615: Warning: Non-void return ignored, return
>> type is 'Tick'
>>
>> MOESI_AMD_Base-L3cache.sm:619: Warning: Non-void return ignored, return
>> type is 

[gem5-dev] Change in gem5/gem5[develop]: cpu,stats: Update stats for tage_sc_l to new style stats

2020-12-10 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/36336 )


Change subject: cpu,stats: Update stats for tage_sc_l to new style stats
..

cpu,stats: Update stats for tage_sc_l to new style stats

Updated tage_sc_l.hh and tage_sc_l.cc to use new style stats.

Change-Id: If172c95bb728c7c3748269469781212ef1da6f32
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36336
Reviewed-by: Hoa Nguyen 
Reviewed-by: Trivikram Reddy 
Maintainer: Bobby R. Bruce 
Tested-by: kokoro 
---
M src/cpu/pred/tage_sc_l.cc
M src/cpu/pred/tage_sc_l.hh
2 files changed, 0 insertions(+), 8 deletions(-)

Approvals:
  Hoa Nguyen: Looks good to me, approved
  Trivikram Reddy: Looks good to me, but someone else must approve
  Bobby R. Bruce: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/pred/tage_sc_l.cc b/src/cpu/pred/tage_sc_l.cc
index 01171cb..bde71a8 100644
--- a/src/cpu/pred/tage_sc_l.cc
+++ b/src/cpu/pred/tage_sc_l.cc
@@ -458,9 +458,3 @@

 delete bi;
 }
-
-void
-TAGE_SC_L::regStats()
-{
-LTAGE::regStats();
-}
diff --git a/src/cpu/pred/tage_sc_l.hh b/src/cpu/pred/tage_sc_l.hh
index b8714ad..d4986e2 100644
--- a/src/cpu/pred/tage_sc_l.hh
+++ b/src/cpu/pred/tage_sc_l.hh
@@ -154,8 +154,6 @@
 bool predict(
 ThreadID tid, Addr branch_pc, bool cond_branch, void* ) override;

-void regStats() override;
-
 void update(ThreadID tid, Addr branch_addr, bool taken, void  
*bp_history,

 bool squashed, const StaticInstPtr & inst,
 Addr corrTarget) override;

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/36336
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: If172c95bb728c7c3748269469781212ef1da6f32
Gerrit-Change-Number: 36336
Gerrit-PatchSet: 2
Gerrit-Owner: Mahyar Samani 
Gerrit-Reviewer: Ayaz Akram 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Hoa Nguyen 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Marjan Fariborz 
Gerrit-Reviewer: Maryam Babaie 
Gerrit-Reviewer: Trivikram Reddy 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: util: Use MAINTAINERS.yaml for valid tags in git hook

2020-11-20 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/37220 )


Change subject: util: Use MAINTAINERS.yaml for valid tags in git hook
..

util: Use MAINTAINERS.yaml for valid tags in git hook

There is a mismatch between the tags in MAINTAINERS.yaml and the
valid_tags in the git hook. This means if a user consults the
MAINTAINERS.yaml file to find the appropriate tag, there is a chance of
the commit being rejected due to this mismatch. Now that the maintainers
file is in yaml format, use the util/maint library to parse the valid
tag options. Additional meta tags are added (WIP, RFC) and tags that
were previously valid but not in the MAINTAINERS.yaml file.

Change-Id: I3de8f0b6f8507aa1afd2118bc4373ac0610cce40
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37220
Reviewed-by: Andreas Sandberg 
Reviewed-by: Daniel Carvalho 
Reviewed-by: Giacomo Travaglini 
Reviewed-by: Jason Lowe-Power 
Reviewed-by: Nikos Nikoleris 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M util/git-commit-msg.py
A util/maint/__init__.py
2 files changed, 10 insertions(+), 13 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  Andreas Sandberg: Looks good to me, approved
  Nikos Nikoleris: Looks good to me, approved
  Giacomo Travaglini: Looks good to me, but someone else must approve
  Daniel Carvalho: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/util/git-commit-msg.py b/util/git-commit-msg.py
index 9cba896..2bddf12 100755
--- a/util/git-commit-msg.py
+++ b/util/git-commit-msg.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 #
 # Copyright (c) 2019 Inria
 # All rights reserved
@@ -32,6 +32,7 @@
 import os
 import re
 import sys
+from maint.lib import maintainers

 from style.repo import GitRepo

@@ -57,8 +58,8 @@

 print("""
 The first line of a commit must contain one or more gem5 tags separated by
-commas (see MAINTAINERS for the possible tags), followed by a colon and a
-commit title. There must be no leading nor trailing whitespaces.
+commas (see MAINTAINERS.yaml for the possible tags), followed by a colon  
and

+a commit title. There must be no leading nor trailing whitespaces.

 This header line must then be followed by an empty line. A detailed  
message,
 although highly recommended, is not mandatory and can follow that empty  
line.

@@ -85,17 +86,12 @@
 """

 # List of valid tags
-# @todo this is error prone, and should be extracted automatically from
-#   a file
+maintainer_dict = maintainers.Maintainers.from_file()
+valid_tags = [tag for tag, _ in maintainer_dict]

-valid_tags = ["arch", "arch-arm", "arch-gcn3",
-"arch-mips", "arch-power", "arch-riscv", "arch-sparc", "arch-x86",
-"base", "configs", "cpu", "cpu-kvm", "cpu-minor", "cpu-o3",
-"cpu-simple", "dev", "dev-arm", "dev-hsa", "dev-virtio", "ext",
-"fastmodel", "gpu-compute", "learning-gem5", "mem", "mem-cache",
-"mem-garnet", "mem-ruby", "misc", "python", "scons", "sim", "sim-se",
-"sim-power", "stats", "system", "system-arm", "systemc", "tests",
-"util", "RFC", "WIP"]
+# Remove non-tag 'pmc' and add special tags not in MAINTAINERS.yaml
+valid_tags.remove('pmc')
+valid_tags.extend(['RFC', 'WIP'])

 tags = ''.join(commit_header.split(':')[0].split()).split(',')
 if (any(tag not in valid_tags for tag in tags)):
diff --git a/util/maint/__init__.py b/util/maint/__init__.py
new file mode 100644
index 000..e5a0d9b
--- /dev/null
+++ b/util/maint/__init__.py
@@ -0,0 +1 @@
+#!/usr/bin/env python3

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/37220
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I3de8f0b6f8507aa1afd2118bc4373ac0610cce40
Gerrit-Change-Number: 37220
Gerrit-PatchSet: 3
Gerrit-Owner: Matthew Poremba 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Boris Shingarov 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Giacomo Travaglini 
Gerrit-Reviewer: Hoa Nguyen 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: util: Relax commit message checker to allow fixups

2020-11-20 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/37598 )


Change subject: util: Relax commit message checker to allow fixups
..

util: Relax commit message checker to allow fixups

Change-Id: I094de0a9cb65af0ba0a8700d77cd51c6537d7beb
Signed-off-by: Nikos Nikoleris 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37598
Tested-by: kokoro 
Reviewed-by: Daniel Carvalho 
Reviewed-by: Jason Lowe-Power 
Reviewed-by: Bobby R. Bruce 
Maintainer: Jason Lowe-Power 
---
M util/git-commit-msg.py
1 file changed, 4 insertions(+), 2 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  Daniel Carvalho: Looks good to me, approved
  Bobby R. Bruce: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/util/git-commit-msg.py b/util/git-commit-msg.py
index 2bddf12..db0fbdd 100755
--- a/util/git-commit-msg.py
+++ b/util/git-commit-msg.py
@@ -109,10 +109,12 @@
 commit_message_lines = commit_message.splitlines()
 commit_header = commit_message_lines[0]
 commit_header_match = \
-re.search("^(\S[\w\-][,\s*[\w\-]+]*:.+\S$)", commit_header)
+re.search("^(fixup! )?(\S[\w\-][,\s*[\w\-]+]*:.+\S$)", commit_header)
 if ((commit_header_match is None)):
 _printErrorQuit("Invalid commit header")
-_validateTags(commit_header)
+if commit_header_match.group(1) == "fixup! ":
+sys.exit(0)
+_validateTags(commit_header_match.group(2))

 # Make sure commit title does not exceed threshold. This line is limited to
 # a smaller number because version control systems may add a prefix,  
causing


--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/37598
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I094de0a9cb65af0ba0a8700d77cd51c6537d7beb
Gerrit-Change-Number: 37598
Gerrit-PatchSet: 3
Gerrit-Owner: Nikos Nikoleris 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: misc: Update maintainers file

2020-11-05 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/36886 )


Change subject: misc: Update maintainers file
..

misc: Update maintainers file

Change-Id: I19810801f0acd5a35dde59a70166339e00b97eca
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36886
Reviewed-by: Nikos Nikoleris 
Reviewed-by: Srikant Bharadwaj 
Reviewed-by: Gabe Black 
Reviewed-by: Bobby R. Bruce 
Reviewed-by: Boris Shingarov 
Reviewed-by: Hoa Nguyen 
Reviewed-by: ZHENGRONG WANG 
Reviewed-by: Andreas Sandberg 
Reviewed-by: Giacomo Travaglini 
Reviewed-by: Matthew Poremba 
Maintainer: Andreas Sandberg 
Tested-by: kokoro 
---
M MAINTAINERS
1 file changed, 53 insertions(+), 22 deletions(-)

Approvals:
  Andreas Sandberg: Looks good to me, approved; Looks good to me, approved
  Nikos Nikoleris: Looks good to me, approved
  Matthew Poremba: Looks good to me, approved
  Boris Shingarov: Looks good to me, approved
  Giacomo Travaglini: Looks good to me, approved
  Srikant Bharadwaj: Looks good to me, approved
  Hoa Nguyen: Looks good to me, approved
  Gabe Black: Looks good to me, approved
  Bobby R. Bruce: Looks good to me, approved
  ZHENGRONG WANG: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/MAINTAINERS b/MAINTAINERS
index 913daaf..7ae23fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6,15 +6,18 @@
 when you upload the patch to Gerrit (https://gem5-review.googlesource.com).
 These keywords mostly follow the directory structure.

-Individuals on the project management committee are maintainers for all of  
the

-gem5 components (i.e., they can review any patch as the maintainer). These
-individuals are required to review any patches to components without  
explicit

-maintainers.
+Maintainers have the following responsibilities:
+1. That at least one maintainer of each subsystem reviews all changes to  
that

+   subsystem (they will be automatically tagged and emailed on each new
+   change).
+2. They will complete your reviews in a timely manner (within a few  
business

+   days).
+3. They pledge to uphold gem5's community standards and its code of  
conduct by
+   being polite and professional in their code reviews. See  
CODE-OF-CONDUCT.md.


 PMC Members (general maintainers):
-  Ali Saidi 
   Andreas Sandberg 
-  Brad Beckmann 
+  Brad Beckmann 
   David Wood 
   Gabe Black 
   Giacomo Travaglini 
@@ -29,65 +32,90 @@
   Andreas Sandberg 
   Giacomo Travaglini 
 arch-gcn3:
-  Tony Gutierrez 
+  UNSUPPORTED
 arch-mips:
+  UNSUPPORTED
 arch-power:
+  Boris Shingarov 
 arch-riscv:
-  Alec Roelke 
+  UNSUPPORTED
 arch-sparc:
   Gabe Black 
 arch-x86:
   Gabe Black 

 base:
+  Bobby Bruce 
+base-stats:
+  UNSUPPORTED

 configs:
   Jason Lowe-Power 

 cpu: General changes to all CPU models (e.g., BaseCPU)
+  Gabe Black 
+  Jason Lowe-Power 
 cpu-kvm:
   Andreas Sandberg 
 cpu-minor:
+  Zhengrong Wang 
 cpu-o3:
+  UNSUPPORTED
 cpu-simple:
+  Jason Lowe-Power 
+  Gabe Black 

 dev:
+  Gabe Black 
 dev-hsa:
-  Tony Gutierrez 
+  UNSUPPORTED
 dev-virtio:
   Andreas Sandberg 
-
 dev-arm:
   Andreas Sandberg 
   Giacomo Travaglini 

+doc:
+  Bobby Bruce 
+
 ext: Components external to gem5
+  Bobby Bruce 
+  Jason Lowe-Power 
+ext-testlib:
+  Bobby Bruce 
+  Hoa Nguyen 

 fastmodel: Changes relating to ARM Fast Models
   Gabe Black 

 gpu-compute:
-  Tony Gutierrez 
   Matt Poremba 

-learning-gem5: The code and configs for the Learning gem5 book (see
-   learning.gem5.com)
+learning-gem5: The code and configs for the Learning gem5 book
   Jason Lowe-Power 

 mem: General memory system (e.g., XBar, Packet)
   Nikos Nikoleris 
 mem-cache: Classic caches and coherence
   Nikos Nikoleris 
+mem-dram:
+  Nikos Nikoleris 
 mem-garnet: Garnet subcomponent of Ruby
-  Tushar Krishna 
+  Srikant Bharadwaj 
 mem-ruby: Ruby structures and protocols
-  Brad Beckmann 
   Jason Lowe-Power 

 misc: Anything outside of the other categories
+  Bobby Bruce 
+  Jason Lowe-Power 

 python: Python SimObject wrapping and infrastructure
   Andreas Sandberg 
+  Jason Lowe-Power 
+
+resources: The gem5-resources repo with auxiliary resources for simulation
+  Bobby Bruce 
+  Jason Lowe-Power 

 scons: Build system
   Gabe Black 
@@ -95,13 +123,8 @@
 sim: General simulation components
   Jason Lowe-Power 
 sim-se: Syscall emulation
-  Brandon Potter 
-sim-power: Power modeling
-  Andreas Sandberg 
+  UNSUPPORTED

-stats: Updates to statistics for regressions
-
-system: System boot code and related components
 system-arm:
   Andreas Sandberg 
   Giacomo Travaglini 
@@ -109,8 +132,16 @@
 systemc: Code for the gem5 SystemC implementation and interface
   Gabe Black 

-tests: testing changes (not stats updates for tests. See stats:)
+tests: testing changes
   Bobby Bruce 

 util:
   Gabe Black 
+util-docker:
+  Bobby Bruce 
+util-m5:
+  Gabe Black 
+
+website: The gem5-website

[gem5-dev] Re: Build failed in Jenkins: Nightly #118

2020-11-04 Thread Jason Lowe-Power via gem5-dev
Hi all,

I'm pretty sure https://gem5-review.googlesource.com/c/public/gem5/+/34984
is the breaking change on last night's build.

It's unfortunate how much time/effort supporting MIPS and other ISAs
takes...

Cheers,
Jason

On Tue, Nov 3, 2020 at 11:03 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/Nightly/118/display/redirect?page=changes>
>
> Changes:
>
> [gabe.black] arch: Clean up the __init__s in (Sub)OperandList.
>
> [davide.basilio.bartolini] configs: Do not require default options for
> caches
>
> [giacomo.travaglini] cpu, fastmodel: Remove the old getDTBPtr/getITBPtr
> virtual methods
>
> [giacomo.travaglini] arch-arm: Add el2Enabled cached variable
>
> [giacomo.travaglini] arch-arm: Fix implementation of TLBI_VMALL
> instructions
>
> [giacomo.travaglini] arch-arm: TlbEntry flush to be considered as
> functional lookup
>
> [giacomo.travaglini] arch-arm: Do not use _flushMva for TLBI IPA
>
> [yuhsingw] configs: Add dtb-gen to fs_bigLITTLE.py
>
>
> --
> [...truncated 68.77 KB...]
>  [SO PARAM] DMA_Controller -> MIPS/params/DMA_Controller.hh
>  [MAKE INC] MIPS/mem/ruby/common/BoolVec.hh -> protocol/BoolVec.hh
>  [MAKE INC] MIPS/mem/ruby/structures/CacheMemory.hh ->
> protocol/CacheMemory.hh
>  [MAKE INC] MIPS/mem/ruby/system/DMASequencer.hh ->
> protocol/DMASequencer.hh
>  [MAKE INC] MIPS/mem/ruby/structures/DirectoryMemory.hh ->
> protocol/DirectoryMemory.hh
>  [MAKE INC] MIPS/mem/ruby/system/HTMSequencer.hh ->
> protocol/HTMSequencer.hh
>  [SO PARAM] RubyPrefetcher -> MIPS/params/RubyPrefetcher.hh
>  [MAKE INC] MIPS/mem/ruby/structures/RubyPrefetcher.hh ->
> protocol/RubyPrefetcher.hh
>  [MAKE INC] MIPS/mem/ruby/system/Sequencer.hh -> protocol/Sequencer.hh
>  [MAKE INC] MIPS/mem/ruby/common/Set.hh -> protocol/Set.hh
>  [MAKE INC] MIPS/mem/ruby/structures/TimerTable.hh ->
> protocol/TimerTable.hh
>  [SO PARAM] RubyWireBuffer -> MIPS/params/RubyWireBuffer.hh
>  [MAKE INC] MIPS/mem/ruby/structures/WireBuffer.hh ->
> protocol/WireBuffer.hh
>  [MAKE INC] MIPS/mem/ruby/common/WriteMask.hh -> protocol/WriteMask.hh
>  [MAKE INC] MIPS/mem/ruby/slicc_interface/AbstractCacheEntry.hh ->
> protocol/AbstractCacheEntry.hh
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Event.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_State.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_TBE.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DirectoryRequestType.cc -> .o
>  [SO PARAM] Directory_Controller -> MIPS/params/Directory_Controller.hh
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Entry.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Event.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_State.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_TBE.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/HtmCallbackMode.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/HtmFailedInCacheReason.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/InvalidateGeneratorStatus.cc -> .o
>  [SO PARAM] L1Cache_Controller -> MIPS/params/L1Cache_Controller.hh
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Entry.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Event.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_State.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_TBE.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/LinkDirection.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/LockStatus.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MachineType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MaskPredictorIndex.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MaskPredictorTraining.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MaskPredictorType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MemoryControlRequestType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MemoryMsg.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MemoryRequestType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MessageSizeType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/PrefetchBit.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/RequestMsg.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/RequestStatus.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/ResponseMsg.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/RubyAccessMode.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/RubyRequestType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/SequencerMsg.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/SequencerRequestType.cc -> .o
>  [   

[gem5-dev] Change in gem5/gem5[develop]: misc: Update maintainers file

2020-11-03 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/36886 )



Change subject: misc: Update maintainers file
..

misc: Update maintainers file

Change-Id: I19810801f0acd5a35dde59a70166339e00b97eca
Signed-off-by: Jason Lowe-Power 
---
M MAINTAINERS
1 file changed, 51 insertions(+), 22 deletions(-)



diff --git a/MAINTAINERS b/MAINTAINERS
index 913daaf..61488fc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6,15 +6,18 @@
 when you upload the patch to Gerrit (https://gem5-review.googlesource.com).
 These keywords mostly follow the directory structure.

-Individuals on the project management committee are maintainers for all of  
the

-gem5 components (i.e., they can review any patch as the maintainer). These
-individuals are required to review any patches to components without  
explicit

-maintainers.
+Maintainers have the following responsibilities:
+1. That at least one maintainer of each subsystem reviews all changes to  
that

+   subsystem (they will be automatically tagged and emailed on each new
+   change).
+2. They will complete your reviews in a timely manner (within a few  
business

+   days).
+3. They pledge to uphold gem5's community standards and its code of  
conduct by
+   being polite and professional in their code reviews. See  
CODE-OF-CONDUCT.md.


 PMC Members (general maintainers):
-  Ali Saidi 
   Andreas Sandberg 
-  Brad Beckmann 
+  Brad Beckmann 
   David Wood 
   Gabe Black 
   Giacomo Travaglini 
@@ -31,63 +34,86 @@
 arch-gcn3:
   Tony Gutierrez 
 arch-mips:
+  UNSUPPORTED
 arch-power:
+  Boris Shingarov 
 arch-riscv:
-  Alec Roelke 
+  UNSUPPORTED
 arch-sparc:
   Gabe Black 
 arch-x86:
   Gabe Black 

 base:
+  Bobby Bruce 

 configs:
   Jason Lowe-Power 

-cpu: General changes to all CPU models (e.g., BaseCPU)
+cpu: General changes to all CPU models (e.g., BzaseCPU)
+  Gabe Black 
+  Jason Lowe-Power 
 cpu-kvm:
   Andreas Sandberg 
 cpu-minor:
+  Zhengrong Wang 
 cpu-o3:
+  UNSUPPORTED
 cpu-simple:
+  Jason Lowe-Power 
+  Gabe Black 

 dev:
+  Gabe Black 
 dev-hsa:
-  Tony Gutierrez 
+  UNSUPPORTED
 dev-virtio:
   Andreas Sandberg 
-
 dev-arm:
   Andreas Sandberg 
   Giacomo Travaglini 

+doc:
+  Bobby Bruce 
+
 ext: Components external to gem5
+  Bobby Bruce 
+  Jason Lowe-Power 
+ext-testlib:
+  Bobby Bruce 
+  Hoa Nguyen 

 fastmodel: Changes relating to ARM Fast Models
   Gabe Black 

 gpu-compute:
-  Tony Gutierrez 
   Matt Poremba 

-learning-gem5: The code and configs for the Learning gem5 book (see
-   learning.gem5.com)
+learning-gem5: The code and configs for the Learning gem5 book
   Jason Lowe-Power 

 mem: General memory system (e.g., XBar, Packet)
   Nikos Nikoleris 
 mem-cache: Classic caches and coherence
   Nikos Nikoleris 
+mem-dram:
+  Nikos Nikoleris 
 mem-garnet: Garnet subcomponent of Ruby
-  Tushar Krishna 
+  Srikant Bharadwaj 
 mem-ruby: Ruby structures and protocols
-  Brad Beckmann 
   Jason Lowe-Power 

 misc: Anything outside of the other categories
+  Bobby Bruce 
+  Jason Lowe-Power 

 python: Python SimObject wrapping and infrastructure
   Andreas Sandberg 
+  Jason Lowe-Power 
+
+resources: The gem5-resources repo with auxiliary resources for simulation
+  Bobby Bruce 
+  Jason Lowe-Power 

 scons: Build system
   Gabe Black 
@@ -95,13 +121,8 @@
 sim: General simulation components
   Jason Lowe-Power 
 sim-se: Syscall emulation
-  Brandon Potter 
-sim-power: Power modeling
-  Andreas Sandberg 
+  UNSUPPORTED

-stats: Updates to statistics for regressions
-
-system: System boot code and related components
 system-arm:
   Andreas Sandberg 
   Giacomo Travaglini 
@@ -109,8 +130,16 @@
 systemc: Code for the gem5 SystemC implementation and interface
   Gabe Black 

-tests: testing changes (not stats updates for tests. See stats:)
+tests: testing changes
   Bobby Bruce 

 util:
   Gabe Black 
+util-docker:
+  Bobby Bruce 
+util-m5:
+  Gabe Black 
+
+website: The gem5-website repo which contains the gem5.org site
+  Bobby Bruce 
+  Hoa Nguyen 

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/36886
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I19810801f0acd5a35dde59a70166339e00b97eca
Gerrit-Change-Number: 36886
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: SimObject params() method

2020-10-22 Thread Jason Lowe-Power via gem5-dev
Another simple proposal:
- Remove params() from the API (with deprecation)
- Update objects that can easily be updated and remove the params()
calls/casts. I think this is most cases of the params use outside of the
constructor.
- Don't worry about the others that use the params() function in many
places that require deeper updates
- Update the documentation to say that the "best practice" is to not use
the param function
- In the future, make sure that new objects don't store the params object.

Cheers,
Jason

On Thu, Oct 22, 2020 at 8:51 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Let me add to the plate a simple proposal though still a bit verbose and
> probably not that different from a manual cast
>
>
>
> Defining a template method in SimObject:
>
>
>
> *template *
>
> *Obj params()*
>
>
> *{ return static_cast(_params);*
>
> *Or more secure:*
>
> *param =  dynamic_cast(_params);*
>
> *assert(param);*
>
> *return param;*
>
> *}*
>
>
>
> And delegate the type specification on the client side:
>
>
>
> For example in my shiny new
>
>
>
> Class MyObject : public SimObject {}
>
>
>
> I would use
>
>
>
> auto p = params();
>
>
>
> You still have to type your param type so that doesn’t make it the best
> but I believe it’s the simplest one
>
>
>
> Giacomo
>
>
>
> *From:* Jason Lowe-Power via gem5-dev 
> *Sent:* 22 October 2020 16:26
> *To:* gem5 Developer List 
> *Cc:* Gabe Black ; Jason Lowe-Power <
> ja...@lowepower.com>
> *Subject:* [gem5-dev] Re: SimObject params() method
>
>
>
> Hey Gabe,
>
>
>
> Thanks for bringing this up. I have also been bothered by the lack of
> consistency with how params are used. I can't think of an example of when
> you need to store the params object. I would be all for getting rid of the
> params() function and updating the documentation to say that it's best
> practice to *not* save the params struct after the constructor. If some
> object had a good reason to go against this best practice, that would be
> OK, and we wouldn't need to enforce any specific design or pattern on these
> exceptions. I would prefer to remove the params() function than add more
> template magic.
>
>
>
> On Thu, Oct 22, 2020 at 1:18 AM Gabe Black via gem5-dev 
> wrote:
>
> Hi folks. I'm looking at the SimObject header, and I see a few things in
> there which are marked as part of the API and maybe shouldn't be.
> Specifically I'm talking about the Params typedef, and the params() method.
> There is also the _params member variable which I can see being a part of
> the API since it can be used by other classes to make their own params()
> function (more on that below), but the Params typedef is more or less an
> implementation detail, and the params() method is essentially worthless
> because it returns a SimObjectParams which doesn't have anything except the
> object's name in it, and you can already get that with the name() method.
>
>
>
> I agree. I think the typedef is useless and shouldn't be in the API. It's
> unfortunate that the API proposals didn't get more reviews. I think it's
> probably OK to just drop that from the API, but the params() function
> itself is going to need to be deprecated.
>
>
>
>
>
> *Params pattern*
>
>
>
> This gets to the whole Params params() pattern which is sporadically
> implemented in some SimObjects in gem5. This pattern is that a given
> SimObject subclass will define a Params typedef which corresponds to its
> Params struct type, and then also define a params() method which returns
> the _params from SimObject cast up to that type.
>
>
>
> The Params typedef itself primarily makes the definition of the
> constructor a little more legible, since the FullFooTypeForTheArmISAParams
> can be really verbose.
>
>
>
> I think verbose is fine. I would vote to abolish all params typedefs.
>
>
>
>
>
> Storing the params struct itself could theoretically serve the purpose of
> having a bunch of parameters and not having to create a member variable for
> each one, spend a bunch of text copying values over in the constructor,
> etc. I think most of the time this is unnecessary, but if an object has
> tons of values in it for some reason this could make sense.
>
>
>
> I don't think there are any examples of this in the codebase. I think in
> all cases the params data is copied into member variables. If there are
> cases where data isn't copied, I doubt it was with a strong reason in mind.
> The one exception to this might be Ruby, but it's an exception for all the
> wrong reasons ;).
>
&g

[gem5-dev] Re: SimObject params() method

2020-10-22 Thread Jason Lowe-Power via gem5-dev
Hey Gabe,

Thanks for bringing this up. I have also been bothered by the lack of
consistency with how params are used. I can't think of an example of when
you need to store the params object. I would be all for getting rid of the
params() function and updating the documentation to say that it's best
practice to *not* save the params struct after the constructor. If some
object had a good reason to go against this best practice, that would be
OK, and we wouldn't need to enforce any specific design or pattern on these
exceptions. I would prefer to remove the params() function than add more
template magic.

On Thu, Oct 22, 2020 at 1:18 AM Gabe Black via gem5-dev 
wrote:

> Hi folks. I'm looking at the SimObject header, and I see a few things in
> there which are marked as part of the API and maybe shouldn't be.
> Specifically I'm talking about the Params typedef, and the params() method.
> There is also the _params member variable which I can see being a part of
> the API since it can be used by other classes to make their own params()
> function (more on that below), but the Params typedef is more or less an
> implementation detail, and the params() method is essentially worthless
> because it returns a SimObjectParams which doesn't have anything except the
> object's name in it, and you can already get that with the name() method.
>

I agree. I think the typedef is useless and shouldn't be in the API. It's
unfortunate that the API proposals didn't get more reviews. I think it's
probably OK to just drop that from the API, but the params() function
itself is going to need to be deprecated.


>
> *Params pattern*
>
> This gets to the whole Params params() pattern which is sporadically
> implemented in some SimObjects in gem5. This pattern is that a given
> SimObject subclass will define a Params typedef which corresponds to its
> Params struct type, and then also define a params() method which returns
> the _params from SimObject cast up to that type.
>
> The Params typedef itself primarily makes the definition of the
> constructor a little more legible, since the FullFooTypeForTheArmISAParams
> can be really verbose.
>

I think verbose is fine. I would vote to abolish all params typedefs.


>
> Storing the params struct itself could theoretically serve the purpose of
> having a bunch of parameters and not having to create a member variable for
> each one, spend a bunch of text copying values over in the constructor,
> etc. I think most of the time this is unnecessary, but if an object has
> tons of values in it for some reason this could make sense.
>

I don't think there are any examples of this in the codebase. I think in
all cases the params data is copied into member variables. If there are
cases where data isn't copied, I doubt it was with a strong reason in mind.
The one exception to this might be Ruby, but it's an exception for all the
wrong reasons ;).


>
> The params() method then makes the _params member available with the
> appropriate type, so that all the FooParams members are accessible. It also
> makes the params struct accessible outside the object which is used in a
> place or two to read parameters without there needing to be a member in the
> object, and probably some sort of accessor to read it.
>
> There are two main problems with this system. First, when used, it adds a
> small but not trivial amount of boilerplate to any given class. Second,
> it's very sporadically implemented. I think in a lot of places it's there
> just because people aren't sure what it's for or if they need it, so they
> just put one there regardless. I think I've done that in the past.
>
> *Alternative*
>
> The existence of the Params type and the params() method could be
> partially eliminated by defining a templated params() method which took a
> SimObject reference and/or pointer as its first parameter. It could then
> figure out what Params struct went with that SimObject type using
> typedef/template magic set up by the Params building code, and then perform
> the appropriate cast.
>
> This has three downsides, two minor and one more serious. The minor one is
> that when a class uses this method internally, it would have to do
> something like params(this) instead of just params(). That's a fairly minor
> difference and not that big a deal. For external consumers that would be
> less of a problem since it would change from foo->params() to params(foo).
>
> The second minor issue is that the name params() is very short, and likely
> to collide with other names. We could define that with SimObject as a
> static method, but then that would make foo->params() turn into the more
> verbose SimObject::params(foo), or (and I haven't checked if this is legal
> syntax) the more odd looking foo->params(foo). The params() class can't be
> a non-static method, because then the type of "this" would be fixed by
> where it was defined, meaning it would not cast _params to the right type.
> I was not able to find any 

[gem5-dev] Change in gem5/gem5[develop]: cpu-kvm, arch-x86: Fix KVM on Intel platforms

2020-10-20 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/12278 )


Change subject: cpu-kvm, arch-x86: Fix KVM on Intel platforms
..

cpu-kvm, arch-x86: Fix KVM on Intel platforms

This is the minimal set of changes from the patch that's been floating
around for a few years originally by Mike Upton.

See http://reviews.gem5.org/r/2613/ and
https://gem5-review.googlesource.com/c/public/gem5/+/7361

The change to the tssDesc is the minimal change to get KVM working on
Intel platforms. However, the other changes seem prudent to add.

Tested on both Intel (i7-7700) and AMD (EPYC 7451) platforms.

Change-Id: I000c7ba102ba161c2bb5e224bf826216cf0ff87a
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/12278
Maintainer: Bobby R. Bruce 
Reviewed-by: Bobby R. Bruce 
Reviewed-by: Jason Lowe-Power 
Reviewed-by: Gabe Black 
Tested-by: kokoro 
---
M src/arch/x86/fs_workload.cc
1 file changed, 12 insertions(+), 0 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved
  Gabe Black: Looks good to me, approved
  Bobby R. Bruce: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/arch/x86/fs_workload.cc b/src/arch/x86/fs_workload.cc
index b66ddfd..a69e50b 100644
--- a/src/arch/x86/fs_workload.cc
+++ b/src/arch/x86/fs_workload.cc
@@ -189,6 +189,12 @@

 // 32 bit data segment
 SegDescriptor dsDesc = initDesc;
+dsDesc.type.e = 0;
+dsDesc.type.w = 1;
+dsDesc.d = 1;
+dsDesc.baseHigh = 0;
+dsDesc.baseLow = 0;
+
 uint64_t dsDescVal = dsDesc;
 phys_proxy.writeBlob(GDTBase + numGDTEntries * 8, (), 8);

@@ -204,10 +210,16 @@
 tc->setMiscReg(MISCREG_SS, (RegVal)ds);

 tc->setMiscReg(MISCREG_TSL, 0);
+SegAttr ldtAttr = 0;
+ldtAttr.unusable = 1;
+tc->setMiscReg(MISCREG_TSL_ATTR, ldtAttr);
 tc->setMiscReg(MISCREG_TSG_BASE, GDTBase);
 tc->setMiscReg(MISCREG_TSG_LIMIT, 8 * numGDTEntries - 1);

 SegDescriptor tssDesc = initDesc;
+tssDesc.type = 0xB;
+tssDesc.s = 0;
+
 uint64_t tssDescVal = tssDesc;
 phys_proxy.writeBlob(GDTBase + numGDTEntries * 8, (), 8);


--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/12278
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I000c7ba102ba161c2bb5e224bf826216cf0ff87a
Gerrit-Change-Number: 12278
Gerrit-PatchSet: 5
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Alexandru Duțu 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: kokoro 
Gerrit-Reviewer: mike upton 
Gerrit-CC: Swapnil Haria 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Proposal for new committing policies

2020-10-19 Thread Jason Lowe-Power via gem5-dev
Hi again gem5 community!

Sorry for sending the previous email at the beginning of the weekend!
However, now that it's Monday, I want to this back up for discussion.

To give a bit more context, this proposal is meant to codify our current
culture for code review. Almost everything proposed here is what most
people try to do when submitting changes and reviews. However, it's never
been "officially" written down anywhere. In keeping with this informal
culture, *nothing* in this change will be enforced automatically. *The
common case will be exactly the same as before* with reviewers enforcing
our project culture.

Our project is maturing. This means we need to do a better job of
documentation, improve transparency, and, in some cases, slow down our
changes to provide more stability for our users. This cannot be the job of
one individual, one group, or one institution. If we want to see this
project continue to grow, mature, and continue to be useful, the entire
community needs to contribute to these goals.

As always, I want to emphasize that gem5 is a meritocratic, consensus-based
community project which values openness, transparency, and inclusiveness
and strives to support its academic, research, and industrial users.

Please review the changeset here:
https://gem5-review.googlesource.com/c/public/gem5/+/36256
And, if you have time, there is another changeset trying to automatically
assign reviewers which will also improve our reviewing capacity (we hope).
See here: https://gem5-review.googlesource.com/c/public/gem5/+/34737

Cheers,
Jason

On Fri, Oct 16, 2020 at 3:50 PM Jason Lowe-Power 
wrote:

> Hi all,
>
> I have just submitted a changeset to gerrit which updates the CONTRIBUTING
> documentation with a proposal for updating the committing policies.
>
> Issue: https://gem5.atlassian.net/browse/GEM5-799
> Changeset: https://gem5-review.googlesource.com/c/public/gem5/+/36256
>
> The gem5 project is maturing! We're getting more contributors and a higher
> rate of contributions. Additionally, we are striving to provide stability
> to our growing user base.
>
> In light of these changes, I am proposing updating our committing
> guidelines for the review process for changes on gem5's "primary"
> infrastructure. Details can be found on gerrit and are included below.
>
> This is currently just a proposal. I am looking for feedback from the
> community.
>
> I believe the goals are:
> - Provide transparency for changes that affect many users and ensure
> community buy-in before making API changes
> - Provide stability for users
> - Provide documentation for API changes and new features
> - Not increase the reviewing load significantly (in conjunction with the
> new maintainer proposal from earlier today)
>
> The main changes are the following:
>
> For "primary" gem5 features at least two different people should review
> the change before it is committed, except for trivial changes. There is no
> automatic enforcement of this rule, but we expect the community to respect
> this guideline. This guideline is meant to increase transparency in the
> development process and prevent painful changes from affecting gem5's
> users.
>
> "Primary" gem5 features are features used by a large number of users or
> which affect many users indirectly. This will include most of the code in
> base/, sim/, etc. This does not include legacy-supported ISAs (i.e., SPARC,
> MIPS, POWER) or other subsystems that are not widely used (e.g., SystemC,
> Arm Fastmodel, GPU VIPER coherence protocol, etc.). All APIs are "primary"
> features.
>
> Before changing a gem5 API is it imperative to receive buy-in from the
> gem5 community. The best way to do this is through communication with the
> community before making the API change or after making a proposal for the
> change. We ask that before any changes to the API are pushed to gerrit (or
> at a minimum at the same time) the committer also does the following:
> 1. Create an issue on the issue tracker.
> 2. Send an email to gem5-dev mailing list
>
> We ask that these extra steps are taken for API changes to improve the
> transparency and publicity of API changes. Not all users will track all
> Jira issues or all commits pushed to Jira. Additionally, it is important to
> provide the gem5 users with some stability to build on top of gem5. All
> APIs are considered "primary" gem5 features and require at least two
> reviewers.
>
> Additionally, APIs must be deprecated for at least two releases before the
> old API is removed. The gem5 community is going through a transition to
> increase its stability, and during this time, there may be some APIs that
> have not been marked as such, but still require higher scrutiny before
> committing.
>
> 

[gem5-dev] Change in gem5/gem5[develop]: misc: Minor updates to CONTRIBUTING.md

2020-10-19 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/36255 )


Change subject: misc: Minor updates to CONTRIBUTING.md
..

misc: Minor updates to CONTRIBUTING.md

This brings the file slightly more up to date

Change-Id: I1ed3300ec3c4980ed22c6a6fb950fa724897906b
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36255
Reviewed-by: Daniel Carvalho 
Reviewed-by: Matt Sinclair 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M CONTRIBUTING.md
1 file changed, 22 insertions(+), 5 deletions(-)

Approvals:
  Matt Sinclair: Looks good to me, approved
  Daniel Carvalho: Looks good to me, approved
  Jason Lowe-Power: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 590c773..10a026e 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -97,7 +97,7 @@

 Changes should be made to this develop branch. Changes to the stable branch
 will be blocked. Once a change on the develop branch is properly  
incorporated

-into the gem5 repo it will be merged into the stable Branch upon the next
+into the gem5 repo it will be merged into the stable branch upon the next
 release of gem5. New releases of gem5 occur three times a year. Ergo,  
changes
 made to the develop branch should appear on the stable branch within three  
to

 four months as part of a stable release.
@@ -109,7 +109,11 @@

  * public/m5threads: The code for a pthreads implementation that works with
gem5's syscall emulation mode.
-
+ * public/gem5-resources: Resources to enable computer architecture  
research
+   with gem5. See the README.md file in the gem5-resources repository for  
more

+   information.
+ * public/gem5-website: The gem5.org website source. See the README.md  
file in

+   the gem5-website repository for more information.

 Making changes to gem5
 ==
@@ -123,6 +127,15 @@
 git, you will be able to pull in and merge changes from mainline and simply
 keep up with upstream changes.

+We use a rebase-always model for contributions to the develop branch of  
gem5.
+In this model, the changes are rebased on top of the tip of develop  
instead of
+merged. This means that to contribute, you will have to frequently rebase  
any
+feature branches on top of develop. If you see a "merge conflict" in  
gerrit, it
+can often be solved with a simple rebase. To find out more information  
about

+rebasing and git, see the [git book].
+
+[git book]: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
+
 Requirements for change descriptions
 
 To help reviewers and future contributors more easily understand and track
@@ -165,10 +178,14 @@
automatically with a commit hook by git.
  * Tested-by: Used to acknowledge people who tested a patch. Sometimes  
added

automatically by review systems that integrate with CI systems.
+ * Issue-On: Used to link a commit to an issue in gem5's [issue tracker].  
The

+   format should be https://gem5.atlassian.net/browse/GEM5-

-Other than the "Signed-off-by", "Reported-by", and "Tested-by" tags, you
-generally don't need to add these manually as they are added automatically  
by

-Gerrit.
+[issue tracker]: https://gem5.atlassian.net/
+
+Other than the "Signed-off-by", "Issue-On", "Reported-by", and "Tested-by"
+tags, you generally don't need to add these manually as they are added
+automatically by Gerrit.

 It is encouraged for the author of the patch and the submitter to add a
 Signed-off-by tag to the commit message. By adding this line, the  
contributor


--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/36255
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I1ed3300ec3c4980ed22c6a6fb950fa724897906b
Gerrit-Change-Number: 36255
Gerrit-PatchSet: 2
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Matt Sinclair 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Proposal for new committing policies

2020-10-16 Thread Jason Lowe-Power via gem5-dev
Hi all,

I have just submitted a changeset to gerrit which updates the CONTRIBUTING
documentation with a proposal for updating the committing policies.

Issue: https://gem5.atlassian.net/browse/GEM5-799
Changeset: https://gem5-review.googlesource.com/c/public/gem5/+/36256

The gem5 project is maturing! We're getting more contributors and a higher
rate of contributions. Additionally, we are striving to provide stability
to our growing user base.

In light of these changes, I am proposing updating our committing
guidelines for the review process for changes on gem5's "primary"
infrastructure. Details can be found on gerrit and are included below.

This is currently just a proposal. I am looking for feedback from the
community.

I believe the goals are:
- Provide transparency for changes that affect many users and ensure
community buy-in before making API changes
- Provide stability for users
- Provide documentation for API changes and new features
- Not increase the reviewing load significantly (in conjunction with the
new maintainer proposal from earlier today)

The main changes are the following:

For "primary" gem5 features at least two different people should review the
change before it is committed, except for trivial changes. There is no
automatic enforcement of this rule, but we expect the community to respect
this guideline. This guideline is meant to increase transparency in the
development process and prevent painful changes from affecting gem5's
users.

"Primary" gem5 features are features used by a large number of users or
which affect many users indirectly. This will include most of the code in
base/, sim/, etc. This does not include legacy-supported ISAs (i.e., SPARC,
MIPS, POWER) or other subsystems that are not widely used (e.g., SystemC,
Arm Fastmodel, GPU VIPER coherence protocol, etc.). All APIs are "primary"
features.

Before changing a gem5 API is it imperative to receive buy-in from the gem5
community. The best way to do this is through communication with the
community before making the API change or after making a proposal for the
change. We ask that before any changes to the API are pushed to gerrit (or
at a minimum at the same time) the committer also does the following:
1. Create an issue on the issue tracker.
2. Send an email to gem5-dev mailing list

We ask that these extra steps are taken for API changes to improve the
transparency and publicity of API changes. Not all users will track all
Jira issues or all commits pushed to Jira. Additionally, it is important to
provide the gem5 users with some stability to build on top of gem5. All
APIs are considered "primary" gem5 features and require at least two
reviewers.

Additionally, APIs must be deprecated for at least two releases before the
old API is removed. The gem5 community is going through a transition to
increase its stability, and during this time, there may be some APIs that
have not been marked as such, but still require higher scrutiny before
committing.

Finally, all API changes or additions require documentation. This
documentation requirement will be enforced during code review.

Let me know what you think! Providing feedback on gerrit is preferred, but
high-level feedback via email is also great.

Cheers,
Jason
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: misc: Add new policies to CONTRIBUTING.md

2020-10-16 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/36256 )



Change subject: misc: Add new policies to CONTRIBUTING.md
..

misc: Add new policies to CONTRIBUTING.md

Change-Id: I7b55862f4d1f0271fb2a62f83a0fdb57c03370ee
Signed-off-by: Jason Lowe-Power 
Issue-on: https://gem5.atlassian.net/browse/GEM5-799
---
M CONTRIBUTING.md
1 file changed, 50 insertions(+), 0 deletions(-)



diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 10a026e..d7cb223 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -430,6 +430,56 @@
 to merge the patch by pressing the "Submit" button on Gerrit. When the  
patch is

 submitted, it is merged into the public gem5 branch.

+For "primary" gem5 features at least two different people should review the
+change before it is committed, except for trivial changes. There is no
+automatic enforcement of this rule, but we expect the community to respect  
this
+guideline. This guideline is meant to increase transparency in the  
development

+process and prevent painful changes from affecting gem5's users.
+
+"Primary" gem5 features are features used by a large number of users or  
which

+affect many users indirectly. This will include most of the code in base/,
+sim/, etc. This does not include legacy-supported ISAs (i.e., SPARC, MIPS,
+POWER) or other subsystems that are not widely used (e.g., SystemC, Arm
+Fastmodel, GPU VIPER coherence protocol, etc.). All APIs are "primary"
+features.
+
+Updating APIs
+=
+
+gem5's APIs are currently documented via [doxygen]. More information about
+gem5's APIs can be found on the [gem5 website][APIs]. Currently, it is the
+responsibility of the gem5 reviewers to make sure the [API change  
rules][APIs]

+are followed.
+
+[doxygen]: http://doxygen.gem5.org/release/current/modules.html
+[APIs]: http://www.gem5.org/documentation/general_docs/gem5-apis/
+
+Before changing a gem5 API is it imperative to receive buy-in from the gem5
+community. The best way to do this is through communication with the  
community
+before making the API change or after making a proposal for the change. We  
ask
+that before any changes to the API are pushed to gerrit (or at a minimum  
at the

+same time) the committer also does the following:
+
+1. Create an issue on the [issue tracker].
+2. Send an email to gem5-dev mailing list
+
+[issue tracker]: https://gem5.atlassian.net/
+
+We ask that these extra steps are taken for API changes to improve the
+transparency and publicity of API changes. Not all users will track all  
Jira
+issues or all commits pushed to Jira. Additionally, it is important to  
provide

+the gem5 users with some stability to build on top of gem5.
+
+All APIs are considered "primary" gem5 features and require at least two
+reviewers. Additionally, APIs must be deprecated for at least two releases
+before the old API is removed. The gem5 community is going through a  
transition

+to increase its stability, and during this time, there maybe some APIs that
+have not been marked as such, but still require higher scrutiny before
+committing.
+
+Finally, all API changes or additions require documentation. This  
documentation

+requirement will be enforced during code review.
+
 Review moderation and guidelines
 


--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/36256
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I7b55862f4d1f0271fb2a62f83a0fdb57c03370ee
Gerrit-Change-Number: 36256
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: misc: Minor updates to CONTRIBUTING.md

2020-10-16 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/36255 )



Change subject: misc: Minor updates to CONTRIBUTING.md
..

misc: Minor updates to CONTRIBUTING.md

This brings the file slightly more up to date

Change-Id: I1ed3300ec3c4980ed22c6a6fb950fa724897906b
Signed-off-by: Jason Lowe-Power 
---
M CONTRIBUTING.md
1 file changed, 22 insertions(+), 5 deletions(-)



diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 590c773..10a026e 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -97,7 +97,7 @@

 Changes should be made to this develop branch. Changes to the stable branch
 will be blocked. Once a change on the develop branch is properly  
incorporated

-into the gem5 repo it will be merged into the stable Branch upon the next
+into the gem5 repo it will be merged into the stable branch upon the next
 release of gem5. New releases of gem5 occur three times a year. Ergo,  
changes
 made to the develop branch should appear on the stable branch within three  
to

 four months as part of a stable release.
@@ -109,7 +109,11 @@

  * public/m5threads: The code for a pthreads implementation that works with
gem5's syscall emulation mode.
-
+ * public/gem5-resources: Resources to enable computer architecture  
research
+   with gem5. See the README.md file in the gem5-resources repository for  
more

+   information.
+ * public/gem5-website: The gem5.org website source. See the README.md  
file in

+   the gem5-website repository for more information.

 Making changes to gem5
 ==
@@ -123,6 +127,15 @@
 git, you will be able to pull in and merge changes from mainline and simply
 keep up with upstream changes.

+We use a rebase-always model for contributions to the develop branch of  
gem5.
+In this model, the changes are rebased on top of the tip of develop  
instead of
+merged. This means that to contribute, you will have to frequently rebase  
any
+feature branches on top of develop. If you see a "merge conflict" in  
gerrit, it
+can often be solved with a simple rebase. To find out more information  
about

+rebasing and git, see the [git book].
+
+[git book]: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
+
 Requirements for change descriptions
 
 To help reviewers and future contributors more easily understand and track
@@ -165,10 +178,14 @@
automatically with a commit hook by git.
  * Tested-by: Used to acknowledge people who tested a patch. Sometimes  
added

automatically by review systems that integrate with CI systems.
+ * Issue-On: Used to link a commit to an issue in gem5's [issue tracker].  
The

+   format should be https://gem5.atlassian.net/browse/GEM5-

-Other than the "Signed-off-by", "Reported-by", and "Tested-by" tags, you
-generally don't need to add these manually as they are added automatically  
by

-Gerrit.
+[issue tracker]: https://gem5.atlassian.net/
+
+Other than the "Signed-off-by", "Issue-On", "Reported-by", and "Tested-by"
+tags, you generally don't need to add these manually as they are added
+automatically by Gerrit.

 It is encouraged for the author of the patch and the submitter to add a
 Signed-off-by tag to the commit message. By adding this line, the  
contributor


--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/36255
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I1ed3300ec3c4980ed22c6a6fb950fa724897906b
Gerrit-Change-Number: 36255
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] A call for maintainers

2020-10-16 Thread Jason Lowe-Power via gem5-dev
Hi everyone!

As you all are aware, we're pushing to increase the stability of gem5.
However, at the same time, we're seeing a significant increase in the rate
of gem5 changes. Between gem5-20.0 and gem5-20.1 we had over 650 commits!
And, that doesn't count the many changes on gerrit that never got reviewed
:(.

We need help reviewing! One of the steps we're taking to help with this is
to assign specific maintainers to review every patch (automatically).

There is a change on gerrit to do this:
https://gem5-review.googlesource.com/c/public/gem5/+/34737 Please let us
know if there are any comments.

In that commit is a new file which specifies the maintainers in a
machine-readable format. Now, for the ask: We're looking for volunteers for
all of the components that are missing maintainers! Being a maintainer
comes with the responsibility of reviewing patches in a timely fashion, but
it also means that you can influence the changes in gem5!

See
https://gem5-review.googlesource.com/c/public/gem5/+/34737/17/util/gerrit_bot/MAINTAINERS.json

Specifically, if you would like to become the maintainer for any of the
following sub-components, simply reply to this email! Additionally, if you
have suggestions for other ways to break down these components, feel free
to comment on the changeset linked above.

- arch-mips
- arch-power
- base
- cpu
- cpu-minor
- cpu-o3
- cpu-simple
- dev
- ext
- misc
- stats
- system

Have a great weekend!

Cheers,
Jason
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: sim,python: Flip logic on loopback listeners

2020-10-16 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/36175 )


Change subject: sim,python: Flip logic on loopback listeners
..

sim,python: Flip logic on loopback listeners

People are bitten by allowing external connections to gem5 runs too often
(it happend to me again today). This change flips the logic so the
default is to only allow localhost connections.

Change-Id: If9233f5ca383721017b30b5837a26c5042d925fd
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36175
Reviewed-by: Hoa Nguyen 
Reviewed-by: Ayaz Akram 
Reviewed-by: Andreas Sandberg 
Maintainer: Gabe Black 
Tested-by: kokoro 
---
M src/python/m5/main.py
1 file changed, 4 insertions(+), 4 deletions(-)

Approvals:
  Andreas Sandberg: Looks good to me, approved
  Ayaz Akram: Looks good to me, but someone else must approve
  Hoa Nguyen: Looks good to me, approved
  Gabe Black: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/python/m5/main.py b/src/python/m5/main.py
index 6fe9218..3408889 100644
--- a/src/python/m5/main.py
+++ b/src/python/m5/main.py
@@ -97,9 +97,9 @@
 choices=listener_modes, default="auto",
 help="Port (e.g., gdb) listener mode (auto: Enable if running " \
 "interactively) [Default: %default]")
-option("--listener-loopback-only", action="store_true", default=False,
-help="Port listeners will only accept connections over the " \
-"loopback device")
+option("--allow-remote-connections", action="store_true",  
default=False,
+help="Port listeners will accept connections from anywhere  
(0.0.0.0). "

+"Default is only localhost.")
 option('-i', "--interactive", action="store_true", default=False,
 help="Invoke the interactive interpreter after running the script")
 option("--pdb", action="store_true", default=False,
@@ -379,7 +379,7 @@
 else:
 panic("Unhandled listener mode: %s" % options.listener_mode)

-if options.listener_loopback_only:
+if not options.allow_remote_connections:
 m5.listenersLoopbackOnly()

 # set debugging options

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/36175
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: If9233f5ca383721017b30b5837a26c5042d925fd
Gerrit-Change-Number: 36175
Gerrit-PatchSet: 2
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Ayaz Akram 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Hoa Nguyen 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Maryam Babaie 
Gerrit-Reviewer: kokoro 
Gerrit-CC: Earl Ou 
Gerrit-CC: Weiping Liao 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: sim,python: Flip logic on loopback listeners

2020-10-15 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/36175 )



Change subject: sim,python: Flip logic on loopback listeners
..

sim,python: Flip logic on loopback listeners

People are bitten by allowing external connections to gem5 runs too often
(it happend to me again today). This change flips the logic so the
default is to only allow localhost connections.

Change-Id: If9233f5ca383721017b30b5837a26c5042d925fd
Signed-off-by: Jason Lowe-Power 
---
M src/python/m5/main.py
1 file changed, 4 insertions(+), 4 deletions(-)



diff --git a/src/python/m5/main.py b/src/python/m5/main.py
index 6fe9218..3408889 100644
--- a/src/python/m5/main.py
+++ b/src/python/m5/main.py
@@ -97,9 +97,9 @@
 choices=listener_modes, default="auto",
 help="Port (e.g., gdb) listener mode (auto: Enable if running " \
 "interactively) [Default: %default]")
-option("--listener-loopback-only", action="store_true", default=False,
-help="Port listeners will only accept connections over the " \
-"loopback device")
+option("--allow-remote-connections", action="store_true",  
default=False,
+help="Port listeners will accept connections from anywhere  
(0.0.0.0). "

+"Default is only localhost.")
 option('-i', "--interactive", action="store_true", default=False,
 help="Invoke the interactive interpreter after running the script")
 option("--pdb", action="store_true", default=False,
@@ -379,7 +379,7 @@
 else:
 panic("Unhandled listener mode: %s" % options.listener_mode)

-if options.listener_loopback_only:
+if not options.allow_remote_connections:
 m5.listenersLoopbackOnly()

 # set debugging options

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/36175
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: If9233f5ca383721017b30b5837a26c5042d925fd
Gerrit-Change-Number: 36175
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Determining the APIC id for a CPU

2020-10-15 Thread Jason Lowe-Power via gem5-dev
Hi all (and specifically our AMD colleagues),

Does anyone know how real hardware assigns APIC IDs in x86? We need to do
something more than just use the CPU number if we want to support multiple
hardware threads.

We have a proposal here:
https://gem5-review.googlesource.com/c/public/gem5/+/35837. However, Gabe
correctly points out that "we should do what real hardware does", but the
problem is we don't know what it does.

Feedback from others would be appreciated!

Note that this is a long standing jira issue (
https://gem5.atlassian.net/browse/GEM5-332) and many of our users have been
asking for us to enable multi-thread support for x86 (there was another
question on this today!). It would be really nice to get this done for the
next gem5 release.

If no one knows what real hardware does, is there anyone against just using
the hw thread number in the lower bits?

Thanks,
Jason
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Implementing PSHUFB instruction

2020-10-13 Thread Jason Lowe-Power via gem5-dev
Thanks, Gabe! I think the slow option is probably the right way to go for
now. It will match other things like our slow integer division
implementation ;). There's a lot in our x86 implementation that needs to be
improved if we want to match the actual latencies of instructions in modern
systems (https://www.agner.org/optimize/instruction_tables.pdf).

BTW, for PSHUFB, it's just one uop and one cycle latency according to those
tables (for modern AMD and Intel parts at least).

Cheers,
Jason

On Tue, Oct 13, 2020 at 5:45 PM Gabe Black  wrote:

> Yeah, it's a bit tricky. One of the tricky parts is that a single
> instruction, no matter how artificially complex you want to make it, can
> only do one load or one store to memory. There are some ways around that
> like subverting the CPU by using the threadcontext and doing, for instance,
> functional accesses, but that's probably prone to breakage and is *very*
> unrealistic.
>
> Another option could be to just write a really inefficient implementation
> in microcode which does all the register twiddling manually. That would be
> very slow and clunky compared to the real deal, but it would fit pretty
> easily into the existing system and would be a workable stop gap to just
> get by some problematic instructions you need for functional purposes. I
> would strongly suggest putting a warn_once microop in there to let people
> know not to expect realistic performance if you go that route.
>
> On Tue, Oct 13, 2020 at 8:27 AM Jason Lowe-Power 
> wrote:
>
>> Hi Gabe,
>>
>> Thanks for the info! This is a bit helpful. Although, I'm still not sure
>> what the next steps would be or how to even start on (1) or (2) that you
>> listed.
>>
>> Is it possible to focus on functional correctness first and then work on
>> the timing correctness? The problem is that modern applications assume
>> these SSE instructions exist. Specifically, we can't get Ubuntu to boot
>> with systemd enabled without SSE instructions (specifically PSHUFB).
>>
>> From your description here, it sounds like this could be weeks+ of
>> development effort for us. Do we think this is worth it? There are like 4
>> cases of this instruction executing in the workloads we've looked at so
>> far. Getting the timing *perfect* doesn't seem important.
>>
>> As you say, we need to overhaul the x86 SIMD instructions completely.
>> However, this is a months long project for someone very familiar with gem5.
>> It's infeasible to do that right now with our current resources.
>> Additionally, since I am not an expert on this code, we would really need
>> someone like you, Gabe, to mentor whoever is working on this project.
>>
>> Cheers,
>> Jason
>>
>> On Mon, Oct 12, 2020 at 10:34 PM Gabe Black via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Hi Hao. The shuffle microop is implemented in
>>> arch/x86/isa/microops/mediaop.isa. It looks like you'll need to do three
>>> things to implement PSHUFB.
>>>
>>> 1. Figure out a realistic way to get all three register operands into
>>> the instruction. The current version takes a destination register, and both
>>> halves of one of the source registers, and then finally takes the 8 bit
>>> immediate value in the ext field of the microop. With larger registers
>>> which won't fit into two 64 bit slices, that scheme won't work for the
>>> source operands. You'll need to figure out how to get all the information
>>> you need into a single instruction, or in other words all the data you'll
>>> need to generate one 64 bit chunk of the destination. It looks like instead
>>> of always passing the shuffle instructions in an 8 bit immediate, the
>>> PSHUFB takes yet another register to hold that value. You'll need to figure
>>> out how to get that in there too.
>>> 2. The shuffle microop seems to expect assume there are two flavors of
>>> behavior, size = 8, and otherwise. You may need to add more logic to handle
>>> additional situations this new instruction needs.
>>> 3. Actually implement the PSHUFB macroop using the revised version of
>>> shuffle.
>>>
>>> The two important requirements for this sort of modification are that
>>> the microops still behave realistically and are constrained. If they could
>>> just do whatever whacky, one off thing a particular instruction needed,
>>> then there wouldn't be much value in microops, we could (sort of) just do
>>> everything with regular instructions directly. That's not entirely true,
>>> but the idea is true. Also we need to make sure not to break any current
>>> 

[gem5-dev] Re: Build failed in Jenkins: Nightly #91

2020-10-13 Thread Jason Lowe-Power via gem5-dev
Hi all,

Yeah, this is 100% a scons problem. I'm not sure what we can do about it.
To be more straightforward here are the possible solutions:

1. install python-is-python3
2. pip install scons
3. Edit /usr/bin/scons to use python3
4. Add `alias scons3="/usr/bin/env python3 $(which scons)"` to ~/.bashrc
5. probably others

For us, I think we should put a check at the very beginning of the scons
execution to check to make sure it's running under python3. If it's not, we
should print the above workarounds.

BTW, I don't think "alias scons=python `which scons`" will work in general.
I think it should be "alias scons=python3 `which scons`" since python may
be a symlink to python2.

Let me know if you have a better idea.

Cheers,
Jason

On Tue, Oct 13, 2020 at 8:41 AM Giacomo Travaglini via gem5-dev <
gem5-dev@gem5.org> wrote:

> Forgot to mention: I am choosing the latter
>
>
>
> Giacomo
>
>
>
> *From:* Giacomo Travaglini
> *Sent:* 13 October 2020 16:40
> *To:* gem5 Developer List ; Poremba, Matthew <
> matthew.pore...@amd.com>
> *Cc:* Jieming Yin 
> *Subject:* RE: [gem5-dev] Re: Build failed in Jenkins: Nightly #91
>
>
>
> Hi all,
>
>
>
> I had the same issue. The problem in my case was in scons, which was
> selecting python2 when building gem5 disregarding my python3 virtualenv
>
>
>
> $less `which scons`
>
> #! /usr/bin/python
>
>
>
> And /usr/bin/python was linked to python2.7.
>
>
>
> So the available solutions are:
>
>
>
>- Installing a newer scons version with
>
>
>
> #!/usr/bin/env python
>
>
>
>- changing the symbolic link,
>- modify the shebang of the preinstalled one,
>- CL selection of the scons interpreter:
>
> alias scons=python `which scons`
>
>
>
> Kind Regards
>
>
>
> Giacomo
>
>
>
> *From:* Jieming Yin via gem5-dev 
> *Sent:* 09 October 2020 02:43
> *To:* Poremba, Matthew 
> *Cc:* gem5 Developer List ; Jieming Yin <
> bjm...@gmail.com>
> *Subject:* [gem5-dev] Re: Build failed in Jenkins: Nightly #91
>
>
>
> Hi Matt,
>
>
>
> My workaround is to do it in a python2 manner:
>
>
>
> class SEWorkload(Workload):
> type = 'SEWorkload'
> __metaclass__ = SEWorkloadMeta
>
>
>
> I have the same syntax error because I am running the gem5-gcn docker, and
> I have both python2 and python3 installed. But I don't really know how to
> fix it, it seems python2 is used sometimes.
>
>
>
> Jieming
>
>
>
> On Thu, Oct 8, 2020 at 7:43 PM Bobby Bruce via gem5-dev 
> wrote:
>
> Hey Matt,
>
>
>
> Before the nightly tests were run on Jenkins server which was an Ubuntu
> 18.04 machine with Python2.
>
>
>
> The nightly tests will now run using our Ubuntu 20.04 docker image:
> gcr.io/gem5-test/ubuntu-20.04_all-dependencies (Dockerfile source:
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile).
>
>
>
>
> So, to compile gem5.opt for the ARM ISA, the nightly will use:
>
>
>
> ```
>
> docker run -u $UID:$GID --volume $(pwd):$(pwd) -w $(pwd) --rm
> gcr.io/gem5-test/ubuntu-20.04_all-dependencies scons build/ARM/gem5.opt
>
> ```
>
>
>
> I'm going to guess you probably still have Python2 somewhere on your
> machine and it's using it during the compilation. I'll setup some tests on
> my end and see if I can recreate this problem. I _think_ right now we only
> test in environments that either have only Python2 or have only Python3, so
> we should probably have some tests to check what happens if someone has
> both.
>
>
>
> Kind regards,
>
> Bobby
>
> --
>
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
>
>
> web: https://www.bobbybruce.net
>
>
>
>
>
> On Thu, Oct 8, 2020 at 4:10 PM Poremba, Matthew 
> wrote:
>
> [AMD Public Use]
>
>
>
> Hi Bobby,
>
>
>
>
>
> What is/was the fix for this issue? I also cannot build even though I have
> python 3.6 installed (via apt-get on Ubuntu 20.04).  I am manually passing
> python3-config to scons but I’m getting a syntax error when it sees the
> metaclass keyword.
>
>
>
>
>
> -Matt
>
>
>
> *From:* Bobby Bruce via gem5-dev 
> *Sent:* Thursday, October 8, 2020 3:19 PM
> *To:* gem5 Developer List 
> *Cc:* Bobby Bruce 
> *Subject:* [gem5-dev] Re: Build failed in Jenkins: Nightly #91
>
>
>
> [CAUTION: External Email]
>
> Hey all,
>
>
>
> The source of this issue is that our Jenkin's server was using Python2,
> and a commit was merged which utilized some Python3 exclusive features:
> https://gem5-review.googlesource.com/c/public/gem5/+/33900
> 
>
>
>
> We are going to drop support for Python2 in the next release, so I've
> upgraded our nightly tests to use Python3. They should pass tonight.
>
>
>
> I'm unsure if this has been officially announced in any 

[gem5-dev] Re: Implementing PSHUFB instruction

2020-10-13 Thread Jason Lowe-Power via gem5-dev
Hi Gabe,

Thanks for the info! This is a bit helpful. Although, I'm still not sure
what the next steps would be or how to even start on (1) or (2) that you
listed.

Is it possible to focus on functional correctness first and then work on
the timing correctness? The problem is that modern applications assume
these SSE instructions exist. Specifically, we can't get Ubuntu to boot
with systemd enabled without SSE instructions (specifically PSHUFB).

>From your description here, it sounds like this could be weeks+ of
development effort for us. Do we think this is worth it? There are like 4
cases of this instruction executing in the workloads we've looked at so
far. Getting the timing *perfect* doesn't seem important.

As you say, we need to overhaul the x86 SIMD instructions completely.
However, this is a months long project for someone very familiar with gem5.
It's infeasible to do that right now with our current resources.
Additionally, since I am not an expert on this code, we would really need
someone like you, Gabe, to mentor whoever is working on this project.

Cheers,
Jason

On Mon, Oct 12, 2020 at 10:34 PM Gabe Black via gem5-dev 
wrote:

> Hi Hao. The shuffle microop is implemented in
> arch/x86/isa/microops/mediaop.isa. It looks like you'll need to do three
> things to implement PSHUFB.
>
> 1. Figure out a realistic way to get all three register operands into the
> instruction. The current version takes a destination register, and both
> halves of one of the source registers, and then finally takes the 8 bit
> immediate value in the ext field of the microop. With larger registers
> which won't fit into two 64 bit slices, that scheme won't work for the
> source operands. You'll need to figure out how to get all the information
> you need into a single instruction, or in other words all the data you'll
> need to generate one 64 bit chunk of the destination. It looks like instead
> of always passing the shuffle instructions in an 8 bit immediate, the
> PSHUFB takes yet another register to hold that value. You'll need to figure
> out how to get that in there too.
> 2. The shuffle microop seems to expect assume there are two flavors of
> behavior, size = 8, and otherwise. You may need to add more logic to handle
> additional situations this new instruction needs.
> 3. Actually implement the PSHUFB macroop using the revised version of
> shuffle.
>
> The two important requirements for this sort of modification are that the
> microops still behave realistically and are constrained. If they could just
> do whatever whacky, one off thing a particular instruction needed, then
> there wouldn't be much value in microops, we could (sort of) just do
> everything with regular instructions directly. That's not entirely true,
> but the idea is true. Also we need to make sure not to break any current
> instructions, so the existing uses of shuffle need to either work as is, or
> be updated to continue working with the revised version of shuffle.
>
> Note that unlike many of the other microops gem5 uses, I actually made up
> the ones that implement SSE. I went through all the SSE instructions that
> existed at that time and made up a set of microops which seemed realistic
> and could implement all the instructions. The instructions have changed
> over time (AVX didn't exist then for instance), and so we may need to
> update those microops to match the new instructions. Whatever we do though,
> we still need to make things realistic, not break any existing
> instructions, and not just hack in a magic microop that does what we need
> in this one case without considering the design as a whole.
>
> Gabe
>
> On Mon, Oct 12, 2020 at 10:08 PM Hoa Nguyen via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Hi all,
>>
>> I've been trying to implement the PSHUFB instruction and I need some
>> help with this? While I found some documentation about this
>> instruction as well as I found a similar(?) instruction implemented in
>> gem5 (PSHUFD), I don't know how to implement PSHUFB in gem5.
>>
>> I saw that PSHUFD is broken down into 3 microps, two of which are
>> `shuffle` instructions. I don't really understand and not able to find
>> any documentation about this shuffle instruction. I wonder whether
>> PSHUFB could also be broken into shuffle instructions.
>>
>> Any help or suggestions would be appreciated!
>>
>> Regards,
>> Hoa Nguyen
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: simple simulator performance check?

2020-10-07 Thread Jason Lowe-Power via gem5-dev
I think Linux boot is pretty reasonable. Or, Linux boot + some
multithreaded tests (parsec is available for x86 in gem5-resources). If
there isn't much performance impact there, I think that would be strong
evidence for little performance impact, generally.

Cheers,
Jason

On Mon, Oct 5, 2020 at 3:07 AM Gabe Black via gem5-dev 
wrote:

> Hey folks. I'm trying out using dynamically allocated arrays to track
> source and destination register indices in static and dynamic instructions
> rather than fixed size arrays and would like to check what the impact on
> performance is. I used to use the twolf SPEC benchmark for that since it
> was fairly quick and easy to run but still ran long enough to get
> meaningful results, but do we have something like that now that's maybe
> even easier to set up? Or is easier for other people to run?
>
> As far as the arrays, what I'm aiming at is to make it unnecessary to
> measure the max number of indices needed and hence the minimum size of
> those arrays since that centralized global value needs to reflect every
> instruction in gem5, and it would be a bit of a pain to coordinate that
> with multiple ISAs. Allocating those arrays statically as part of the
> StaticInst or DynInst classes makes allocation cheaper since it just makes
> the classes a little bigger, and making them dynamic will inevitably
> involve secondary allocations to give the vectors (for instance) their
> backing store. I'm hopeful it won't be that bad though, since StaticInsts
> are usually reused from a cache and not reallocated, and dynamic
> instructions are used in CPUs which already have lots of other, more
> substantial overhead.
>
> Gabe
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: MOESI_CMP_directory coherence protocol

2020-10-05 Thread Jason Lowe-Power via gem5-dev
Hello,

Without digging deeper into things, I *believe* `Writeback_Ack_Data` has
the data with the acknowledgement, but `Writeback_Ack` just has the ack.
That's why you have to send the data from the TBE if you receive a
Writeback_Ack_Data.

Cheers,
Jason

On Fri, Sep 25, 2020 at 6:26 AM 1154063264--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> MOESI_CMP_directory-L1cache.sm , what is the difference between the events
> Writeback_Ack_Data and Writeback_Ack?
>
> Writeback_Ack,   desc="Writeback O.K. from directory";
> Writeback_Ack_Data,   desc="Writeback O.K. from directory";
>
> When the Writeback_Ack is triggered, there is no qq_sendWBDataFromTBEToL2,
> why the state is still converted to I ?
>   transition({SI, OI, MI}, Writeback_Ack, I) {
> g_sendUnblock;
> s_deallocateTBE;
> l_popForwardQueue;
>   }
>   transition({SI, OI, MI}, Writeback_Ack_Data, I) {
> qq_sendWBDataFromTBEToL2;  // always send data
> s_deallocateTBE;
> l_popForwardQueue;
>   }
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Status of Ruby tester and DMA

2020-10-05 Thread Jason Lowe-Power via gem5-dev
Hi all (specifically Matt P. and other AMDers and Tuan),

What's the status of adding DMA to the ruby tester? I see a couple of
issues on Jira (e.g., https://gem5.atlassian.net/browse/GEM5-740) and there
are some patches on gerrit for the GPU tester (e.g.,
https://gem5-review.googlesource.com/c/public/gem5/+/32855).

Is it possible to use these on protocols that don't use a GPU? What are the
limitations and capabilities of this new tester? If it *can* test DMA, can
you point to some documentation describing how to use the tester?

Thanks!
Jason
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: base: Notify stats output of first/last dump

2020-10-03 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/35576 )



Change subject: base: Notify stats output of first/last dump
..

base: Notify stats output of first/last dump

To have multiple stats dumps in a single json file, we need to use a
json array. However, to have a json array, we need to know when the
first stat dump happens and the last at the json output. This changeset
adds this new interface to the stats output object, plumbs these calls
into the python code and implements them in the json output.

Change-Id: I482fd330af23b4a5f690739a81853eb5e2518839
Signed-off-by: Jason Lowe-Power 
---
M src/base/stats/json.cc
M src/base/stats/json.hh
M src/base/stats/output.hh
M src/python/m5/simulate.py
M src/python/m5/stats/__init__.py
M src/python/pybind11/stats.cc
6 files changed, 51 insertions(+), 1 deletion(-)



diff --git a/src/base/stats/json.cc b/src/base/stats/json.cc
index 0dc5472..c97df81 100644
--- a/src/base/stats/json.cc
+++ b/src/base/stats/json.cc
@@ -36,8 +36,24 @@
 {

 void
+Json::firstDump()
+{
+ccprintf(*stream, "[");
+}
+
+void
+Json::lastDump()
+{
+ccprintf(*stream, "]");
+}
+
+void
 Json::begin()
 {
+printComma();
+
+_first.push(true);
+
 ccprintf(*stream, "{");
 }

diff --git a/src/base/stats/json.hh b/src/base/stats/json.hh
index 9723211..7cd5cd4 100644
--- a/src/base/stats/json.hh
+++ b/src/base/stats/json.hh
@@ -72,6 +72,8 @@
 void begin() override;
 void end() override;

+void firstDump() override;
+void lastDump() override;
 };

 Output *initJson(const std::string );
diff --git a/src/base/stats/output.hh b/src/base/stats/output.hh
index 6ff4a5d..7ad413c 100644
--- a/src/base/stats/output.hh
+++ b/src/base/stats/output.hh
@@ -59,6 +59,20 @@
 {
 virtual ~Output() {}

+/**
+ * This function is used to signal to the output that this is the first
+ * time that "dump" has been called. Used in formats where the first  
dump
+ * must output a special character (e.g., beginning of an array in  
json)

+ */
+virtual void firstDump() { }
+
+/**
+ * This function is used to signal to the output that this is the last
+ * time that "dump" will be called. Used in formats where the last dump
+ * must output a special character (e.g., end of an array in json)
+ */
+virtual void lastDump() { }
+
 virtual void begin() = 0;
 virtual void end() = 0;
 virtual bool valid() const = 0;
diff --git a/src/python/m5/simulate.py b/src/python/m5/simulate.py
index 080d725..e39735e 100644
--- a/src/python/m5/simulate.py
+++ b/src/python/m5/simulate.py
@@ -164,6 +164,7 @@

 # Python exit handlers happen in reverse order.
 # We want to dump stats last.
+atexit.register(stats.finalDump)
 atexit.register(stats.dump)

 # register our C++ exit callback function with Python
diff --git a/src/python/m5/stats/__init__.py  
b/src/python/m5/stats/__init__.py

index 20867da..9a721e4 100644
--- a/src/python/m5/stats/__init__.py
+++ b/src/python/m5/stats/__init__.py
@@ -382,8 +382,14 @@
 global global_dump_roots
 all_roots.extend(global_dump_roots)

-now = m5.curTick()
 global lastDump
+
+if lastDump == 0:
+first_dump = True
+else:
+first_dump = False
+
+now = m5.curTick()
 assert lastDump <= now
 new_dump = lastDump != now
 lastDump = now
@@ -404,10 +410,19 @@

 for output in outputList:
 if output.valid():
+if first_dump:
+output.firstDump()
 output.begin()
 _dump_to_visitor(output, roots=all_roots)
 output.end()

+def finalDump():
+"""Calls lastDump() on all outputs to finalize the output files
+"""
+for output in outputList:
+if output.valid():
+output.lastDump()
+
 def reset():
 '''Reset all statistics to the base state'''

diff --git a/src/python/pybind11/stats.cc b/src/python/pybind11/stats.cc
index 8ac46c2..9e0ff4b 100644
--- a/src/python/pybind11/stats.cc
+++ b/src/python/pybind11/stats.cc
@@ -117,6 +117,8 @@
 ;

 py::class_(m, "Output")
+.def("firstDump", ::Output::firstDump)
+.def("lastDump", ::Output::lastDump)
 .def("begin", ::Output::begin)
 .def("end", ::Output::end)
 .def("valid", ::Output::valid)

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/35576
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I482fd330af23b4a5f690739a81853eb5e2518839
Gerrit-Change-Number: 35576
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: n

[gem5-dev] Change in gem5/gem5[develop]: base: Add JSON output for stats

2020-10-03 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/35575 )



Change subject: base: Add JSON output for stats
..

base: Add JSON output for stats

This patch adds the initial code to allow JSON file output for stats.
No options, yet. All "new style" stats are correctly nested under their
parents, but the "old style" are just keys containing their entire
name. Only scalar stats are currently supported.

Change-Id: If6f98fbad7f61dd6f87ac9c409e54e2724807de6
Signed-off-by: Jason Lowe-Power 
---
M src/base/SConscript
A src/base/stats/json.cc
A src/base/stats/json.hh
M src/python/m5/stats/__init__.py
M src/python/pybind11/stats.cc
5 files changed, 262 insertions(+), 0 deletions(-)



diff --git a/src/base/SConscript b/src/base/SConscript
index e04d84a..c464ab2 100644
--- a/src/base/SConscript
+++ b/src/base/SConscript
@@ -76,6 +76,7 @@
 GTest('uncontended_mutex.test', 'uncontended_mutex.test.cc')

 Source('stats/group.cc')
+Source('stats/json.cc')
 Source('stats/text.cc')
 if env['USE_HDF5']:
 if main['GCC']:
diff --git a/src/base/stats/json.cc b/src/base/stats/json.cc
new file mode 100644
index 000..0dc5472
--- /dev/null
+++ b/src/base/stats/json.cc
@@ -0,0 +1,161 @@
+/* Copyright (c) 2020 The Regents of The University of California
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met: redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer;
+ * redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution;
+ * neither the name of the copyright holders nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+
+#include "base/stats/json.hh"
+
+#include "base/logging.hh"
+#include "base/stats/info.hh"
+#include "base/str.hh"
+
+namespace Stats
+{
+
+void
+Json::begin()
+{
+ccprintf(*stream, "{");
+}
+
+void
+Json::end()
+{
+ccprintf(*stream, "}");
+}
+
+void
+Json::printComma()
+{
+// Note: json doesn't allow trailing commas. So, we are going to put a
+// comma *before* every entry except the first
+if (!_first.top()) {
+ccprintf(*stream, ",");
+} else {
+// If this is the first element in the section, replace the  
top "true"

+// with false.
+_first.pop();
+_first.push(false);
+}
+}
+
+void
+Json::beginGroup(const char *name)
+{
+printComma();
+
+_first.push(true);
+
+ccprintf(*stream, "\"%s\":{", name);
+}
+
+void
+Json::endGroup()
+{
+_first.pop();
+ccprintf(*stream, "}");
+}
+
+void
+Json::visit(const ScalarInfo )
+{
+if (noOutput(info))
+return;
+
+printComma();
+
+ccprintf(*stream, "\"%s\":%s", info.name,
+ ValueToString(info.result(), info.precision));
+}
+
+void
+Json::visit(const VectorInfo )
+{
+if (noOutput(info))
+return;
+
+warn_once("json output does not support vectors");
+}
+
+void
+Json::visit(const DistInfo )
+{
+if (noOutput(info))
+return;
+
+warn_once("json output does not support distributions");
+}
+
+void
+Json::visit(const VectorDistInfo )
+{
+if (noOutput(info))
+return;
+
+warn_once("json output does not support vector distributions");
+}
+
+void
+Json::visit(const Vector2dInfo )
+{
+if (noOutput(info))
+return;
+
+warn_once("json output does not support 2D vectors");
+}
+
+void
+Json::visit(const FormulaInfo )
+{
+if (noOutput(info))
+return;
+
+warn_once("json output does not support formulas");
+}
+
+void
+Json:

[gem5-dev] Re: PCI memory BARs broken on ARM

2020-10-02 Thread Jason Lowe-Power via gem5-dev
Hey Gabe,

I believe the developers at AMD have already implemented a lot of similar
things to get their GPU model working. The relevant Jira issue is
https://gem5.atlassian.net/browse/GEM5-470 (I think). There may be other
relevant issues on this Epic: https://gem5.atlassian.net/browse/GEM5-195.

I just want to make sure we rope in everyone who has been doing development
in this space!

Cheers,
Jason

On Thu, Oct 1, 2020 at 9:33 PM Gabe Black via gem5-dev 
wrote:

> Hi folks. We locally just rebased and picked up a change where the ARM PCI
> controller's configuration was fixed so that it had the appropriate
> starting address for memory mappings. Now that that's correct, it means
> that instead of setting memory BARs to 0x4000 (for example) to get them
> in the correct place, they need to be set to 0, and the "hardware" will
> take care of adding in a 0x4000 offset.
>
> That's more correct, but it means that now the BAR needs to be set to 0,
> and the gem5 PCI BAR handling code is a little bit simplistic and wrong in
> that it treats 0 and 0x as magical values and has special behavior
> when the BARs are set to them. Specifically, it treats a 0 as off, and
> doesn't update the ranges the device responds to on its parent bus. This
> isn't a problem on x86 where the memory addresses are usually not 0 since
> there's actual RAM there, and there's generally no offset applied either.
>
> To fix this, I have a big rework in progress which will change how BARs
> are set up for PCI devices across the board. Note that this will not affect
> any of the work Andreas did a while ago setting up a host device, the
> DeviceInterface type, etc., which is all fine. There are two major parts to
> the change I'm making, in python and C++.
>
> First, rather than having several arrays of scalar parameters which
> together control the BARs, a raw BAR value as it would be in the config, a
> flag setting it s a "legacyIO", and a size, (and a legacy IO offset!) each
> BAR is represented by a python object whose type reflects it's job. There
> is one for IO, one for memory, one for the upper 32 bits of a 64 bit BAR,
> and one for legacy IO. They each have appropriate properties like a fixed
> address or a size as appropriate, and are assigned to a device as a
> VectorParam.
>
> Then on the C++ side, rather than try to track things from the raw BAR
> values, config writes are filtered through the BAR objects which know what
> bits to mask, what the corresponding address range should be based on their
> type, etc. I also took this opportunity to clear away a number of clumsy
> bookkeeping mechanisms and bugs/misunderstandings of how BARs work, many of
> them my own from a long time ago. Also, the handling of disabling memory or
> IO BARs through the config "command" byte is now handled centrally, rather
> than being implemented one off in the IDE controller.
>
> Both of these things seem to now be working, so that's great. The reason
> I'm writing an email rather than sending a code review (yet) is that I'm
> also running into a problem with the python config.
>
> The gist of it is that the PCI device creates the VectorParam of BARs. The
> IDE controller then sets the BARs using a python list of BAR objects as a
> default, and that works. Then in the X86 SouthBridge object (x86 is a
> little easier for me to test atm), I've tried to overwrite some of those
> BARs individually to give them new defaults which make sense on x86. That
> fails because the new values are not parented correctly. If I try setting
> the whole VectorParam with a new list, then it works fine. I think the
> problem is that foo.bar[0] = doesn't actually set foo.bar, it extracts bar
> from foo and then sets element 0 in the bar it extracted. The bookkeeping
> for this is wrong somehow.
>
> Anyway, I wanted to send out an email to let people know there's a bug
> here on both counts, in case they ran into any problems. The default ARM
> setup should be mostly ok since the only PCI device seems to be the IDE
> controller, and that uses legacy style fixed IO BARs which seem to work
> fine. I also wanted to let people know I'm fighting with the bug in the
> config system. I'm going to try to figure that one out, but it's pretty
> twisty in there and I'm struggling to understand how all that plumbing
> works. If anybody has any great insights, I'd be happy to hear them!
>
> Gabe
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[release-staging-v20.1.0.0]: misc: Add release notes for 20.1

2020-09-30 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/35375 )


Change subject: misc: Add release notes for 20.1
..

misc: Add release notes for 20.1

Change-Id: I011ff987e222326dd7f0787c41043578b52b236a
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35375
Maintainer: Jason Lowe-Power 
Reviewed-by: Giacomo Travaglini 
Reviewed-by: Matthew Poremba 
Tested-by: kokoro 
---
M RELEASE-NOTES.md
1 file changed, 119 insertions(+), 1 deletion(-)

Approvals:
  Matthew Poremba: Looks good to me, approved
  Giacomo Travaglini: Looks good to me, approved
  Jason Lowe-Power: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/RELEASE-NOTES.md b/RELEASE-NOTES.md
index 1a97b4c..492bb96 100644
--- a/RELEASE-NOTES.md
+++ b/RELEASE-NOTES.md
@@ -1,6 +1,124 @@
 # Version 20.1.0.0

-* m5.stats.dump() root argument renamed to roots to reflect the fact that  
it now takes a list of SimObjects

+Thank you to everyone that made this release possible!
+This has been a very productive release with [150  
issues](https://gem5.atlassian.net/), over 650  commits (a 25% increase  
from the 20.0 release), and 58 unique contributors (a 100% increase!).

+
+## Process changes
+
+We are no longer using the "master" branch.
+Instead, we will have two branches:
+
+* "stable": This will point to the latest stable release (gem5-20.1 as of  
today)
+* "develop": This is the latest development code that will be merged in to  
the "stable" branch at each release.

+
+We suggest all *users* use the stable (default) branch.
+However, to contribute your fixes and new changes to gem5, it should be  
contributed to the develop branch.

+See CONTRIBUTING.md for more details.
+
+gem5 has also implemented a project code of conduct.
+See the CODE-OF-CONDUCT.md file for details.
+In the code of conduct "we pledge to act and interact in ways that  
contribute to an open, welcoming, diverse, inclusive, and healthy  
community."

+
+## New features in 20.1
+
+### New DRAM interface: Contributed by *Wendy Elsasser*
+
+You can find details about this on the [gem5  
blog](http://www.gem5.org/2020/05/27/memory-controller.html) or Wendy's  
talks on YouTube: [Talk on new interface and  
NVM](https://www.youtube.com/watch?v=t2PRoZPwwpk) and the [talk on  
LPDDR5](https://www.youtube.com/watch?v=ttJ9_I_Avyc)

+
+* **[PYTHON API CHANGE]**: The DRAM models are now *DRAM interfaces* which  
is a child of the *memory controller*. Example change shown [in the blog  
post](http://www.gem5.org/project/2020/07/18/gem5-20-1.html).

+  * The DRAM is split into a memory controller and a DRAM interface
+  * `SimpleMemory` is no longer a drop-in replacement for a DRAM-based  
memory controller.

+* LPDDR5 model added
+* NVM model added
+* New memory controller model that can use both NVM and DRAM
+
+### Improved on-chip interconnect model, HeteroGarnet: Contributed by  
*Srikant Bharadwaj*

+
+You can find details about this on the [gem5  
blog](http://www.gem5.org/2020/05/27/heterogarnet.html) and [Srikant's talk  
on YouTube](https://www.youtube.com/watch?v=AH9r44r2lHA).

+
+* **[USER-FACING CHANGE]**: The network type options are now "simple"  
and "garnet" instead of "garnet2.0". (If "garnet2.0" is used, you will get  
a warning until gem5-20.2)
+* Added models for clock domain crossings and  
serialization/deserialization (SERDES)

+
+### Transactional memory support: Contributed by *Timothy Hayes*
+
+You can find details on the [Jira  
issue](https://gem5.atlassian.net/browse/GEM5-587)

+
+* gem5 now supports Arm TME (transactional memory extensions)
+* Transactional memory is only implemented in the `MESI_Three_Level_HTM`  
Ruby protocol, and it is only implemented in Ruby.
+* This implements a checkpointing mechanism for the architectural state  
and buffering of speculative memory updates.

+* IBM POWER and x86 HTM extensions have *not* been implemented.
+
+### Other new features
+
+* External simulator integrations
+  * Added support for DRAMSim3
+  * Added back support for DRAMSim2
+* Armv8-A Self Hosted Debug extension added
+* KVM support for Armv8-A  hosts without GICv2 hardware
+* Implemented Secure EL2 for Armv8-A
+
+## Removed features
+
+* Dropped support for mercurial version control
+
+## New supported platforms
+
+* GCC up to 10.2 is now supported. Minimum GCC is now 5.0.
+* Clang up to version 9. Minimum Clang is now 3.9.
+
+## Platforms no longer support
+
+* **[USER-FACING CHANGE]**: Python 2 is officially deprecated. We will  
drop support for Python 2 in the next release. In this release you will get  
a warning if you're using Python 2.

+* **[USER-FACING CHANGE]**: We have dropped support for GCC 4.X
+* **[USER-FACING CHANGE]**: We have dropped support for Scons 2.x (Note:  
this i

[gem5-dev] gem5-20.1 release imminent

2020-09-29 Thread Jason Lowe-Power via gem5-dev
Hi all,

We're planning on making the gem5-20.1 release official tomorrow. Please
let us know if there's any last minute blocking issues. There are a couple
of small things we're still waiting on, but we're confident they'll be
resolved by tomorrow morning (US west coast time).

In the meantime, let me know if you have any comments on the release notes
here: https://gem5-review.googlesource.com/c/public/gem5/+/35375

Thanks to everyone for making this another successful release!

Cheers,
Jason
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[release-staging-v20.1.0.0]: misc: Add release notes for 20.1

2020-09-29 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/35375 )



Change subject: misc: Add release notes for 20.1
..

misc: Add release notes for 20.1

Change-Id: I011ff987e222326dd7f0787c41043578b52b236a
Signed-off-by: Jason Lowe-Power 
---
M RELEASE-NOTES.md
1 file changed, 115 insertions(+), 1 deletion(-)



diff --git a/RELEASE-NOTES.md b/RELEASE-NOTES.md
index 1a97b4c..5525972 100644
--- a/RELEASE-NOTES.md
+++ b/RELEASE-NOTES.md
@@ -1,6 +1,120 @@
 # Version 20.1.0.0

-* m5.stats.dump() root argument renamed to roots to reflect the fact that  
it now takes a list of SimObjects

+Thank you to everyone that made this release possible!
+This has been a very productive release with [150  
issues](https://gem5.atlassian.net/), over 650  commits (a 25% increase  
from the 20.0 release), and 58 unique contributors (a 100% increase!).

+
+## Process changes
+
+We are no longer using the "master" branch.
+Instead, we will have two branches:
+
+* "stable": This will point to the latest stable release (gem5-20.1 as of  
today)
+* "develop": This is the latest development code that will be merged in to  
the "stable" branch at each release.

+
+We suggest all *users* use the stable (default) branch.
+However, to contribute your fixes and new changes to gem5, it should be  
contributed to the develop branch.

+See CONTRIBUTING.md for more details.
+
+## New features in 20.1
+
+### New DRAM interface: Contributed by *Wendy Elsasser*
+
+You can find details about this on the [gem5  
blog](http://www.gem5.org/2020/05/27/memory-controller.html) or Wendy's  
talks on YouTube: [Talk on new interface and  
NVM](https://www.youtube.com/watch?v=t2PRoZPwwpk) and the [talk on  
LPDDR5](https://www.youtube.com/watch?v=ttJ9_I_Avyc)

+
+* **[PYTHON API CHANGE]**: The DRAM models are now *DRAM interfaces* which  
is a child of the *memory controller*. Example change shown [in the blog  
post](http://www.gem5.org/project/2020/07/18/gem5-20-1.html).

+  * The DRAM is split into a memory controller and a DRAM interface
+  * `SimpleMemory` is no longer a drop-in replacement for a DRAM-based  
memory controller.

+* LPDDR5 model added
+* NVM model added
+* New memory controller model that can use both NVM and DRAM
+
+### Improved on-chip interconnect model, HeteroGarnet: Contributed by  
*Srikant Bharadwaj*

+
+You can find details about this on the [gem5  
blog](http://www.gem5.org/2020/05/27/heterogarnet.html) and [Srikant's talk  
on YouTube](https://www.youtube.com/watch?v=AH9r44r2lHA).

+
+* **[USER-FACING CHANGE]**: The network type options are now "simple"  
and "garnet" instead of "garnet2.0". (If "garnet2.0" is used, you will get  
a warning until gem5-20.2)
+* Added models for clock domain crossings and  
serialization/deserialization (SERDES)

+
+### Transactional memory support: Contributed by *Timothy Hayes*
+
+You can find details on the [Jira  
issue](https://gem5.atlassian.net/browse/GEM5-587)

+
+* gem5 now supports Arm TME (transactional memory extensions)
+* Transactional memory is only implemented in the `MESI_Three_Level_HTM`  
Ruby protocol, and it is only implemented in Ruby.
+* This implements a checkpointing mechanism for the architectural state  
and buffering of speculative memory updates.

+* IBM POWER and x86 HTM extensions have *not* been implemented.
+
+### Other new features
+
+* External simulator integrations
+  * Added support for DRAMSim3
+  * Added back support for DRAMSim2
+* Armv8-A Self Hosted Debug extension added
+* KVM support for Armv8 hosts without GICv2 hardware
+* Implemented Secure EL2 for ARMv8
+
+## Removed features
+
+* Dropped support for mercurial version control
+
+## New supported platforms
+
+* GCC up to 10.2 is now supported. Minimum GCC is now 5.0.
+* Clang up to version 9. Minimum Clang is now 3.9.
+
+## Platforms no longer support
+
+* **[USER-FACING CHANGE]**: Python 2 is officially deprecated. We will  
drop support for Python 2 in the next release. In this release you will get  
a warning if you're using Python 2.

+* **[USER-FACING CHANGE]**: We have dropped support for GCC 4.X
+* **[USER-FACING CHANGE]**: We have dropped support for Scons 2.x (Note:  
this is the default in Ubuntu 16.04. Use pip to install a newer scons.)

+
+See <http://www.gem5.org/documentation/general_docs/building> for gem5's  
current dependencies.

+
+## Other changes
+
+### Deprecating "master" and "slave"
+
+* **[API CHANGE]**: The names "master" and "slave" have been deprecated
+  * Special thanks to Lakin Smith, Shivani Parekh, Eden Avivi, and Emily  
Brickey.

+  * Below is a guide to most of the name changes.
+  * The goal was to replace problematic language with more descriptive and  
precise terms.
+* There may be some bugs introduced wit

[gem5-dev] Re: MMU object vs. DTB and ITB

2020-09-29 Thread Jason Lowe-Power via gem5-dev
Hey Giacomo,

Thanks for the patches! I think this is moving in the right direction. It
looks like the C++ interface is getting much better, though there are still
a few places to improve :).

However, I think we need to reconsider the python interface at this time
too. Right now, we have the following "dependencies".

To hook up the memory system, you have to know details about the internal
CPU implementation. This in turn depends on the MMU implementation. This in
turn depends on the TLB implementation. This in turn depends on the walker
implementation (which also depends on the ISA!).

To create a CPU correctly, the CPU also depends on the memory system (i.e.,
classic caches use "cpu_side" whereas Ruby (now) uses "in_port"). This also
means that the transitive dependency described above also depends on the
memory system implementation. (There's also the dependence on "cached" vs
"uncached" ports in the CPU too... But I think this is a different issue.)

These circular dependencies are not great.

I think we should talk about which way we want the dependencies to flow,
and then hide the implementation behind functions. By defining some
functions in the Python SimObject description files, we can hide the
implementation details (e.g., that an MMU has two child SimObjects called
itb and dtb). In doing this, we can have *well defined* interfaces/APIs for
the Python SimObjects instead of the mess of "duck typing" that we have
right now.

Given all of the changes in
https://gem5-review.googlesource.com/c/public/gem5/+/34976 to the config
files, I would prefer to hash this out before these changes go in, but I
would also be open to waiting and going through some pain on the develop
branch. However, if we're going to do this TLB refactor now, I think it's a
requirement to also refactor the python interface before the 20.2 release.

Cheers,
Jason

On Tue, Sep 22, 2020 at 8:48 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hey Jason,
>
>
>
> I have just posted the patchset:
>
>
>
> https://gem5-review.googlesource.com/c/public/gem5/+/34975/1
>
>
>
> Supporting a multi-level TLB design was actually the reason why I started
> implementing this.
>
> I am not at that point yet, but I believe we are getting closer now,
> having a MMU hiding the TLB hierarchy to the rest of the cpu code.
>
> The remaining thing after this patches would be to move most TLB methods
> to the MMU class and to make the TLB a simple passive translation cache.
> That will allow us to stack them in any way we want
>
>
>
> Giacomo
>
>
>
> *From:* Jason Lowe-Power via gem5-dev 
> *Sent:* 21 September 2020 16:02
> *To:* gem5 Developer List 
> *Cc:* Jason Lowe-Power 
> *Subject:* [gem5-dev] Re: MMU object vs. DTB and ITB
>
>
>
> We (well, mostly Ayaz) have also been looking at this interface. We've
> been thinking more about x86 and RISC-V, but would also like to be kept up
> to date!
>
>
>
> We were also thinking that many of the TLB/MMU concepts are shared between
> ISAs (or are microarchitecture details). So, it would be nice to be able to
> use the same multi-level TLB design for any ISA similar to how we can use
> caches for any ISA. I'm not sure if this is something that's enabled by
> your changes, Giacomo, or if it's something others think is important.
>
>
>
> Cheers,
>
> Jason
>
>
>
> On Mon, Sep 21, 2020 at 4:06 AM Gabe Black via gem5-dev 
> wrote:
>
> Oh, nice. I got sidetracked with some other things I wanted to rearrange
> first, so I haven't actually started on the MMU part :-). Please add me as
> a reviewer!
>
>
>
> Gabe
>
>
>
> On Mon, Sep 21, 2020 at 1:17 AM Giacomo Travaglini <
> giacomo.travagl...@arm.com> wrote:
>
> Hi  Gabe, I am actually about to post the same patchset (which is:
> removing the TLB from the CPU interface and make it interface with an MMU
> instead)
>
>
>
> Giacomo
>
>
>
> *From:* Gabe Black via gem5-dev 
> *Sent:* 20 September 2020 04:44
> *To:* gem5 Developer List 
> *Cc:* Gabe Black 
> *Subject:* [gem5-dev] Re: MMU object vs. DTB and ITB
>
>
>
> Oh, this will also absorb multilevel TLBs too, like how ARM has second
> level translation in some cases. This isn't really implemented in x86, but
> could also be used for it's multilevel translation in SVM and VT's nested
> page table schemes.
>
>
>
> Gabe
>
>
>
> On Sat, Sep 19, 2020 at 8:25 PM Gabe Black  wrote:
>
> Hi folks. I've been thinking about how to rework the
> scanning-through-page-translation thing we currently do when translating a
> region of addresses through both the ITB and DTB. We currently do that one
> page at a time by trying one, and the

[gem5-dev] Re: Build failed in Jenkins: Nightly #75

2020-09-22 Thread Jason Lowe-Power via gem5-dev
I think the problem is that google perftools isn't installed in this image.
I guess we could skip building perf for the unittests?

On Mon, Sep 21, 2020 at 11:26 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See  >
>
> Changes:
>
> [Bobby R. Bruce] util: Removed libelf-dev dep from Dockerfiles
>
> [Bobby R. Bruce] tests,base: Fixed unittests for .fast
>
>
> --
> [...truncated 157.07 KB...]
> [ RUN  ] StrTest.EatEndWhiteNoTrailingWhitespace
> [   OK ] StrTest.EatEndWhiteNoTrailingWhitespace (0 ms)
> [ RUN  ] StrTest.EatWhite
> [   OK ] StrTest.EatWhite (0 ms)
> [ RUN  ] StrTest.EatWhiteNoWhitespace
> [   OK ] StrTest.EatWhiteNoWhitespace (0 ms)
> [ RUN  ] StrTest.ToLower
> [   OK ] StrTest.ToLower (0 ms)
> [ RUN  ] StrTest.SplitFirst
> [   OK ] StrTest.SplitFirst (0 ms)
> [ RUN  ] StrTest.SplitFirstNoChar
> [   OK ] StrTest.SplitFirstNoChar (0 ms)
> [ RUN  ] StrTest.SplitFirstOnFirstChar
> [   OK ] StrTest.SplitFirstOnFirstChar (0 ms)
> [ RUN  ] StrTest.SplitLast
> [   OK ] StrTest.SplitLast (0 ms)
> [ RUN  ] StrTest.SplitLastNoChar
> [   OK ] StrTest.SplitLastNoChar (0 ms)
> [ RUN  ] StrTest.SplitLastOnLastChar
> [   OK ] StrTest.SplitLastOnLastChar (0 ms)
> [ RUN  ] StrTest.TokenizeOnSpace
> [   OK ] StrTest.TokenizeOnSpace (0 ms)
> [ RUN  ] StrTest.TokenizeOnSpaceIgnFalse
> [   OK ] StrTest.TokenizeOnSpaceIgnFalse (0 ms)
> [ RUN  ] StrTest.TokenizedTokenDoesNotExist
> [   OK ] StrTest.TokenizedTokenDoesNotExist (0 ms)
> [ RUN  ] StrTest.ToNumber8BitInt
> [   OK ] StrTest.ToNumber8BitInt (0 ms)
> [ RUN  ] StrTest.ToNumber8BitIntStringOutOfRange
> [   OK ] StrTest.ToNumber8BitIntStringOutOfRange (0 ms)
> [ RUN  ] StrTest.ToNumber8BitIntInvalidString
> [   OK ] StrTest.ToNumber8BitIntInvalidString (1 ms)
> [ RUN  ] StrTest.ToNumberUnsigned8BitInt
> [   OK ] StrTest.ToNumberUnsigned8BitInt (0 ms)
> [ RUN  ] StrTest.ToNumberUnsigned8BitIntNegative
> [   OK ] StrTest.ToNumberUnsigned8BitIntNegative (0 ms)
> [ RUN  ] StrTest.ToNumber64BitInt
> [   OK ] StrTest.ToNumber64BitInt (0 ms)
> [ RUN  ] StrTest.ToNumber64BitIntInvalidString
> [   OK ] StrTest.ToNumber64BitIntInvalidString (0 ms)
> [ RUN  ] StrTest.ToNumberFloat
> [   OK ] StrTest.ToNumberFloat (0 ms)
> [ RUN  ] StrTest.ToNumberFloatIntegerString
> [   OK ] StrTest.ToNumberFloatIntegerString (0 ms)
> [ RUN  ] StrTest.ToNumberFloatNegative
> [   OK ] StrTest.ToNumberFloatNegative (0 ms)
> [ RUN  ] StrTest.ToNumberDouble
> [   OK ] StrTest.ToNumberDouble (0 ms)
> [ RUN  ] StrTest.ToNumberDoubleIntegerString
> [   OK ] StrTest.ToNumberDoubleIntegerString (0 ms)
> [ RUN  ] StrTest.ToNumberDoubleNegative
> [   OK ] StrTest.ToNumberDoubleNegative (0 ms)
> [ RUN  ] StrTest.ToBoolTrue
> [   OK ] StrTest.ToBoolTrue (0 ms)
> [ RUN  ] StrTest.ToBoolFalse
> [   OK ] StrTest.ToBoolFalse (0 ms)
> [ RUN  ] StrTest.ToBoolInvalidInput
> [   OK ] StrTest.ToBoolInvalidInput (0 ms)
> [ RUN  ] StrTest.QuoteStringNoSpace
> [   OK ] StrTest.QuoteStringNoSpace (0 ms)
> [ RUN  ] StrTest.QuoteStringWithSpace
> [   OK ] StrTest.QuoteStringWithSpace (0 ms)
> [ RUN  ] StrTest.QuoteQuotedString
> [   OK ] StrTest.QuoteQuotedString (0 ms)
> [ RUN  ] StrTest.QuoteStringWithTab
> [   OK ] StrTest.QuoteStringWithTab (0 ms)
> [ RUN  ] StrTest.StartswithDoubleStringDoesStartWith
> [   OK ] StrTest.StartswithDoubleStringDoesStartWith (0 ms)
> [ RUN  ] StrTest.StartswithDoubleStringDoesNotStartWith
> [   OK ] StrTest.StartswithDoubleStringDoesNotStartWith (0 ms)
> [ RUN  ] StrTest.StartswithDoubleCharArrayDoesStartWith
> [   OK ] StrTest.StartswithDoubleCharArrayDoesStartWith (0 ms)
> [ RUN  ] StrTest.StartswithDoubleCharArrayDoesNotStartWith
> [   OK ] StrTest.StartswithDoubleCharArrayDoesNotStartWith (0 ms)
> [ RUN  ] StrTest.StartswithStringCharArrayDoesStartWith
> [   OK ] StrTest.StartswithStringCharArrayDoesStartWith (0 ms)
> [ RUN  ] StrTest.StartswithStringCharArrayDoesNotStartWith
> [   OK ] StrTest.StartswithStringCharArrayDoesNotStartWith (0 ms)
> [--] 42 tests from StrTest (1 ms total)
>
> [--] Global test environment tear-down
> [==] 42 tests from 1 test case ran. (1 ms total)
> [  PASSED  ] 42 tests.
>  [ CXX] NULL/sim/proxy_ptr.test.cc -> .fo
>  [LINK]  -> NULL/base/trie.test.fast.unstripped
>  [   STRIP] NULL/base/trie.test.fast.unstripped -> .fast
>  [LINK]  -> NULL/sim/byteswap.test.fast.unstripped
> build/NULL/base/trie.test.fast
> --gtest_output=xml:build/NULL/unittests.fast/base/trie.test.xml
> Running main() from gtest_main.cc
> [==] Running 7 tests from 1 test case.
> [--] Global 

[gem5-dev] Re: MMU object vs. DTB and ITB

2020-09-21 Thread Jason Lowe-Power via gem5-dev
We (well, mostly Ayaz) have also been looking at this interface. We've been
thinking more about x86 and RISC-V, but would also like to be kept up to
date!

We were also thinking that many of the TLB/MMU concepts are shared between
ISAs (or are microarchitecture details). So, it would be nice to be able to
use the same multi-level TLB design for any ISA similar to how we can use
caches for any ISA. I'm not sure if this is something that's enabled by
your changes, Giacomo, or if it's something others think is important.

Cheers,
Jason

On Mon, Sep 21, 2020 at 4:06 AM Gabe Black via gem5-dev 
wrote:

> Oh, nice. I got sidetracked with some other things I wanted to rearrange
> first, so I haven't actually started on the MMU part :-). Please add me as
> a reviewer!
>
> Gabe
>
> On Mon, Sep 21, 2020 at 1:17 AM Giacomo Travaglini <
> giacomo.travagl...@arm.com> wrote:
>
>> Hi  Gabe, I am actually about to post the same patchset (which is:
>> removing the TLB from the CPU interface and make it interface with an MMU
>> instead)
>>
>>
>>
>> Giacomo
>>
>>
>>
>> *From:* Gabe Black via gem5-dev 
>> *Sent:* 20 September 2020 04:44
>> *To:* gem5 Developer List 
>> *Cc:* Gabe Black 
>> *Subject:* [gem5-dev] Re: MMU object vs. DTB and ITB
>>
>>
>>
>> Oh, this will also absorb multilevel TLBs too, like how ARM has second
>> level translation in some cases. This isn't really implemented in x86, but
>> could also be used for it's multilevel translation in SVM and VT's nested
>> page table schemes.
>>
>>
>>
>> Gabe
>>
>>
>>
>> On Sat, Sep 19, 2020 at 8:25 PM Gabe Black  wrote:
>>
>> Hi folks. I've been thinking about how to rework the
>> scanning-through-page-translation thing we currently do when translating a
>> region of addresses through both the ITB and DTB. We currently do that one
>> page at a time by trying one, and then the other. That requires knowing
>> what "the" page size is, which introduces a dependence on the ISA and also
>> constraints things to a single page size.
>>
>>
>>
>> One improvement that I think makes sense is to instead use an approach
>> where you'd ask for a translation for a region and let whatever is
>> translating for you decide how to break things up. Then it can use a single
>> page size, the size of whatever the mapping is, a single byte, etc., as it
>> sees fit without there ever needing to be a particular page size. This
>> would fit mostly nicely with the idea of a range based for loop or
>> generator object.
>>
>>
>>
>> One problem with this approach is how we try one TLB and then the other
>> if we can't get a translation. With a range based for loop, there isn't a
>> good way that I'm aware of to iterate over two different objects at the
>> same time, and also there wouldn't be any coordination between the TLBs.
>> For instance, what should happen in both have a translation? Or if they're
>> to the same place, who's idea of the size of the step takes precedence?
>>
>>
>>
>> That led me to the idea of merging the TLBs into a single object called
>> the MMU. This fits pretty well with the structure of actual hardware, and
>> would also absorb the "UnifiedTLB" concept which was added to the CPU,
>> since the structure of the TLBs would no longer be visible to the CPU.
>>
>>
>>
>> I think this makes a lot of sense and will probably take a stab at it
>> this weekend, but since it's a structural shift that will be fairly visible
>> in a lot of places I wanted to let everybody know a little ahead of time in
>> case there are any big concerns.
>>
>>
>>
>> Gabe
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: gem5 python version?

2020-09-20 Thread Jason Lowe-Power via gem5-dev
Hi Mike,

I believe we've decided to drop 2.7 support after the 20.1 release. This
hasn't been checked into develop, yet, but I think it's a safe assumption
that develop now only supports python3.

Cheers,
Jason

On Sun, Sep 20, 2020 at 10:52 AM mike upton via gem5-dev 
wrote:

>
> Do we still support python2.7?
>
> I am adding some functionality and it is cleanest in python3, but the code
> will fail if running in python2.
>
>
> thanks
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: A few quick thoughts

2020-09-19 Thread Jason Lowe-Power via gem5-dev
I agree with all of this.

I'm not sure it's worth the change right now. A quick grep of "bits(" shows
that there's many cases (maybe 5-10%?) where there are variables used for
the bits. I suspect that most of these are constexpr, but it's impossible
to tell without checking each one. Just for ease of this change, I think
that we should keep the same function name in both cases.

Approximately all places bits() is called with only numbers as the 2nd and
3rd arguments.
> grep -E "bits\(.*, *[0-9]{1,2}, *[0-9]{1,2}\)" src -r | wc -l
2271

Approximately all places bits() is called with 3 arguments.
> grep -E "bits\(.*,.*,.*\)" src -r | wc -l
2589

Cheers,
Jason

On Fri, Sep 18, 2020 at 8:49 PM Gabe Black  wrote:

> Well, I *think* having not extensively surveyed the code, that the vast
> majority of the time the bits that are being extracted are constant, so the
> templated form would be the default, and you'd just need to use the current
> form in the few cases where it's not fixed. As somebody suggested, we could
> use a macro to make it look a little more uniform and keep the arguments in
> the same order. Perhaps:
>
> #define bits(val, first, last) _bits_template(val)
>
> and call the full flexibility function bitsv (for variable). Most of the
> time you'd use the normal version, except when it yells at you and forces
> you to use bitsv.
>
> This is not ideal in I think three ways.
> 1. Macros are not namespaced. MyFavoritClass::bits would be problematic
> but is totally fine today.
> 2. Slightly more complexity than today. The complexity is *mostly*
> obscured, which can be a good or bad thing depending on circumstances.
> 3. If somebody does copy paste coding and doesn't know *why* something is
> bitsv vs bits, they're more likely to use the wrong one than if they were
> starting from scratch.
>
> Importantly, if somebody *does* use the wrong thing, the only way they
> could do that would be to use the variable form unnecessarily. The other
> way around would definitely be a compiler error. If they do that, then we
> would be no worse off than we are today, we would just lose a little bit of
> the error checking which we have none of now.
>
> I don't think this is a slam dunk obvious right thing to do, but I think
> it has some merits and is worth considering. If in the future somebody does
> either figure out some crazy clever way to do this without the templates,
> or the standard evolves to the point where we can use something more
> elegant, then it should be relatively easy to move to that instead.
>
> Gabe
>
> On Fri, Sep 18, 2020 at 8:35 AM Jason Lowe-Power 
> wrote:
>
>> Sorry for the spam...
>>
>> One last thing: We have to keep both bits(val, first, last) *and*
>> bits(val) because sometimes first and last are *not*
>> constexpr. If they were *always* constexpr, this would be much simpler (I
>> think).
>>
>> Cheers,
>> Jason
>>
>> On Fri, Sep 18, 2020 at 8:33 AM Jason Lowe-Power 
>> wrote:
>>
>>> I don't like the following change
>>>
>>> bits(val, first, last)
>>>
>>> would now be
>>>
>>> bits(val).
>>>
>>> IMO, it's confusing to put function *parameters* as template arguments.
>>>
>>> This would mean that when you use the bits() function, you'll have to
>>> think about "are these constexpr that I'm using, and, if so, should I use
>>> bits() or bits<>()?"
>>>
>>> We can go through and manually change the current code, but for new
>>> code, this will be yet another thing that we'd have to catch during code
>>> review.
>>>
>>> Just my two cents. I won't block anything, I just think that readability
>>> is more important than a little* performance.
>>>
>>> *It depends on how much performance difference assert() vs
>>> static_assert() is in this case.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Fri, Sep 18, 2020 at 8:29 AM Gutierrez, Anthony <
>>> anthony.gutier...@amd.com> wrote:
>>>
>>>> [AMD Public Use]
>>>>
>>>>
>>>>
>>>> Hey, Jason perhaps you mentioned this somewhere but what is the reason
>>>> for such a strong aversion to the template approach? It seems to solve the
>>>> issue nicely with what seems to be a minor change in syntax. gem5 is C++,
>>>> so we should allow users to write C++.
>>>>
>>>>
>>>>
>>>> Tony
>>>>
>>>>
>>>>
>>>> *From:* Jason Lowe-Power via gem5-dev 
>>>> *Sent

[gem5-dev] Re: A few quick thoughts

2020-09-18 Thread Jason Lowe-Power via gem5-dev
Sorry for the spam...

One last thing: We have to keep both bits(val, first, last) *and*
bits(val) because sometimes first and last are *not*
constexpr. If they were *always* constexpr, this would be much simpler (I
think).

Cheers,
Jason

On Fri, Sep 18, 2020 at 8:33 AM Jason Lowe-Power 
wrote:

> I don't like the following change
>
> bits(val, first, last)
>
> would now be
>
> bits(val).
>
> IMO, it's confusing to put function *parameters* as template arguments.
>
> This would mean that when you use the bits() function, you'll have to
> think about "are these constexpr that I'm using, and, if so, should I use
> bits() or bits<>()?"
>
> We can go through and manually change the current code, but for new code,
> this will be yet another thing that we'd have to catch during code review.
>
> Just my two cents. I won't block anything, I just think that readability
> is more important than a little* performance.
>
> *It depends on how much performance difference assert() vs static_assert()
> is in this case.
>
> Cheers,
> Jason
>
> On Fri, Sep 18, 2020 at 8:29 AM Gutierrez, Anthony <
> anthony.gutier...@amd.com> wrote:
>
>> [AMD Public Use]
>>
>>
>>
>> Hey, Jason perhaps you mentioned this somewhere but what is the reason
>> for such a strong aversion to the template approach? It seems to solve the
>> issue nicely with what seems to be a minor change in syntax. gem5 is C++,
>> so we should allow users to write C++.
>>
>>
>>
>> Tony
>>
>>
>>
>> *From:* Jason Lowe-Power via gem5-dev 
>> *Sent:* Friday, September 18, 2020 8:05 AM
>> *To:* Gabe Black 
>> *Cc:* gem5 Developer List ; Jason Lowe-Power <
>> ja...@lowepower.com>
>> *Subject:* [gem5-dev] Re: A few quick thoughts
>>
>>
>>
>> [CAUTION: External Email]
>>
>> There is another option to keep the function-like syntax, but get the
>> constexpr via templates: A preprocessor macro:
>>
>>
>>
>> #define bits(val, first, last) bits(val)
>>
>>
>>
>> The major downside is that we can't overload preprocessor macros. We'd
>> have to have two name bits_const() and bits(), which I also don't like.
>>
>>
>>
>> Personally, I strongly don't want to lose the function-like syntax for
>> the bits function. I won't *block* the change, but I'll push back against
>> the template syntax.
>>
>>
>>
>> Cheers,
>>
>> Jason
>>
>>
>>
>> On Fri, Sep 18, 2020 at 5:02 AM Gabe Black  wrote:
>>
>> I spent some more time digging into 2, and while I didn't find anything
>> that directly stated that you aren't allowed to do that, without explicit
>> support I think it flies in the face of how C++ templates, types, etc. work
>> to the point where if you *did* find a way to do it, it would almost
>> certainly be a bug or an oversight in the standard somewhere. So unless
>> they do adopt one of those standards I saw proposed and we wait a good
>> number of years for it to be implemented in all the compilers we support
>> (one said it targeted C++23) I think templates, while slightly gross, are
>> really the only way to make it work.
>>
>>
>>
>> Gabe
>>
>>
>>
>> On Thu, Sep 17, 2020 at 2:53 PM Jason Lowe-Power 
>> wrote:
>>
>>
>>
>>
>>
>> On Thu, Sep 17, 2020 at 2:48 PM Gabe Black via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>> 1. Sounds good, I'll hopefully have some time to put together a CL in no
>> too long (weekend?).
>>
>>
>>
>> 2. I 5ries to figure out a way to do it without the template that wasn't
>> really gross a somewhat fragile and wasn't able to, but that would
>> definitely be preferable. I'll keep thinking about it, but the internet
>> didn't seem to have any ideas either. Unfortunately using constexpr won't
>> work like that Jason, although I wish it did and found a couple unadopted
>> (as far as I know) standards proposals to that effect.
>>
>>
>>
>> Yeah, that's what I found, too :).
>>
>>
>>
>>
>>
>> 3. Sounds good. Likely this weekend?
>>
>>
>>
>> Gabe
>>
>>
>>
>> On Thu, Sep 17, 2020, 1:15 PM Bobby Bruce via gem5-dev 
>> wrote:
>>
>> 1) Seems fine to me.
>>
>>
>>
>> 2) I remember looking into this and I agree with Jason, it involves
>> template magic which I'm not a huge fan of. I feel like in order to add
>> these compile time asserts we'd be sacrificing some

[gem5-dev] Re: A few quick thoughts

2020-09-18 Thread Jason Lowe-Power via gem5-dev
I don't like the following change

bits(val, first, last)

would now be

bits(val).

IMO, it's confusing to put function *parameters* as template arguments.

This would mean that when you use the bits() function, you'll have to think
about "are these constexpr that I'm using, and, if so, should I use bits()
or bits<>()?"

We can go through and manually change the current code, but for new code,
this will be yet another thing that we'd have to catch during code review.

Just my two cents. I won't block anything, I just think that readability is
more important than a little* performance.

*It depends on how much performance difference assert() vs static_assert()
is in this case.

Cheers,
Jason

On Fri, Sep 18, 2020 at 8:29 AM Gutierrez, Anthony <
anthony.gutier...@amd.com> wrote:

> [AMD Public Use]
>
>
>
> Hey, Jason perhaps you mentioned this somewhere but what is the reason for
> such a strong aversion to the template approach? It seems to solve the
> issue nicely with what seems to be a minor change in syntax. gem5 is C++,
> so we should allow users to write C++.
>
>
>
> Tony
>
>
>
> *From:* Jason Lowe-Power via gem5-dev 
> *Sent:* Friday, September 18, 2020 8:05 AM
> *To:* Gabe Black 
> *Cc:* gem5 Developer List ; Jason Lowe-Power <
> ja...@lowepower.com>
> *Subject:* [gem5-dev] Re: A few quick thoughts
>
>
>
> [CAUTION: External Email]
>
> There is another option to keep the function-like syntax, but get the
> constexpr via templates: A preprocessor macro:
>
>
>
> #define bits(val, first, last) bits(val)
>
>
>
> The major downside is that we can't overload preprocessor macros. We'd
> have to have two name bits_const() and bits(), which I also don't like.
>
>
>
> Personally, I strongly don't want to lose the function-like syntax for the
> bits function. I won't *block* the change, but I'll push back against the
> template syntax.
>
>
>
> Cheers,
>
> Jason
>
>
>
> On Fri, Sep 18, 2020 at 5:02 AM Gabe Black  wrote:
>
> I spent some more time digging into 2, and while I didn't find anything
> that directly stated that you aren't allowed to do that, without explicit
> support I think it flies in the face of how C++ templates, types, etc. work
> to the point where if you *did* find a way to do it, it would almost
> certainly be a bug or an oversight in the standard somewhere. So unless
> they do adopt one of those standards I saw proposed and we wait a good
> number of years for it to be implemented in all the compilers we support
> (one said it targeted C++23) I think templates, while slightly gross, are
> really the only way to make it work.
>
>
>
> Gabe
>
>
>
> On Thu, Sep 17, 2020 at 2:53 PM Jason Lowe-Power 
> wrote:
>
>
>
>
>
> On Thu, Sep 17, 2020 at 2:48 PM Gabe Black via gem5-dev 
> wrote:
>
> 1. Sounds good, I'll hopefully have some time to put together a CL in no
> too long (weekend?).
>
>
>
> 2. I 5ries to figure out a way to do it without the template that wasn't
> really gross a somewhat fragile and wasn't able to, but that would
> definitely be preferable. I'll keep thinking about it, but the internet
> didn't seem to have any ideas either. Unfortunately using constexpr won't
> work like that Jason, although I wish it did and found a couple unadopted
> (as far as I know) standards proposals to that effect.
>
>
>
> Yeah, that's what I found, too :).
>
>
>
>
>
> 3. Sounds good. Likely this weekend?
>
>
>
> Gabe
>
>
>
> On Thu, Sep 17, 2020, 1:15 PM Bobby Bruce via gem5-dev 
> wrote:
>
> 1) Seems fine to me.
>
>
>
> 2) I remember looking into this and I agree with Jason, it involves
> template magic which I'm not a huge fan of. I feel like in order to add
> these compile time asserts we'd be sacrificing some
> readability/ease-of-usability of bitfields.hh. This may just be a "me
> thing", but something about templates confuse me whenever I need to deal
> with them.
>
>
>
> 3) In truth, our minimum supported Clang version is 3.9 in practise (We
> even state on our website's building documentation that we support Clang
> 3.9 to 9: http://www.gem5.org/documentation/general_docs/building
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.gem5.org%2Fdocumentation%2Fgeneral_docs%2Fbuilding=02%7C01%7Canthony.gutierrez%40amd.com%7C8dda55bf862b42f3f16408d85be45700%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637360383571740119=6hkyKwsWGm%2BY67faMlI2NvDQR21oA6h0L2fDRekCD7o%3D=0>).
> I didn't realize we still have "3.1" hardcoded in the SConscript and would
> be happy for this to be bumped up to 3.9. Our compiler tests do not test
> with

[gem5-dev] Re: A few quick thoughts

2020-09-18 Thread Jason Lowe-Power via gem5-dev
There is another option to keep the function-like syntax, but get the
constexpr via templates: A preprocessor macro:

#define bits(val, first, last) bits(val)

The major downside is that we can't overload preprocessor macros. We'd have
to have two name bits_const() and bits(), which I also don't like.

Personally, I strongly don't want to lose the function-like syntax for the
bits function. I won't *block* the change, but I'll push back against the
template syntax.

Cheers,
Jason

On Fri, Sep 18, 2020 at 5:02 AM Gabe Black  wrote:

> I spent some more time digging into 2, and while I didn't find anything
> that directly stated that you aren't allowed to do that, without explicit
> support I think it flies in the face of how C++ templates, types, etc. work
> to the point where if you *did* find a way to do it, it would almost
> certainly be a bug or an oversight in the standard somewhere. So unless
> they do adopt one of those standards I saw proposed and we wait a good
> number of years for it to be implemented in all the compilers we support
> (one said it targeted C++23) I think templates, while slightly gross, are
> really the only way to make it work.
>
> Gabe
>
> On Thu, Sep 17, 2020 at 2:53 PM Jason Lowe-Power 
> wrote:
>
>>
>>
>> On Thu, Sep 17, 2020 at 2:48 PM Gabe Black via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> 1. Sounds good, I'll hopefully have some time to put together a CL in no
>>> too long (weekend?).
>>>
>>> 2. I 5ries to figure out a way to do it without the template that wasn't
>>> really gross a somewhat fragile and wasn't able to, but that would
>>> definitely be preferable. I'll keep thinking about it, but the internet
>>> didn't seem to have any ideas either. Unfortunately using constexpr won't
>>> work like that Jason, although I wish it did and found a couple unadopted
>>> (as far as I know) standards proposals to that effect.
>>>
>>
>> Yeah, that's what I found, too :).
>>
>>
>>>
>>> 3. Sounds good. Likely this weekend?
>>>
>>> Gabe
>>>
>>> On Thu, Sep 17, 2020, 1:15 PM Bobby Bruce via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
>>>> 1) Seems fine to me.
>>>>
>>>> 2) I remember looking into this and I agree with Jason, it involves
>>>> template magic which I'm not a huge fan of. I feel like in order to add
>>>> these compile time asserts we'd be sacrificing some
>>>> readability/ease-of-usability of bitfields.hh. This may just be a "me
>>>> thing", but something about templates confuse me whenever I need to deal
>>>> with them.
>>>>
>>>> 3) In truth, our minimum supported Clang version is 3.9 in practise (We
>>>> even state on our website's building documentation that we support Clang
>>>> 3.9 to 9: http://www.gem5.org/documentation/general_docs/building). I
>>>> didn't realize we still have "3.1" hardcoded in the SConscript and would be
>>>> happy for this to be bumped up to 3.9. Our compiler tests do not test with
>>>> versions of clang before 3.9, so, at present, we aren't doing much to help
>>>> those using versions older than 3.9. I'd love to bump up to c++14 also.
>>>> While I'm sure there are plenty of good reasons, I personally would like to
>>>> use C++14's deprecation attribute for if/when we start deprecating gem5 C++
>>>> APIs: https://en.cppreference.com/w/cpp/language/attributes/deprecated
>>>>
>>>
>> We already do use the deprecated attribute (see
>> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#55
>> ).
>>
>> We should be able to get rid of this:
>> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#93
>> And maybe this:
>> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#69
>>
>>
>>>
>>>> --
>>>> Dr. Bobby R. Bruce
>>>> Room 2235,
>>>> Kemper Hall, UC Davis
>>>> Davis,
>>>> CA, 95616
>>>>
>>>> web: https://www.bobbybruce.net
>>>>
>>>>
>>>> On Thu, Sep 17, 2020 at 8:25 AM Jason Lowe-Power via gem5-dev <
>>>> gem5-dev@gem5.org> wrote:
>>>>
>>>>> Hey Gabe,
>>>>>
>>>>> On Thu, Sep 17, 2020 at 4:46 AM Gabe Black via gem5-dev <
>>>>> gem5-dev@gem5.org> wrote:
>>>>>
>>>>>> 1. Use __builtin_expect() fo

[gem5-dev] Re: A few quick thoughts

2020-09-17 Thread Jason Lowe-Power via gem5-dev
On Thu, Sep 17, 2020 at 2:48 PM Gabe Black via gem5-dev 
wrote:

> 1. Sounds good, I'll hopefully have some time to put together a CL in no
> too long (weekend?).
>
> 2. I 5ries to figure out a way to do it without the template that wasn't
> really gross a somewhat fragile and wasn't able to, but that would
> definitely be preferable. I'll keep thinking about it, but the internet
> didn't seem to have any ideas either. Unfortunately using constexpr won't
> work like that Jason, although I wish it did and found a couple unadopted
> (as far as I know) standards proposals to that effect.
>

Yeah, that's what I found, too :).


>
> 3. Sounds good. Likely this weekend?
>
> Gabe
>
> On Thu, Sep 17, 2020, 1:15 PM Bobby Bruce via gem5-dev 
> wrote:
>
>> 1) Seems fine to me.
>>
>> 2) I remember looking into this and I agree with Jason, it involves
>> template magic which I'm not a huge fan of. I feel like in order to add
>> these compile time asserts we'd be sacrificing some
>> readability/ease-of-usability of bitfields.hh. This may just be a "me
>> thing", but something about templates confuse me whenever I need to deal
>> with them.
>>
>> 3) In truth, our minimum supported Clang version is 3.9 in practise (We
>> even state on our website's building documentation that we support Clang
>> 3.9 to 9: http://www.gem5.org/documentation/general_docs/building). I
>> didn't realize we still have "3.1" hardcoded in the SConscript and would be
>> happy for this to be bumped up to 3.9. Our compiler tests do not test with
>> versions of clang before 3.9, so, at present, we aren't doing much to help
>> those using versions older than 3.9. I'd love to bump up to c++14 also.
>> While I'm sure there are plenty of good reasons, I personally would like to
>> use C++14's deprecation attribute for if/when we start deprecating gem5 C++
>> APIs: https://en.cppreference.com/w/cpp/language/attributes/deprecated
>>
>
We already do use the deprecated attribute (see
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#55
).

We should be able to get rid of this:
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#93
And maybe this:
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#69


>
>> --
>> Dr. Bobby R. Bruce
>> Room 2235,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Thu, Sep 17, 2020 at 8:25 AM Jason Lowe-Power via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Hey Gabe,
>>>
>>> On Thu, Sep 17, 2020 at 4:46 AM Gabe Black via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
>>>> 1. Use __builtin_expect() for panic, fatal, etc. Preexisting library
>>>> functions like assert probably already have this, but our versions don't
>>>> and have similar behavior patterns. This should improve performance.
>>>>
>>>
>>> Seems like a good idea. It shouldn't hurt anything.
>>>
>>>
>>>>
>>>> 2. Create template versions of the bits, etc functions in bitfields.hh
>>>> which use static_assert to verify that the bounds are in the right order.
>>>> Unless the bounds change at runtime (probably very uncommon in practice)
>>>>
>>>
>>> I like the idea of static asserts, but don't like the change in the
>>> syntax away from a simple function call.
>>>
>>> Would it be possible to instead use a constexpr function parameter?
>>>
>>> What we would really like is
>>>
>>> template 
>>> inline
>>> T
>>> bits(T val, *constexpr *int first, *constexpr *int last)
>>> {
>>> int nbits = first - last + 1;
>>> *static*_assert((first - last) >= 0);
>>> return (val >> last) & mask(nbits);
>>> }
>>>
>>> However, after spending 15-30 minutes researching it doesn't seem like
>>> this is easy to do today. Gabe... you seem to know much more template
>>> magic. Maybe there's a way?
>>>
>>>
>>>> bits(foo, 2, 1) => bits<2, 1>(foo)
>>>>
>>>> Then we get the free compile time checking of bounds most of the time
>>>> without big overhead otherwise. Something like this:
>>>>
>>>> template 
>>>> constexpr T
>>>> bits(T val)
>>>> {
>>>> static_assert(first > last);
>>>> return bits(val, first, l

[gem5-dev] Re: A few quick thoughts

2020-09-17 Thread Jason Lowe-Power via gem5-dev
Hey Gabe,

On Thu, Sep 17, 2020 at 4:46 AM Gabe Black via gem5-dev 
wrote:

> 1. Use __builtin_expect() for panic, fatal, etc. Preexisting library
> functions like assert probably already have this, but our versions don't
> and have similar behavior patterns. This should improve performance.
>

Seems like a good idea. It shouldn't hurt anything.


>
> 2. Create template versions of the bits, etc functions in bitfields.hh
> which use static_assert to verify that the bounds are in the right order.
> Unless the bounds change at runtime (probably very uncommon in practice)
>

I like the idea of static asserts, but don't like the change in the syntax
away from a simple function call.

Would it be possible to instead use a constexpr function parameter?

What we would really like is

template 
inline
T
bits(T val, *constexpr *int first, *constexpr *int last)
{
int nbits = first - last + 1;
*static*_assert((first - last) >= 0);
return (val >> last) & mask(nbits);
}

However, after spending 15-30 minutes researching it doesn't seem like this
is easy to do today. Gabe... you seem to know much more template magic.
Maybe there's a way?


> bits(foo, 2, 1) => bits<2, 1>(foo)
>
> Then we get the free compile time checking of bounds most of the time
> without big overhead otherwise. Something like this:
>
> template 
> constexpr T
> bits(T val)
> {
> static_assert(first > last);
> return bits(val, first, last);
> }
>
> 3. Our new min gcc is version 5 which supports c++14. Our min clang is 3.1
> which does not, but 3.4 does. Do we want to bump the min clang version up
> and move from C++11 to C++14? C++17 has more compelling features, but C++14
> fixed some annoyances, at least according to wikipedia:
>
> https://en.wikipedia.org/wiki/C%2B%2B14
>

Yeah, I don't see any reason not to bump our minimum clang version. If we
do go up to c++14, we can simplify compiler.hh significantly.

Thanks for starting this conversation!

Cheers,
Jason


>
>
> Gabe
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: misc: Add Matt Poremba as GPU maintainer

2020-09-16 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34655 )


Change subject: misc: Add Matt Poremba as GPU maintainer
..

misc: Add Matt Poremba as GPU maintainer

Change-Id: I90494955b6db628695ef8a42111977decba27618
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34655
Maintainer: Jason Lowe-Power 
Maintainer: Matthew Poremba 
Reviewed-by: Matt Sinclair 
Reviewed-by: Matthew Poremba 
Tested-by: kokoro 
---
M MAINTAINERS
1 file changed, 1 insertion(+), 0 deletions(-)

Approvals:
  Matthew Poremba: Looks good to me, approved; Looks good to me, approved
  Matt Sinclair: Looks good to me, approved
  Jason Lowe-Power: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/MAINTAINERS b/MAINTAINERS
index 92c4ce8..d248ec1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -68,6 +68,7 @@

 gpu-compute:
   Tony Gutierrez 
+  Matt Poremba 

 learning-gem5: The code and configs for the Learning gem5 book (see
learning.gem5.com)

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34655
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I90494955b6db628695ef8a42111977decba27618
Gerrit-Change-Number: 34655
Gerrit-PatchSet: 2
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Matt Sinclair 
Gerrit-Reviewer: Matthew Poremba 
Gerrit-Reviewer: kokoro 
Gerrit-CC: Alexandru Duțu 
Gerrit-CC: Anthony Gutierrez 
Gerrit-CC: Bradford Beckmann 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[release-staging-v20.1.0.0]: configs: Add special case in MemConfig

2020-09-16 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34595 )


Change subject: configs: Add special case in MemConfig
..

configs: Add special case in MemConfig

SimpleMemory doesn't implement a full MemCtrl interface. Thus, like the
NVM and HMC memories, we need to add a special case to MemConfig.py. The
--mem-type command line option now works for SimpleMemory and all of the
DRAM interfaces (it does not work for the NVM interfaces, though).

Issue-on: https://gem5.atlassian.net/browse/GEM5-777

Change-Id: I6d60649215be324bdd2a104b1976752f936c960e
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34595
Reviewed-by: Daniel Carvalho 
Reviewed-by: Nikos Nikoleris 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M configs/common/MemConfig.py
1 file changed, 5 insertions(+), 1 deletion(-)

Approvals:
  Nikos Nikoleris: Looks good to me, approved
  Daniel Carvalho: Looks good to me, approved
  Jason Lowe-Power: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/configs/common/MemConfig.py b/configs/common/MemConfig.py
index 941b381..8221f85 100644
--- a/configs/common/MemConfig.py
+++ b/configs/common/MemConfig.py
@@ -227,11 +227,15 @@
 mem_ctrl = m5.objects.MemCtrl(min_writes_per_switch =  
8,
  static_backend_latency  
= '4ns',
  static_frontend_latency  
= '4ns')

+elif opt_mem_type == "SimpleMemory":
+mem_ctrl = m5.objects.SimpleMemory()
 else:
 mem_ctrl = m5.objects.MemCtrl()

 # Hookup the controller to the interface and add to the  
list

-mem_ctrl.dram = dram_intf
+if opt_mem_type != "SimpleMemory":
+mem_ctrl.dram = dram_intf
+
 mem_ctrls.append(mem_ctrl)

 elif opt_nvm_type and (not opt_mem_type or range_iter % 2 ==  
0):


--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34595
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: release-staging-v20.1.0.0
Gerrit-Change-Id: I6d60649215be324bdd2a104b1976752f936c960e
Gerrit-Change-Number: 34595
Gerrit-PatchSet: 4
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-Reviewer: kokoro 
Gerrit-CC: Ciro Santilli 
Gerrit-CC: Tiago Mück 
Gerrit-CC: Wendy Elsasser 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: misc: Add Matt Poremba as GPU maintainer

2020-09-16 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34655 )



Change subject: misc: Add Matt Poremba as GPU maintainer
..

misc: Add Matt Poremba as GPU maintainer

Change-Id: I90494955b6db628695ef8a42111977decba27618
Signed-off-by: Jason Lowe-Power 
---
M MAINTAINERS
1 file changed, 1 insertion(+), 0 deletions(-)



diff --git a/MAINTAINERS b/MAINTAINERS
index 92c4ce8..d248ec1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -68,6 +68,7 @@

 gpu-compute:
   Tony Gutierrez 
+  Matt Poremba 

 learning-gem5: The code and configs for the Learning gem5 book (see
learning.gem5.com)

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34655
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I90494955b6db628695ef8a42111977decba27618
Gerrit-Change-Number: 34655
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[release-staging-v20.1.0.0]: configs: Add special case in MemConfig

2020-09-15 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34595 )



Change subject: configs: Add special case in MemConfig
..

configs: Add special case in MemConfig

SimpleMemory doesn't implement a full MemCtrl interface. Thus, like the
NVM and HMC memories, we need to add a special case to MemConfig.py. The
--mem-type command line option now works for SimpleMemory and all of the
DRAM interfaces (it does not work for the NVM interfaces, though).

Change-Id: I6d60649215be324bdd2a104b1976752f936c960e
Signed-off-by: Jason Lowe-Power 
---
M configs/common/MemConfig.py
1 file changed, 8 insertions(+), 1 deletion(-)



diff --git a/configs/common/MemConfig.py b/configs/common/MemConfig.py
index 941b381..224ddc7 100644
--- a/configs/common/MemConfig.py
+++ b/configs/common/MemConfig.py
@@ -177,6 +177,9 @@
 if opt_nvm_type:
 n_intf = ObjectList.mem_list.get(opt_nvm_type)

+print(opt_mem_type)
+ObjectList.mem_list.print()
+
 nvm_intfs = []
 mem_ctrls = []

@@ -227,11 +230,15 @@
 mem_ctrl = m5.objects.MemCtrl(min_writes_per_switch =  
8,
  static_backend_latency  
= '4ns',
  static_frontend_latency  
= '4ns')

+elif opt_mem_type == "SimpleMemory":
+mem_ctrl = m5.objects.SimpleMemory()
 else:
 mem_ctrl = m5.objects.MemCtrl()

 # Hookup the controller to the interface and add to the  
list

-mem_ctrl.dram = dram_intf
+if opt_mem_type != "SimpleMemory":
+mem_ctrl.dram = dram_intf
+
 mem_ctrls.append(mem_ctrl)

 elif opt_nvm_type and (not opt_mem_type or range_iter % 2 ==  
0):


--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34595
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: release-staging-v20.1.0.0
Gerrit-Change-Id: I6d60649215be324bdd2a104b1976752f936c960e
Gerrit-Change-Number: 34595
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: MessageBuffer double counting delay between arrival and dequeue ticks?

2020-09-15 Thread Jason Lowe-Power via gem5-dev
That's fine with me! I love removing code!

Cheers,
Jason

On Tue, Sep 15, 2020 at 1:08 PM Gambord, Ryan via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi Srikant,
>
> Thank you for looking into it. I noticed the miscalculation while working
> on something unrelated, and wasn't sure what those values were used for (I
> don't need them). If it's not being used, then my proposed change would be
> to remove it from the codebase as legacy bloat. Does anyone have a problem
> with that?
>
> Ryan Gambord
> 
>
>
>
> On Mon, Sep 14, 2020 at 11:44 PM Srikant Bharadwaj via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> [This email originated from outside of OSU. Use caution with links and
>> attachments.]
>> Hi Ryan,
>> You are right. If the message goes to the next message buffer, delay is
>> added again.
>> However, as far as I know we are not using the delayed ticks for
>> calculating anything anymore. The earlier use case was to calculate the
>> stall time within MessageBuffer, but we use the getTime to do that now.
>> Is there any specific use case you are trying to fix here?
>>
>> In any case, it would be great if you can post a fix.
>>
>> Thanks,
>> Srikant
>>
>> On Mon, Sep 14, 2020 at 10:48 AM Jason Lowe-Power via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Hey Ryan,
>>>
>>> Sorry for the slow reply. Yes, it looks like delayedTicks may be double
>>> counting in some cases. I wonder if a little microbenchmark might be able
>>> to confirm more clearly? Assuming it is being double counted, we'd welcome
>>> a fix!
>>>
>>> @Bharadwaj, Srikant  might be able to help
>>> as well. Srikant, did you see anything like this with Garnet 3.0?
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Fri, Sep 11, 2020 at 2:35 AM Gambord, Ryan via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
>>>> bump
>>>>
>>>> On Tue, Sep 1, 2020, 12:21 Gambord, Ryan 
>>>> wrote:
>>>>
>>>>> I noticed that MessageBuffer calls UpdateDelayedTicks in both enqueue
>>>>> and dequeue methods. Since dequeue does not setLastEnqueueTime of the
>>>>> message to the time it was dequeued at, when enqueue calls
>>>>> UpdateDelayedTicks, doesn't it add the dequeue delay to the delayed ticks 
>>>>> a
>>>>> second time?
>>>>>
>>>>> Below is a table of the timeline. X and Y are the starting values for
>>>>> LastEnqueueTime and DelayedTicks when the first message buffer receives 
>>>>> the
>>>>> message. When the message is dequeued from MB1, DelayedTicks gets C-B 
>>>>> added
>>>>> to it. When it is then enqueued in MB2, it gets D-B added, which double
>>>>> counts the C-B interval.
>>>>>
>>>>> curTime() FunctionCall m_LastEnqueueTime m_DelayedTicks
>>>>>
>>>>>
>>>>> X Y
>>>>> A enqueue() B = A + Delta Y + (A-X)
>>>>> B wakeup() " "
>>>>> C dequeue() " Y + (A-X) + (C-B)
>>>>> D enqueue() E = D + Delta
>>>>> Y + (A-X) + (C-B) + (D-B) = Y + (A-X) + (C-B) + (D-C) + (C-B)
>>>>>
>>>>>
>>>>> Ryan Gambord
>>>>> 
>>>>>
>>>>> ___
>>>> gem5-dev mailing list -- gem5-dev@gem5.org
>>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>>> ___
>>> gem5-dev mailing list -- gem5-dev@gem5.org
>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[release-staging-v20.1.0.0]: mem-ruby: Update port names in Ruby

2020-09-14 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34417 )


Change subject: mem-ruby: Update port names in Ruby
..

mem-ruby: Update port names in Ruby

After the terminology update commit there were still many confusing
names in the Ruby ports. This changeset is a proposal for updating these
names.

For an example use case, see the following resources changeset.
https://gem5-review.googlesource.com/c/public/gem5-resources/+/34416

Change-Id: I01d4f24a70b300e39438ee147dfab7a8d674d5c7
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34417
Reviewed-by: Ayaz Akram 
Reviewed-by: Bobby R. Bruce 
Maintainer: Bobby R. Bruce 
Tested-by: kokoro 
---
M src/mem/ruby/slicc_interface/Controller.py
M src/mem/ruby/system/RubyPort.cc
M src/mem/ruby/system/Sequencer.py
3 files changed, 23 insertions(+), 12 deletions(-)

Approvals:
  Ayaz Akram: Looks good to me, but someone else must approve
  Bobby R. Bruce: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/mem/ruby/slicc_interface/Controller.py  
b/src/mem/ruby/slicc_interface/Controller.py

index 2c6c655..1f9c0db 100644
--- a/src/mem/ruby/slicc_interface/Controller.py
+++ b/src/mem/ruby/slicc_interface/Controller.py
@@ -66,5 +66,8 @@
 Param.Cycles(1, "Default latency for requests added to the " \
 "mandatory queue on top-level controllers")

-memory = RequestPort("Port for attaching a memory controller")
+memory_out_port = RequestPort("Port for attaching a memory controller")
+memory = DeprecatedParam(memory_out_port, "The request port for Ruby "
+"memory output to the main memory is now called `memory_out_port`")
+
 system = Param.System(Parent.any, "system object parameter")
diff --git a/src/mem/ruby/system/RubyPort.cc  
b/src/mem/ruby/system/RubyPort.cc

index 4fc41c9..fc011cc 100644
--- a/src/mem/ruby/system/RubyPort.cc
+++ b/src/mem/ruby/system/RubyPort.cc
@@ -61,13 +61,13 @@
   memResponsePort(csprintf("%s-mem-response-port", name()), this,
p->ruby_system->getAccessBackingStore(), -1,
p->no_retry_on_stall),
-  gotAddrRanges(p->port_request_ports_connection_count),
+  gotAddrRanges(p->port_interrupt_out_port_connection_count),
   m_isCPUSequencer(p->is_cpu_sequencer)
 {
 assert(m_version != -1);

 // create the response ports based on the number of connected ports
-for (size_t i = 0; i < p->port_response_ports_connection_count; ++i) {
+for (size_t i = 0; i < p->port_in_ports_connection_count; ++i) {
 response_ports.push_back(new MemResponsePort(csprintf
 ("%s.response_ports%d", name(), i), this,
 p->ruby_system->getAccessBackingStore(),
@@ -75,7 +75,7 @@
 }

 // create the request ports based on the number of connected ports
-for (size_t i = 0; i < p->port_request_ports_connection_count; ++i) {
+for (size_t i = 0; i < p->port_interrupt_out_port_connection_count;  
++i) {

 request_ports.push_back(new PioRequestPort(csprintf(
 "%s.request_ports%d", name(), i), this));
 }
@@ -99,7 +99,7 @@
 return memResponsePort;
 } else if (if_name == "pio_response_port") {
 return pioResponsePort;
-} else if (if_name == "request_ports") {
+} else if (if_name == "interrupt_out_port") {
 // used by the x86 CPUs to connect the interrupt PIO and interrupt
 // response port
 if (idx >= static_cast(request_ports.size())) {
@@ -107,7 +107,7 @@
 }

 return *request_ports[idx];
-} else if (if_name == "response_ports") {
+} else if (if_name == "in_ports") {
 // used by the CPUs to connect the caches to the interconnect, and
 // for the x86 case also the interrupt request port
 if (idx >= static_cast(response_ports.size())) {
diff --git a/src/mem/ruby/system/Sequencer.py  
b/src/mem/ruby/system/Sequencer.py

index 6869fc2..0a28d36 100644
--- a/src/mem/ruby/system/Sequencer.py
+++ b/src/mem/ruby/system/Sequencer.py
@@ -35,18 +35,26 @@
cxx_header = "mem/ruby/system/RubyPort.hh"
version = Param.Int(0, "")

-   response_ports = VectorResponsePort("CPU response port")
-   slave = DeprecatedParam(response_ports,
-'`slave` is now called `response_ports`')
-   request_ports = VectorRequestPort("CPU request port")
-   master= DeprecatedParam(request_ports,
-'`master` is now called `request_ports`')
+   in_ports = VectorResponsePort("CPU side of this Ruby

[gem5-dev] Change in gem5/gem5[release-staging-v20.1.0.0]: tests: Remove MIPS from Learning gem5 tests

2020-09-14 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34415 )


Change subject: tests: Remove MIPS from Learning gem5 tests
..

tests: Remove MIPS from Learning gem5 tests

Change-Id: Iffd9f5da188cac26ac75a8109886c36789956959
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34415
Reviewed-by: mike upton 
Reviewed-by: Bobby R. Bruce 
Maintainer: Bobby R. Bruce 
Tested-by: kokoro 
---
M tests/gem5/learning_gem5/part1_test.py
1 file changed, 0 insertions(+), 21 deletions(-)

Approvals:
  Bobby R. Bruce: Looks good to me, approved; Looks good to me, approved
  mike upton: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/tests/gem5/learning_gem5/part1_test.py  
b/tests/gem5/learning_gem5/part1_test.py

index b57ba17..f8363ac 100644
--- a/tests/gem5/learning_gem5/part1_test.py
+++ b/tests/gem5/learning_gem5/part1_test.py
@@ -38,16 +38,6 @@
 valid_isas=('X86', 'RISCV', 'ARM'),
 )

-# The "long" simple tests.
-gem5_verify_config(
-name='simple_test',
-verifiers = (),
-config=joinpath(config_path, 'simple.py'),
-config_args = [],
-length = constants.long_tag,
-valid_isas=('MIPS',),
-)
-
 # The "quick" two level tests.
 gem5_verify_config(
 name='two_level_test',
@@ -57,14 +47,3 @@
 length = constants.quick_tag,
 valid_isas=('X86', 'RISCV', 'ARM'),
 )
-
-# The "long" two level tests.
-gem5_verify_config(
-name='two_level_test',
-verifiers = (),
-config=joinpath(config_path, 'two_level.py'),
-config_args = [],
-length = constants.long_tag,
-valid_isas=('MIPS',),
-)
-

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34415
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: release-staging-v20.1.0.0
Gerrit-Change-Id: Iffd9f5da188cac26ac75a8109886c36789956959
Gerrit-Change-Number: 34415
Gerrit-PatchSet: 2
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: kokoro 
Gerrit-Reviewer: mike upton 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[release-staging-v20.1.0.0]: dev: Fix port name in x86 device

2020-09-14 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34435 )


Change subject: dev: Fix port name in x86 device
..

dev: Fix port name in x86 device

Change-Id: I7704109287b9a1a09e51da3c62c29720631ce87e
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34435
Reviewed-by: Bobby R. Bruce 
Maintainer: Bobby R. Bruce 
Tested-by: kokoro 
---
A src/cpu/tmp.ipynb
M src/dev/x86/i82094aa.cc
2 files changed, 1 insertion(+), 1 deletion(-)

Approvals:
  Bobby R. Bruce: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/tmp.ipynb b/src/cpu/tmp.ipynb
new file mode 100644
index 000..e69de29
--- /dev/null
+++ b/src/cpu/tmp.ipynb
diff --git a/src/dev/x86/i82094aa.cc b/src/dev/x86/i82094aa.cc
index c7817dc..bb28a8a 100644
--- a/src/dev/x86/i82094aa.cc
+++ b/src/dev/x86/i82094aa.cc
@@ -79,7 +79,7 @@
 Port &
 X86ISA::I82094AA::getPort(const std::string _name, PortID idx)
 {
-if (if_name == "int_request")
+if (if_name == "int_requestor")
 return intRequestPort;
 if (if_name == "inputs")
 return *inputs.at(idx);

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34435
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: release-staging-v20.1.0.0
Gerrit-Change-Id: I7704109287b9a1a09e51da3c62c29720631ce87e
Gerrit-Change-Number: 34435
Gerrit-PatchSet: 2
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: kokoro 
Gerrit-CC: mike upton 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: MessageBuffer double counting delay between arrival and dequeue ticks?

2020-09-14 Thread Jason Lowe-Power via gem5-dev
Hey Ryan,

Sorry for the slow reply. Yes, it looks like delayedTicks may be double
counting in some cases. I wonder if a little microbenchmark might be able
to confirm more clearly? Assuming it is being double counted, we'd welcome
a fix!

@Bharadwaj, Srikant  might be able to help as
well. Srikant, did you see anything like this with Garnet 3.0?

Cheers,
Jason

On Fri, Sep 11, 2020 at 2:35 AM Gambord, Ryan via gem5-dev <
gem5-dev@gem5.org> wrote:

> bump
>
> On Tue, Sep 1, 2020, 12:21 Gambord, Ryan  wrote:
>
>> I noticed that MessageBuffer calls UpdateDelayedTicks in both enqueue and
>> dequeue methods. Since dequeue does not setLastEnqueueTime of the message
>> to the time it was dequeued at, when enqueue calls UpdateDelayedTicks,
>> doesn't it add the dequeue delay to the delayed ticks a second time?
>>
>> Below is a table of the timeline. X and Y are the starting values for
>> LastEnqueueTime and DelayedTicks when the first message buffer receives the
>> message. When the message is dequeued from MB1, DelayedTicks gets C-B added
>> to it. When it is then enqueued in MB2, it gets D-B added, which double
>> counts the C-B interval.
>>
>> curTime() FunctionCall m_LastEnqueueTime m_DelayedTicks
>>
>>
>> X Y
>> A enqueue() B = A + Delta Y + (A-X)
>> B wakeup() " "
>> C dequeue() " Y + (A-X) + (C-B)
>> D enqueue() E = D + Delta
>> Y + (A-X) + (C-B) + (D-B) = Y + (A-X) + (C-B) + (D-C) + (C-B)
>>
>>
>> Ryan Gambord
>> 
>>
>> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[release-staging-v20.1.0.0]: dev: Fix port name in x86 device

2020-09-11 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34435 )



Change subject: dev: Fix port name in x86 device
..

dev: Fix port name in x86 device

Change-Id: I7704109287b9a1a09e51da3c62c29720631ce87e
Signed-off-by: Jason Lowe-Power 
---
A src/cpu/tmp.ipynb
M src/dev/x86/i82094aa.cc
2 files changed, 1 insertion(+), 1 deletion(-)



diff --git a/src/cpu/tmp.ipynb b/src/cpu/tmp.ipynb
new file mode 100644
index 000..e69de29
--- /dev/null
+++ b/src/cpu/tmp.ipynb
diff --git a/src/dev/x86/i82094aa.cc b/src/dev/x86/i82094aa.cc
index c7817dc..bb28a8a 100644
--- a/src/dev/x86/i82094aa.cc
+++ b/src/dev/x86/i82094aa.cc
@@ -79,7 +79,7 @@
 Port &
 X86ISA::I82094AA::getPort(const std::string _name, PortID idx)
 {
-if (if_name == "int_request")
+if (if_name == "int_requestor")
 return intRequestPort;
 if (if_name == "inputs")
 return *inputs.at(idx);

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34435
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: release-staging-v20.1.0.0
Gerrit-Change-Id: I7704109287b9a1a09e51da3c62c29720631ce87e
Gerrit-Change-Number: 34435
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: Nightly #65

2020-09-11 Thread Jason Lowe-Power via gem5-dev
This was Wendy's DRAM patches that caused this error. Specifically
https://gem5-review.googlesource.com/c/public/gem5/+/31654 and
https://gem5-review.googlesource.com/c/public/gem5/+/28968.

This is an issue similar to above, how we've assumed there was a consistent
interface, but now there's not. The current code assumes that you will
always use a DRAM-based controller. It will have to be updated to work with
SimpleMemory.

I don't know the best solution off the top of my head. We'll have to work
this out, though.

Cheers,
Jason


On Fri, Sep 11, 2020 at 12:32 PM Timothy Hayes 
wrote:

> Hi Jason,
>
>
>
> Thanks for raising and identifying these issues. I rebased my repositories
> onto `develop` today and see that my Ruby experiments no longer work.
>
>
>
> command line: ./gem5/build/ARM_MESI_Three_Level_HTM/gem5.opt
> ./gem5/configs/example/fs.py --ruby --num-cpus=1 --mem-type=SimpleMemory
> --mem-size=4GB --cpu-type=TimingSimpleCPU
> --kernel=vmlinux.vexpress_gem5_v1_64 --machine-type=VExpress_GEM5_V1
> --disk-image=snip.img --script=/snip/start.sh
>
>
>
> warn: You are trying to use Ruby on ARM, which is not working properly yet.
>
> Traceback (most recent call last):
>
>   File "", line 1, in 
>
>   File "build/ARM_MESI_Three_Level_HTM/python/m5/main.py", line 457, in
> main
>
>   File "./gem5/configs/example/fs.py", line 339, in 
>
> test_sys = build_test_system(np)
>
>   File "./gem5/configs/example/fs.py", line 157, in build_test_system
>
> test_sys._dma_ports, bootmem)
>
>   File "/snip/gem5/configs/ruby/Ruby.py", line 224, in create_system
>
> setup_memory_controllers(system, ruby, dir_cntrls, options)
>
>   File "/snip/gem5/configs/ruby/Ruby.py", line 136, in
> setup_memory_controllers
>
> mem_ctrl = m5.objects.MemCtrl(dram = dram_intf)
>
>   File "build/ARM_MESI_Three_Level_HTM/python/m5/SimObject.py", line 1251,
> in __init__
>
>   File "build/ARM_MESI_Three_Level_HTM/python/m5/SimObject.py", line 1337,
> in __setattr__
>
>   File "build/ARM_MESI_Three_Level_HTM/python/m5/params.py", line 215, in
> convert
>
> TypeError: __init__() takes exactly 1 argument (2 given)
>
> Error setting param MemCtrl.dram to 
>
>
>
> Do you know which commits are responsible for this?
>
>
>
> Thanks in advance
>
>
>
> --
>
> Timothy Hayes
>
> Senior Research Engineer
>
> Arm Research
>
> Phone: +44-1223 645690
>
> timothy.ha...@arm.com
>
>
>
> *From: *Jason Lowe-Power via gem5-dev 
> *Reply to: *gem5 Developer List 
> *Date: *Friday, 11 September 2020 at 18:10
> *To: *gem5 Developer List 
> *Cc: *"jenkins-no-re...@gem5.org" , Jason
> Lowe-Power 
> *Subject: *[gem5-dev] Re: Build failed in Jenkins: Nightly #65
>
>
>
> It looks like there are two (or more) problems here:
>
>
>
> 1. Something wrong with MIPS (we'll look into this ASAP, probably on
> Monday)
>
> 2. ARM FS + Ruby
>
>
>
> I'd like to discuss the latter for a moment.
>
>
>
> Here's the backtrace:
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "build/ARM/python/m5/main.py", line 457, in main
>   File "/home/jlp/Code/gem5/gem5/tests/gem5/fs/linux/arm/run.py", line 68,
> in 
> exec(compile(open(config).read(), config, 'exec'))
>   File
> "/home/jlp/Code/gem5/gem5/tests/gem5/configs/realview-simple-timing-ruby.py",
> line 44, in 
> use_ruby=True).create_root()
>   File "/home/jlp/Code/gem5/gem5/tests/gem5/configs/base_config.py", line
> 299, in create_root
> system = self.create_system()
>   File "/home/jlp/Code/gem5/gem5/tests/gem5/configs/arm_generic.py", line
> 114, in create_system
> self.init_system(system)
>   File "/home/jlp/Code/gem5/gem5/tests/gem5/configs/base_config.py", line
> 271, in init_system
> super(BaseFSSystem, self).init_system(system)
>   File "/home/jlp/Code/gem5/gem5/tests/gem5/configs/base_config.py", line
> 180, in init_system
> cpu.connectCachedPorts(system.ruby._cpu_ports[i])
>   File "build/ARM/cpu/BaseCPU.py", line 197, in connectCachedPorts
>   File "", line 1, in 
>   File "build/ARM/python/m5/SimObject.py", line 1313, in __getattr__
> AttributeError: object 'RubySequencer' has no attribute 'cpu_side_ports'
>   (C++ object is not yet constructed, so wrapped C++ methods are
> unavailable.)
>
>
>
> The problem here is that we made an assumption in "base_config.py" that
> the interface to a Ruby sequencer and a xbar is the same. I do

[gem5-dev] Change in gem5/gem5[release-staging-v20.1.0.0]: tests: Remove MIPS from Learning gem5 tests

2020-09-11 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34415 )



Change subject: tests: Remove MIPS from Learning gem5 tests
..

tests: Remove MIPS from Learning gem5 tests

Change-Id: Iffd9f5da188cac26ac75a8109886c36789956959
Signed-off-by: Jason Lowe-Power 
---
M tests/gem5/learning_gem5/part1_test.py
1 file changed, 0 insertions(+), 21 deletions(-)



diff --git a/tests/gem5/learning_gem5/part1_test.py  
b/tests/gem5/learning_gem5/part1_test.py

index b57ba17..f8363ac 100644
--- a/tests/gem5/learning_gem5/part1_test.py
+++ b/tests/gem5/learning_gem5/part1_test.py
@@ -38,16 +38,6 @@
 valid_isas=('X86', 'RISCV', 'ARM'),
 )

-# The "long" simple tests.
-gem5_verify_config(
-name='simple_test',
-verifiers = (),
-config=joinpath(config_path, 'simple.py'),
-config_args = [],
-length = constants.long_tag,
-valid_isas=('MIPS',),
-)
-
 # The "quick" two level tests.
 gem5_verify_config(
 name='two_level_test',
@@ -57,14 +47,3 @@
 length = constants.quick_tag,
 valid_isas=('X86', 'RISCV', 'ARM'),
 )
-
-# The "long" two level tests.
-gem5_verify_config(
-name='two_level_test',
-verifiers = (),
-config=joinpath(config_path, 'two_level.py'),
-config_args = [],
-length = constants.long_tag,
-valid_isas=('MIPS',),
-)
-

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34415
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: release-staging-v20.1.0.0
Gerrit-Change-Id: Iffd9f5da188cac26ac75a8109886c36789956959
Gerrit-Change-Number: 34415
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: Nightly #65

2020-09-11 Thread Jason Lowe-Power via gem5-dev
(I think this message might have bounced. If not, sorry for the duplication)

It looks like there are two (or more) problems here:

1. Something wrong with MIPS (we'll look into this ASAP, probably on Monday)
2. ARM FS + Ruby

I'd like to discuss the latter for a moment.

Here's the backtrace:
Traceback (most recent call last):
  File "", line 1, in 
  File "build/ARM/python/m5/main.py", line 457, in main
  File "/home/jlp/Code/gem5/gem5/tests/gem5/fs/linux/arm/run.py", line 68,
in 
exec(compile(open(config).read(), config, 'exec'))
  File
"/home/jlp/Code/gem5/gem5/tests/gem5/configs/realview-simple-timing-ruby.py",
line 44, in 
use_ruby=True).create_root()
  File "/home/jlp/Code/gem5/gem5/tests/gem5/configs/base_config.py", line
299, in create_root
system = self.create_system()
  File "/home/jlp/Code/gem5/gem5/tests/gem5/configs/arm_generic.py", line
114, in create_system
self.init_system(system)
  File "/home/jlp/Code/gem5/gem5/tests/gem5/configs/base_config.py", line
271, in init_system
super(BaseFSSystem, self).init_system(system)
  File "/home/jlp/Code/gem5/gem5/tests/gem5/configs/base_config.py", line
180, in init_system
cpu.connectCachedPorts(system.ruby._cpu_ports[i])
  File "build/ARM/cpu/BaseCPU.py", line 197, in connectCachedPorts
  File "", line 1, in 
  File "build/ARM/python/m5/SimObject.py", line 1313, in __getattr__
AttributeError: object 'RubySequencer' has no attribute 'cpu_side_ports'
  (C++ object is not yet constructed, so wrapped C++ methods are
unavailable.)

The problem here is that we made an assumption in "base_config.py" that the
interface to a Ruby sequencer and a xbar is the same. I don't think this
makes sense. The xbar has CPU-side and memory-side ports. A Ruby sequencer
should only have an incoming port. (Currently, after the terminology
change, the name is "response_ports" which is probably not the right name.)

So, I have a couple of questions:

1. What is the "right" names for the ports on the sequencer? Right now, we
have 5!! ports on each sequencer. This doesn't seem necessary.

   response_ports = VectorResponsePort("CPU response port") (was "slave")
   request_ports = VectorRequestPort("CPU request port") (was "master")
   pio_request_port = RequestPort("Ruby pio request port") (was
"pio_master_port")
   mem_request_port = RequestPort("Ruby mem request port") (was
"mem_master_port")
   pio_response_port = ResponsePort("Ruby pio response port") (was
"pio_slave_port")

To be honest, I would consider myself a ruby expert, but both the old names
and the new names are inscrutable to me. If anyone has any suggestions, I'm
happy to hear them.

2. Do we really want the Ruby sequencer to have the same interface as the
XBar? If so, we should create a base class so they can both implement that
interface. The current code in BaseCPU.py has used python's duck-typing too
heavily, and this is really biting us right now.

If anyone has ideas on how to improve the "connectPort" interface on the
CPU, please let me know. I think that it's probably better to do this *in
the cache model* as the CPU is the one with the consistent interface
(icache_port and dcache_port are defined in BaseCPU.py). I'm open to
suggestions.

Finally, I'll try to find the time myself to look into the problem with
Ruby, but I can't promise anything will be done quickly. I imagine the long
test failures are going to bug us until at least early next week.

Cheers,
Jason

On Fri, Sep 11, 2020 at 9:40 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <https://jenkins.gem5.org/job/Nightly/65/display/redirect?page=changes
> >
>
> Changes:
>
> [gabeblack] fastmodel: Create a fake "Interrupts" object for fast model
> CPUs.
>
> [gabeblack] fastmodel: Add an ISA class which defers to IRIS.
>
> [Andreas.Sandberg] dev: Use the new ByteOrder param type in SimpleUart
>
> [Andreas.Sandberg] dev: Use the new ByteOrder param type in VirtIO devices
>
> [Bobby R. Bruce] arch-arm: Fix build errors with gcc 10.2
>
> [Bobby R. Bruce] arch-arm: just return the fault in twoEqualRegInst{,Fp}
>
> [Bobby R. Bruce] cpu: Fixed unused var error when with fast builds
>
> [Bobby R. Bruce] tests: cross-compiling hello binaries for hello_se tests.
>
> [Jason Lowe-Power] configs,python: Fixes an issue with python3 and the
> config scripts when restoring a checkpoint
>
> [shparekh] misc: Replaced master/slave terminology
>
> [srikant.bharadwaj] mem-garnet: Fix default value of network bridge
>
> [srikant.bharadwaj] mem-garnet: Allow empty vnet list for garnet network
> links
>
> [Bobby R. Bruce] tests: Update x86 system.py for MemCtrl i

[gem5-dev] Re: Build failed in Jenkins: Nightly #65

2020-09-11 Thread Jason Lowe-Power via gem5-dev
It looks like there are two (or more) problems here:

1. Something wrong with MIPS (we'll look into this ASAP, probably on Monday)
2. ARM FS + Ruby

I'd like to discuss the latter for a moment.

Here's the backtrace:
Traceback (most recent call last):
  File "", line 1, in 
  File "build/ARM/python/m5/main.py", line 457, in main
  File "/home/jlp/Code/gem5/gem5/tests/gem5/fs/linux/arm/run.py", line 68,
in 
exec(compile(open(config).read(), config, 'exec'))
  File
"/home/jlp/Code/gem5/gem5/tests/gem5/configs/realview-simple-timing-ruby.py",
line 44, in 
use_ruby=True).create_root()
  File "/home/jlp/Code/gem5/gem5/tests/gem5/configs/base_config.py", line
299, in create_root
system = self.create_system()
  File "/home/jlp/Code/gem5/gem5/tests/gem5/configs/arm_generic.py", line
114, in create_system
self.init_system(system)
  File "/home/jlp/Code/gem5/gem5/tests/gem5/configs/base_config.py", line
271, in init_system
super(BaseFSSystem, self).init_system(system)
  File "/home/jlp/Code/gem5/gem5/tests/gem5/configs/base_config.py", line
180, in init_system
cpu.connectCachedPorts(system.ruby._cpu_ports[i])
  File "build/ARM/cpu/BaseCPU.py", line 197, in connectCachedPorts
  File "", line 1, in 
  File "build/ARM/python/m5/SimObject.py", line 1313, in __getattr__
AttributeError: object 'RubySequencer' has no attribute 'cpu_side_ports'
  (C++ object is not yet constructed, so wrapped C++ methods are
unavailable.)

The problem here is that we made an assumption in "base_config.py" that the
interface to a Ruby sequencer and a xbar is the same. I don't think this
makes sense. The xbar has CPU-side and memory-side ports. A Ruby sequencer
should only have an incoming port. (Currently, after the terminology
change, the name is "response_ports" which is probably not the right name.)

So, I have a couple of questions:

1. What is the "right" names for the ports on the sequencer? Right now, we
have 5!! ports on each sequencer. This doesn't seem necessary.

   response_ports = VectorResponsePort("CPU response port") (was "slave")
   request_ports = VectorRequestPort("CPU request port") (was "master")
   pio_request_port = RequestPort("Ruby pio request port") (was
"pio_master_port")
   mem_request_port = RequestPort("Ruby mem request port") (was
"mem_master_port")
   pio_response_port = ResponsePort("Ruby pio response port") (was
"pio_slave_port")

To be honest, I would consider myself a ruby expert, but both the old names
and the new names are inscrutable to me. If anyone has any suggestions, I'm
happy to hear them.

2. Do we really want the Ruby sequencer to have the same interface as the
XBar? If so, we should create a base class so they can both implement that
interface. The current code in BaseCPU.py has used python's duck-typing too
heavily, and this is really biting us right now.

If anyone has ideas on how to improve the "connectPort" interface on the
CPU, please let me know. I think that it's probably better to do this *in
the cache model* as the CPU is the one with the consistent interface
(icache_port and dcache_port are defined in BaseCPU.py). I'm open to
suggestions.

Finally, I'll try to find the time myself to look into the problem with
Ruby, but I can't promise anything will be done quickly. I imagine the long
test failures are going to bug us until at least early next week.

Cheers,
Jason



On Fri, Sep 11, 2020 at 9:40 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <https://jenkins.gem5.org/job/Nightly/65/display/redirect?page=changes
> >
>
> Changes:
>
> [gabeblack] fastmodel: Create a fake "Interrupts" object for fast model
> CPUs.
>
> [gabeblack] fastmodel: Add an ISA class which defers to IRIS.
>
> [Andreas.Sandberg] dev: Use the new ByteOrder param type in SimpleUart
>
> [Andreas.Sandberg] dev: Use the new ByteOrder param type in VirtIO devices
>
> [Bobby R. Bruce] arch-arm: Fix build errors with gcc 10.2
>
> [Bobby R. Bruce] arch-arm: just return the fault in twoEqualRegInst{,Fp}
>
> [Bobby R. Bruce] cpu: Fixed unused var error when with fast builds
>
> [Bobby R. Bruce] tests: cross-compiling hello binaries for hello_se tests.
>
> [Jason Lowe-Power] configs,python: Fixes an issue with python3 and the
> config scripts when restoring a checkpoint
>
> [shparekh] misc: Replaced master/slave terminology
>
> [srikant.bharadwaj] mem-garnet: Fix default value of network bridge
>
> [srikant.bharadwaj] mem-garnet: Allow empty vnet list for garnet network
> links
>
> [Bobby R. Bruce] tests: Update x86 system.py for MemCtrl interface
>
> [Bobby R. Bruce] arch-arm: Initialize some cases of 

[gem5-dev] Change in gem5/gem5[develop]: arch-arm: Initialize some cases of destReg

2020-09-10 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34335 )



Change subject: arch-arm: Initialize some cases of destReg
..

arch-arm: Initialize some cases of destReg

Some compilers complained that this variable may be uninitialized. This
change initializes it to 0.

Change-Id: I201d75ba05ce49d13bbaf4d67e1c728ef704fdf0
Signed-off-by: Jason Lowe-Power 
---
M src/arch/arm/isa/insts/neon.isa
M src/arch/arm/isa/insts/neon64.isa
2 files changed, 6 insertions(+), 6 deletions(-)



diff --git a/src/arch/arm/isa/insts/neon.isa  
b/src/arch/arm/isa/insts/neon.isa

index 1dfefe7..c8f8fcd 100644
--- a/src/arch/arm/isa/insts/neon.isa
+++ b/src/arch/arm/isa/insts/neon.isa
@@ -1452,7 +1452,7 @@
 rCount = 2
 eWalkCode = simdEnabledCheckCode + '''
 RegVect srcReg1, srcReg2;
-BigRegVect destReg;
+BigRegVect destReg = {0};
 '''
 for reg in range(rCount):
 eWalkCode += '''
@@ -1654,7 +1654,7 @@
 global header_output, exec_output
 eWalkCode = simdEnabledCheckCode + '''
 RegVect srcReg1;
-BigRegVect destReg;
+BigRegVect destReg = {0};
 '''
 for reg in range(2):
 eWalkCode += '''
@@ -1884,7 +1884,7 @@
 global header_output, exec_output
 eWalkCode = simdEnabledCheckCode + '''
 RegVect srcRegs;
-BigRegVect destReg;
+BigRegVect destReg = {0};
 '''
 for reg in range(rCount):
 eWalkCode += '''
@@ -2010,7 +2010,7 @@
 global header_output, exec_output
 eWalkCode = simdEnabledCheckCode + '''
 RegVect srcReg1;
-BigRegVect destReg;
+BigRegVect destReg = {0};
 '''
 for reg in range(2):
 eWalkCode += '''
diff --git a/src/arch/arm/isa/insts/neon64.isa  
b/src/arch/arm/isa/insts/neon64.isa

index b9729a1..702c128 100644
--- a/src/arch/arm/isa/insts/neon64.isa
+++ b/src/arch/arm/isa/insts/neon64.isa
@@ -351,7 +351,7 @@
 global header_output, exec_output
 eWalkCode = simd64EnabledCheckCode + '''
 RegVect srcReg1;
-BigRegVect destReg;
+BigRegVect destReg = {0};
 '''
 destReg = 0 if not hi else 2
 for reg in range(2):
@@ -632,7 +632,7 @@
 global header_output, exec_output
 eWalkCode = simd64EnabledCheckCode + '''
 RegVect srcRegs;
-BigRegVect destReg;
+BigRegVect destReg = {0};
 '''
 for reg in range(rCount):
 eWalkCode += '''

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34335
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I201d75ba05ce49d13bbaf4d67e1c728ef704fdf0
Gerrit-Change-Number: 34335
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: configs,python: Fixes an issue with python3 and the config scripts wh...

2020-09-10 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34295 )


Change subject: configs,python: Fixes an issue with python3 and the config  
scripts when restoring a checkpoint

..

configs,python: Fixes an issue with python3 and the config scripts when  
restoring a checkpoint


Fixes a compatibility issue with the configuration scripts when trying to  
restore a checkpoint.  Since python2.4 list.sort has an updated interface.   
The older one has been dropped in python3.


Jira Issue: https://gem5.atlassian.net/browse/GEM5-754

Change-Id: I09f819057d510e477d6ceae0356fafad40f4280d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34295
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M configs/common/Simulation.py
1 file changed, 1 insertion(+), 1 deletion(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/configs/common/Simulation.py b/configs/common/Simulation.py
index e7fb878..a8d3771 100644
--- a/configs/common/Simulation.py
+++ b/configs/common/Simulation.py
@@ -196,7 +196,7 @@
 if match:
 cpts.append(match.group(1))

-cpts.sort(lambda a,b: cmp(long(a), long(b)))
+cpts.sort(key = lambda a: long(a))

 cpt_num = options.checkpoint_restore
 if cpt_num > len(cpts):

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34295
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I09f819057d510e477d6ceae0356fafad40f4280d
Gerrit-Change-Number: 34295
Gerrit-PatchSet: 5
Gerrit-Owner: Dimitrios Chasapis 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: tests: Update x86 system.py for MemCtrl interface

2020-09-10 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34315 )



Change subject: tests: Update x86 system.py for MemCtrl interface
..

tests: Update x86 system.py for MemCtrl interface

Change-Id: If4103b197720f74df70d0a24602e2b3715936826
Signed-off-by: Jason Lowe-Power 
---
M tests/gem5/x86-boot-tests/system/system.py
1 file changed, 2 insertions(+), 2 deletions(-)



diff --git a/tests/gem5/x86-boot-tests/system/system.py  
b/tests/gem5/x86-boot-tests/system/system.py

index bffd08a..00c0ae3 100755
--- a/tests/gem5/x86-boot-tests/system/system.py
+++ b/tests/gem5/x86-boot-tests/system/system.py
@@ -171,8 +171,8 @@

 def _createMemoryControllers(self, num, cls):
 self.mem_cntrls = [
-cls(range = self.mem_ranges[0],
-port = self.membus.master)
+MemCtrl(dram = cls(range = self.mem_ranges[0]),
+port = self.membus.master)
 for i in range(num)
 ]


--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34315
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: If4103b197720f74df70d0a24602e2b3715936826
Gerrit-Change-Number: 34315
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: cpu-o3: convert decode to new style stats

2020-09-09 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/33316 )


Change subject: cpu-o3: convert decode to new style stats
..

cpu-o3: convert decode to new style stats

Change-Id: Ia67a51f3b2c2d40d8bf09f1636c721550f5e9a23
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33316
Reviewed-by: Jason Lowe-Power 
Reviewed-by: Andreas Sandberg 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/cpu/o3/cpu.cc
M src/cpu/o3/decode.hh
M src/cpu/o3/decode_impl.hh
3 files changed, 63 insertions(+), 80 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  Andreas Sandberg: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/o3/cpu.cc b/src/cpu/o3/cpu.cc
index c705801..c5b4a82 100644
--- a/src/cpu/o3/cpu.cc
+++ b/src/cpu/o3/cpu.cc
@@ -441,7 +441,6 @@
 .precision(6);
 totalIpc =  sum(committedInsts) / numCycles;

-this->decode.regStats();
 this->rename.regStats();
 this->iew.regStats();
 this->rob.regStats();
diff --git a/src/cpu/o3/decode.hh b/src/cpu/o3/decode.hh
index 9e26bae..c0c0b81 100644
--- a/src/cpu/o3/decode.hh
+++ b/src/cpu/o3/decode.hh
@@ -109,9 +109,6 @@
 /** Returns the name of decode. */
 std::string name() const;

-/** Registers statistics. */
-void regStats();
-
 /** Sets the main backwards communication time buffer pointer. */
 void setTimeBuffer(TimeBuffer *tb_ptr);

@@ -295,29 +292,32 @@
  */
 bool squashAfterDelaySlot[Impl::MaxThreads];

+struct DecodeStats : public Stats::Group {
+DecodeStats(O3CPU *cpu);

-/** Stat for total number of idle cycles. */
-Stats::Scalar decodeIdleCycles;
-/** Stat for total number of blocked cycles. */
-Stats::Scalar decodeBlockedCycles;
-/** Stat for total number of normal running cycles. */
-Stats::Scalar decodeRunCycles;
-/** Stat for total number of unblocking cycles. */
-Stats::Scalar decodeUnblockCycles;
-/** Stat for total number of squashing cycles. */
-Stats::Scalar decodeSquashCycles;
-/** Stat for number of times a branch is resolved at decode. */
-Stats::Scalar decodeBranchResolved;
-/** Stat for number of times a branch mispredict is detected. */
-Stats::Scalar decodeBranchMispred;
-/** Stat for number of times decode detected a non-control instruction
- * incorrectly predicted as a branch.
- */
-Stats::Scalar decodeControlMispred;
-/** Stat for total number of decoded instructions. */
-Stats::Scalar decodeDecodedInsts;
-/** Stat for total number of squashed instructions. */
-Stats::Scalar decodeSquashedInsts;
+/** Stat for total number of idle cycles. */
+Stats::Scalar idleCycles;
+/** Stat for total number of blocked cycles. */
+Stats::Scalar blockedCycles;
+/** Stat for total number of normal running cycles. */
+Stats::Scalar runCycles;
+/** Stat for total number of unblocking cycles. */
+Stats::Scalar unblockCycles;
+/** Stat for total number of squashing cycles. */
+Stats::Scalar squashCycles;
+/** Stat for number of times a branch is resolved at decode. */
+Stats::Scalar branchResolved;
+/** Stat for number of times a branch mispredict is detected. */
+Stats::Scalar branchMispred;
+/** Stat for number of times decode detected a non-control  
instruction

+ * incorrectly predicted as a branch.
+ */
+Stats::Scalar controlMispred;
+/** Stat for total number of decoded instructions. */
+Stats::Scalar decodedInsts;
+/** Stat for total number of squashed instructions. */
+Stats::Scalar squashedInsts;
+} stats;
 };

 #endif // __CPU_O3_DECODE_HH__
diff --git a/src/cpu/o3/decode_impl.hh b/src/cpu/o3/decode_impl.hh
index cf3d601..24640f6 100644
--- a/src/cpu/o3/decode_impl.hh
+++ b/src/cpu/o3/decode_impl.hh
@@ -64,7 +64,8 @@
   commitToDecodeDelay(params->commitToDecodeDelay),
   fetchToDecodeDelay(params->fetchToDecodeDelay),
   decodeWidth(params->decodeWidth),
-  numThreads(params->numThreads)
+  numThreads(params->numThreads),
+  stats(_cpu)
 {
 if (decodeWidth > Impl::MaxWidth)
 fatal("decodeWidth (%d) is larger than compiled limit (%d),\n"
@@ -119,50 +120,33 @@
 }

 template 
-void
-DefaultDecode::regStats()
+DefaultDecode::DecodeStats::DecodeStats(O3CPU *cpu)
+: Stats::Group(cpu, "decode"),
+  ADD_STAT(idleCycles, "Number of cycles decode is idle"),
+  ADD_STAT(blockedCycles, "Number of cycles decode is blocked"),
+  ADD_STAT(runCycles, "Number of cycles decode is running"),
+  ADD_STAT(unblockCycles, "Number of cycles decode is unblocking"),
+  ADD_STAT(squa

[gem5-dev] Change in gem5/gem5[develop]: cpu-o3: convert commit to new style stats

2020-09-09 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/33315 )


Change subject: cpu-o3: convert commit to new style stats
..

cpu-o3: convert commit to new style stats

Change-Id: I859fe753d1a2ec2da8a4209d1db122f1014af5d6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33315
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/cpu/o3/commit.hh
M src/cpu/o3/commit_impl.hh
M src/cpu/o3/cpu.cc
3 files changed, 117 insertions(+), 155 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/o3/commit.hh b/src/cpu/o3/commit.hh
index 85d00a9..01a0b7f 100644
--- a/src/cpu/o3/commit.hh
+++ b/src/cpu/o3/commit.hh
@@ -143,9 +143,6 @@
 /** Returns the name of the DefaultCommit. */
 std::string name() const;

-/** Registers statistics. */
-void regStats();
-
 /** Registers probes. */
 void regProbePoints();

@@ -479,52 +476,55 @@
 /** Updates commit stats based on this instruction. */
 void updateComInstStats(const DynInstPtr );

-
 // HTM
 int htmStarts[Impl::MaxThreads];
 int htmStops[Impl::MaxThreads];

-/** Stat for the total number of squashed instructions discarded by  
commit.

- */
-Stats::Scalar commitSquashedInsts;
-/** Stat for the total number of times commit has had to stall due to  
a non-

- * speculative instruction reaching the head of the ROB.
- */
-Stats::Scalar commitNonSpecStalls;
-/** Stat for the total number of branch mispredicts that caused a  
squash. */

-Stats::Scalar branchMispredicts;
-/** Distribution of the number of committed instructions each cycle. */
-Stats::Distribution numCommittedDist;
+struct CommitStats : public Stats::Group {
+CommitStats(O3CPU *cpu, DefaultCommit *commit);
+/** Stat for the total number of squashed instructions discarded by
+ * commit.
+ */
+Stats::Scalar commitSquashedInsts;
+/** Stat for the total number of times commit has had to stall due
+ * to a non-speculative instruction reaching the head of the ROB.
+ */
+Stats::Scalar commitNonSpecStalls;
+/** Stat for the total number of branch mispredicts that caused a
+ * squash.
+ */
+Stats::Scalar branchMispredicts;
+/** Distribution of the number of committed instructions each  
cycle. */

+Stats::Distribution numCommittedDist;

-/** Total number of instructions committed. */
-Stats::Vector instsCommitted;
-/** Total number of ops (including micro ops) committed. */
-Stats::Vector opsCommitted;
-/** Total number of software prefetches committed. */
-Stats::Vector statComSwp;
-/** Stat for the total number of committed memory references. */
-Stats::Vector statComRefs;
-/** Stat for the total number of committed loads. */
-Stats::Vector statComLoads;
-/** Stat for the total number of committed atomics. */
-Stats::Vector statComAmos;
-/** Total number of committed memory barriers. */
-Stats::Vector statComMembars;
-/** Total number of committed branches. */
-Stats::Vector statComBranches;
-/** Total number of vector instructions */
-Stats::Vector statComVector;
-/** Total number of floating point instructions */
-Stats::Vector statComFloating;
-/** Total number of integer instructions */
-Stats::Vector statComInteger;
-/** Total number of function calls */
-Stats::Vector statComFunctionCalls;
-/** Committed instructions by instruction type (OpClass) */
-Stats::Vector2d statCommittedInstType;
+/** Total number of instructions committed. */
+Stats::Vector instsCommitted;
+/** Total number of ops (including micro ops) committed. */
+Stats::Vector opsCommitted;
+/** Stat for the total number of committed memory references. */
+Stats::Vector memRefs;
+/** Stat for the total number of committed loads. */
+Stats::Vector loads;
+/** Stat for the total number of committed atomics. */
+Stats::Vector amos;
+/** Total number of committed memory barriers. */
+Stats::Vector membars;
+/** Total number of committed branches. */
+Stats::Vector branches;
+/** Total number of vector instructions */
+Stats::Vector vector;
+/** Total number of floating point instructions */
+Stats::Vector floating;
+/** Total number of integer instructions */
+Stats::Vector integer;
+/** Total number of function calls */
+Stats::Vector functionCalls;
+/** Committed instructions by instruction type (OpClass) */
+Stats::Vector2d committedInstType;

-/** Number of cycles where the commit

[gem5-dev] Change in gem5/gem5[develop]: cpu-o3: convert lsq_unit to new style stats

2020-09-09 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/33394 )


Change subject: cpu-o3: convert lsq_unit to new style stats
..

cpu-o3: convert lsq_unit to new style stats

Removes unused stats: invAddrLoads, invAddrSwpfs, lsqBlockedLoads

Change-Id: Icd7fc6d8a040f4a1f9b190409b7cdb0a57fd68cf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33394
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/cpu/o3/iew_impl.hh
M src/cpu/o3/lsq.hh
M src/cpu/o3/lsq_impl.hh
M src/cpu/o3/lsq_unit.hh
M src/cpu/o3/lsq_unit_impl.hh
5 files changed, 49 insertions(+), 93 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/o3/iew_impl.hh b/src/cpu/o3/iew_impl.hh
index 9a04fe6..497c532 100644
--- a/src/cpu/o3/iew_impl.hh
+++ b/src/cpu/o3/iew_impl.hh
@@ -146,7 +146,6 @@
 using namespace Stats;

 instQueue.regStats();
-ldstQueue.regStats();

 iewIdleCycles
 .name(name() + ".iewIdleCycles")
diff --git a/src/cpu/o3/lsq.hh b/src/cpu/o3/lsq.hh
index 35c2873..bc5e154 100644
--- a/src/cpu/o3/lsq.hh
+++ b/src/cpu/o3/lsq.hh
@@ -856,9 +856,6 @@
 /** Returns the name of the LSQ. */
 std::string name() const;

-/** Registers statistics of each LSQ unit. */
-void regStats();
-
 /** Sets the pointer to the list of active threads. */
 void setActiveThreads(std::list *at_ptr);

diff --git a/src/cpu/o3/lsq_impl.hh b/src/cpu/o3/lsq_impl.hh
index a535dcc..7657b23 100644
--- a/src/cpu/o3/lsq_impl.hh
+++ b/src/cpu/o3/lsq_impl.hh
@@ -118,16 +118,6 @@

 template
 void
-LSQ::regStats()
-{
-//Initialize LSQs
-for (ThreadID tid = 0; tid < numThreads; tid++) {
-thread[tid].regStats();
-}
-}
-
-template
-void
 LSQ::setActiveThreads(list *at_ptr)
 {
 activeThreads = at_ptr;
diff --git a/src/cpu/o3/lsq_unit.hh b/src/cpu/o3/lsq_unit.hh
index 70995d6..3d6e3f0 100644
--- a/src/cpu/o3/lsq_unit.hh
+++ b/src/cpu/o3/lsq_unit.hh
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "arch/generic/debugfaults.hh"
@@ -225,7 +226,10 @@
  * contructor is deleted explicitly. However, STL vector requires
  * a valid copy constructor for the base type at compile time.
  */
-LSQUnit(const LSQUnit ) { panic("LSQUnit is not copy-able"); }
+LSQUnit(const LSQUnit ): stats(nullptr)
+{
+panic("LSQUnit is not copy-able");
+}

 /** Initializes the LSQ unit with the specified number of entries. */
 void init(O3CPU *cpu_ptr, IEW *iew_ptr, DerivO3CPUParams *params,
@@ -234,9 +238,6 @@
 /** Returns the name of the LSQ unit. */
 std::string name() const;

-/** Registers statistics. */
-void regStats();
-
 /** Sets the pointer to the dcache port. */
 void setDcachePort(RequestPort *dcache_port);

@@ -561,39 +562,35 @@
 /** Flag for memory model. */
 bool needsTSO;

+  protected:
 // Will also need how many read/write ports the Dcache has.  Or keep  
track
 // of that in stage that is one level up, and only call  
executeLoad/Store

 // the appropriate number of times.
-/** Total number of loads forwaded from LSQ stores. */
-Stats::Scalar lsqForwLoads;
+struct LSQUnitStats : public Stats::Group{
+LSQUnitStats(Stats::Group *parent);

-/** Total number of loads ignored due to invalid addresses. */
-Stats::Scalar invAddrLoads;
+/** Total number of loads forwaded from LSQ stores. */
+Stats::Scalar forwLoads;

-/** Total number of squashed loads. */
-Stats::Scalar lsqSquashedLoads;
+/** Total number of squashed loads. */
+Stats::Scalar squashedLoads;

-/** Total number of responses from the memory system that are
- * ignored due to the instruction already being squashed. */
-Stats::Scalar lsqIgnoredResponses;
+/** Total number of responses from the memory system that are
+ * ignored due to the instruction already being squashed. */
+Stats::Scalar ignoredResponses;

-/** Tota number of memory ordering violations. */
-Stats::Scalar lsqMemOrderViolation;
+/** Tota number of memory ordering violations. */
+Stats::Scalar memOrderViolation;

-/** Total number of squashed stores. */
-Stats::Scalar lsqSquashedStores;
+/** Total number of squashed stores. */
+Stats::Scalar squashedStores;

-/** Total number of software prefetches ignored due to invalid  
addresses. */

-Stats::Scalar invAddrSwpfs;
+/** Number of loads that were rescheduled. */
+Stats::Scalar rescheduledLoads;

-/** Ready loads blocked due to partial store-forwarding. */
-Stats::Scalar lsqBlockedLoads;
-
-/** Number of loads that were rescheduled

[gem5-dev] Change in gem5/gem5[develop]: cpu-o3: convert rename to new style stats

2020-09-09 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/33397 )


Change subject: cpu-o3: convert rename to new style stats
..

cpu-o3: convert rename to new style stats

Change-Id: Id34a85e40ad7e83d5805a034df6e0c5ad9b9af82
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33397
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/cpu/o3/cpu.cc
M src/cpu/o3/rename.hh
M src/cpu/o3/rename_impl.hh
3 files changed, 150 insertions(+), 176 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/o3/cpu.cc b/src/cpu/o3/cpu.cc
index bbc6b82..414913d 100644
--- a/src/cpu/o3/cpu.cc
+++ b/src/cpu/o3/cpu.cc
@@ -441,7 +441,6 @@
 .precision(6);
 totalIpc =  sum(committedInsts) / numCycles;

-this->rename.regStats();
 this->iew.regStats();

 intRegfileReads
diff --git a/src/cpu/o3/rename.hh b/src/cpu/o3/rename.hh
index e3dc3e9..5b45218 100644
--- a/src/cpu/o3/rename.hh
+++ b/src/cpu/o3/rename.hh
@@ -133,9 +133,6 @@
 /** Returns the name of rename. */
 std::string name() const;

-/** Registers statistics. */
-void regStats();
-
 /** Registers probes. */
 void regProbePoints();

@@ -481,51 +478,62 @@
  */
 inline void incrFullStat(const FullSource );

-/** Stat for total number of cycles spent squashing. */
-Stats::Scalar renameSquashCycles;
-/** Stat for total number of cycles spent idle. */
-Stats::Scalar renameIdleCycles;
-/** Stat for total number of cycles spent blocking. */
-Stats::Scalar renameBlockCycles;
-/** Stat for total number of cycles spent stalling for a serializing  
inst. */

-Stats::Scalar renameSerializeStallCycles;
-/** Stat for total number of cycles spent running normally. */
-Stats::Scalar renameRunCycles;
-/** Stat for total number of cycles spent unblocking. */
-Stats::Scalar renameUnblockCycles;
-/** Stat for total number of renamed instructions. */
-Stats::Scalar renameRenamedInsts;
-/** Stat for total number of squashed instructions that rename  
discards. */

-Stats::Scalar renameSquashedInsts;
-/** Stat for total number of times that the ROB starts a stall in  
rename. */

-Stats::Scalar renameROBFullEvents;
-/** Stat for total number of times that the IQ starts a stall in  
rename. */

-Stats::Scalar renameIQFullEvents;
-/** Stat for total number of times that the LQ starts a stall in  
rename. */

-Stats::Scalar renameLQFullEvents;
-/** Stat for total number of times that the SQ starts a stall in  
rename. */

-Stats::Scalar renameSQFullEvents;
-/** Stat for total number of times that rename runs out of free  
registers

- * to use to rename. */
-Stats::Scalar renameFullRegistersEvents;
-/** Stat for total number of renamed destination registers. */
-Stats::Scalar renameRenamedOperands;
-/** Stat for total number of source register rename lookups. */
-Stats::Scalar renameRenameLookups;
-Stats::Scalar intRenameLookups;
-Stats::Scalar fpRenameLookups;
-Stats::Scalar vecRenameLookups;
-Stats::Scalar vecPredRenameLookups;
-/** Stat for total number of committed renaming mappings. */
-Stats::Scalar renameCommittedMaps;
-/** Stat for total number of mappings that were undone due to a  
squash. */

-Stats::Scalar renameUndoneMaps;
-/** Number of serialize instructions handled. */
-Stats::Scalar renamedSerializing;
-/** Number of instructions marked as temporarily serializing. */
-Stats::Scalar renamedTempSerializing;
-/** Number of instructions inserted into skid buffers. */
-Stats::Scalar renameSkidInsts;
+struct RenameStats : public Stats::Group {
+RenameStats(Stats::Group *parent);
+
+/** Stat for total number of cycles spent squashing. */
+Stats::Scalar squashCycles;
+/** Stat for total number of cycles spent idle. */
+Stats::Scalar idleCycles;
+/** Stat for total number of cycles spent blocking. */
+Stats::Scalar blockCycles;
+/** Stat for total number of cycles spent stalling for a  
serializing

+ *  inst. */
+Stats::Scalar serializeStallCycles;
+/** Stat for total number of cycles spent running normally. */
+Stats::Scalar runCycles;
+/** Stat for total number of cycles spent unblocking. */
+Stats::Scalar unblockCycles;
+/** Stat for total number of renamed instructions. */
+Stats::Scalar renamedInsts;
+/** Stat for total number of squashed instructions that rename
+ * discards. */
+Stats::Scalar squashedInsts;
+/** Stat for total number of times that the ROB starts a stall in
+ * rename. */
+Stats::Scalar ROBFull

[gem5-dev] Change in gem5/gem5[develop]: cpu-o3: convert rob to new style stats

2020-09-09 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/33398 )


Change subject: cpu-o3: convert rob to new style stats
..

cpu-o3: convert rob to new style stats

Change-Id: I84430d50c49742cd536dd75ce25184c2316dce51
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33398
Reviewed-by: Andreas Sandberg 
Maintainer: Andreas Sandberg 
Tested-by: kokoro 
---
M src/cpu/o3/cpu.cc
M src/cpu/o3/rob.hh
M src/cpu/o3/rob_impl.hh
3 files changed, 19 insertions(+), 23 deletions(-)

Approvals:
  Andreas Sandberg: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/o3/cpu.cc b/src/cpu/o3/cpu.cc
index c5b4a82..bbc6b82 100644
--- a/src/cpu/o3/cpu.cc
+++ b/src/cpu/o3/cpu.cc
@@ -443,7 +443,6 @@

 this->rename.regStats();
 this->iew.regStats();
-this->rob.regStats();

 intRegfileReads
 .name(name() + ".int_regfile_reads")
diff --git a/src/cpu/o3/rob.hh b/src/cpu/o3/rob.hh
index eb8d1d6..4b87dc4 100644
--- a/src/cpu/o3/rob.hh
+++ b/src/cpu/o3/rob.hh
@@ -257,9 +257,6 @@
  */
 size_t countInsts(ThreadID tid);

-/** Registers statistics. */
-void regStats();
-
   private:
 /** Reset the ROB state */
 void resetState();
@@ -323,10 +320,15 @@
 /** Number of active threads. */
 ThreadID numThreads;

-// The number of rob_reads
-Stats::Scalar robReads;
-// The number of rob_writes
-Stats::Scalar robWrites;
+
+struct ROBStats : public Stats::Group {
+ROBStats(Stats::Group *parent);
+
+// The number of rob_reads
+Stats::Scalar reads;
+// The number of rob_writes
+Stats::Scalar writes;
+} stats;
 };

 #endif //__CPU_O3_ROB_HH__
diff --git a/src/cpu/o3/rob_impl.hh b/src/cpu/o3/rob_impl.hh
index 80ea1e6..bfc368b 100644
--- a/src/cpu/o3/rob_impl.hh
+++ b/src/cpu/o3/rob_impl.hh
@@ -58,7 +58,8 @@
   numEntries(params->numROBEntries),
   squashWidth(params->squashWidth),
   numInstsInROB(0),
-  numThreads(params->numThreads)
+  numThreads(params->numThreads),
+  stats(_cpu)
 {
 //Figure out rob policy
 if (robPolicy == SMTQueuePolicy::Dynamic) {
@@ -204,7 +205,7 @@
 {
 assert(inst);

-robWrites++;
+stats.writes++;

 DPRINTF(ROB, "Adding inst PC %s to the ROB.\n", inst->pcState());

@@ -239,7 +240,7 @@
 void
 ROB::retireHead(ThreadID tid)
 {
-robWrites++;
+stats.writes++;

 assert(numInstsInROB > 0);

@@ -274,7 +275,7 @@
 bool
 ROB::isHeadReady(ThreadID tid)
 {
-robReads++;
+stats.reads++;
 if (threadEntries[tid] != 0) {
 return instList[tid].front()->readyToCommit();
 }
@@ -319,7 +320,7 @@
 void
 ROB::doSquash(ThreadID tid)
 {
-robWrites++;
+stats.writes++;
 DPRINTF(ROB, "[tid:%i] Squashing instructions until [sn:%llu].\n",
 tid, squashedSeqNum[tid]);

@@ -528,17 +529,11 @@
 }

 template 
-void
-ROB::regStats()
+ROB::ROBStats::ROBStats(Stats::Group *parent)
+: Stats::Group(parent, "rob"),
+  ADD_STAT(reads, "The number of ROB reads"),
+  ADD_STAT(writes, "The number of ROB writes")
 {
-using namespace Stats;
-robReads
-.name(name() + ".rob_reads")
-.desc("The number of ROB reads");
-
-robWrites
-.name(name() + ".rob_writes")
-.desc("The number of ROB writes");
 }

 template 

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/33398
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I84430d50c49742cd536dd75ce25184c2316dce51
Gerrit-Change-Number: 33398
Gerrit-PatchSet: 4
Gerrit-Owner: Emily Brickey 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: cpu-minor: convert fetch2 to new style stats

2020-09-08 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/33975 )


Change subject: cpu-minor: convert fetch2 to new style stats
..

cpu-minor: convert fetch2 to new style stats

Change-Id: Idfe0f1f256c93209fe51140b9cab3b454153c597
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33975
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/cpu/minor/fetch2.cc
M src/cpu/minor/fetch2.hh
M src/cpu/minor/pipeline.cc
M src/cpu/minor/pipeline.hh
4 files changed, 44 insertions(+), 59 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/minor/fetch2.cc b/src/cpu/minor/fetch2.cc
index d090edd..c43b2f8 100644
--- a/src/cpu/minor/fetch2.cc
+++ b/src/cpu/minor/fetch2.cc
@@ -69,7 +69,7 @@
 processMoreThanOneInput(params.fetch2CycleInput),
 branchPredictor(*params.branchPred),
 fetchInfo(params.numThreads),
-threadPriority(0)
+threadPriority(0), stats(_)
 {
 if (outputWidth < 1)
 fatal("%s: decodeInputWidth must be >= 1 (%d)\n", name,  
outputWidth);

@@ -413,17 +413,17 @@

 // Collect some basic inst class stats
 if (decoded_inst->isLoad())
-loadInstructions++;
+stats.loadInstructions++;
 else if (decoded_inst->isStore())
-storeInstructions++;
+stats.storeInstructions++;
 else if (decoded_inst->isAtomic())
-amoInstructions++;
+stats.amoInstructions++;
 else if (decoded_inst->isVector())
-vecInstructions++;
+stats.vecInstructions++;
 else if (decoded_inst->isFloating())
-fpInstructions++;
+stats.fpInstructions++;
 else if (decoded_inst->isInteger())
-intInstructions++;
+stats.intInstructions++;

 DPRINTF(Fetch, "Instruction extracted from line %s"
 " lineWidth: %d output_index: %d inputIndex: %d"
@@ -602,40 +602,33 @@
(*predictionOut.inputWire).isBubble();
 }

-void
-Fetch2::regStats()
+Fetch2::Fetch2Stats::Fetch2Stats(MinorCPU *cpu)
+  : Stats::Group(cpu, "fetch2"),
+  ADD_STAT(intInstructions,
+   "Number of integer instructions successfully decoded"),
+  ADD_STAT(fpInstructions,
+   "Number of floating point instructions successfully decoded"),
+  ADD_STAT(vecInstructions,
+   "Number of SIMD instructions successfully decoded"),
+  ADD_STAT(loadInstructions,
+   "Number of memory load instructions successfully decoded"),
+  ADD_STAT(storeInstructions,
+   "Number of memory store instructions successfully decoded"),
+  ADD_STAT(amoInstructions,
+   "Number of memory atomic instructions successfully decoded")
 {
-using namespace Stats;
-
-intInstructions
-.name(name() + ".int_instructions")
-.desc("Number of integer instructions successfully decoded")
-.flags(total);
-
-fpInstructions
-.name(name() + ".fp_instructions")
-.desc("Number of floating point instructions successfully decoded")
-.flags(total);
-
-vecInstructions
-.name(name() + ".vec_instructions")
-.desc("Number of SIMD instructions successfully decoded")
-.flags(total);
-
-loadInstructions
-.name(name() + ".load_instructions")
-.desc("Number of memory load instructions successfully decoded")
-.flags(total);
-
-storeInstructions
-.name(name() + ".store_instructions")
-.desc("Number of memory store instructions successfully decoded")
-.flags(total);
-
-amoInstructions
-.name(name() + ".amo_instructions")
-.desc("Number of memory atomic instructions successfully decoded")
-.flags(total);
+intInstructions
+.flags(Stats::total);
+fpInstructions
+.flags(Stats::total);
+vecInstructions
+.flags(Stats::total);
+loadInstructions
+.flags(Stats::total);
+storeInstructions
+.flags(Stats::total);
+amoInstructions
+.flags(Stats::total);
 }

 void
diff --git a/src/cpu/minor/fetch2.hh b/src/cpu/minor/fetch2.hh
index d9726a9..3196e4e 100644
--- a/src/cpu/minor/fetch2.hh
+++ b/src/cpu/minor/fetch2.hh
@@ -163,13 +163,17 @@
 std::vec

[gem5-dev] Change in gem5/gem5[develop]: cpu: convert trace cpu to new style stats

2020-09-08 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/33875 )


Change subject: cpu: convert trace cpu to new style stats
..

cpu: convert trace cpu to new style stats

This required making minor changes to how the name was set for the
generators within the trace CPU to enable the stats to keep similar
names.

Change-Id: I9f97d4006a0edbd717fc34d0033b9548011d1631
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33875
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
Reviewed-by: Ayaz Akram 
---
M src/cpu/trace/trace_cpu.cc
M src/cpu/trace/trace_cpu.hh
2 files changed, 110 insertions(+), 171 deletions(-)

Approvals:
  Ayaz Akram: Looks good to me, approved
  Jason Lowe-Power: Looks good to me, approved
  kokoro: Regressions pass

Objections:
  Andreas Sandberg: I would prefer this is not merged as is



diff --git a/src/cpu/trace/trace_cpu.cc b/src/cpu/trace/trace_cpu.cc
index 13f194c..80db94c 100644
--- a/src/cpu/trace/trace_cpu.cc
+++ b/src/cpu/trace/trace_cpu.cc
@@ -50,8 +50,8 @@
 dataMasterID(params->system->getMasterId(this, "data")),
 instTraceFile(params->instTraceFile),
 dataTraceFile(params->dataTraceFile),
-icacheGen(*this, ".iside", icachePort, instMasterID,  
instTraceFile),

-dcacheGen(*this, ".dside", dcachePort, dataMasterID, dataTraceFile,
+icacheGen(*this, "iside", icachePort, instMasterID, instTraceFile),
+dcacheGen(*this, "dside", dcachePort, dataMasterID, dataTraceFile,
   params),
 icacheNextEvent([this]{ schedIcacheNext(); }, name()),
 dcacheNextEvent([this]{ schedDcacheNext(); }, name()),
@@ -60,7 +60,7 @@
 execCompleteEvent(nullptr),
 enableEarlyExit(params->enableEarlyExit),
 progressMsgInterval(params->progressMsgInterval),
-progressMsgThreshold(params->progressMsgInterval)
+progressMsgThreshold(params->progressMsgInterval), traceStats(this)
 {
 // Increment static counter for number of Trace CPUs.
 ++TraceCPU::numTraceCPUs;
@@ -91,8 +91,9 @@
 void
 TraceCPU::updateNumOps(uint64_t rob_num)
 {
-numOps = rob_num;
-if (progressMsgInterval != 0 && numOps.value() >=  
progressMsgThreshold) {

+traceStats.numOps = rob_num;
+if (progressMsgInterval != 0 &&
+ traceStats.numOps.value() >= progressMsgThreshold) {
 inform("%s: %i insts committed\n", name(), progressMsgThreshold);
 progressMsgThreshold += progressMsgInterval;
 }
@@ -161,7 +162,7 @@
 DPRINTF(TraceCPUInst, "Scheduling next icacheGen event "
 "at %d.\n", curTick() + icacheGen.tickDelta());
 schedule(icacheNextEvent, curTick() + icacheGen.tickDelta());
-++numSchedIcacheEvent;
+++traceStats.numSchedIcacheEvent;
 } else {
 // check if traceComplete. If not, do nothing because sending  
failed

 // and next event will be scheduled via RecvRetry()
@@ -208,93 +209,33 @@
 }
 }
 }
-
-void
-TraceCPU::regStats()
+ TraceCPU::TraceStats::TraceStats(TraceCPU *trace)
+: Stats::Group(trace),
+ADD_STAT(numSchedDcacheEvent,
+ "Number of events scheduled to trigger data request generator"),
+ADD_STAT(numSchedIcacheEvent,
+ "Number of events scheduled to trigger instruction request  
generator"),

+ADD_STAT(numOps, "Number of micro-ops simulated by the Trace CPU"),
+ADD_STAT(cpi, "Cycles per micro-op used as a proxy for CPI",
+ trace->numCycles / numOps)
 {
-
-BaseCPU::regStats();
-
-numSchedDcacheEvent
-.name(name() + ".numSchedDcacheEvent")
-.desc("Number of events scheduled to trigger data request generator")
-;
-
-numSchedIcacheEvent
-.name(name() + ".numSchedIcacheEvent")
-.desc("Number of events scheduled to trigger instruction request  
generator")

-;
-
-numOps
-.name(name() + ".numOps")
-.desc("Number of micro-ops simulated by the Trace CPU")
-;
-
-cpi
-.name(name() + ".cpi")
-.desc("Cycles per micro-op used as a proxy for CPI")
-.precision(6)
-;
-cpi = numCycles/numOps;
-
-icacheGen.regStats();
-dcacheGen.regStats();
+cpi.precision(6);
 }
-
-void
-TraceCPU::ElasticDataGen::regStats()
+TraceCPU::ElasticDataGen::
+ElasticDataGenStatGroup::ElasticDataGenStatGroup(Stats::Group *parent,
+ const std::string& _name)
+: Stats::Group(parent, _name.c_str()),
+ADD_STAT(maxDependents, "Max number of dependents observed on a node"),
+ADD_STAT(maxReadyListSize, "Max size of the ready list observed"),
+ADD

[gem5-dev] Change in gem5/gem5[develop]: cpu-o3: convert elastic trace to new style stats

2020-09-08 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/33399 )


Change subject: cpu-o3: convert elastic trace to new style stats
..

cpu-o3: convert elastic trace to new style stats

Change-Id: If767f17b905a77e12058022a9e8bc65b854978a4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33399
Reviewed-by: Andreas Sandberg 
Maintainer: Andreas Sandberg 
Tested-by: kokoro 
---
M src/cpu/o3/probe/elastic_trace.cc
M src/cpu/o3/probe/elastic_trace.hh
2 files changed, 76 insertions(+), 106 deletions(-)

Approvals:
  Andreas Sandberg: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/o3/probe/elastic_trace.cc  
b/src/cpu/o3/probe/elastic_trace.cc

index 8292c33..b40d281 100644
--- a/src/cpu/o3/probe/elastic_trace.cc
+++ b/src/cpu/o3/probe/elastic_trace.cc
@@ -54,7 +54,8 @@
instTraceStream(nullptr),
startTraceInst(params->startTraceInst),
allProbesReg(false),
-   traceVirtAddr(params->traceVirtAddr)
+   traceVirtAddr(params->traceVirtAddr),
+   stats(this)
 {
 cpu = dynamic_cast*>(params->manager);
 fatal_if(!cpu, "Manager of %s is not of type O3CPU and thus does not "\
@@ -193,8 +194,8 @@
 }

 exec_info_ptr->executeTick = curTick();
-maxTempStoreSize = std::max(tempStore.size(),
-(std::size_t)maxTempStoreSize.value());
+stats.maxTempStoreSize = std::max(tempStore.size(),
+ 
(std::size_t)stats.maxTempStoreSize.value());

 }

 void
@@ -282,8 +283,8 @@
 physRegDepMap[phys_dest_reg->flatIndex()] = seq_num;
 }
 }
-maxPhysRegDepMapSize = std::max(physRegDepMap.size(),
- 
(std::size_t)maxPhysRegDepMapSize.value());

+stats.maxPhysRegDepMapSize = std::max(physRegDepMap.size(),
+ 
(std::size_t)stats.maxPhysRegDepMapSize.value());

 }

 void
@@ -450,7 +451,7 @@
 TraceInfo* reg_dep = trace_info_itr->second;
 reg_dep->numDepts++;
 compDelayPhysRegDep(reg_dep, new_record);
-++numRegDep;
+++stats.numRegDep;
 } else {
 // The instruction that this has a register dependency on was
 // not added to the trace because of one of the following
@@ -533,7 +534,7 @@
 if (hasLoadCompleted(past_record, execute_tick)) {
 // Assign rob dependency and calculate the computational  
delay

 assignRobDep(past_record, new_record);
-++numOrderDepStores;
+++stats.numRegDep;
 return;
 }
 } else {
@@ -542,7 +543,7 @@
 if (hasStoreCommitted(past_record, execute_tick)) {
 // Assign rob dependency and calculate the computational  
delay

 assignRobDep(past_record, new_record);
-++numOrderDepStores;
+++stats.numRegDep;
 return;
 }
 }
@@ -567,15 +568,15 @@
 if (new_record->isLoad()) {
 // The execution time of a load is when a request is sent
 execute_tick = new_record->executeTick;
-++numIssueOrderDepLoads;
+++stats.numIssueOrderDepLoads;
 } else if (new_record->isStore()) {
 // The execution time of a store is when it is sent, i.e. committed
 execute_tick = curTick();
-++numIssueOrderDepStores;
+++stats.numIssueOrderDepStores;
 } else {
 // The execution time of a non load/store is when it completes
 execute_tick = new_record->toCommitTick;
-++numIssueOrderDepOther;
+++stats.numIssueOrderDepOther;
 }

 // We search if this record has an issue order dependency on a past  
record.

@@ -610,8 +611,8 @@
 // Increment number of dependents of the past record
 ++(past_record->numDepts);
 // Update stat to log max number of dependents
-maxNumDependents = std::max(past_record->numDepts,
-(uint32_t)maxNumDependents.value());
+stats.maxNumDependents = std::max(past_record->numDepts,
+(uint32_t)stats.maxNumDependents.value());
 }

 bool
@@ -863,7 +864,7 @@
 } else {
 // Don't write the node to the trace but note that we have  
filtered

 // out a node.
-++numFilteredNodes;
+++stats.numFilteredNodes;
 ++num_filtered_nodes;
 }
 dep_trace_itr++;
@@ -874,59 +875,27 @@
 depTrace.erase(dep_trace_itr_start, dep_trace_itr);
 }

-void
-ElasticTrace::regStats() {
-ProbeListenerObject::regStats();
-
-using namespace Stats;
-numRegDep
-.name(name() + ".numRegDep")
-  

[gem5-dev] Change in gem5/gem5[develop]: cpu: convert memtest to new style stats

2020-09-08 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34137 )


Change subject: cpu: convert memtest to new style stats
..

cpu: convert memtest to new style stats

Change-Id: I91b17dd46fd0f70816159ea14c1c8f498048c696
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34137
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/cpu/testers/memtest/memtest.cc
M src/cpu/testers/memtest/memtest.hh
2 files changed, 14 insertions(+), 22 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/testers/memtest/memtest.cc  
b/src/cpu/testers/memtest/memtest.cc

index 720b273..026a325 100644
--- a/src/cpu/testers/memtest/memtest.cc
+++ b/src/cpu/testers/memtest/memtest.cc
@@ -99,7 +99,7 @@
   nextProgressMessage(p->progress_interval),
   maxLoads(p->max_loads),
   atomic(p->system->isAtomicMode()),
-  suppressFuncErrors(p->suppress_func_errors)
+  suppressFuncErrors(p->suppress_func_errors), stats(this)
 {
 id = TESTER_ALLOCATOR++;
 fatal_if(id >= blockSize, "Too many testers, only %d allowed\n",
@@ -160,7 +160,7 @@
 }

 numReads++;
-numReadsStat++;
+stats.numReads++;

 if (numReads == (uint64_t)nextProgressMessage) {
 ccprintf(cerr, "%s: completed %d read, %d write accesses  
@%d\n",

@@ -176,7 +176,7 @@
 // update the reference data
 referenceData[req->getPaddr()] = pkt_data[0];
 numWrites++;
-numWritesStat++;
+stats.numWrites++;
 }
 }

@@ -190,23 +190,12 @@
 else if (noResponseEvent.scheduled())
 deschedule(noResponseEvent);
 }
-
-void
-MemTest::regStats()
+MemTest::MemTestStats::MemTestStats(Stats::Group *parent)
+  : Stats::Group(parent),
+  ADD_STAT(numReads, "number of read accesses completed"),
+  ADD_STAT(numWrites, "number of write accesses completed")
 {
-ClockedObject::regStats();

-using namespace Stats;
-
-numReadsStat
-.name(name() + ".num_reads")
-.desc("number of read accesses completed")
-;
-
-numWritesStat
-.name(name() + ".num_writes")
-.desc("number of write accesses completed")
-;
 }

 void
diff --git a/src/cpu/testers/memtest/memtest.hh  
b/src/cpu/testers/memtest/memtest.hh

index 86b27a4..5eb4e35 100644
--- a/src/cpu/testers/memtest/memtest.hh
+++ b/src/cpu/testers/memtest/memtest.hh
@@ -72,7 +72,6 @@
 typedef MemTestParams Params;
 MemTest(const Params *p);

-void regStats() override;

 Port (const std::string _name,
   PortID idx=InvalidPortID) override;
@@ -166,9 +165,13 @@
 const bool atomic;

 const bool suppressFuncErrors;
-
-Stats::Scalar numReadsStat;
-Stats::Scalar numWritesStat;
+  protected:
+struct MemTestStats : public Stats::Group
+{
+MemTestStats(Stats::Group *parent);
+Stats::Scalar numReads;
+Stats::Scalar numWrites;
+} stats;

 /**
  * Complete a request by checking the response.

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34137
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I91b17dd46fd0f70816159ea14c1c8f498048c696
Gerrit-Change-Number: 34137
Gerrit-PatchSet: 3
Gerrit-Owner: Eden Avivi 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: cpu: Set ContextId on request from trace CPU

2020-09-04 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34035 )


Change subject: cpu: Set ContextId on request from trace CPU
..

cpu: Set ContextId on request from trace CPU

Adds a contextId to the trace CPU in one more case that was missing.
Without this a panic is triggered in the cache.

Change-Id: I78bd70ad1e3657c9a6a1d56c234c007c2e2b586c
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34035
Reviewed-by: Bobby R. Bruce 
Maintainer: Bobby R. Bruce 
Tested-by: kokoro 
---
M src/cpu/trace/trace_cpu.cc
1 file changed, 3 insertions(+), 0 deletions(-)

Approvals:
  Bobby R. Bruce: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/trace/trace_cpu.cc b/src/cpu/trace/trace_cpu.cc
index dd91257..13f194c 100644
--- a/src/cpu/trace/trace_cpu.cc
+++ b/src/cpu/trace/trace_cpu.cc
@@ -653,6 +653,9 @@
 node_ptr->physAddr, node_ptr->size, node_ptr->flags, masterID);
 req->setReqInstSeqNum(node_ptr->seqNum);

+// If this is not done it triggers assert in L1 cache for invalid  
contextId

+req->setContext(ContextID(0));
+
 req->setPC(node_ptr->pc);
 // If virtual address is valid, set the virtual address field
 // of the request.

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34035
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I78bd70ad1e3657c9a6a1d56c234c007c2e2b586c
Gerrit-Change-Number: 34035
Gerrit-PatchSet: 2
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Scons minimum version breaks GCN-gpu dockerfile build

2020-09-03 Thread Jason Lowe-Power via gem5-dev
@Daniel Gerzhoy , could you let us know how you
modified the dockerfile?

@Kyle or @Dan, if you can make an update to the dockerfile and push it,
we'd appreciate it.

It's really too bad (and difficult for everyone) that we're stuck on such a
specific version of ROCm :).

Cheers,
Jason

On Thu, Sep 3, 2020 at 11:11 AM Poremba, Matthew 
wrote:

> [AMD Public Use]
>
>
>
> Hi all,
>
>
>
>
>
> I would also be interested if anyone has found a solution to this.  I
> currently cannot test any of the patches I was hoping to finish this week
> due to this issue.  I am not very familiar with docker, and after about 30
> minutes of going through documentation wasn’t even sure how to install
> additional things after the build command. Eventually I ended up rebuilding
> the whole image again.  I’ve also tried adding scons with pip, which seems
> to install the correct “script” for scons, however the “engine” version is
> still pointing to the older copy that ships with 16.04 so that again didn’t
> work. The last thing I am going to try it figure out what is installing the
> system version of scons (apt?) and remove that completely in hopes that it
> only finds the pip version.
>
>
>
>
>
> -Matt
>
>
>
> *From:* Jason Lowe-Power via gem5-dev 
> *Sent:* Wednesday, September 2, 2020 8:03 AM
> *To:* Gabe Black 
> *Cc:* gem5 Developer List ; Kyle Roarty <
> kroa...@wisc.edu>; Jason Lowe-Power 
> *Subject:* [gem5-dev] Re: Scons minimum version breaks GCN-gpu dockerfile
> build
>
>
>
> [CAUTION: External Email]
>
> It's AMD's GPGPU runtime framework: https://rocmdocs.amd.com/en/latest/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Frocmdocs.amd.com%2Fen%2Flatest%2F=02%7C01%7Cmatthew.poremba%40amd.com%7Ce7a7d2e4b29249f2bcb308d84f516166%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637346558243267801=q8hCTHB5S0MYRy4DrbqdM2NKT5WUSyDLAsieiZKbyEI%3D=0>
>
>
>
> From what I can tell (it's been many years since I've worked deeply with
> AMD GPGPUs) the user and kernel APIs change incredibly frequently. So,
> rather than trying to keep up with a moving target, the current GCN
> (graphics core next, which is actually not "next" anymore but a couple of
> generations behind) support in gem5 is tied to a version of ROCm from ~3-5
> years ago. This requires Ubuntu 16.04. Kyle did a great job setting up a
> docker environment with everything that's needed (
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/util/dockerfiles/gcn-gpu/Dockerfile
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5.googlesource.com%2Fpublic%2Fgem5%2F%2B%2Frefs%2Fheads%2Fdevelop%2Futil%2Fdockerfiles%2Fgcn-gpu%2FDockerfile=02%7C01%7Cmatthew.poremba%40amd.com%7Ce7a7d2e4b29249f2bcb308d84f516166%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637346558243277804=A46b5FVp9jRXV7RfP776yNG6gq2vnCBpr%2F7MWtV0Na8%3D=0>).
> Annoyingly, since gem5 (currently) only supports SE mode for GPGPUs you
> have to use the docker container to build benchmarks, build gem5 *and run*
> gem5.
>
>
>
> Matt, Brad, Tony, Kyle and others can probably answer any deeper questions.
>
>
>
> Cheers,
>
> jason
>
>
>
> On Wed, Sep 2, 2020 at 1:46 AM Gabe Black  wrote:
>
> What's a ROCM?
>
>
>
> Gabe
>
>
>
> On Tue, Sep 1, 2020 at 11:43 AM Jason Lowe-Power via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> Hi Dan,
>
>
>
> :facepalm: At least this is on develop and not the stable branch!
>
>
>
> I think we need to get input from Kyle on this since he developed that
> docker image. TBH, I think pip isn't a bad solution given that 16.04 is
> more than four years old and we're stuck with that to support the older
> version of the ROCM stack.
>
>
>
> Creating a jira issue would be appreciated. Please tag Kyle in it, if you
> do that.
>
>
>
> Cheers,
>
> Jason
>
>
>
> On Tue, Sep 1, 2020 at 11:19 AM Daniel Gerzhoy via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> Hey all,
>
>
>
> Pulled latest updates and the minimum version requirement for scons breaks
> the GCN-gpu dockerfile.
>
>
>
> My fix involved installing the latest scons via pip (after installing pip)
> but there is probably a better way to do it (apt-get) but it looks like the
> Ubuntu16.04 base for the DockerFile automatically points to 2.4 not 3.0 and
> I haven't figured out how to get it to install 3.0 instead yet.
>
>
>
> I can open up a Jira ticket as well if that's desirable. (Also if I should
> have just done that instead of sending this email please let me know, still
> learning protocol).
>
>
>
> Thanks,
>
>
>
> Dan
>
> _

[gem5-dev] Change in gem5/gem5[develop]: cpu: Set ContextId on request from trace CPU

2020-09-03 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34035 )



Change subject: cpu: Set ContextId on request from trace CPU
..

cpu: Set ContextId on request from trace CPU

Adds a contextId to the trace CPU in one more case that was missing.
Without this a panic is triggered in the cache.

Change-Id: I78bd70ad1e3657c9a6a1d56c234c007c2e2b586c
Signed-off-by: Jason Lowe-Power 
---
M src/cpu/trace/trace_cpu.cc
1 file changed, 3 insertions(+), 0 deletions(-)



diff --git a/src/cpu/trace/trace_cpu.cc b/src/cpu/trace/trace_cpu.cc
index dd91257..13f194c 100644
--- a/src/cpu/trace/trace_cpu.cc
+++ b/src/cpu/trace/trace_cpu.cc
@@ -653,6 +653,9 @@
 node_ptr->physAddr, node_ptr->size, node_ptr->flags, masterID);
 req->setReqInstSeqNum(node_ptr->seqNum);

+// If this is not done it triggers assert in L1 cache for invalid  
contextId

+req->setContext(ContextID(0));
+
 req->setPC(node_ptr->pc);
 // If virtual address is valid, set the virtual address field
 // of the request.

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34035
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I78bd70ad1e3657c9a6a1d56c234c007c2e2b586c
Gerrit-Change-Number: 34035
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Scons minimum version breaks GCN-gpu dockerfile build

2020-09-02 Thread Jason Lowe-Power via gem5-dev
It's AMD's GPGPU runtime framework: https://rocmdocs.amd.com/en/latest/

>From what I can tell (it's been many years since I've worked deeply with
AMD GPGPUs) the user and kernel APIs change incredibly frequently. So,
rather than trying to keep up with a moving target, the current GCN
(graphics core next, which is actually not "next" anymore but a couple of
generations behind) support in gem5 is tied to a version of ROCm from ~3-5
years ago. This requires Ubuntu 16.04. Kyle did a great job setting up a
docker environment with everything that's needed (
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/util/dockerfiles/gcn-gpu/Dockerfile).
Annoyingly, since gem5 (currently) only supports SE mode for GPGPUs you
have to use the docker container to build benchmarks, build gem5 *and run*
gem5.

Matt, Brad, Tony, Kyle and others can probably answer any deeper questions.

Cheers,
jason

On Wed, Sep 2, 2020 at 1:46 AM Gabe Black  wrote:

> What's a ROCM?
>
> Gabe
>
> On Tue, Sep 1, 2020 at 11:43 AM Jason Lowe-Power via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Hi Dan,
>>
>> :facepalm: At least this is on develop and not the stable branch!
>>
>> I think we need to get input from Kyle on this since he developed that
>> docker image. TBH, I think pip isn't a bad solution given that 16.04 is
>> more than four years old and we're stuck with that to support the older
>> version of the ROCM stack.
>>
>> Creating a jira issue would be appreciated. Please tag Kyle in it, if you
>> do that.
>>
>> Cheers,
>> Jason
>>
>> On Tue, Sep 1, 2020 at 11:19 AM Daniel Gerzhoy via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Hey all,
>>>
>>> Pulled latest updates and the minimum version requirement for scons
>>> breaks the GCN-gpu dockerfile.
>>>
>>> My fix involved installing the latest scons via pip (after installing
>>> pip) but there is probably a better way to do it (apt-get) but it looks
>>> like the Ubuntu16.04 base for the DockerFile automatically points to 2.4
>>> not 3.0 and I haven't figured out how to get it to install 3.0 instead yet.
>>>
>>> I can open up a Jira ticket as well if that's desirable. (Also if I
>>> should have just done that instead of sending this email please let me
>>> know, still learning protocol).
>>>
>>> Thanks,
>>>
>>> Dan
>>> ___
>>> gem5-dev mailing list -- gem5-dev@gem5.org
>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: sim: Add missing overrides in the *Fault classes

2020-09-01 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/33777 )


Change subject: sim: Add missing overrides in the *Fault classes
..

sim: Add missing overrides in the *Fault classes

Change-Id: I7a74df78f0f85ccf7fd896f98b301c1f998c1497
Signed-off-by: Nikos Nikoleris 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33777
Reviewed-by: Gabe Black 
Reviewed-by: Jason Lowe-Power 
Maintainer: Gabe Black 
Tested-by: kokoro 
---
M src/sim/faults.hh
1 file changed, 9 insertions(+), 5 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved
  Gabe Black: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/sim/faults.hh b/src/sim/faults.hh
index e9a57c6..4b5c1a5 100644
--- a/src/sim/faults.hh
+++ b/src/sim/faults.hh
@@ -55,7 +55,11 @@
   public:
 UnimpFault(std::string _str) : panicStr(_str) {}

-FaultName name() const { return "Unimplemented simulator feature"; }
+FaultName
+name() const override
+{
+return "Unimplemented simulator feature";
+}
 void invoke(ThreadContext *tc, const StaticInstPtr  =
 StaticInst::nullStaticInstPtr) override;
 };
@@ -63,7 +67,7 @@
 class ReExec : public FaultBase
 {
   public:
-virtual FaultName name() const { return "Re-execution fault"; }
+virtual FaultName name() const override { return "Re-execution fault";  
}

 void invoke(ThreadContext *tc, const StaticInstPtr =
 StaticInst::nullStaticInstPtr) override;
 };
@@ -78,7 +82,7 @@
 class SyscallRetryFault : public FaultBase
 {
   public:
-virtual FaultName name() const { return "System call retry fault"; }
+FaultName name() const override { return "System call retry fault"; }
 SyscallRetryFault() {}
 void invoke(ThreadContext *tc, const StaticInstPtr =
 StaticInst::nullStaticInstPtr) override;
@@ -89,7 +93,7 @@
   private:
 Addr vaddr;
   public:
-FaultName name() const { return "Generic page table fault"; }
+FaultName name() const override { return "Generic page table fault"; }
 GenericPageTableFault(Addr va) : vaddr(va) {}
 void invoke(ThreadContext *tc, const StaticInstPtr =
 StaticInst::nullStaticInstPtr) override;
@@ -101,7 +105,7 @@
   private:
 Addr vaddr;
   public:
-FaultName name() const { return "Generic alignment fault"; }
+FaultName name() const override { return "Generic alignment fault"; }
 GenericAlignmentFault(Addr va) : vaddr(va) {}
 void invoke(ThreadContext *tc, const StaticInstPtr =
 StaticInst::nullStaticInstPtr) override;

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/33777
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I7a74df78f0f85ccf7fd896f98b301c1f998c1497
Gerrit-Change-Number: 33777
Gerrit-PatchSet: 2
Gerrit-Owner: Nikos Nikoleris 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: kokoro 
Gerrit-CC: Bobby R. Bruce 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Scons minimum version breaks GCN-gpu dockerfile build

2020-09-01 Thread Jason Lowe-Power via gem5-dev
Hi Dan,

:facepalm: At least this is on develop and not the stable branch!

I think we need to get input from Kyle on this since he developed that
docker image. TBH, I think pip isn't a bad solution given that 16.04 is
more than four years old and we're stuck with that to support the older
version of the ROCM stack.

Creating a jira issue would be appreciated. Please tag Kyle in it, if you
do that.

Cheers,
Jason

On Tue, Sep 1, 2020 at 11:19 AM Daniel Gerzhoy via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hey all,
>
> Pulled latest updates and the minimum version requirement for scons breaks
> the GCN-gpu dockerfile.
>
> My fix involved installing the latest scons via pip (after installing pip)
> but there is probably a better way to do it (apt-get) but it looks like the
> Ubuntu16.04 base for the DockerFile automatically points to 2.4 not 3.0 and
> I haven't figured out how to get it to install 3.0 instead yet.
>
> I can open up a Jira ticket as well if that's desirable. (Also if I should
> have just done that instead of sending this email please let me know, still
> learning protocol).
>
> Thanks,
>
> Dan
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: python: Import reduce function in FileSystemConfig

2020-08-31 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/32374 )


Change subject: python: Import reduce function in FileSystemConfig
..

python: Import reduce function in FileSystemConfig

Not sure if this is required due to python3 or something else, but I got
the error "NameError: name 'reduce' is not defined". This fixes that
error.

Change-Id: I2dd71674306abcad1a90311664b18b9eee29b9ac
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32374
Reviewed-by: Gabe Black 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M configs/common/FileSystemConfig.py
1 file changed, 1 insertion(+), 0 deletions(-)

Approvals:
  Gabe Black: Looks good to me, approved
  Jason Lowe-Power: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/configs/common/FileSystemConfig.py  
b/configs/common/FileSystemConfig.py

index ec27656..29041fd 100644
--- a/configs/common/FileSystemConfig.py
+++ b/configs/common/FileSystemConfig.py
@@ -42,6 +42,7 @@
 from m5.objects import *
 from m5.util.convert import *

+from functools import reduce
 import operator, os, platform, getpass
 from os import mkdir, makedirs, getpid, listdir, stat, access
 from pwd import getpwuid

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/32374
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I2dd71674306abcad1a90311664b18b9eee29b9ac
Gerrit-Change-Number: 32374
Gerrit-PatchSet: 2
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Bradford Beckmann 
Gerrit-Reviewer: Brandon Potter 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Matthew Poremba 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: For gem5 20.1: Remove "master" and replace with new "stable" default branch (?)

2020-08-28 Thread Jason Lowe-Power via gem5-dev
+1

Thanks for getting the ball rolling on this, Bobby!

On Fri, Aug 28, 2020 at 5:26 PM Bobby Bruce via gem5-dev 
wrote:

> Dear all,
>
> Back when we moved from the master branch being under constant development
> to a dual "master-as-stable" and "develop" branch setup, there was talk of
> renaming the master branch. Though, at this time, it seemed unconventional
> so avoided doing so. In the past few months there has been greater momentum
> in the direction of allowing git repositories to call their default branch
> whatever they wish. For example, Github is reworking things in this regard (
> https://github.com/github/renaming/) and defaulting new repos to have
> "main" as the default branch.
>
> Our GoogleSource/Gerrit setup allows us to set HEAD to point towards
> whatever branch we wish. We therefore think v20.1 would be a good time to
> rename "master" to "stable". This afternoon I created a "stable" branch,
> identical to "master", here:
> https://gem5.googlesource.com/public/gem5/+/refs/heads/stable. The next
> step would be to redirect HEAD to this branch, then delete the master
> branch. Coinciding this with the release of v20.1 (in roughly 2 weeks time)
> seems like an ideal timing.
>
> I'm writing this email to ask if the community agrees with this, and if
> there is anything I'm not taking into account. I believe this should be a
> fairly seamless transition, and will give our two branches more descriptive
> names  --- stable and develop.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Change in gem5/gem5[develop]: mem-cache: Create Compressor namespace

2020-08-26 Thread Jason Lowe-Power via gem5-dev
It's a good idea to send an email to gem5-users. However, with our new
release model, it should affect many fewer people. It's probably not true
today, but the vision is that the only people who will care if develop
breaks something are people subscribed to gem5-dev :).

Cheers,
Jason

On Wed, Aug 26, 2020 at 12:32 AM Nikos Nikoleris via gem5-dev <
gem5-dev@gem5.org> wrote:

> Do we also need to notify users about this? It might be worth sending an
> email about this. In fact an email with a different subject to both
> gem5-users and gem5-dev as people might ignore emails for a specific CL.
>
> Nikos
>
> On 25/08/2020 23:17, Daniel Carvalho via gem5-dev wrote:
> > Was about to send an e-mail with a heads up, but I guess I was too late.
> >
> > As reported here
> > (
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-753),
> > itis not an issue caused by this patch itself. SCons does not trigger
> > recompilation when a change modifies the cxx_class; therefore,
> > params/BaseCache.hh is not recompiled and generates the error. To solve
> > this, one must manually delete this file and force a recompilation.
> >
> > Regards,
> > Daniel
> >
> > Em terça-feira, 25 de agosto de 2020 21:20:56 GMT+2, mike upton via
> > gem5-dev  escreveu:
> >
> >
> > This checkin breaks the build.
> >
> > you can check at:
> > http://jenkins.gem5.org:8080/job/gem5_develop/136/
> >
> >
> >
> > On Tue, Aug 25, 2020 at 8:13 AM Daniel Carvalho (Gerrit) via gem5-dev
> > mailto:gem5-dev@gem5.org>> wrote:
> >
> > Daniel Carvalho *submitted* this change.
> >
> > View Change <
> https://gem5-review.googlesource.com/c/public/gem5/+/33294>
> >
> > Approvals: Nikos Nikoleris: Looks good to me, approved; Looks good
> > to me, approved kokoro: Regressions pass
> >
> > mem-cache: Create Compressor namespace
> >
> > Creation of the Compressor namespace. It encapsulates all the cache
> > compressors, and other classes used by them.
> >
> > The following classes have been renamed:
> > BaseCacheCompressor -> Base
> > PerfectCompressor - Perfect
> > RepeatedQwordsCompressor -> RepeatedQwords
> > ZeroCompressor -> Zero
> >
> > BaseDictionaryCompressor and DictionaryCompressor were not renamed
> > because the there is a high probability that users may want to
> > create a Dictionary class that encompasses the dictionary contained
> > by these compressors.
> >
> > To apply this patch one must force recompilation (e.g., by deleting
> > it) of build//params/BaseCache.hh (and any other files that
> > were previously using these compressors).
> >
> > Change-Id: I78cb3b6fb8e3e50a52a04268e0e08dd664d81230
> > Signed-off-by: Daniel R. Carvalho  oda...@yahoo.com.br>>
> > Reviewed-on:
> https://gem5-review.googlesource.com/c/public/gem5/+/33294
> > Reviewed-by: Nikos Nikoleris  nikos.nikole...@arm.com>>
> > Maintainer: Nikos Nikoleris  nikos.nikole...@arm.com>>
> > Tested-by: kokoro  noreply%2bkok...@google.com>>
> > ---
> > M src/mem/cache/base.hh
> > M src/mem/cache/compressors/Compressors.py
> > M src/mem/cache/compressors/base.cc
> > M src/mem/cache/compressors/base.hh
> > M src/mem/cache/compressors/base_delta.cc
> > M src/mem/cache/compressors/base_delta.hh
> > M src/mem/cache/compressors/base_delta_impl.hh
> > M src/mem/cache/compressors/base_dictionary_compressor.cc
> > M src/mem/cache/compressors/cpack.cc
> > M src/mem/cache/compressors/cpack.hh
> > M src/mem/cache/compressors/dictionary_compressor.hh
> > M src/mem/cache/compressors/dictionary_compressor_impl.hh
> > M src/mem/cache/compressors/fpcd.cc
> > M src/mem/cache/compressors/fpcd.hh
> > M src/mem/cache/compressors/multi.cc
> > M src/mem/cache/compressors/multi.hh
> > M src/mem/cache/compressors/perfect.cc
> > M src/mem/cache/compressors/perfect.hh
> > M src/mem/cache/compressors/repeated_qwords.cc
> > M src/mem/cache/compressors/repeated_qwords.hh
> > M src/mem/cache/compressors/zero.cc
> > M src/mem/cache/compressors/zero.hh
> > 22 files changed, 231 insertions(+), 165 deletions(-)
> >
> > diff --git a/src/mem/cache/base.hh b/src/mem/cache/base.hh
> > index 3efc7c7..d30de3f 100644
> > --- a/src/mem/cache/base.hh
> > +++ b/src/mem/cache/base.hh
> > @@ -320,7 +320,7 @@
> > BaseTags *tags;
> >
> > /** Compression method being used. */
> > - BaseCacheCompressor* compressor;
> > + Compressor::Base* compressor;
> >
> > /** Prefetcher */
> > Prefetcher::Base *prefetcher;
> > diff --git a/src/mem/cache/compressors/Compressors.py
> > b/src/mem/cache/compressors/Compressors.py
> > index eb1952a..46050f6 100644
> > --- a/src/mem/cache/compressors/Compressors.py
> > +++ b/src/mem/cache/compressors/Compressors.py
> > @@ -1,4 +1,4 @@
> > -# Copyright (c) 2018 Inria
> > +# Copyright (c) 2018-2020 Inria
> > # All rights 

[gem5-dev] Re: switching to python 3 for config scripts?

2020-08-26 Thread Jason Lowe-Power via gem5-dev
Hey Gabe,

We've had many discussions on this in the past couple of months. The
underlying problem is that each distro has decided to do something
different with /usr/bin/python. Some of them allow it to point to python3
others force it to point to python2. This screws up Scons, our scripts, and
lots of other things.

The only solution, as far as we can tell, is to drop support for python2
and switch everything to use python3. I think we should do this after
gem5-20.1 is released.

I've found that if you install python3 and create a symlink from
/usr/bin/python to /usr/bin/python3 (apt install python-is-python3 on
Ubuntu, but not possible on OpenSUSE except manually, not sure about arch)
thing work OK.

Cheers,
Jason

On Tue, Aug 25, 2020 at 11:42 PM Gabe Black via gem5-dev 
wrote:

> Hi folks. We've been moving to python 3 for many things, but for gem5's
> built in python, aka config scripts, we still default to python 2 instead
> of python 3. When do we plan to change that? I ask because I ran into a
> problem where the python 2.7 pyconfig.h doesn't compile correctly on my
> desktop, and since 2.7 is EOL I don't think my distribution (Arch Linux) is
> going to fix it.
>
> I can get it to work by manually saying I want to use python3-config, but
> would it make sense for that to be the default?
>
> Gabe
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: python: Add DeprecatedParam type

2020-08-26 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/31954 )


Change subject: python: Add DeprecatedParam type
..

python: Add DeprecatedParam type

There are times when we need to change the name of parameter, but this
breaks the external-facing python API used in configuration files. Using
this "type" for a parameter will warn users that they are using the old
name, but allow for backwards compatibility.

Declaring a SimObject parameter of type `DeprecatedParam` allows the
python configuration files to use the old name transparently. This
leverages some of the SimObject magic to remember the names of
deprecated parameters and the DeprecatedParam object stores the
"translation" from old name to new name.

This has been tested with Ports, "normal" parameters, and SimObject
parameters. It has not been tested with checkpointing as there are no
checkpointing tests in gem5 right now. The testing was manually adding
some deprecated params and checking that config scripts still run
correctly that use the old, deprecated, variables.

Change-Id: I0465a748c08a24278d6b1a9d9ee1bcd67baa5b13
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31954
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/python/m5/SimObject.py
M src/python/m5/params.py
2 files changed, 105 insertions(+), 1 deletion(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/python/m5/SimObject.py b/src/python/m5/SimObject.py
index 7f12856..7c4c809 100644
--- a/src/python/m5/SimObject.py
+++ b/src/python/m5/SimObject.py
@@ -467,6 +467,12 @@
 cls._params = multidict() # param descriptions
 cls._ports = multidict()  # port descriptions

+# Parameter names that are deprecated. Dict[str, DeprecatedParam]
+# The key is the "old_name" so that when the old_name is used in
+# python config files, we will use the DeprecatedParam object to
+# translate to the new type.
+cls._deprecated_params = multidict()
+
 # class or instance attributes
 cls._values = multidict()   # param values
 cls._hr_values = multidict() # human readable param values
@@ -495,6 +501,7 @@
 cls._base = base
 cls._params.parent = base._params
 cls._ports.parent = base._ports
+cls._deprecated_params.parent = base._deprecated_params
 cls._values.parent = base._values
 cls._hr_values.parent = base._hr_values
 cls._children.parent = base._children
@@ -532,6 +539,15 @@
 elif isinstance(val, Port):
 cls._new_port(key, val)

+# Deprecated variable names
+elif isinstance(val, DeprecatedParam):
+new_name, new_val = cls._get_param_by_value(val.newParam)
+# Note: We don't know the (string) name of this variable  
until

+# here, so now we can finish setting up the dep_param.
+val.oldName = key
+val.newName = new_name
+cls._deprecated_params[key] = val
+
 # init-time-only keywords
 elif key in cls.init_keywords:
 cls._set_keyword(key, val, cls.init_keywords[key])
@@ -604,6 +620,18 @@
 cls._port_refs[attr] = ref
 return ref

+def _get_param_by_value(cls, value):
+"""Given an object, value, return the name and the value from the
+internal list of parameter values. If this value can't be found,  
raise

+a runtime error. This will search both the current object and its
+parents.
+"""
+for k,v in cls._value_dict.items():
+if v == value:
+return k,v
+raise RuntimeError("Cannot find parameter {} in parameter list"
+   .format(value))
+
 # Set attribute (called on foo.attr = value when foo is an
 # instance of class cls).
 def __setattr__(cls, attr, value):
@@ -1255,6 +1283,11 @@
 return ref

 def __getattr__(self, attr):
+if attr in self._deprecated_params:
+dep_param = self._deprecated_params[attr]
+dep_param.printWarning(self._name, self.__class__.__name__)
+return getattr(self, self._deprecated_params[attr].newName)
+
 if attr in self._ports:
 return self._get_port_ref(attr)

@@ -1287,6 +1320,11 @@
 object.__setattr__(self, attr, value)
 return

+if attr in self._deprecated_params:
+dep_param = self._deprecated_params[attr]
+dep_param.printWarning(self._name, self.__class__.__name__)
+return setattr(self, se

[gem5-dev] Re: Problem with libelf

2020-08-24 Thread Jason Lowe-Power via gem5-dev
I finally got back around to this :).

Here's an updated issue and some WIP changes:
https://gem5.atlassian.net/browse/GEM5-752. I updated our code to work with
current libelf, which was pretty simple except for one change from 1998 :D.

There's two things missing:
1. I'm not sure how to tell scons that libelf is required. I hacked
something up in https://gem5-review.googlesource.com/c/public/gem5/+/33317,
but I know it's wrong. Any pointers on the "right" way to do this would be
appreciated. I couldn't find any other example of *required* libs.
2. Need to run more tests to double check nothing breaks.

Cheers,
Jason

On Tue, Aug 11, 2020 at 7:03 PM Gabe Black  wrote:

> I see that we had a local version of libelf as far back as when we started
> using scons in 2004, where we referred to it's SConscript in
> m5/libelf/SConscript (not src/m5 or util/m5, just m5), although that
> directory and all its history seems to have been dropped during one of the
> times we switched version control systems I'd guess, probably from
> bitkeeper to mercurial. I think having a local version is a very old
> historical decision, and only someone who was contemporary could tell you
> about it. My guess is to ensure compatibility, probably particular when the
> gem5 binary gets shipped off to another system to actually run.
>
> Gabe
>
> On Tue, Aug 11, 2020 at 6:49 PM Gabe Black  wrote:
>
>> I'm pretty sure it's been that way "forever", where forever is defined as
>> as far back as I can remember. Looking at the history, I see that Nate
>> replaced a GNU libelf with "autoconf nastiness" (I can imagine), and
>> replaced it with a freeBSD version in 2007, so it's been that way at least
>> as long as that. Maybe it was uncommon in package managers, annoying to
>> install, etc? Maybe there were interface differences? I'll see if I can
>> find record of the older GNU version and see if there are any more commit
>> message clues there. I don't *think* we've done anything to customize
>> libelf, but maybe we have or used to.
>>
>> As far as the linker, the short answer is I don't know how it chooses,
>> but I think I've run into that before with some of the fast model stuff. I
>> don't remember all the specifics, but my comment in
>> src/arch/arm/fastmodel/SConscript says:
>>
>> # We need to use the static libraries as files so that the linker
>> # doesn't use the shared versions of them instead. We need to use
>> # the shared libraries by name so that the linker will apply RPATH
>> # and be able to find them at run time. If a shared libary
>> includes
>> # a path, the dynamic linker will apparently ignore RPATH when
>> looking
>>     # for it.
>>
>> Or in other words, .../build/ARM/libfoo.a and -lfoo for libfoo.so so we
>> can embed what relative path to find that library at in the binary.
>>
>> Gabe
>>
>> On Tue, Aug 11, 2020 at 6:10 PM Jason Lowe-Power via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Hi all,
>>>
>>> Does anyone remember why we have our own libelf in ext? Gabe, you were
>>> recently changing the elf loader, do you have any idea?
>>>
>>> I'm having a huge frustration trying to get gem5 to work with openSUSE.
>>> For some reason, gem5 is picking up the libelf.so file in /usr/lib instead
>>> of the libelf.a in build/libelf/. This is causing a segfault in
>>> ElfObject::determineOpSys() because the Elf_Data returned by libelf.so is
>>> in a different format than what our "special" libelf expects. If I force
>>> gem5 to use libelf.a (by manually linking) things work fine. I've also
>>> double checked in gdb that all of the elf calls are going to the libelf.so
>>> in /usr.
>>>
>>> I guess I have two questions:
>>> 1. Why do we ship libelf and not use the generic one?
>>> 2. Why would the linker prefer the shared lib in /lib instead of the
>>> static lib in build/libelf? Does anyone know how to convince the linker to
>>> grab the right one?
>>>
>>> Thanks,
>>> Jason
>>> ___
>>> gem5-dev mailing list -- gem5-dev@gem5.org
>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Remove CP annotation support?

2020-08-19 Thread Jason Lowe-Power via gem5-dev
Hi all,

Generally, I think that any code that doesn't have tests and we are not
actively supporting should be removed. We can always resurrect it with
about the same amount of work as getting it up to date today. Plus, we can
now say "the code is available in gem5-20."

We have an extremely lean development team, most of which are contributing
to gem5 in their "spare time." Supporting such a sprawling codebase is
taking time away from making deeper and more impactful changes.

In conclusion, I think you should remove the code!

Cheers,
Jason


On Wed, Aug 19, 2020 at 3:31 AM Gabe Black via gem5-dev 
wrote:

> Hi folks. I was doing some spelunking trying to eliminate more ISA related
> dependencies from common code, and I ran across the CPA (critical path
> annotation) support in, among maybe a few other places, base/cp_annotate.cc.
>
> This code can't actually compile since it depends on there being a
> TheISA::IPR_PALtemp23 register index defined, and possibly from that name
> you might guess that that is not actually defined by any ISA anywhere. It
> would have been defined in Alpha, but that's gone now. I vaguely remember
> this being something Ali developed long ago but don't remember anything
> else (or maybe ever knew anything else?) about it. I did see some stuff
> related to it in the pseudoInst code, but it looked like that had been
> partially removed already.
>
> This file is gated behind a CP_ANNOTATE flag accepted by scons which is
> why it doesn't blow up in day to day use.
>
> I think we have three choices as far as what to do with this code:
>
> 1. Leave it alone and keep ignoring it, possibly to do something with it
> in the future.
> 2. Delete it.
> 3. Figure out what it's doing and make it work for other/all ISAs.
>
> Since I don't even really know what it does and it's currently
> uncompilable, my vote would be for number 2. What do other folks think?
>
> Gabe
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Problem with libelf

2020-08-11 Thread Jason Lowe-Power via gem5-dev
Hi all,

Does anyone remember why we have our own libelf in ext? Gabe, you were
recently changing the elf loader, do you have any idea?

I'm having a huge frustration trying to get gem5 to work with openSUSE. For
some reason, gem5 is picking up the libelf.so file in /usr/lib instead of
the libelf.a in build/libelf/. This is causing a segfault in
ElfObject::determineOpSys() because the Elf_Data returned by libelf.so is
in a different format than what our "special" libelf expects. If I force
gem5 to use libelf.a (by manually linking) things work fine. I've also
double checked in gdb that all of the elf calls are going to the libelf.so
in /usr.

I guess I have two questions:
1. Why do we ship libelf and not use the generic one?
2. Why would the linker prefer the shared lib in /lib instead of the static
lib in build/libelf? Does anyone know how to convince the linker to grab
the right one?

Thanks,
Jason
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: arch-mips: Remove old TypeBufferArg call

2020-08-08 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/32414 )


Change subject: arch-mips: Remove old TypeBufferArg call
..

arch-mips: Remove old TypeBufferArg call

TypeBufferArg was replaced by VPtr so this call is no longer needed.
This fixes the MIPS build / nightly build.

Change-Id: I3880229fa0ad87fad1ca35c136e12efc6c36ceda
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32414
Reviewed-by: Gabe Black 
Maintainer: Gabe Black 
Tested-by: kokoro 
---
M src/arch/mips/linux/process.cc
1 file changed, 0 insertions(+), 1 deletion(-)

Approvals:
  Gabe Black: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/arch/mips/linux/process.cc b/src/arch/mips/linux/process.cc
index 8f1ec16..600d053 100644
--- a/src/arch/mips/linux/process.cc
+++ b/src/arch/mips/linux/process.cc
@@ -127,7 +127,6 @@
 // SSI_IEEE_FP_CONTROL
 ConstVPtr fpcr(bufPtr, tc);
 // I don't think this exactly matches the HW FPCR
-fpcr.copyIn(tc->getVirtProxy());
  
DPRINTFR(SyscallVerbose, "sys_setsysinfo(SSI_IEEE_FP_CONTROL): "

" setting FPCR to 0x%x\n", letoh(*fpcr));
 return 0;

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/32414
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I3880229fa0ad87fad1ca35c136e12efc6c36ceda
Gerrit-Change-Number: 32414
Gerrit-PatchSet: 2
Gerrit-Owner: Matthew Poremba 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: Nightly #27

2020-08-07 Thread Jason Lowe-Power via gem5-dev
Feel free to post a fix if you have one!

Cheers,
Jason

On Fri, Aug 7, 2020 at 7:58 AM Poremba, Matthew 
wrote:

> [AMD Public Use]
>
>
>
> The line that has the error should be deleted to fix the MIPS build.  I
> missed that in the review.  I can post a fix if you want but I thought I’d
> give Gabe a chance to take a look.
>
>
>
>
>
> -Matt
>
>
>
> *From:* Jason Lowe-Power via gem5-dev 
> *Sent:* Thursday, August 6, 2020 7:36 AM
> *To:* gem5 Developer List ; Bobby Bruce <
> bbr...@ucdavis.edu>
> *Cc:* Jason Lowe-Power 
> *Subject:* [gem5-dev] Re: Build failed in Jenkins: Nightly #27
>
>
>
> [CAUTION: External Email]
>
> Cool! The nightly builds are "working"! (At least in the sense that they
> let us know when something failed :D)
>
>
>
> It looks like the change that caused this issue is
> https://gem5-review.googlesource.com/c/public/gem5/+/29403
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F29403=02%7C01%7Cmatthew.poremba%40amd.com%7C321f165569a34ae5ac2f08d83a163afb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637323214451683905=t2pzfK9BE3ov5Xt48iAcrZsTghpnMmwHcF7dY1itPgU%3D=0>
> .
>
>
>
> @Bobby Bruce , it might be nice if this message could
> give us links to the commits. If we can't get links to the gerrit easily,
> at least links to gem5.googlesource.com
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgem5.googlesource.com%2F=02%7C01%7Cmatthew.poremba%40amd.com%7C321f165569a34ae5ac2f08d83a163afb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637323214451683905=3eFJM%2B%2FIs6b%2BXhUhw1s1EMVK04DPMjHs0ZHksEuvuY8%3D=0>
> would be useful.
>
>
>
> Cheers,
>
> Jason
>
>
>
> On Thu, Aug 6, 2020 at 1:51 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> See <https://jenkins.gem5.org/job/Nightly/27/display/redirect?page=changes
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjenkins.gem5.org%2Fjob%2FNightly%2F27%2Fdisplay%2Fredirect%3Fpage%3Dchanges=02%7C01%7Cmatthew.poremba%40amd.com%7C321f165569a34ae5ac2f08d83a163afb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637323214451693903=lC8%2FcrUiPWMD2A81%2BG3MA2vZ%2BuHAu4eNOc%2BJKnDQ%2FO4%3D=0>
> >
>
> Changes:
>
> [gabeblack] scons: Remove the plumbing for running regression tests from
> scons.
>
> [gabeblack] tests: Get rid of the tests/tests.py script.
>
> [gabeblack] tests: Get rid of the tests/testing python package.
>
> [gabeblack] tests: Get rid of the now unused diff-out script.
>
> [gabeblack] util: Delete the util/regress script.
>
> [Bobby R. Bruce] utils,tests: Enable passing of build args to
> compiler-tests.sh
>
> [gabeblack] scons: Remove explicitly set defaults in calls to AddOption.
>
> [gabeblack] scons: Delete the now unused --update-ref option.
>
> [gabeblack] sim: Convert stat functions to use VPtr.
>
> [gabeblack] arch: Use VPtr for uname.
>
> [gabeblack] scons: Make src/systemc/tests/SConscript python 3 compatible.
>
> [gabeblack] scons,fastmodel: Limit how many instances of simgen can run at
> once.
>
> [gabeblack] systemc: Filter a pydot warning message out when checking test
> output.
>
> [gabeblack] systemc: Adjust some type names in a couple tests.
>
> [gabeblack] cpu: Remove the "profile" parameter and plumbing.
>
>
> --
> [...truncated 40.75 KB...]
>  [VER TAGS]  -> MIPS/sim/tags.cc
>  [ CXX] MIPS/sim/debug.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MachineType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Wakeup.cc -> .o
>  [LINK]  -> MIPS/cpu/simple/probes/lib.o.partial
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Controller.cc -> .o
>  [ CXX] MIPS/sim/kernel_workload.cc -> .o
>  [ CXX] MIPS/sim/stat_control.cc -> .o
>  [ CXX] MIPS/sim/system.cc -> .o
>  [ CXX] MIPS/sim/faults.cc -> .o
>  [LINK]  -> MIPS/mem/ruby/protocol/lib.o.partial
>  [ CXX] MIPS/sim/process.cc -> .o
>  [ CXX] MIPS/sim/mem_state.cc -> .o
>  [SO PARAM] BaseCPU -> MIPS/params/BaseCPU.hh
>  [ CXX] MIPS/sim/pseudo_ins

[gem5-dev] Change in gem5/gem5[develop]: python: Import reduce function in FileSystemConfig

2020-08-06 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/32374 )



Change subject: python: Import reduce function in FileSystemConfig
..

python: Import reduce function in FileSystemConfig

Not sure if this is required due to python3 or something else, but I got
the error "NameError: name 'reduce' is not defined". This fixes that
error.

Change-Id: I2dd71674306abcad1a90311664b18b9eee29b9ac
Signed-off-by: Jason Lowe-Power 
---
M configs/common/FileSystemConfig.py
1 file changed, 1 insertion(+), 0 deletions(-)



diff --git a/configs/common/FileSystemConfig.py  
b/configs/common/FileSystemConfig.py

index ec27656..29041fd 100644
--- a/configs/common/FileSystemConfig.py
+++ b/configs/common/FileSystemConfig.py
@@ -42,6 +42,7 @@
 from m5.objects import *
 from m5.util.convert import *

+from functools import reduce
 import operator, os, platform, getpass
 from os import mkdir, makedirs, getpid, listdir, stat, access
 from pwd import getpwuid

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/32374
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I2dd71674306abcad1a90311664b18b9eee29b9ac
Gerrit-Change-Number: 32374
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: Nightly #27

2020-08-06 Thread Jason Lowe-Power via gem5-dev
Cool! The nightly builds are "working"! (At least in the sense that they
let us know when something failed :D)

It looks like the change that caused this issue is
https://gem5-review.googlesource.com/c/public/gem5/+/29403.

@Bobby Bruce , it might be nice if this message could
give us links to the commits. If we can't get links to the gerrit easily,
at least links to gem5.googlesource.com would be useful.

Cheers,
Jason

On Thu, Aug 6, 2020 at 1:51 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See  >
>
> Changes:
>
> [gabeblack] scons: Remove the plumbing for running regression tests from
> scons.
>
> [gabeblack] tests: Get rid of the tests/tests.py script.
>
> [gabeblack] tests: Get rid of the tests/testing python package.
>
> [gabeblack] tests: Get rid of the now unused diff-out script.
>
> [gabeblack] util: Delete the util/regress script.
>
> [Bobby R. Bruce] utils,tests: Enable passing of build args to
> compiler-tests.sh
>
> [gabeblack] scons: Remove explicitly set defaults in calls to AddOption.
>
> [gabeblack] scons: Delete the now unused --update-ref option.
>
> [gabeblack] sim: Convert stat functions to use VPtr.
>
> [gabeblack] arch: Use VPtr for uname.
>
> [gabeblack] scons: Make src/systemc/tests/SConscript python 3 compatible.
>
> [gabeblack] scons,fastmodel: Limit how many instances of simgen can run at
> once.
>
> [gabeblack] systemc: Filter a pydot warning message out when checking test
> output.
>
> [gabeblack] systemc: Adjust some type names in a couple tests.
>
> [gabeblack] cpu: Remove the "profile" parameter and plumbing.
>
>
> --
> [...truncated 40.75 KB...]
>  [VER TAGS]  -> MIPS/sim/tags.cc
>  [ CXX] MIPS/sim/debug.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MachineType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Wakeup.cc -> .o
>  [LINK]  -> MIPS/cpu/simple/probes/lib.o.partial
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Controller.cc -> .o
>  [ CXX] MIPS/sim/kernel_workload.cc -> .o
>  [ CXX] MIPS/sim/stat_control.cc -> .o
>  [ CXX] MIPS/sim/system.cc -> .o
>  [ CXX] MIPS/sim/faults.cc -> .o
>  [LINK]  -> MIPS/mem/ruby/protocol/lib.o.partial
>  [ CXX] MIPS/sim/process.cc -> .o
>  [ CXX] MIPS/sim/mem_state.cc -> .o
>  [SO PARAM] BaseCPU -> MIPS/params/BaseCPU.hh
>  [ CXX] MIPS/sim/pseudo_inst.cc -> .o
>  [ CXX] MIPS/sim/syscall_emul.cc -> .o
>  [ CXX] MIPS/sim/syscall_desc.cc -> .o
>  [ CXX] MIPS/cpu/testers/directedtest/DirectedGenerator.cc -> .o
>  [ CXX] MIPS/cpu/o3/probe/simple_trace.cc -> .o
>  [ CXX] MIPS/cpu/o3/probe/elastic_trace.cc -> .o
>  [ CXX] MIPS/cpu/testers/traffic_gen/base.cc -> .o
>  [LINK]  -> MIPS/sim/lib.o.partial
>  [ CXX] MIPS/cpu/testers/traffic_gen/base_gen.cc -> .o
>  [ CXX] MIPS/cpu/testers/traffic_gen/traffic_gen.cc -> .o
>  [ CXX] MIPS/python/_m5/param_AtomicSimpleCPU.cc -> .o
>  [SO PyBind] BaseCPU -> MIPS/python/_m5/param_BaseCPU.cc
>  [ CXX] MIPS/python/_m5/param_BaseCPU.cc -> .o
>  [LINK]  -> MIPS/cpu/o3/probe/lib.o.partial
>  [ CXX] MIPS/python/_m5/param_BaseCache.cc -> .o
>  [LINK]  -> MIPS/cpu/testers/traffic_gen/lib.o.partial
>  [ CXX] MIPS/python/_m5/param_BasePrefetcher.cc -> .o
>  [ CXX] MIPS/python/_m5/param_BaseSetAssoc.cc -> .o
>  [ CXX] MIPS/python/_m5/param_BaseSimpleCPU.cc -> .o
>  [ CXX] MIPS/python/_m5/param_BaseTags.cc -> .o
>  [ CXX] MIPS/python/_m5/param_BaseTrafficGen.cc -> .o
>  [ CXX] MIPS/python/_m5/param_BiModeBP.cc -> .o
>  [ CXX] MIPS/python/_m5/param_BranchPredictor.cc -> .o
>  [ CXX] MIPS/python/_m5/param_Cache.cc -> .o
>  [ CXX] MIPS/python/_m5/param_CheckerCPU.cc -> .o
>  [ CXX] MIPS/python/_m5/param_CoherentXBar.cc -> .o
>  [ CXX] MIPS/python/_m5/param_CommMonitor.cc -> .o
>  [ CXX] MIPS/python/_m5/param_CopyEngine.cc -> .o
>  [ CXX] MIPS/python/_m5/param_DMA_Controller.cc -> .o
>  [ CXX] MIPS/python/_m5/param_DRAMCtrl.cc -> .o
>  [ CXX] MIPS/python/_m5/param_DerivO3CPU.cc -> .o
>  [ CXX] MIPS/python/_m5/param_DirectedGenerator.cc -> .o
>  [ CXX] MIPS/python/_m5/param_Directory_Controller.cc -> .o
>  [ CXX] MIPS/python/_m5/param_DmaDevice.cc -> .o
>  [ CXX] MIPS/python/_m5/param_DummyChecker.cc -> .o
>  [ CXX] MIPS/python/_m5/param_ElasticTrace.cc -> .o
>  [ CXX] MIPS/python/_m5/param_EtherDevBase.cc -> .o
>  [ CXX] MIPS/python/_m5/param_EtherDevice.cc -> .o
> 

[gem5-dev] Change in gem5/gem5[develop]: python: Add DeprecatedParam type

2020-07-29 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/31954 )



Change subject: python: Add DeprecatedParam type
..

python: Add DeprecatedParam type

There are times when we need to change the name of parameter, but this
breaks the external-facing python API used in configuration files. Using
this "type" for a parameter will warn users that they are using the old
name, but allow for backwards compatibility.

Declaring a SimObject parameter of type `DeprecatedParam` allows the
python configuration files to use the old name transparently. This
leverages some of the SimObject magic to remember the names of
deprecated parameters and the DeprecatedParam object stores the
"translation" from old name to new name.

This has been tested with Ports, "normal" parameters, and SimObject
parameters. It has not been tested with checkpointing as there are no
checkpointing tests in gem5 right now. The testing was manually adding
some deprecated params and checking that config scripts still run
correctly that use the old, deprecated, variables.

Change-Id: I0465a748c08a24278d6b1a9d9ee1bcd67baa5b13
Signed-off-by: Jason Lowe-Power 
---
M src/python/m5/SimObject.py
M src/python/m5/params.py
2 files changed, 105 insertions(+), 1 deletion(-)



diff --git a/src/python/m5/SimObject.py b/src/python/m5/SimObject.py
index 7f12856..159ab18 100644
--- a/src/python/m5/SimObject.py
+++ b/src/python/m5/SimObject.py
@@ -467,6 +467,12 @@
 cls._params = multidict() # param descriptions
 cls._ports = multidict()  # port descriptions

+# Parameter names that are deprecated. Dict[str, DeprecatedParam]
+# The key is the "old_name" so that when the old_name is used in
+# python config files, we will use the DeprecatedParam object to
+# translate to the new type.
+cls._deprecated_params = multidict()
+
 # class or instance attributes
 cls._values = multidict()   # param values
 cls._hr_values = multidict() # human readable param values
@@ -532,6 +538,15 @@
 elif isinstance(val, Port):
 cls._new_port(key, val)

+# Deprecated variable names
+elif isinstance(val, DeprecatedParam):
+new_name, new_val = cls._get_param_by_value(val.newParam)
+# Note: We don't know the (string) name of this variable  
until

+# here, so now we can finish setting up the dep_param.
+val.oldName = key
+val.newName = new_name
+cls._deprecated_params[key] = val
+
 # init-time-only keywords
 elif key in cls.init_keywords:
 cls._set_keyword(key, val, cls.init_keywords[key])
@@ -604,6 +619,18 @@
 cls._port_refs[attr] = ref
 return ref

+def _get_param_by_value(cls, value):
+"""Given an object, value, return the name and the value from the
+internal list of parameter values. If this value can't be found,  
raise

+a runtime error. This will search both the current object and its
+parents.
+"""
+for k,v in cls._value_dict.items():
+if v == value:
+return k,v
+raise RuntimeError("Cannot find parameter {} in parameter list"
+   .format(value))
+
 # Set attribute (called on foo.attr = value when foo is an
 # instance of class cls).
 def __setattr__(cls, attr, value):
@@ -1255,6 +1282,11 @@
 return ref

 def __getattr__(self, attr):
+if attr in self._deprecated_params:
+dep_param = self._deprecated_params[attr]
+dep_param.printWarning(self._name, self.__class__.__name__)
+return getattr(self, self._deprecated_params[attr].newName)
+
 if attr in self._ports:
 return self._get_port_ref(attr)

@@ -1287,6 +1319,11 @@
 object.__setattr__(self, attr, value)
 return

+if attr in self._deprecated_params:
+dep_param = self._deprecated_params[attr]
+dep_param.printWarning(self._name, self.__class__.__name__)
+return setattr(self, self._deprecated_params[attr].newName,  
value)

+
 if attr in self._ports:
 # set up port connection
 self._get_port_ref(attr).connect(value)
diff --git a/src/python/m5/params.py b/src/python/m5/params.py
index 2ea614e..695604c 100644
--- a/src/python/m5/params.py
+++ b/src/python/m5/params.py
@@ -2162,6 +2162,71 @@
 ptype_str = 'Port'
 ptype = Port

+class DeprecatedParam(object):
+"""A special type for deprecated parameter variable names.
+
+There are times when we need to change the name of parameter, but this
+breaks the external-facing py

[gem5-dev] Re: Ticks to Cycles

2020-07-24 Thread Jason Lowe-Power via gem5-dev
Hi John,

Yeah, that would work! In the c++ code you can also use the Cycle() object.

Cheers,
Jason

On Fri, Jul 24, 2020 at 3:17 PM John Domingo 
wrote:

> Hi Jason,
>
> If I look at the config.json, I see "clk_domain->clock" under it.
> To manually calculate the number of cycles, can I divide the number of
> ticks by this value ?
>
> Thank you,
> John Domingo
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
> <#m_1664881264737493666_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Fri, Jul 24, 2020 at 5:55 PM Jason Lowe-Power 
> wrote:
>
>> Hi John,
>>
>> The clock domain object should do this conversion for you. If you set a
>> clock to 1 GHz, then when you use "Cycle" in that object it will be
>> converted to 1000 ticks (assuming then normal tick rate of 1ps). Most
>> objects are a "ClockedObject"
>>
>> Cheers,
>> Jason
>>
>> On Fri, Jul 24, 2020 at 2:41 PM John Domingo via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Hello Everyone,
>>>
>>> How can I convert ticks to cycles for the CPU, GPU, Memory, Garnet NoC
>>> etc.
>>> How are these values set in Gem5 ?
>>>
>>> Thank you,
>>> John Domingo
>>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>>  Virus-free.
>>> www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>>> <#m_1664881264737493666_m_-3424119545472373766_m_8866858317461354833_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>> ___
>>> gem5-dev mailing list -- gem5-dev@gem5.org
>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Ticks to Cycles

2020-07-24 Thread Jason Lowe-Power via gem5-dev
Hi John,

The clock domain object should do this conversion for you. If you set a
clock to 1 GHz, then when you use "Cycle" in that object it will be
converted to 1000 ticks (assuming then normal tick rate of 1ps). Most
objects are a "ClockedObject"

Cheers,
Jason

On Fri, Jul 24, 2020 at 2:41 PM John Domingo via gem5-dev 
wrote:

> Hello Everyone,
>
> How can I convert ticks to cycles for the CPU, GPU, Memory, Garnet NoC etc.
> How are these values set in Gem5 ?
>
> Thank you,
> John Domingo
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_8866858317461354833_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: base,sim,python: Add core python API

2020-07-24 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/31756 )



Change subject: base,sim,python: Add core python API
..

base,sim,python: Add core python API

Add documenation to the _m5.core library and add tags to all of the
functions used in this Python API.

When executing help(_m5.core) in Python, there is now a helpful message
printed.

This and following changes are setting up the Python interface for
larger updates. The first step is to improve the documentation.

Issue-on: https://gem5.atlassian.net/browse/GEM5-647
Change-Id: I0f290eb2b689020e53cf4393ec62a9ba1725ddc9
Signed-off-by: Jason Lowe-Power 
---
M src/base/logging.hh
M src/base/socket.hh
M src/base/types.hh
M src/python/pybind11/core.cc
M src/sim/core.cc
M src/sim/core.hh
M src/sim/init.cc
M src/sim/serialize.hh
8 files changed, 114 insertions(+), 28 deletions(-)



diff --git a/src/base/logging.hh b/src/base/logging.hh
index 0c4265b..d97eeac 100644
--- a/src/base/logging.hh
+++ b/src/base/logging.hh
@@ -64,6 +64,9 @@
 NUM_LOG_LEVELS,
 };

+/*
+ * @group api_python_core
+ */
 static void
 setLevel(LogLevel ll)
 {
diff --git a/src/base/socket.hh b/src/base/socket.hh
index 74a379b..eae1faa 100644
--- a/src/base/socket.hh
+++ b/src/base/socket.hh
@@ -38,10 +38,15 @@
 static bool bindToLoopback;

   public:
+/**
+ * @ingroup api_python_core
+ * @{
+ */
 static void disableAll();
 static bool allDisabled();

 static void loopbackOnly();
+/**@}*/ //end of api_python_core

   protected:
 bool listening;
diff --git a/src/base/types.hh b/src/base/types.hh
index 4f606cd..9e93d34 100644
--- a/src/base/types.hh
+++ b/src/base/types.hh
@@ -88,13 +88,17 @@

   public:

-/** Explicit constructor assigning a value. */
+/** Explicit constructor assigning a value.
+ * @ingroup api_python_core
+*/
 explicit constexpr Cycles(uint64_t _c) : c(_c) { }

 /** Default constructor for parameter classes. */
 Cycles() : c(0) { }

-/** Converting back to the value type. */
+/** Converting back to the value type.
+ * @ingroup api_python_core
+ */
 constexpr operator uint64_t() const { return c; }

 /** Prefix increment operator. */
@@ -113,9 +117,15 @@
 constexpr bool operator>(const Cycles& cc) const
 { return c > cc.c; }

+/**
+ * @ingroup api_python_core
+ */
 constexpr Cycles operator +(const Cycles& b) const
 { return Cycles(c + b.c); }

+/**
+ * @ingroup api_python_core
+ */
 constexpr Cycles operator -(const Cycles& b) const
 {
 return c >= b.c ? Cycles(c - b.c) :
diff --git a/src/python/pybind11/core.cc b/src/python/pybind11/core.cc
index 8655d73..9dd26d9 100644
--- a/src/python/pybind11/core.cc
+++ b/src/python/pybind11/core.cc
@@ -210,11 +210,12 @@
 void
 pybind_init_core(py::module _native)
 {
-py::module m_core = m_native.def_submodule("core");
+py::module m_core = m_native.def_submodule("core",
+"Contains gem5 core types and functions.");

 py::class_(m_core, "Cycles")
-.def(py::init<>())
-.def(py::init())
+.def(py::init<>(), "Initializes the cycles to 0.")
+.def(py::init(), "Initializes the cycles to the given  
value")

 .def("__int__", ::operator uint64_t)
 .def("__add__", ::operator+)
 .def("__sub__", ::operator-)
@@ -241,22 +242,51 @@
 ;

 m_core
-.def("setLogLevel", ::setLevel)
-.def("setOutputDir", )
-.def("doExitCleanup", )
+.def("setLogLevel", ::setLevel,
+"Sets the log level to dump all logs at this level and above.")
+.def("setOutputDir", ,
+"Sets the directory for gem5's output files.\n"
+"\n"
+"These files include config.ini, stats.txt, etc.")
+.def("doExitCleanup", ,
+"Do C++ simulator exit processing. Calls all exit callbacks.")

-.def("disableAllListeners", ::disableAll)
-.def("listenersDisabled", ::allDisabled)
-.def("listenersLoopbackOnly", ::loopbackOnly)
-.def("seedRandom", [](uint64_t seed) { random_mt.init(seed); })
+.def("disableAllListeners", ::disableAll,
+"Disable all socket listeners (e.g., gdb, term, etc.).")
+.def("listenersDisabled", ::allDisabled,
+"Returns true if all listeners are disabled.")
+.def("listenersLoopbackOnly", ::loopbackOnly,
+"Binds all listeners to the loopback device.")
+.def("s

[gem5-dev] Call for Ruby reviewers

2020-07-17 Thread Jason Lowe-Power via gem5-dev
Hi all,

Tiago has recently pushed the largest number of Ruby changes we've seen for
quite a while! I'm going to work to get through these in the next week or
so, but it would be good if others with Ruby expertise and that use Ruby
frequently would also give these a look.

I believe this is the top of the review change:
https://gem5-review.googlesource.com/c/public/gem5/+/31421

Tiago, from what I understand, the goal is to enable hardware transactional
memory and prepare for the new coherence protocol that's coming. Is there
any other context we should know to help us review these patches? Are there
other patches I missed? Also, I tried to find some Jira issues to help with
context, but I wasn't sure what was relevant and not. Anything you can do
to help us review would be appreciated!

Cheers,
Jason
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: misc: Add a code of conduct

2020-07-14 Thread Jason Lowe-Power (Gerrit) via gem5-dev
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/30954 )


Change subject: misc: Add a code of conduct
..

misc: Add a code of conduct

This file codifies our current unofficial policies. This doesn't change
the community in any way except for clarifying our policies.

This was modeled off of https://www.contributor-covenant.org/.

Change-Id: Ib976636b490bbe4d46bf79260e6a345b46c02e2c
Signed-off-by: Jason Lowe-Power 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30954
Reviewed-by: Andreas Sandberg 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
A CODE-OF-CONDUCT.md
1 file changed, 135 insertions(+), 0 deletions(-)

Approvals:
  Andreas Sandberg: Looks good to me, approved
  Jason Lowe-Power: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/CODE-OF-CONDUCT.md b/CODE-OF-CONDUCT.md
new file mode 100644
index 000..12b90d8
--- /dev/null
+++ b/CODE-OF-CONDUCT.md
@@ -0,0 +1,135 @@
+
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in  
our
+community a harassment-free experience for everyone, regardless of age,  
body
+size, visible or invisible disability, ethnicity, sex characteristics,  
gender
+identity and expression, level of experience, education, socio-economic  
status,

+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open,  
welcoming,

+diverse, inclusive, and healthy community.
+
+## Scope
+
+This Code of Conduct applies within all community spaces (e.g., mailing  
lists,

+forums, code review platforms, workshops, etc.), and also applies when an
+individual is officially representing the community in public spaces.  
Examples of
+representing our community include using an official e-mail address,  
posting via
+an official social media account, or acting as an appointed representative  
at an

+online or offline event.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our  
mistakes,

+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political  
attacks

+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+The project management committee (PMC) is responsible for clarifying and
+enforcing our standards of acceptable behavior and will take appropriate  
and

+fair corrective action in response to any behavior that they deem
+inappropriate, threatening, offensive, or harmful.
+
+The PMC has the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that  
are
+not aligned to this Code of Conduct, and will communicate reasons for  
moderation

+decisions when appropriate.
+
+See the [governance document](http://www.gem5.org/governance/) for more  
information.

+<http://www.gem5.org/governance/>
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the project management committee (PMC). The point of contact  
for

+code of conduct violations is David Wood (da...@cs.wisc.edu) or any other
+member of the PMC. See the MAINTAINERS file for a list of the current PMC
+members and email addresses.
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of  
the

+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in  
determining
+the consequences for any action they deem in violation of this Code of  
Conduct:

+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior  
deemed

+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders,  
providing

+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single in

[gem5-dev] gem5-20 paper on arXiv

2020-07-08 Thread Jason Lowe-Power via gem5-dev
Hi everyone!

I'm excited to announce that we've published a new gem5 paper! Right now,
it's available on arXiv at this URL: https://arxiv.org/abs/2007.03152

I tried to reach out to everyone who has been involved in gem5 development
since its inception in 2011. However, I'm certain to have missed people.
Plus, I got 100s of emails about this, and I'm sure one fell through the
cracks. If I missed anyone, I'm so sorry!

We will be "releasing" another version of the paper on arXiv in a few
weeks. So, if you spot any errors or if you wish to be included as an
author of the paper and contributed to gem5 between 2011 and gem5 version
20.0, please open an issue on this github repo:
https://github.com/darchr/gem5-20-paper. See the README
 for
authorship information.

If you use gem5-20.0+, we would appreciate it if you would cite this paper.

Cheers,
Jason
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

  1   2   3   4   5   6   7   8   9   10   >