Re: [gem5-dev] Packet ID messages in the protobuf packet trace format

[Andreas Hansson]

Hi Gabe,

The pkt_id field was intentionally left up to the user to populate as they
see fit. Master ID, stream ID, or PC as in the case of the mem_probe used
by the CommMonitor. If you think there is need for another ID, then by all
means we should add it. The question is, could you use the ID that is
already there?

If we change the format I agree we should make the field optional to not
deprecate old traces.

Andreas

On 12/09/2017, 00:24, "gem5-dev on behalf of Gabe Black"
 wrote:

>Hi folks. I'd like to propose adding a new type of message to the
>packet.proto format used for protobuf memory traces.
>
>Currently, packet IDs are opaque numbers which in some hand wavy way
>"identify" a packet, presumably to say where that packet came from
>(instruction, bus master, etc.) Currently there is no in-channel way to
>map
>those numbers to something more useful like an object name. What are
>people's thoughs as far as adding a new message type which would provide
>that information? Off the top of my head, it would make sense to have a
>single message per ID, and to have a single "string" type field which
>would
>be used to describe the meaning of the ID in whatever way was appropriate.
>
>I haven't thought through the specifics very much, so suggestions would be
>very appreciated. Currently I've got a hacky side-channel way to preserve
>that information, but it would be less fragile and inconvenient if that
>was
>preserved directly in the trace itself.
>
>Also, would this warrant a new file format version number, or would the
>fact that the additional messages can be ignored with no ill effect let us
>keep it at the same number?
>
>Gabe
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] "RamBank" SimObject

[Andreas Hansson]

Hi Gabe,

It is not that simple.

The whole point is that the crossbar does any address interleaving, so
that it can be used both for memories and caches (or really any slave
downstream). Moreover, there is no need for a single level of crossbars to
actually have all addresses represented. It can be used to build trees,
diamonds, etc. See the HMC construction for example where we split
addresses across links, then quadrants, and finally to the vaults/channels.

We spent quite some time thinking about how to best represent this, and I
think the best option would actually be to use some form of sub system and
port-group type construct, perhaps combined with a more refined AddrRange.
There are a lot of challenges that need to be addressed though, and
previous whiteboard discussions have not yielded a design that actually
encompasses all the important use-cases.

It would be great to see a good design for this, but it¹s definitely not
obvious what it would be.

Andreas

On 08/08/2017, 03:17, "gem5-dev on behalf of Gabe Black"
 wrote:

>Hi folks. I notice that there's a fair bit of code in MemConfig.py which
>sets up a bank of memory objects to interleave memory accesses among
>themselves and collectively act as a single memory. This seems like
>something which should be bound up into a wrapping object, perhaps a
>RamBank SimObject, which would abstract the complexity of setting up the
>interleaving. There could be a specialized DramBank object which would
>help
>get rid of the ugly issubclass() in create_mem_ctrl function.
>
>Gabe
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] running system C models as gem5 SimObjects

[Andreas Hansson]

Hi Gabe,

The similarity between TLM2 and gem5 is not accidental. We did a lot of
work in 2011 and 2012 to make it that way. In fact, we even created a
version of the gem5 ports that use the 4-phase TLM2 non-blocking protocol,
but ended up never pushing it as it has a fairly sizeable negative
performance impact (15% or so if I remember correctly). We also separated
the actual protocol from the physical port, as in TLM2
(http://reviews.gem5.org/r/1301/), but ended up never pushing it, again
for performance reasons. I still think it would make sense to try and
align the two, but there are undoubtedly challenges.

When it comes to the simulation kernel, the problem you will run into is
that SystemC supports both blocking and non-blocking modelling semantics.
gem5 should be able to wrap SC_METHODS without problems, but will not be
able to deal with SC_THREAD and SC_CTHREAD without the addition of some
form of threading/fibres/contexts. There has been work done in the bast to
add boost fibres to gem5 (we never posted this), and it is definitely
doable, but the devil is in the details.

Overall I strongly support aligning gem5 and SystemC further. The best
outcome, in my view, would be if gem5 was transitioned to work on the
SystemC kernel, allowing interoperability and more elaborate event
semantics, and then also transitioned to use the TLM ports. That would be
quite a work package though.

Andreas

On 26/07/2017, 01:53, "gem5-dev on behalf of Gabe Black"
 wrote:

>Hi folks. As a part of some work I'm doing, I've been considering what it
>would take to run system C models inside gem5 as SimObjects. I'm working
>through some reading material I have about system C, but I haven't
>actually
>tried writing any of it yet. This seems similar to the work that was done
>to allow running gem5 as a system C model, but sort of in reverse and at a
>finer granularity, ie each object as its own thing and not system C as a
>large black box.
>
>One thing I was wondering is what sort of complications might make that
>not
>work out. So far, I can imagine how to adapt the system C model into gem5
>without too much fuss, but there's still a lot of pages left in the book
>I'm reading and I haven't touched the actual spec yet. What was the
>thinking behind putting gem5 into system C and not doing something like
>what I'm thinking of?
>
>Another thing I'm wondering about is whether it would make sense to try to
>replace gem5's port protocol with the one in system C. Obviously that
>would
>involve touching a lot of code, but I was surprised at how similar the
>system C port setup and the gem5 one are. It might be nice generally to
>use
>a standardized mechanism that people might already be familiar with and
>have an implementation against. That might also obviate the
>bridging/adapter ports that are in the current system C/gem5 integration
>mechanism. Thoughts?
>
>Gabe
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] system C reading material

[Andreas Hansson]

Hi Gabe,

I think the best resource is Doulos:
https://www.doulos.com/knowhow/systemc/

For an up-to-date view of what is going on, it is usually best to see what
is being presented at recent events: http://www.accellera.org/news/events
with the latest SystemC evolution day being a great example:
http://www.accellera.org/news/events/systemc-evolution-day-2016

Andreas


On 02/06/2017, 10:43, "gem5-dev on behalf of Gabe Black"
 wrote:

>Hi folks that know about system C stuff. I'm interested in learning about
>system C and am started mostly but not entirely from scratch. Is there any
>good book or website to read to get a good working knowledge of what all
>the pieces, how they work together, how to use them, etc.? Maybe something
>akin to an O'Reilly book? Any advice is appreciated.
>
>Gabe
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] use of C++ exceptions

[Andreas Hansson]

Google’s C++ guide nicely sums it up:
https://google.github.io/styleguide/cppguide.html#Exceptions

I am not against using exceptions as long as they are only used inside
modules, after careful consideration, and never leaks into the public API
of a module/block.

Andreas

On 10/05/2017, 22:37, "gem5-dev on behalf of nathan binkert"
<gem5-dev-boun...@gem5.org on behalf of n...@binkert.org> wrote:

>This is super historical.  We chose not to use exceptions because we were
>worried that they were "slow".  That's largely just not true anymore.
>IMHO, exceptions definitely have their place.  They're super useful when
>dealing with rare error cases that need to fail a deep call tree.  They
>can
>reduce the number of lines of code by a ton.  There are pitfalls and
>people
>need to know what they're doing (i.e. don't throw in a destructor).
>
>  Nate
>
>On Wed, May 10, 2017 at 9:36 AM, Andreas Sandberg
><andreas.sandb...@arm.com>
>wrote:
>
>> Having had a quick look at the code, I'd say that exceptions could
>> definitely make sense. I would support limited use of exceptions where
>> it makes sense to make the code flow less entangled. Initially, I would
>> argue that we should keep exceptions local to SimObjects (interfaces
>> like ports should never have to deal with exceptions) and only be used
>> for recoverable errors (e.g., unexpected input that should result in a
>> warning).
>>
>> Are there any technical reason why we aren't using exceptions?
>>
>> //Andreas
>>
>>
>> On 10/05/2017 08:25, Gabe Black wrote:
>>
>>> This would be internal to the gdb code, ie if a read from the socket
>>> fails,
>>> it would detach and throw an exception which would unwind back out of
>>>all
>>> the gdb stuff without having to add ifs all over the place. This bit of
>>> code doesn't really have an external interface, so it wouldn't be
>>>visible
>>> to the caller, assuming a stray exception didn't escape somehow. I
>>>think
>>> it
>>> would be a little nicer that way, but not so much that I'd want to
>>>argue
>>> for it very strongly.
>>>
>>> Gabe
>>>
>>> On Wed, May 10, 2017 at 12:09 AM, Andreas Hansson <
>>> andreas.hans...@arm.com>
>>> wrote:
>>>
>>> Hi Gabe,
>>>>
>>>> I do not think adding exceptions will make things any less cluttered.
>>>>It
>>>> will simply move that complexity to any caller, will it not? I am not
>>>>a
>>>> fan of exceptions in general as it mucks with the control flow.
>>>>
>>>> Andreas
>>>>
>>>> On 10/05/2017, 07:31, "gem5-dev on behalf of Gabe Black"
>>>> <gem5-dev-boun...@gem5.org on behalf of gabebl...@google.com> wrote:
>>>>
>>>> Hi folks. I have a change to make the GDB stub in gem5 a bit less
>>>>> fragile:
>>>>>
>>>>> https://gem5-review.googlesource.com/#/c/3180/
>>>>>
>>>>> Unfortunately that involved adding a lot of error code checking which
>>>>> makes
>>>>> things a bit cluttered and ugly. I think it would be a lot nicer to
>>>>>use
>>>>> exceptions, but I remember those being a no-no. Are they currently
>>>>> against
>>>>> the rules, or could I use them to make that code a bit nicer?
>>>>>
>>>>> Gabe
>>>>> ___
>>>>> gem5-dev mailing list
>>>>> gem5-dev@gem5.org
>>>>> http://m5sim.org/mailman/listinfo/gem5-dev
>>>>>
>>>> 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
>>>> http://m5sim.org/mailman/listinfo/gem5-dev
>>>>
>>> ___
>>> gem5-dev mailing list
>>> gem5-dev@gem5.org
>>> http://m5sim.org/mailman/listinfo/gem5-dev
>>>
>>
>> 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
>> http://m5sim.org/mailman/listinfo/gem5-dev
>>
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] use of C++ exceptions

[Andreas Hansson]

Hi Gabe,

I do not think adding exceptions will make things any less cluttered. It
will simply move that complexity to any caller, will it not? I am not a
fan of exceptions in general as it mucks with the control flow.

Andreas

On 10/05/2017, 07:31, "gem5-dev on behalf of Gabe Black"
 wrote:

>Hi folks. I have a change to make the GDB stub in gem5 a bit less fragile:
>
>https://gem5-review.googlesource.com/#/c/3180/
>
>Unfortunately that involved adding a lot of error code checking which
>makes
>things a bit cluttered and ugly. I think it would be a lot nicer to use
>exceptions, but I remember those being a no-no. Are they currently against
>the rules, or could I use them to make that code a bit nicer?
>
>Gabe
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] testing the gem5 library

[Andreas Hansson]

Hi Gabe,

The best would be to test the SystemC main.cc which is in util/systemc and
links to libgem5. I know that Matthias has worked on getting SystemC
included in ext so that we can build this all as part of the regressions.

Andreas

On 28/04/2017, 22:13, "gem5-dev on behalf of Gabe Black"
 wrote:

>Hey folks. Does anyone know of a way to verify that the gem5 library
>(build/ARM/libgem5_opt.so, for instance) still works? I have a change
>ready
>to go which affects how it's built, and I'd like to make sure I haven't
>broken the library version of things before I check it in.
>
>Gabe
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] annoying rebuild of swig wrappers during NULL build

[Andreas Hansson]

Note that Swig is about to be removed and replaced with Pybind11. Perhaps
the problem will still be there, but don’t invest time if that’s not the
case.

Andreas

On 22/04/2017, 00:55, "gem5-dev on behalf of Steve Reinhardt"
 wrote:

>Yup, I remember getting frustrated by this and looking into it and
>realizing that the problem is that the dependencies get reordered. Seemed
>like the right thing would be to sort the dependencies at the right point
>so that the insertion order doesn't matter, but I never figured out when
>or
>how to do that, so I gave up. Best wishes on finding a solution!
>
>Steve
>
>
>On Fri, Apr 21, 2017 at 4:36 PM, Gabe Black  wrote:
>
>> Hi folks. I've been looking into why the swig wrappers are all rebuilt
>>even
>> after a successful build when nothing has changed. I think I know why,
>>but
>> I'm not quite sure how to fix it.
>>
>> Basically, when scons scans the files looking for dependencies using the
>> ClassicCPP scanner class (which has been used to build a swig scanner),
>>it
>> will recursively look through dependencies which are identified in an
>> earlier pass. This makes sense for regular-ole-C, where that might be
>>the
>> only way to identify dependencies from nested includes. If it gets to a
>> point where there's an include and there isn't a file for it yet
>>(because
>> it's a generated file probably), then it will stop recursing. Later on,
>> when that file is actually generated, its dependencies will be scanned
>>for,
>> and will transitively become dependencies for the original file (I
>>think).
>>
>> This leads to a problem where the files involved don't exist in the
>>first
>> build, but older versions of them do exist in subsequent builds. The
>>first
>> build will stop recursing when it hits those files and their
>>dependencies
>> won't be added. The later builds will be able to recurse into those
>>files,
>> however, and they'll add those dependencies right away. The list of
>> dependencies are correct in either case (at least as far as I can tell),
>> but because they're added in a different way the order is different.
>> Because scons is really picky, the dependency ordering change causes
>>those
>> files to be "rebuilt", resulting in an identical tree.
>>
>> Subsequent NULL builds will have the same dependency ordering as the
>>second
>> build, assuming nothing else has changed, and so the annoying swig
>>rebuild
>> won't happen.
>>
>> At this point I'm sort of at a loss as to what to do, because this
>>seems to
>> just be something broken in how scons handles scanning for dependencies
>>in
>> generated files. If anybody has any ideas, please let me know. This
>>isn't
>> anything that urgently needs fixing, but it would be nice to knock off
>>that
>> rough edge.
>>
>> Gabe
>> ___
>> gem5-dev mailing list
>> gem5-dev@gem5.org
>> http://m5sim.org/mailman/listinfo/gem5-dev
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] scons question

[Andreas Hansson]

The best solution, in my view, would be to link the various subdirectories
into static libraries, libbase.a etc, and do so independent of the ISA
that is being built. Everything besides the arch and dev tree should then
be able to be built once, and the linking also ends up being hierarchical.

Andreas

On 13/04/2017, 17:50, "gem5-dev on behalf of Gabe Black"
 wrote:

>Oh, I bet you're right. They actually spawn something like 'sh', '-c', '
>'.join(args), and I bet sh (which is symlinked to /bin/bash) is blowing up
>because the command line is very long. I remember my terminal asking if I
>really wanted to copy/paste something like 129K characters when trying to
>copy the command line to run it outside of scons.
>
>Now to figure out how to fix it...
>
>On Thu, Apr 13, 2017 at 8:02 AM, Beckmann, Brad 
>wrote:
>
>> Have you investigated the length of the linker command when building
>>from
>> outside the gem5 directory?  In the past, we've seen that mysterious
>>error
>> 127 because the linker stage uses a shell command length that exceeds
>>the
>> length supported by the OS.  64KB I believe.  I suspect that the
>>filenames
>> are longer when building outside of gem5, thus it only happens in that
>> situation.  The linker command may be shorter using clang as well.
>>
>> Brad
>>
>>
>>
>> -Original Message-
>> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe
>>Black
>> Sent: Thursday, April 13, 2017 1:53 AM
>> To: gem5 Developer List 
>> Subject: [gem5-dev] scons question
>>
>> Hi folks. I'm fighting with a very confusing problem with scons at the
>> moment. For reasons I haven't determined, when I have things set up to
>> build when scons is run from outside the gem5 directory (using -C), it
>> fails the final linker step with error 127 and no other output 100% of
>>the
>> time. If I run from within the gem5 directory everything works fine.
>>
>> I did some reading, and bash reports error 127 when it can't find the
>> command you asked it to run. To determine if that might be the problem,
>>I
>> modified scons to run "which" on each command it was about to spawn
>>before
>> it did, to make sure it resolved to something. That worked just fine.
>>If I
>> run the command manually, it returns exit code 0. If I take the
>>environment
>> scons tries to run g++ under and partially duplicate that with a script
>>and
>> env -i, it still succeeds.
>>
>> If I run with clang instead of g++, I get the same behavior which makes
>>me
>> think it's not g++ doing something weird, it's scons. I can't for the
>>life
>> of me figure out what though, and I can't seem to get any information to
>> work with other than this mysterious error 127.
>>
>> If any of you have any idea why it's doing what it's doing, or if
>>there's
>> any information I can gather that might help, I would be very happy to
>>hear
>> it.
>>
>> Gabe
>> ___
>> gem5-dev mailing list
>> gem5-dev@gem5.org
>> http://m5sim.org/mailman/listinfo/gem5-dev
>> ___
>> gem5-dev mailing list
>> gem5-dev@gem5.org
>> http://m5sim.org/mailman/listinfo/gem5-dev
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] More problems in SE land

[Andreas Hansson]

Great. Thanks Brandon.

Just shout if you need any help testing it out.

Andreas

From: "Potter, Brandon" <brandon.pot...@amd.com<mailto:brandon.pot...@amd.com>>
Date: Friday, 10 March 2017 at 08:31
To: Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>>, 
gem5 Developer List <gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>>
Subject: RE: More problems in SE land

I will post a patch to fix the compilation problem in the next few days.

-Brandon

From: Andreas Hansson [mailto:andreas.hans...@arm.com]
Sent: Friday, March 10, 2017 2:29 AM
To: gem5 Developer List <gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>>
Cc: Potter, Brandon <brandon.pot...@amd.com<mailto:brandon.pot...@amd.com>>
Subject: Re: More problems in SE land

Merely a reminder that this is still broken.

Andreas

From: Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>>
Date: Tuesday, 7 March 2017 at 08:54
To: gem5 Developer List <gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>>
Subject: More problems in SE land

Hi all (and Brandon in particular),

More problems in SE land I’m afraid. The following changeset prevents gem5 from 
building on macOS:

commit 2367198921765848a4f5b3d020a7cc5776209f80
Author: Brandon Potter <brandon.pot...@amd.com<mailto:brandon.pot...@amd.com>>
Date:   Mon Feb 27 14:10:15 2017 -0500

syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess 
simulations

Modifies the clone system call and adds execve system call. Requires 
allowing
processes to steal thread contexts from other processes in the same system
object and the ability to detach pieces of process state (such as MemState)
to allow dynamic sharing.

The result is the following:

build/ARM/sim/process.cc:157:9: error: use of undeclared identifier 'CLONE_VM'
if (CLONE_VM & flags) {
^
build/ARM/sim/process.cc:187:9: error: use of undeclared identifier
  'CLONE_FILES'
if (CLONE_FILES & flags) {
^
build/ARM/sim/process.cc:227:9: error: use of undeclared identifier
  'CLONE_THREAD'
if (CLONE_THREAD & flags) {
^
3 errors generated.

I am inclined to suggest we create a linux_process.cc or similar for all the 
sys calls that are only available on Linux (to avoid ifdef’s all over the 
place).

Andreas

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.
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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] More problems in SE land

[Andreas Hansson]

Merely a reminder that this is still broken.

Andreas

From: Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>>
Date: Tuesday, 7 March 2017 at 08:54
To: gem5 Developer List <gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>>
Subject: More problems in SE land

Hi all (and Brandon in particular),

More problems in SE land I’m afraid. The following changeset prevents gem5 from 
building on macOS:

commit 2367198921765848a4f5b3d020a7cc5776209f80
Author: Brandon Potter <brandon.pot...@amd.com<mailto:brandon.pot...@amd.com>>
Date:   Mon Feb 27 14:10:15 2017 -0500

syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess 
simulations

Modifies the clone system call and adds execve system call. Requires 
allowing
processes to steal thread contexts from other processes in the same system
object and the ability to detach pieces of process state (such as MemState)
to allow dynamic sharing.

The result is the following:

build/ARM/sim/process.cc:157:9: error: use of undeclared identifier 'CLONE_VM'
if (CLONE_VM & flags) {
^
build/ARM/sim/process.cc:187:9: error: use of undeclared identifier
  'CLONE_FILES'
if (CLONE_FILES & flags) {
^
build/ARM/sim/process.cc:227:9: error: use of undeclared identifier
  'CLONE_THREAD'
if (CLONE_THREAD & flags) {
^
3 errors generated.

I am inclined to suggest we create a linux_process.cc or similar for all the 
sys calls that are only available on Linux (to avoid ifdef’s all over the 
place).

Andreas

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
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] More problems in SE land

[Andreas Hansson]

Hi all (and Brandon in particular),

More problems in SE land I’m afraid. The following changeset prevents gem5 from 
building on macOS:

commit 2367198921765848a4f5b3d020a7cc5776209f80
Author: Brandon Potter 
Date:   Mon Feb 27 14:10:15 2017 -0500

syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess 
simulations

Modifies the clone system call and adds execve system call. Requires 
allowing
processes to steal thread contexts from other processes in the same system
object and the ability to detach pieces of process state (such as MemState)
to allow dynamic sharing.

The result is the following:

build/ARM/sim/process.cc:157:9: error: use of undeclared identifier 'CLONE_VM'
if (CLONE_VM & flags) {
^
build/ARM/sim/process.cc:187:9: error: use of undeclared identifier
  'CLONE_FILES'
if (CLONE_FILES & flags) {
^
build/ARM/sim/process.cc:227:9: error: use of undeclared identifier
  'CLONE_THREAD'
if (CLONE_THREAD & flags) {
^
3 errors generated.

I am inclined to suggest we create a linux_process.cc or similar for all the 
sys calls that are only available on Linux (to avoid ifdef’s all over the 
place).

Andreas

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3814: misc: Add a CONTRIBUTING document

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3814/#review9503
---

Ship it!


Please go ahead with this and we can fine tune later. Could you also update 
http://gem5.org/Submitting_Contributions accordingly?

- Andreas Hansson


On Feb. 21, 2017, 5:34 p.m., Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3814/
> ---
> 
> (Updated Feb. 21, 2017, 5:34 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> changesets:
>   11849:b5f456096b51 "misc: Add a CONTRIBUTING document
> 
> This document details how to contribute to gem5 based on our new
> contribution flow with git and gerrit.
> 
> Signed-off-by: Jason Lowe-Power <ja...@lowepower.com>"
> 
> 
> Diffs
> -
> 
>   CONTRIBUTING.md PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3814/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Best method for adding code to ext/

[Andreas Hansson]

Hi Jason,

How would we keep the external repos in sync? Can a subrepo refer to a
specific version?

Also note that we need to keep GPL code out of gem5 (including binaries),
not just the source tree, so your bad point (3) below doesn’t change
either way.

Andreas



On 03/03/2017, 19:35, "gem5-dev on behalf of Jason Lowe-Power"
 wrote:

>Hi all,
>
>There are a couple of patches in review that add a large chunk of code
>from
>other repositories to gem5 in ext/. Andreas S. has a patch that adds
>PyBind11 and Matthias is updating DRAMPower. And we're thinking about
>including SystemC in a similar way.
>
>Is there a better way for us to include these other projects in gem5's
>source tree? For instance, we could use subrepos. What is the community's
>thoughts on this?
>
>A few things I don't like about including the code in gem5:
>1) It increases the amount of code in our repository
>2) It is hard to track updates to these systems
>3) The code cannot be GPL.
>
>Good thing about including the code in gem5:
>1) Updates to external code won't break our system
>2) It's easy to build gem5 without having to download other software
>
>Any other opinions or options for this?
>
>Thanks,
>Jason
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] ISA Deprecation

[Andreas Hansson]

Hi all,

I am in favour of revisiting this on a regular basis. Our previous
discussion started with SPARC being the #1 candidate for removal (due to
level of functionality and lack of testing as well as maintainers), but
eventually we landed on ALPHA being a more likely candidate (due to
absence of an up-to-date tool chain and modern kernels etc).

What I would propose to make some progress is to update
http://gem5.org/Supported_Architectures with a simple table, for each ISA:

Maintainers (none, or a list of names)

Level of functionality/ISA support (low, med, high)
OS support (Linux, BSD, etc)
Test coverage (low, med, high)
Tool chain availability (yes, no)
Kernel availability (yes, no)

Others? Are these the right ones?

Then for each ISA it is fairly obvious which ones are candidates for
removal, based on our priorities.

Brandon, would you be happy to take a first stab at such a table?

Andreas


On 27/02/2017, 18:01, "gem5-dev on behalf of Potter, Brandon"
 wrote:

>Hi Jason,
>
>Thanks for the links; I was not aware that they existed.
>
>I am not going to try to press the issue if others want to keep the ISAs.
>I was not sure what the consensus was on keeping them, but it seems that
>some folks want them to stick around.
>
>Regards,
>Brandon
>
>-Original Message-
>From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason
>Lowe-Power
>Sent: Monday, February 27, 2017 10:24 AM
>To: gem5 Developer List 
>Subject: Re: [gem5-dev] ISA Deprecation
>
>Hi Brandon,
>
>See this discussion for some of the history here:
>http://comments.gmane.org/gmane.comp.emulators.m5.devel/30510
>
>Let me try to summarize for everyone.
>
>There are a number of reasons to deprecate/phase out most of the
>supported ISAs. Briefly:
> - Less work for contributors especially when updating SE mode
> - Less testing time
> - Some ISAs have no maintainer
> - Some ISAs have (basically) no tests, or the tests are proprietary
> - Causes confusion for users (e.g., they run experiments with an
>incomplete ISA, or worse)
>
>However, some people *do* use the code for ISAs other than x86, ARM,
>RISC-V, and HSAIL. For instance:
> - From Jakub "[gem5 is] the only existing and basically working open
>source sun4v simulator.
> - Boris uses gem5's support for MIPS and POWER to do retargetable
>compiler research, and "dropping them would be pretty much equivalent to
>discontinuing GEM5 altogether"
>
>I think Steve makes one of the best arguments both for and against this
>in this message:
>http://www.mail-archive.com/gem5-dev@gem5.org/msg19429.html.
>
>-- My opinions below:
>
>From our discussion at HPCA, I think it comes down to "what does the
>community want gem5 to be?" Right now, gem5 has a wide variety of
>different use cases. I think we need to decide as a community what use
>cases we want to support and focus our limited developer time on those
>use cases. For instance, do we think it is worth it to support MIPS
>emulation?
>
>Maybe someone can come up with a list of "gem5 use cases" for us to look
>at and discuss. I don't have time in the next week or so, but after that
>I'll put it on my to do list.
>
>At a higher level, I strongly believe we need to take a step back and
>make sure that gem5 is serving its users as best as it can. There's a lot
>of unmaintained code in gem5 that is hurting and not helping. For
>instance, it would be great if Brandon could focus his time purely on
>improving x86 SE mode, which many people use, and not fixing bugs with
>SPARC.
>
>Cheers,
>Jason
>
>On Thu, Feb 23, 2017 at 4:47 PM Potter, Brandon 
>wrote:
>
>Hello all,
>
>A colleague mentioned that ISA deprecation was discussed during the recent
>gem5 meeting. I am wondering what the community's feelings are toward the
>idea and which ISAs would be on the chopping block. Personally, I'd like
>to kill ALPHA, MIPS, POWER, and SPARC. This means that we'd retain X86,
>ARM, RISCV, and HSAIL-X86.
>
>I can help out with the removal if we decide that we want to kill some of
>them. We might wait until March 1st to start the process since we're
>supposed to transition to fully transition to Git on that day; we could
>create a tag for the ISA deprecation in case someone wants to revive one
>of them in the future (i.e. MIPS or POWER if someone wants to maintain
>them).
>
>Regards,
>Brandon
>
>
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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 

Re: [gem5-dev] Review Request 3812: ext: Include SystemC 2.3.1 into gem5

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3812/#review9485
---


I think this is a good step in the right direction, and it has the potential of 
greatly enhancing the support for gem5 in SystemC environments. The only 
question is have is with respect to our current build process for gem5-SystemC, 
and how it interacts with the with/without Python build.

Could we eventually have one executable that can do both SC and non-SC, and 
then only leave the with/without Python as an option? What combinations 
actually make sense, and what is the overhead if we were to always include SC?

I think having "one executable to rule them all" would also help tremendously 
with testing, but perhaps there are other ways of keeping this working.

On a separate note, I think it would be really interesting if someone skilled 
in the arts could take a stab at moving gem5 to use the SystemC event kernel. 
This would enable a more elaborate set of tools and modelling paradirms, 
including SC_THREAD/SC_CTHREAD style concepts that work very well for state 
machines. Clearly this is off topic for the patch, but I am keen to know if 
anyone has already progress this train of thought, or would be keen to discuss 
the options.

- Andreas Hansson


On Feb. 14, 2017, 8:33 p.m., Matthias Jung wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3812/
> ---
> 
> (Updated Feb. 14, 2017, 8:33 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11837:f68a638dd4c7
> ---
> ext: Include SystemC 2.3.1 into gem5
> 
> In the past it happened several times that some changes in gem5 broke the
> SystemC coupling. Recently Accelera has changed the licence for SystemC from
> their own licence to Apache2.0, which is compatible with gem5. However, 
> SystemC
> usually relies on the Boost library, but I was able to exchange the boost 
> calls
> by c++11 alternatives. The recent SystemC version is placed into /ext and is
> integrated into gem5's build system. The goal is to integrate some SystemC
> tests for the CI in some following patches.
> 
> 
> Diffs
> -
> 
>   ext/systemc/src/sysc/utils/sc_pq.cpp PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_pvector.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_report.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_report.cpp PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_report_handler.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_report_handler.cpp PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_stop_here.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_stop_here.cpp PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_string.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_string.cpp PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_temporary.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_utils_ids.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_utils_ids.cpp PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_vector.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_vector.cpp PRE-CREATION 
>   ext/systemc/src/systemc PRE-CREATION 
>   ext/systemc/src/systemc.h PRE-CREATION 
>   ext/systemc/src/tlm PRE-CREATION 
>   ext/systemc/src/tlm.h PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm.pc.in PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/README.txt PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_analysis/tlm_analysis.h PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_analysis/tlm_analysis_fifo.h 
> PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_analysis/tlm_analysis_if.h PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_analysis/tlm_analysis_port.h 
> PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_analysis/tlm_analysis_triple.h 
> PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_analysis/tlm_write_if.h PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_core_ifs.h 
> PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_fifo_ifs.h 
> PRE-CREATION 
>   
> ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_master_slave_ifs.h
>  PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_tag.h 
> PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_adapters/tlm_adapters.h 
> PRE-CREATION 
>   
> ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/circular_buffer.h
>  PRE-CREATION 
>   ext/systemc/src/

Re: [gem5-dev] Review Request 3827: python: Use PyBind11 instead of SWIG for Python wrappers

[Andreas Hansson]

> On Feb. 23, 2017, 9:37 p.m., Tony Gutierrez wrote:
> > This seems like a welcome change. A question: are there any requirements 
> > for using PyBind besides Python 2.7 or 3.x and the std clibs? I see that 
> > the PyBind GitHub only mentions these dependencies, and I wanted to get 
> > confirmation based on your experiences using it.
> 
> Andreas Sandberg wrote:
> There shouldn't be any external dependencies other than Python 2.7/3.x 
> and C++11. I have tested it with gcc 4.8 our CI system (RHEL 6.6), gcc 6.2, 
> and clang 3.8. I haven't seen any issues other than a weird clang error 
> (possibly a clang bug) related to the PyEventDeleter class. I have updated 
> the patch to work around that issue.

Great stuff!

Could we get some coverage from devs to make sure this works across the board:

1) BSD, Bjoern et al?
2) macOS (OSX works on my machine, so likely not a problem)
3) anyone else that has a less-well-tested build environment?


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3827/#review9469
---


On Feb. 24, 2017, 10:20 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3827/
> ---
> 
> (Updated Feb. 24, 2017, 10:20 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11884:e0f1c63a8440
> ---
> python: Use PyBind11 instead of SWIG for Python wrappers
> 
> Use the PyBind11 wrapping infrastructure instead of SWIG to generate
> wrappers for functionality that needs to be exported to Python. This
> has several benefits:
> 
>   * PyBind11 can be redistributed with gem5, which means that we have
> full control of the version used. This avoid a large number of
> hard-to-debug SWIG issues we have seen in the past.
> 
>   * PyBind11 doesn't rely on a custom C++ parser, instead it relies on
> wrappers being explicitly declared in C++. The leads to slightly
> more boiler-plate code in manually created wrappers, but doesn't
> doesn't increase the overall code size. A big benefit is that this
> avoids strange compilation errors when SWIG doesn't understand
> modern language features.
> 
>   * Unlike SWIG, there is no risk that the wrapper code incorporates
> incorrect type casts (this has happened on numerous occasions in
> the past) since these will result in compile-time errors.
> 
> As a part of this change, the mechanism to define exported methods has
> been redesigned slightly. New methods can be exported either by
> declaring them in the SimObject declaration and decorating them with
> the cxxMethod decorator or by adding an instance of
> PyBindMethod/PyBindProperty to the cxx_exports class variable. The
> decorator has the added benefit of making it possible to add a
> docstring and naming the method's parameters.
> 
> The new wrappers has the following known issues:
> 
>   * Global events can't be memory managed correctly. This was the
> case in SWIG as well.
> 
> Change-Id: I88c5a95b6cf6c32fa9e1ad31dfc08b2e8199a763
> Signed-off-by: Andreas Sandberg <andreas.sandb...@arm.com>
> Reviewed-by: Andreas Hansson <andreas.hans...@arm.com>
> Reviewed-by: Andrew Bardsley <andrew.bards...@arm.com>
> 
> 
> Diffs
> -
> 
>   src/cpu/BaseCPU.py ba90ffa751b6 
>   src/arch/arm/ArmPMU.py ba90ffa751b6 
>   src/SConscript ba90ffa751b6 
>   src/python/pybind11/stats.cc PRE-CREATION 
>   src/python/swig/core.i ba90ffa751b6 
>   src/python/swig/debug.i ba90ffa751b6 
>   src/python/swig/drain.i ba90ffa751b6 
>   src/python/swig/event.i ba90ffa751b6 
>   src/python/swig/inet.i ba90ffa751b6 
>   src/python/swig/pyevent.hh ba90ffa751b6 
>   src/python/swig/pyevent.cc ba90ffa751b6 
>   src/python/swig/pyobject.hh ba90ffa751b6 
>   src/python/swig/pyobject.cc ba90ffa751b6 
>   src/python/swig/pyobject.i ba90ffa751b6 
>   src/python/swig/range.i ba90ffa751b6 
>   src/python/swig/serialize.i ba90ffa751b6 
>   src/python/swig/stats.i ba90ffa751b6 
>   src/python/swig/time.i ba90ffa751b6 
>   src/python/swig/trace.i ba90ffa751b6 
>   src/sim/Process.py ba90ffa751b6 
>   src/sim/System.py ba90ffa751b6 
>   src/sim/init.hh ba90ffa751b6 
>   src/sim/init.cc ba90ffa751b6 
>   src/sim/power/PowerModel.py ba90ffa751b6 
>   src/sim/power/PowerModelState.py ba90ffa751b6 
>   src/sim/power/ThermalDomain.py ba90ffa751b6 

Re: [gem5-dev] Review Request 3838: ext: Update DRAMPower

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3838/#review9483
---

Ship it!


Great. Thanks Matthias!

How can we best make sure the functionality is matched by the DRAMCtrl? Is 
there anyone that already played around with bank-wise refresh?

- Andreas Hansson


On Feb. 24, 2017, 9:56 p.m., Matthias Jung wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3838/
> ---
> 
> (Updated Feb. 24, 2017, 9:56 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11881:910b9376009a
> ---
> ext: Update DRAMPower
> 
> This patch syncs the DRAMPower library of gem5 to the external
> one on github (https://github.com/ravenrd/DRAMPower) of which
> I am one of the maintainers.
> 
> The version used is the commit:
> 90d6290f802c29b3de9e10233ceee22290907ce6
> from 30. Oct. 2016.
> 
> The new version features a bank-wise power estimation.
> Furthermore, PASR and Per-Bank Refresh is supported.
> 
> More Informtation can be found in the following papers:
> 
> A Bank-Wise DRAM Power Model for System Simulations
> Deepak M. Mathew, Eder F. Zulian, Subash. Kannoth, Matthias Jung, Christian 
> Weis, Norbert Wehn.
> International Conference on High-Performance and Embedded Architectures and 
> Compilers 2016 (HiPEAC), Workshop on: Rapid Simulation and Performance 
> Evaluation: Methods and Tools (RAPIDO), Stockholm, 2017.
> 
> A New Bank Sensitive DRAMPower Model for Efficient Design Space Exploration
> Matthias Jung, Deepak M. Mathew, Eder F. Zulian, Christian Weis, Norbert Wehn.
> International Workshop on Power And Timing Modeling, Optimization and 
> Simulation (PATMOS 2016), September, 2016, Bremen, Germany
> 
> 
> Diffs
> -
> 
>   ext/drampower/README.md 5ea85692a53e 
>   ext/drampower/SConscript 5ea85692a53e 
>   ext/drampower/src/CAHelpers.cc PRE-CREATION 
>   ext/drampower/src/CmdHandlers.cc PRE-CREATION 
>   ext/drampower/src/CommandAnalysis.h 5ea85692a53e 
>   ext/drampower/src/CommandAnalysis.cc 5ea85692a53e 
>   ext/drampower/src/MemBankWiseParams.h PRE-CREATION 
>   ext/drampower/src/MemBankWiseParams.cc PRE-CREATION 
>   ext/drampower/src/MemCommand.h 5ea85692a53e 
>   ext/drampower/src/MemPowerSpec.h 5ea85692a53e 
>   ext/drampower/src/MemPowerSpec.cc 5ea85692a53e 
>   ext/drampower/src/MemTimingSpec.h 5ea85692a53e 
>   ext/drampower/src/MemTimingSpec.cc 5ea85692a53e 
>   ext/drampower/src/MemoryPowerModel.h 5ea85692a53e 
>   ext/drampower/src/MemoryPowerModel.cc 5ea85692a53e 
>   ext/drampower/src/TraceParser.h 5ea85692a53e 
>   ext/drampower/src/TraceParser.cc 5ea85692a53e 
>   ext/drampower/src/libdrampower/LibDRAMPower.h 5ea85692a53e 
>   ext/drampower/src/libdrampower/LibDRAMPower.cc 5ea85692a53e 
>   ext/drampower/test/libdrampowertest/Makefile 5ea85692a53e 
>   ext/drampower/test/libdrampowertest/commands.trace 5ea85692a53e 
>   ext/drampower/test/libdrampowertest/lib_test.cc 5ea85692a53e 
> 
> Diff: http://reviews.gem5.org/r/3838/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthias Jung
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3841: gpu-compute: mark functions with override if replacing virtual

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3841/#review9482
---

Ship it!


Ship It!

- Andreas Hansson


On Feb. 25, 2017, 7:33 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3841/
> ---
> 
> (Updated Feb. 25, 2017, 7:33 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11880:7ad57dc06157
> ---
> gpu-compute: mark functions with override if replacing virtual
> 
> The clang compiler is more stringent than the recent versions of
> GCC when dealing with overrides. This changeset adds the specifier
> to the methods which need it to silence the compiler.
> 
> 
> Diffs
> -
> 
>   src/arch/hsail/insts/gpu_static_inst.hh 
> 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/gpu-compute/gpu_static_inst.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
> 
> Diff: http://reviews.gem5.org/r/3841/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3840: gpu-compute: remove unnecessary member from class

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3840/#review9481
---

Ship it!


Ship It!

- Andreas Hansson


On Feb. 25, 2017, 7:31 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3840/
> ---
> 
> (Updated Feb. 25, 2017, 7:31 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11879:12817f27b991
> ---
> gpu-compute: remove unnecessary member from class
> 
> The clang compiler complains that the wavefront member in
> the GpuISA class is unused. This changeset removes the member,
> because it does not appear serve a purpose.
> 
> 
> Diffs
> -
> 
>   src/arch/hsail/gpu_isa.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/gpu-compute/wavefront.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
> 
> Diff: http://reviews.gem5.org/r/3840/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3814: misc: Add a CONTRIBUTING document

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3814/#review9457
---


Thanks for getting this in shape. Some minor things worth considering.


CONTRIBUTING.md (line 7)
<http://reviews.gem5.org/r/3814/#comment7979>

This is quite defensive and negative at the moment.

Could we not make 1 and 2:

* Share your work with others, so that they can benefit from new 
functionality.
* Support the scientific principle by enabling others to evaluate your 
suggestions without having to guess what you did.



CONTRIBUTING.md (line 10)
<http://reviews.gem5.org/r/3814/#comment7978>

I would think we should drop the s at the end.



CONTRIBUTING.md (line 69)
<http://reviews.gem5.org/r/3814/#comment7980>

Is there a step where tests/regressions are added and/or updated, or is 
that perhaps too much detail for this doc?


- Andreas Hansson


On Feb. 21, 2017, 5:34 p.m., Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3814/
> ---
> 
> (Updated Feb. 21, 2017, 5:34 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> changesets:
>   11849:b5f456096b51 "misc: Add a CONTRIBUTING document
> 
> This document details how to contribute to gem5 based on our new
> contribution flow with git and gerrit.
> 
> Signed-off-by: Jason Lowe-Power <ja...@lowepower.com>"
> 
> 
> Diffs
> -
> 
>   CONTRIBUTING.md PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3814/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: mem: Fix memory footprint includes

[Andreas Hansson]

changeset 77b4fd593427 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=77b4fd593427
description:
mem: Fix memory footprint includes

Fix compilation errors due to missing include.

diffstat:

 src/mem/probes/mem_footprint.hh |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diffs (12 lines):

diff -r 103e2f92c965 -r 77b4fd593427 src/mem/probes/mem_footprint.hh
--- a/src/mem/probes/mem_footprint.hh   Wed Nov 09 14:27:42 2016 -0600
+++ b/src/mem/probes/mem_footprint.hh   Sun Feb 19 05:30:31 2017 -0500
@@ -41,7 +41,7 @@
 #ifndef __MEM_PROBES_MEM_FOOTPRINT_HH__
 #define __MEM_PROBES_MEM_FOOTPRINT_HH__
 
-#include 
+#include 
 
 #include "base/callback.hh"
 #include "mem/packet.hh"
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: sim: Ensure draining is deterministic

[Andreas Hansson]

changeset 76c36516e0ae in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=76c36516e0ae
description:
sim: Ensure draining is deterministic

The traversal of drainable objects could potentially be
non-deterministic when using an unordered set containing object
pointers. To ensure that the iteration is deterministic, we switch to
a vector. Note that the lookup and traversal of the drainable objects
is not performance critical, so the change has no negative consequences.

diffstat:

 src/mem/cache/cache.hh   |   2 ++
 src/mem/coherent_xbar.hh |   2 ++
 src/sim/drain.cc |  11 +--
 src/sim/drain.hh |   4 ++--
 4 files changed, 15 insertions(+), 4 deletions(-)

diffs (86 lines):

diff -r 5869c83bc8c7 -r 76c36516e0ae src/mem/cache/cache.hh
--- a/src/mem/cache/cache.hhSun Feb 19 05:30:31 2017 -0500
+++ b/src/mem/cache/cache.hhSun Feb 19 05:30:31 2017 -0500
@@ -52,6 +52,8 @@
 #ifndef __MEM_CACHE_CACHE_HH__
 #define __MEM_CACHE_CACHE_HH__
 
+#include 
+
 #include "base/misc.hh" // fatal, panic, and warn
 #include "enums/Clusivity.hh"
 #include "mem/cache/base.hh"
diff -r 5869c83bc8c7 -r 76c36516e0ae src/mem/coherent_xbar.hh
--- a/src/mem/coherent_xbar.hh  Sun Feb 19 05:30:31 2017 -0500
+++ b/src/mem/coherent_xbar.hh  Sun Feb 19 05:30:31 2017 -0500
@@ -51,6 +51,8 @@
 #ifndef __MEM_COHERENT_XBAR_HH__
 #define __MEM_COHERENT_XBAR_HH__
 
+#include 
+
 #include "mem/snoop_filter.hh"
 #include "mem/xbar.hh"
 #include "params/CoherentXBar.hh"
diff -r 5869c83bc8c7 -r 76c36516e0ae src/sim/drain.cc
--- a/src/sim/drain.cc  Sun Feb 19 05:30:31 2017 -0500
+++ b/src/sim/drain.cc  Sun Feb 19 05:30:31 2017 -0500
@@ -39,6 +39,8 @@
 
 #include "sim/drain.hh"
 
+#include 
+
 #include "base/misc.hh"
 #include "base/trace.hh"
 #include "debug/Drain.hh"
@@ -126,6 +128,7 @@
 void
 DrainManager::signalDrainDone()
 {
+assert(_count > 0);
 if (--_count == 0) {
 DPRINTF(Drain, "All %u objects drained..\n", drainableCount());
 exitSimLoop("Finished drain", 0);
@@ -137,14 +140,18 @@
 DrainManager::registerDrainable(Drainable *obj)
 {
 std::lock_guard lock(globalLock);
-_allDrainable.insert(obj);
+assert(std::find(_allDrainable.begin(), _allDrainable.end(), obj) ==
+   _allDrainable.end());
+_allDrainable.push_back(obj);
 }
 
 void
 DrainManager::unregisterDrainable(Drainable *obj)
 {
 std::lock_guard lock(globalLock);
-_allDrainable.erase(obj);
+auto o = std::find(_allDrainable.begin(), _allDrainable.end(), obj);
+assert(o != _allDrainable.end());
+_allDrainable.erase(o);
 }
 
 size_t
diff -r 5869c83bc8c7 -r 76c36516e0ae src/sim/drain.hh
--- a/src/sim/drain.hh  Sun Feb 19 05:30:31 2017 -0500
+++ b/src/sim/drain.hh  Sun Feb 19 05:30:31 2017 -0500
@@ -42,7 +42,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 class Drainable;
 
@@ -162,7 +162,7 @@
 mutable std::mutex globalLock;
 
 /** Set of all drainable objects */
-std::unordered_set _allDrainable;
+std::vector _allDrainable;
 
 /**
  * Number of objects still draining. This is flagged atomic since
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: mem: Ensure deferred snoops are cache-line al...

[Andreas Hansson]

changeset 5869c83bc8c7 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=5869c83bc8c7
description:
mem: Ensure deferred snoops are cache-line aligned

This patch fixes a bug where a deferred snoop ended up being to a
partial cache line, and not cache-line aligned, all due to how we copy
the packet.

diffstat:

 src/mem/cache/mshr.cc |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diffs (12 lines):

diff -r 77b4fd593427 -r 5869c83bc8c7 src/mem/cache/mshr.cc
--- a/src/mem/cache/mshr.cc Sun Feb 19 05:30:31 2017 -0500
+++ b/src/mem/cache/mshr.cc Sun Feb 19 05:30:31 2017 -0500
@@ -415,7 +415,7 @@
 // the packet and the request as part of handling the deferred
 // snoop.
 PacketPtr cp_pkt = will_respond ? new Packet(pkt, true, true) :
-new Packet(new Request(*pkt->req), pkt->cmd);
+new Packet(new Request(*pkt->req), pkt->cmd, blkSize);
 
 if (will_respond) {
 // we are the ordering point, and will consequently
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: stats: Get all stats updated to reflect curre...

[Andreas Hansson]

changeset 67dee11badea in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=67dee11badea
description:
stats: Get all stats updated to reflect current behaviour

Line everything up again.

diffstat:

 tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-minor/stats.txt
  |  1671 +-
 tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/stats.txt  
  |  3793 ++--
 tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3/stats.txt   
  |  2220 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor-dual/stats.txt
  |  5082 +++---
 tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor/stats.txt 
  |  2050 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3-dual/stats.txt   
  |  6209 
 tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3/stats.txt
  |  2405 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview64-minor-dual/stats.txt  
  |  5676 
 tests/long/fs/10.linux-boot/ref/arm/linux/realview64-minor/stats.txt   
  |  2493 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview64-o3-dual/stats.txt 
  |  6844 +
 tests/long/fs/10.linux-boot/ref/arm/linux/realview64-o3/stats.txt  
  |  3137 ++--
 
tests/long/fs/10.linux-boot/ref/arm/linux/realview64-simple-atomic-dual/stats.txt
|  2541 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview64-simple-atomic/stats.txt   
  |  1161 +-
 
tests/long/fs/10.linux-boot/ref/arm/linux/realview64-simple-timing-dual/stats.txt
|  5586 
 tests/long/fs/10.linux-boot/ref/arm/linux/realview64-simple-timing/stats.txt   
  |  2522 +-
 tests/long/se/10.mcf/ref/arm/linux/minor-timing/stats.txt  
  |   760 +-
 tests/long/se/10.mcf/ref/arm/linux/o3-timing/stats.txt 
  |  1636 +-
 tests/long/se/10.mcf/ref/x86/linux/o3-timing/stats.txt 
  |  1610 +-
 tests/long/se/20.parser/ref/arm/linux/minor-timing/stats.txt   
  |  1170 +-
 tests/long/se/20.parser/ref/arm/linux/o3-timing/stats.txt  
  |  1794 +-
 tests/long/se/20.parser/ref/x86/linux/o3-timing/stats.txt  
  |  1709 +-
 tests/long/se/30.eon/ref/arm/linux/minor-timing/stats.txt  
  |   736 +-
 tests/long/se/30.eon/ref/arm/linux/o3-timing/stats.txt 
  |  1579 +-
 tests/long/se/40.perlbmk/ref/arm/linux/minor-timing/stats.txt  
  |   892 +-
 tests/long/se/40.perlbmk/ref/arm/linux/o3-timing/stats.txt 
  |  1768 +-
 tests/long/se/50.vortex/ref/arm/linux/minor-timing/stats.txt   
  |  1102 +-
 tests/long/se/50.vortex/ref/arm/linux/o3-timing/stats.txt  
  |  1824 +-
 tests/long/se/60.bzip2/ref/arm/linux/minor-timing/stats.txt
  |   974 +-
 tests/long/se/60.bzip2/ref/arm/linux/o3-timing/stats.txt   
  |  1746 +-
 tests/long/se/70.twolf/ref/arm/linux/minor-timing/stats.txt
  |   684 +-
 tests/long/se/70.twolf/ref/arm/linux/o3-timing/stats.txt   
  |  1591 +-
 tests/long/se/70.twolf/ref/x86/linux/o3-timing/stats.txt   
  |  1496 +-
 tests/quick/se/00.hello/ref/alpha/linux/minor-timing/stats.txt 
  |   306 +-
 tests/quick/se/00.hello/ref/alpha/linux/o3-timing/stats.txt
  |  1026 +-
 tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby/stats.txt   
  |54 +-
 tests/quick/se/00.hello/ref/arm/linux/minor-timing/stats.txt   
  |   526 +-
 tests/quick/se/00.hello/ref/arm/linux/o3-timing-checker/stats.txt  
  |  1132 +-
 tests/quick/se/00.hello/ref/arm/linux/o3-timing/stats.txt  
  |   678 +-
 tests/quick/se/00.hello/ref/mips/linux/o3-timing/stats.txt 
  |   550 +-
 tests/quick/se/00.hello/ref/mips/linux/simple-timing-ruby/stats.txt
  |56 +-
 tests/quick/se/00.hello/ref/power/linux/o3-timing/stats.txt
  |  1196 +-
 tests/quick/se/00.hello/ref/riscv/linux/minor-timing/stats.txt 
  |20 +-
 tests/quick/se/00.hello/ref/riscv/linux/o3-timing/stats.txt
  |   302 +-
 tests/quick/se/00.hello/ref/riscv/linux/simple-timing-ruby/stats.txt   
  |56 +-
 tests/quick/se/00.hello/ref/sparc/linux/simple-timing-ruby/stats.txt   
  |56 +-
 tests/quick/se/00.hello/ref/x86/linux/o3-timing/stats.txt  
  |  1212 +-
 tests/quick/se/00.hello/ref/x86/linux/simple-timing-ruby/stats.txt 
  |54 +-
 tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing-mt/stats.txt  
  |  1776 +-
 

Re: [gem5-dev] Review Request 3806: sparc: fix bugs caused by cd7f3a1dbf55

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3806/#review9433
---

Ship it!


I would argue that this is a prime example why removing SPARC is a good idea.

- Andreas Hansson


On Feb. 10, 2017, 8:31 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3806/
> ---
> 
> (Updated Feb. 10, 2017, 8:31 p.m.)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, and Steve Reinhardt.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11803:0ab0146d777a
> ---
> sparc: fix bugs caused by cd7f3a1dbf55
> 
> Turns out that SPARC SE mode relied on M5_pid being "0" in
> all cases. The entries in the SPARC TLBs are accessed with
> M5_pid as their context. This is buggy in the sense that it
> will never work with more than one process or any
> initialization that doesn't have the M5_pid value passed in
> as "0".
> 
> cd7f3a1dbf55 broke the SPARC build because it deletes M5_pid
> and uses a _pid with a default of "100" instead. This caused
> the SPARC TLB to never return any valid lookups for any
> request; the program never moved past the first instruction
> with SPARC SE in the regression tester.
> 
> The solution proposed in this changeset is to initialize
> the address space identification register with the PID value
> that is passed into the process class as a parameter from
> Python. This should return the correct responses from the TLB
> since the insertions and lookups into the page table will be
> using the same PID.
> 
> Furthermore, there are corner cases in the code which elevate
> privileges and revert to using context "0" as the context in
> the TLB. I believe that these are related to kernel level
> traps and hypervisor privilege escalations, but I'm not
> completely sure. I've tried to address the corner cases
> properly, but it would be beneficial to have someone who is
> familiar with the SPARC architecture to take a look at this
> fix.
> 
> 
> Diffs
> -
> 
>   src/arch/sparc/process.cc cd7f3a1dbf55bfa03b436c8cde51ebda515fbdbc 
>   src/arch/sparc/faults.cc cd7f3a1dbf55bfa03b436c8cde51ebda515fbdbc 
> 
> Diff: http://reviews.gem5.org/r/3806/diff/
> 
> 
> Testing
> ---
> 
> util/regress all
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3813: mem: add M5_VAR_USED to comm_monitor function vars

[Andreas Hansson]

Great! Thanks Jason.

On 15/02/2017, 21:06, "gem5-dev on behalf of Jason Lowe-Power"
 wrote:

>I just pushed the other patch.
>
>Cheers,
>Jason
>
>On Wed, Feb 15, 2017 at 2:48 PM Brandon Potter 
>wrote:
>
>> This is an automatically generated e-mail. To reply, visit:
>> http://reviews.gem5.org/r/3813/
>>
>> On February 15th, 2017, 8:46 p.m. UTC, *Jason Lowe-Power* wrote:
>>
>> Same as http://reviews.gem5.org/r/3801?
>>
>> Thanks for pointing that out; I hadn't noticed the other review.
>>
>> I'll close this one, but can we ship the other patch now that it has
>>several ShipIts?
>>
>>
>> - Brandon
>>
>> On February 15th, 2017, 8:43 p.m. UTC, Brandon Potter wrote:
>> Review request for Default.
>> By Brandon Potter.
>>
>> *Updated Feb. 15, 2017, 8:43 p.m.*
>> *Repository: * gem5
>> Description
>>
>> Changeset 11834:8623109df37d
>> ---
>> mem: add M5_VAR_USED to comm_monitor function vars
>>
>> Diffs
>>
>>- src/mem/comm_monitor.cc (0e73ec98b6bc0758e43d0bc2cb46228acfa47313)
>>
>> View Diff 
>>
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3813: mem: add M5_VAR_USED to comm_monitor function vars

[Andreas Hansson]

> On Feb. 15, 2017, 8:46 p.m., Andreas Hansson wrote:
> > It's not the third time this is resolved :-)
> > 
> > http://reviews.gem5.org/r/3801/
> > 
> > Jason, is there any chance you could push the aforementioned patch?

s/not/now/


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3813/#review9430
---


On Feb. 15, 2017, 8:43 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3813/
> ---
> 
> (Updated Feb. 15, 2017, 8:43 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11834:8623109df37d
> ---
> mem: add M5_VAR_USED to comm_monitor function vars
> 
> 
> Diffs
> -
> 
>   src/mem/comm_monitor.cc 0e73ec98b6bc0758e43d0bc2cb46228acfa47313 
> 
> Diff: http://reviews.gem5.org/r/3813/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3813: mem: add M5_VAR_USED to comm_monitor function vars

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3813/#review9430
---


It's not the third time this is resolved :-)

http://reviews.gem5.org/r/3801/

Jason, is there any chance you could push the aforementioned patch?

- Andreas Hansson


On Feb. 15, 2017, 8:43 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3813/
> ---
> 
> (Updated Feb. 15, 2017, 8:43 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11834:8623109df37d
> ---
> mem: add M5_VAR_USED to comm_monitor function vars
> 
> 
> Diffs
> -
> 
>   src/mem/comm_monitor.cc 0e73ec98b6bc0758e43d0bc2cb46228acfa47313 
> 
> Diff: http://reviews.gem5.org/r/3813/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Thoughts On Project Using C++14

[Andreas Hansson]

Hi Brandon,

I suggest we stick to a compiler/stdlib version that is already part of
shipping LTS distros and RHE or similar. If I’m not mistaken, for Ubuntu
that means gcc 5.3, and for RHE7 that means gcc 4.8.5.

Andreas

On 14/02/2017, 23:40, "gem5-dev on behalf of Potter, Brandon"
 wrote:

>Hello all,
>
>What is the general feeling behind bumping to C++14 instead of keeping
>the top-level SConstruct flag at C++11? I would like to use generic
>lambdas in some of my code, but cannot do so because it's not available
>until C++14.
>
>Both GCC and clang support a full implementation of C++14 now: GCC became
>fully compliant as of GCC 6.1 (04/27/16); clang was compliant with clang
>3.4 (01/01/14).
>
>https://gcc.gnu.org/projects/cxx-status.html#cxx14
>https://gcc.gnu.org/gcc-6/
>https://clang.llvm.org/cxx_status.html
>http://releases.llvm.org
>
>Regards,
>Brandon
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3781: riscv: Remove ECALL tests from insttest

[Andreas Hansson]

> On Jan. 25, 2017, 11:28 a.m., Andreas Sandberg wrote:
> > Ship It!

What was the verdict? Is it just a matter of an updated patch 
description/summary and then this should be pushed?


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3781/#review9316
---


On Jan. 24, 2017, 4:33 p.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3781/
> ---
> 
> (Updated Jan. 24, 2017, 4:33 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11796:1c03f7dcaa8c
> ---
> riscv: Remove ECALL tests from insttest
> 
> The system calls tested in rv64i.cpp in RISC-V's insttest suite have
> different behavior depending on the operating system and file system they
> are run on. This patch removes those tests from the regression.
> 
> [Change deletion of ECALL test to block comment.]
> [Restore ECALL test but remove test output to test only for completion
> without error.]
> 
> 
> Diffs
> -
> 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/stats.txt 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/stats.txt 
> 97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/config.ini
>  97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/config.json
>  97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/simout 
> 97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/stats.txt 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/stats.txt 
> 97eebddaae84 
> 
> Diff: http://reviews.gem5.org/r/3781/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alec Roelke
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3777: misc: Clean up and complete the gem5<->SystemC-TLM bridge [6/10]

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3777/#review9415
---

Ship it!


I think this one did not get committed. Is that right?

- Andreas Hansson


On Feb. 5, 2017, 1:15 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3777/
> ---
> 
> (Updated Feb. 5, 2017, 1:15 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11815:357f61d007cd
> ---
> misc: Clean up and complete the gem5<->SystemC-TLM bridge [6/10]
> 
> The current TLM bridge only provides a Slave Port that allows the gem5 world 
> to
> send request to the SystemC world. This patch series refractors and cleans up
> the existing code, and adds a Master Port that allows the SystemC world to 
> send
> requests to the gem5 world.
> 
> This patch:
>  * Update the README
> 
> 
> Diffs
> -
> 
>   util/tlm/README c10c50cb8ac9 
> 
> Diff: http://reviews.gem5.org/r/3777/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3804: sim: fix build breakage in process.cc after brandon@11801

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3804/#review9396
---

Ship it!


Thanks for fixing.

I am also very surprised gcc did not warn here. After a bit of reading on 
stackoverflow it seems it could be because the member is default initialized...

- Andreas Hansson


On Feb. 3, 2017, 4:29 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3804/
> ---
> 
> (Updated Feb. 3, 2017, 4:29 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Seeing build breakage after brandon@11801:
> 
>  [ CXX] X86/sim/process.cc -> .o 
> build/X86/sim/process.cc:137:64: error: field '_pid' is uninitialized when 
> used here [-Werror,-Wuninitialized]
> static_cast(new ArchPageTable(name(), _pid, system)) 
> :
>^
> build/X86/sim/process.cc:138:64: error: field '_pid' is uninitialized when 
> used here [-Werror,-Wuninitialized]
> static_cast(new FuncPageTable(name(), _pid))),
>^
> 2 errors generated.
> 
> 
> Diffs
> -
> 
>   src/sim/process.cc 63325e5b0a9d 
> 
> Diff: http://reviews.gem5.org/r/3804/diff/
> 
> 
> Testing
> ---
> 
> Compiles now on FreeBSD 10 with clang.
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3803: sim: Patch to fix the statfs build

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3803/#review9395
---

Ship it!


Rather unfortunate with all the complexity involved, but it does indeed seem to 
do the trick also for OSX.

Thanks!

- Andreas Hansson


On Feb. 3, 2017, 4:25 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3803/
> ---
> 
> (Updated Feb. 3, 2017, 4:25 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> See developers mailing list.  Trying to unbreak statfs.
> 
> 
> Diffs
> -
> 
>   src/sim/syscall_emul.hh 63325e5b0a9d 
> 
> Diff: http://reviews.gem5.org/r/3803/diff/
> 
> 
> Testing
> ---
> 
> Builds on FreeBSD now.
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3378: scons: make build better on FreeBSD

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3378/#review9389
---

Ship it!


Ship It!

- Andreas Hansson


On Feb. 3, 2017, 4:20 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3378/
> ---
> 
> (Updated Feb. 3, 2017, 4:20 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> scons: make build better on FreeBSD
> 
> Various changes we found needed to build gem5 successfully on
> FreeBSD.
> 
> 
> Diffs
> -
> 
>   SConstruct 63325e5b0a9d 
> 
> Diff: http://reviews.gem5.org/r/3378/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3801: mem, misc: fix building issue with CommMonitor (unused variables)

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3801/#review9387
---

Ship it!


Ship It!

- Andreas Hansson


On Feb. 3, 2017, 9:04 a.m., Pierre-Yves Péneau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3801/
> ---
> 
> (Updated Feb. 3, 2017, 9:04 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11808:e0730e1d7afa
> ---
> misc: fix building issue (undefined variables)
> 
> Signed-off-by: Pierre-Yves Péneau <first.l...@lirmm.fr>
> 
> 
> Diffs
> -
> 
>   src/mem/comm_monitor.cc 63325e5b0a9d 
> 
> Diff: http://reviews.gem5.org/r/3801/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Pierre-Yves Péneau
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3801: misc: fix building issue (undefined variables)

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3801/#review9386
---


Thanks for fixing. Could you make it "mem:" and also include CommMonitor in the 
description. I also expect this is due to unused variables in fast builds? Not 
undefined variables.

- Andreas Hansson


On Feb. 3, 2017, 8:37 a.m., Pierre-Yves Péneau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3801/
> ---
> 
> (Updated Feb. 3, 2017, 8:37 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11808:e0730e1d7afa
> ---
> misc: fix building issue (undefined variables)
> 
> Signed-off-by: Pierre-Yves Péneau <first.l...@lirmm.fr>
> 
> 
> Diffs
> -
> 
>   src/mem/comm_monitor.cc 63325e5b0a9d 
> 
> Diff: http://reviews.gem5.org/r/3801/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Pierre-Yves Péneau
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3801: misc: fix building issue (undefined variables)

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3801/#review9385
---



src/mem/comm_monitor.cc (line 276)
<http://reviews.gem5.org/r/3801/#comment7951>

the (const bool) part seems excessive


- Andreas Hansson


On Feb. 3, 2017, 8:37 a.m., Pierre-Yves Péneau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3801/
> ---
> 
> (Updated Feb. 3, 2017, 8:37 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11808:e0730e1d7afa
> ---
> misc: fix building issue (undefined variables)
> 
> Signed-off-by: Pierre-Yves Péneau <first.l...@lirmm.fr>
> 
> 
> Diffs
> -
> 
>   src/mem/comm_monitor.cc 63325e5b0a9d 
> 
> Diff: http://reviews.gem5.org/r/3801/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Pierre-Yves Péneau
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3800: x86 fix Mul1u instructions

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3800/#review9366
---


Would this not spell the end of gem5 support on 32-bit platforms/kernels? Is it 
not possible to avoid using the non-standard type?

- Andreas Hansson


On Feb. 2, 2017, 12:32 a.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3800/
> ---
> 
> (Updated Feb. 2, 2017, 12:32 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11970:a7fb935f1418
> ---
> x86 fix Mul1u instructions
> 
> the Mul1uFlags and Mul1u instructions perform the 64b multiplication using
> only 64b registers, however this method causes the high 64b to be corrupted
> for certain inputs. to avoid this complexity, we use the compiler builtin
> __uint128_t, which is supported by gcc and clang to simplify the code and
> get correct results.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/isa/microops/regop.isa 
> ed89cb178ecd7586296d2a2e83595174474db554 
> 
> Diff: http://reviews.gem5.org/r/3800/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tony Gutierrez
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Compilation error for gem5 after statfs change

[Andreas Hansson]

Hi Brad,

A few things worth noting here:

- OSX/MacOs has been working fine for the last 4+ years, and is mentioned
on gem5.org as a supported OS (so is OpenBSD btw). I know there are users
that rely on it, and I would suggest we try and keep it working.

- Clearly there is a problem in that we have plenty ‘supported’ builds
(OSX, without Python, with SystemC, etc) that are not tested or even built
as part of the regressions. Once we make the move to CI-land some of this
should be easier to address.

- For now I would suggest we simply try our best to not break things, and
for the few patches related to syscall emulation it would be great if you
can check on a OSX/BSD host before pushing (alternatively co-ordinate with
someone else to check). For the breakage that already snuck in, there are
plenty people willing to help, but they will likely need Brandon’s help to
get things resolved.

Thanks again to everyone, especially Brandon, for all help.

Andreas

On 28/01/2017, 20:21, "gem5-dev on behalf of Beckmann, Brad"
<gem5-dev-boun...@gem5.org on behalf of brad.beckm...@amd.com> wrote:

>I must chime in here.
>
>Brandon is putting in an heroic effort here and you keep asking him to do
>more and more.  I'm really concerned with the precedent being set.  I do
>not believe there has ever been a consensus that gem5 supports any OS
>other than Linux.  Once we have a common public regression tester
>infrastructure that allows us to test multiple OSes, then we can
>officially add other OSes if people add the tests to do so.  However
>until that happens, can someone who actually cares about these
>non-standard environments run these tests?
>
>Brad
>
>
>
>-Original Message-
>From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason
>Lowe-Power
>Sent: Thursday, January 26, 2017 3:55 PM
>To: gem5 Developer List <gem5-dev@gem5.org>; Potter, Brandon
><brandon.pot...@amd.com>
>Subject: Re: [gem5-dev] Compilation error for gem5 after statfs change
>
>Hi Brandon,
>
>BTW, here's a Travis-CI config file that will run tests on GCC and Clang
>on both Mac and Linux hosts. We can add many more parameters for
>different versions of compilers, etc., but this is something that should
>allow you to test changes on more than just your current platform.
>
>If you have a github mirror, every time you push to it, Travis-CI kicks
>off
>4 builds (for the matrix of OS and compiler).
>
>https://github.com/powerjg/gem5-ci-test/blob/master/.travis.yml
>
>It would be great if you could take a look at this, Brandon.
>
>Thanks,
>Jason
>
>On Thu, Jan 26, 2017 at 4:47 AM Andreas Hansson <andreas.hans...@arm.com>
>wrote:
>
>> Hi all,
>>
>> While I agree about the end goal (test every commit on every platform)
>> I would suggest we go about this one step at a time. The likelihood of
>> breakage is only high for anything related to syscall emulation, so it
>> really only affects a small part of the developer community. Agreed?
>>
>> With that in mind I think we can prevent 99% of the issues if syscall
>> emulation patches are built on a BSD system with clang. I would be
>> wrong, but I would think this is a very good filter, with a fairly low
>> cost and effort of deployment. Virtualbox + some flavour of BSD would
>>do it.
>>
>> Andreas
>>
>> On 25/01/2017, 23:18, "gem5-dev on behalf of Jason Lowe-Power"
>> <gem5-dev-boun...@gem5.org on behalf of ja...@lowepower.com> wrote:
>>
>> >Yeah, it's a major problem that we say that we support macOS and
>> >others when we allow commits that break builds on these other OSes.
>> >
>> >If we are going to say that we have support for OSes other than
>> >Linux, we need to at least verify gem5 builds on these OSes,
>> >preferably before accepting a commit. I'm currently testing out the
>> >free Travis-CI service ( https://travis-ci.org/powerjg/gem5-ci-test).
>> >We could probably hook this up to our gem5 github page, if it works
>> >out.
>> >
>> >Another important point, though, is that we can't expect all
>> >committers to own multiple machines to test their changes on. We need
>> >something that will do pre-commit builds on all the platforms we
>> >claim to support.
>> >
>> >We're in the middle of moving the regression tests to a hosted
>> >jenkins instance. Hopefully this will solve some of these issues
>> >(though I don't think it will support multiple OS builds).
>> >
>> >Do others have any ideas on a long-term solution here?
>> >
>> >Cheers,
>> >Jason
>> >
>> >On Tue, Jan 24, 2017 at 

Re: [gem5-dev] Review Request 3796: misc: Clean up and complete the gem5<->SystemC-TLM bridge [7/6]

[Andreas Hansson]

> On Feb. 1, 2017, 1:29 p.m., Andreas Hansson wrote:
> > It would be tremendously helpful if we could get some regressions tests, 
> > but until core SystemC is available with Apache v2 (which supposedly should 
> > happen) I do not see a good way. Any thoughts?

Actually, I noticed that the systemc2.3.1a download is actually updated to 
Apache v2. I am tempted to suggest we include it in gem5's ext/ directory, 
which would also enable us to integrate the systemc builds into regressions.

What do you think? Is anyone happy to give it a go?


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3796/#review9361
---


On Jan. 30, 2017, 4:13 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3796/
> ---
> 
> (Updated Jan. 30, 2017, 4:13 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11800:b5ad6c483119
> ---
> misc: Clean up and complete the gem5<->SystemC-TLM bridge [7/6]
> 
> The current TLM bridge only provides a Slave Port that allows the gem5 world 
> to
> send request to the SystemC world. This patch series refractors and cleans up
> the existing code, and adds a Master Port that allows the SystemC world to 
> send
> requests to the gem5 world.
> 
> This patch:
>  * Implement 'pipe through' for gem5 Packets (see explanation below)
> 
> Basically, this patch ensures that all transactions that originated in the 
> gem5
> world are converted back to the original packet when entering the gem5 world.
> So far, this only worked for packets that are responded to by a SyctemC
> component (e.g. when a gem5 CPU sends a request to a SystemC memory). By
> implementing the 'pipe through' this patch ensures, that packets that are
> responded to by a gem5 component (e.g. when a gem5 CPU sends a request to a
> gem5 memory via a SystemC interconnect) are handled properly.
> 
> 
> Diffs
> -
> 
>   util/tlm/sc_ext.hh c10c50cb8ac9 
>   util/tlm/sc_ext.cc c10c50cb8ac9 
>   util/tlm/sc_master_port.hh PRE-CREATION 
>   util/tlm/sc_master_port.cc PRE-CREATION 
>   util/tlm/sc_slave_port.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3796/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3378: scons: make build better on FreeBSD

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3378/#review9358
---



SConstruct (line 1097)
<http://reviews.gem5.org/r/3378/#comment7949>

Before committing this, could you add a comment before this line to explain 
that is is for BSD?


- Andreas Hansson


On Jan. 31, 2017, 1:44 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3378/
> ---
> 
> (Updated Jan. 31, 2017, 1:44 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> scons: make build better on FreeBSD
> 
> Various changes we found needed to build gem5 successfully on
> FreeBSD.
> 
> 
> Diffs
> -
> 
>   SConstruct e47703369039 
> 
> Diff: http://reviews.gem5.org/r/3378/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Compilation error for gem5 after statfs change

[Andreas Hansson]

Thanks Brandon!

For those attending the workshop at HPCA, it would be great if you could
spend a few minutes and see if you can come up with some recommendations
around this.

Andreas

On 26/01/2017, 18:04, "gem5-dev on behalf of Potter, Brandon"
<gem5-dev-boun...@gem5.org on behalf of brandon.pot...@amd.com> wrote:

>Hello all,
>
>I'm trying to resolve this issue. I'm setting up FreeBSD 11 on a
>VirtualBox instance now to see if I can resolve the problems. Hopefully
>this covers OSX indirectly as well.
>
>I don't expect that moving the offending system calls into Linux specific
>files will resolve the problem where the underlying host OS needs to make
>the system call on behalf of the target (like what happens with
>fallocate). I think the only way to resolve the issue is to add in
>preprocessor directives to prevent compilation/linkage errors on
>platforms that don't support what's necessary under the covers. (Correct
>me if there's a better way to handle this.)
>
>I'll post a patch and respond to the mailing list when I have it working.
>
>Regards,
>Brandon
>
>-Original Message-----
>From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas
>Hansson
>Sent: Thursday, January 26, 2017 2:18 AM
>To: gem5 Developer List <gem5-dev@gem5.org>
>Subject: Re: [gem5-dev] Compilation error for gem5 after statfs change
>
>Hi all,
>
>While I agree about the end goal (test every commit on every platform) I
>would suggest we go about this one step at a time. The likelihood of
>breakage is only high for anything related to syscall emulation, so it
>really only affects a small part of the developer community. Agreed?
>
>With that in mind I think we can prevent 99% of the issues if syscall
>emulation patches are built on a BSD system with clang. I would be wrong,
>but I would think this is a very good filter, with a fairly low cost and
>effort of deployment. Virtualbox + some flavour of BSD would do it.
>
>Andreas
>
>On 25/01/2017, 23:18, "gem5-dev on behalf of Jason Lowe-Power"
><gem5-dev-boun...@gem5.org on behalf of ja...@lowepower.com> wrote:
>
>>Yeah, it's a major problem that we say that we support macOS and others
>>when we allow commits that break builds on these other OSes.
>>
>>If we are going to say that we have support for OSes other than Linux,
>>we need to at least verify gem5 builds on these OSes, preferably before
>>accepting a commit. I'm currently testing out the free Travis-CI
>>service ( https://travis-ci.org/powerjg/gem5-ci-test). We could
>>probably hook this up to our gem5 github page, if it works out.
>>
>>Another important point, though, is that we can't expect all committers
>>to own multiple machines to test their changes on. We need something
>>that will do pre-commit builds on all the platforms we claim to
>>support.
>>
>>We're in the middle of moving the regression tests to a hosted jenkins
>>instance. Hopefully this will solve some of these issues (though I
>>don't think it will support multiple OS builds).
>>
>>Do others have any ideas on a long-term solution here?
>>
>>Cheers,
>>Jason
>>
>>On Tue, Jan 24, 2017 at 5:46 PM Bjoern A. Zeeb <
>>bzeeb-li...@lists.zabbadoz.net> wrote:
>>
>>On 24 Jan 2017, at 22:08, Jason Lowe-Power wrote:
>>
>>> Hi Brandon,
>>>
>>> I think this is a "real" bug:
>>>
>>http://qa.gem5.org//1905/compiling-problem-gem5-mac-os-10-11-6-scons-bu
>>ild
>>-arm-gem5-opt
>>.
>>> I think there are a few more places that need an #ifdef NO_STATFS.
>>> Could
>>> you look into it and post a patch if there's a problem? If not,
>>> please reply to the gem5 QA post and let them know.
>>
>>Can people try this one and probably get the #ifdefs right for NetBSD
>>as well?  There are at least 3 different checks for that code;  if
>>people don’t care about “style” I could get it right, but ..
>>
>>diff -r e47703369039 src/sim/syscall_emul.hh
>>--- a/src/sim/syscall_emul.hh   Fri Jan 20 14:12:58 2017 -0500
>>+++ b/src/sim/syscall_emul.hh   Tue Jan 24 23:45:04 2017 +
>>@@ -70,6 +70,8 @@
>>  #include 
>>  #if (NO_STATFS == 0)
>>  #include 
>>+#else
>>+#include 
>>  #endif
>>  #include 
>>  #include 
>>@@ -530,20 +532,25 @@
>>  {
>>  TypedBufferArg tgt(addr);
>>
>>+tgt->f_type = TheISA::htog(host->f_type);
>>  #if defined(__OpenBSD__) || defined(__APPLE__) || defined(__FreeBSD__)
>>-tgt->f_type = 0;
>>+tgt->f_bsize = TheISA::htog(host->f_iosize);
>&g

Re: [gem5-dev] Compilation error for gem5 after statfs change

[Andreas Hansson]

Hi all,

While I agree about the end goal (test every commit on every platform) I
would suggest we go about this one step at a time. The likelihood of
breakage is only high for anything related to syscall emulation, so it
really only affects a small part of the developer community. Agreed?

With that in mind I think we can prevent 99% of the issues if syscall
emulation patches are built on a BSD system with clang. I would be wrong,
but I would think this is a very good filter, with a fairly low cost and
effort of deployment. Virtualbox + some flavour of BSD would do it.

Andreas

On 25/01/2017, 23:18, "gem5-dev on behalf of Jason Lowe-Power"
 wrote:

>Yeah, it's a major problem that we say that we support macOS and others
>when we allow commits that break builds on these other OSes.
>
>If we are going to say that we have support for OSes other than Linux, we
>need to at least verify gem5 builds on these OSes, preferably before
>accepting a commit. I'm currently testing out the free Travis-CI service (
>https://travis-ci.org/powerjg/gem5-ci-test). We could probably hook this
>up
>to our gem5 github page, if it works out.
>
>Another important point, though, is that we can't expect all committers to
>own multiple machines to test their changes on. We need something that
>will
>do pre-commit builds on all the platforms we claim to support.
>
>We're in the middle of moving the regression tests to a hosted jenkins
>instance. Hopefully this will solve some of these issues (though I don't
>think it will support multiple OS builds).
>
>Do others have any ideas on a long-term solution here?
>
>Cheers,
>Jason
>
>On Tue, Jan 24, 2017 at 5:46 PM Bjoern A. Zeeb <
>bzeeb-li...@lists.zabbadoz.net> wrote:
>
>On 24 Jan 2017, at 22:08, Jason Lowe-Power wrote:
>
>> Hi Brandon,
>>
>> I think this is a "real" bug:
>>
>http://qa.gem5.org//1905/compiling-problem-gem5-mac-os-10-11-6-scons-build
>-arm-gem5-opt
>.
>> I think there are a few more places that need an #ifdef NO_STATFS.
>> Could
>> you look into it and post a patch if there's a problem? If not, please
>> reply to the gem5 QA post and let them know.
>
>Can people try this one and probably get the #ifdefs right for NetBSD as
>well?  There are at least 3 different checks for that code;  if people
>don’t care about “style” I could get it right, but ..
>
>diff -r e47703369039 src/sim/syscall_emul.hh
>--- a/src/sim/syscall_emul.hh   Fri Jan 20 14:12:58 2017 -0500
>+++ b/src/sim/syscall_emul.hh   Tue Jan 24 23:45:04 2017 +
>@@ -70,6 +70,8 @@
>  #include 
>  #if (NO_STATFS == 0)
>  #include 
>+#else
>+#include 
>  #endif
>  #include 
>  #include 
>@@ -530,20 +532,25 @@
>  {
>  TypedBufferArg tgt(addr);
>
>+tgt->f_type = TheISA::htog(host->f_type);
>  #if defined(__OpenBSD__) || defined(__APPLE__) || defined(__FreeBSD__)
>-tgt->f_type = 0;
>+tgt->f_bsize = TheISA::htog(host->f_iosize);
>  #else
>-tgt->f_type = TheISA::htog(host->f_type);
>+tgt->f_bsize = TheISA::htog(host->f_bsize);
>  #endif
>-tgt->f_bsize = TheISA::htog(host->f_bsize);
>  tgt->f_blocks = TheISA::htog(host->f_blocks);
>  tgt->f_bfree = TheISA::htog(host->f_bfree);
>  tgt->f_bavail = TheISA::htog(host->f_bavail);
>  tgt->f_files = TheISA::htog(host->f_files);
>  tgt->f_ffree = TheISA::htog(host->f_ffree);
>  memcpy(>f_fsid, >f_fsid, sizeof(host->f_fsid));
>+#if defined(__OpenBSD__) || defined(__APPLE__) || defined(__FreeBSD__)
>+tgt->f_namelen = TheISA::htog(host->f_namemax);
>+tgt->f_frsize = TheISA::htog(host->f_bsize);
>+#else
>  tgt->f_namelen = TheISA::htog(host->f_namelen);
>  tgt->f_frsize = TheISA::htog(host->f_frsize);
>+#endif
>  memcpy(>f_spare, >f_spare, sizeof(host->f_spare));
>
>  tgt.copyOut(mem);
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Ideas for sprint projects

[Andreas Hansson]

Hi all,

A large-sized project for some crafty person out there: A
binary-translation CPU for fast-forwarding, much like the KVMCpu, but more
portable. It could, for example, be built on top of the Tiny Code
Generator (TCG), as it is BSD licensed.

Quite a big task, but also a very big contribution to gem5.

Andreas

On 23/01/2017, 16:57, "gem5-dev on behalf of Andreas Hansson"
<gem5-dev-boun...@gem5.org on behalf of andreas.hans...@arm.com> wrote:

>Hi all,
>
>Another medium-sized idea: Embed the generated system SVG in a web page
>that can be used to interactively navigate the simulation results
>
>This should be fairly easy for anyone skilled in client-side scripting. It
>may even be used to view incremental results while the simulation is
>running.
>
>Andreas
>
>On 23/01/2017, 15:57, "gem5-dev on behalf of Andreas Sandberg"
><gem5-dev-boun...@gem5.org on behalf of andreas.sandb...@arm.com> wrote:
>
>>Hi Everyone,
>>
>>Thanks for organising this! See below for some of my ideas.
>>
>>Small projects:
>>   * Clean up serialization code for better code reuse (particularly
>>container helpers)
>>   * Create a separate test classification for CI smoke tests (faster
>>than quick)
>>
>>Medium-sized projects:
>>   * New test binaries based on the LLVM test suite
>>   * Mini-DSL for param overrides from the command line
>>   * Config cleanups. E.g., move some of config/common/ to a m5.config
>>name space.
>>   * Proper support for pthreads in SE mode
>>   * Implement a fast mode in the HDLCD controller to support graphical
>>worklaods (e.g., Android) in KVM
>>
>>Large projects:
>>   * Get scons to build basic components only once and share them
>>between architectures
>>
>>
>>I'd like to throw cmake in to the build system mix as well. I started
>>hacking on a small prototype a while back, but it isn't able to build
>>gem5 yet.
>>
>>
>>Cheers,
>>Andreas
>>
>>
>>On 17/01/17 16:12, Jason Lowe-Power wrote:
>>> Hi gem5 Developers!
>>>
>>> As you're probably aware, I'm going to be running a gem5 coding sprint
>>>in
>>> the afternoon after the Learning gem5 tutorial at HPCA on Sunday Feb 5.
>>>
>>> I'm looking for ideas for small projects that could be started (or even
>>> better, completed) in a few hours. Do you have any small bugs that have
>>> been bothering you? Any little features that would be nice, but you
>>>haven't
>>> had the time to work on? Now's the time to get these things done!
>>>
>>> Also, if you have any bigger projects that you think it would be good
>>>for
>>> people to chat about in the same room to come up with a plan of attack,
>>>we
>>> may be able to fit one or two of those in, too.
>>>
>>> Some examples that I have so far:
>>>
>>> Little projects:
>>> 1. Fix TLB warmup for x86. (See http://reviews.gem5.org/r/3474/)
>>> 2. Modify EventWrapper to understand C++11 lambdas so you can pass
>>> parameters to simple process() functions without creating a new class.
>>> 3. Develop some ISA instruction tests to find out what is implemented
>>> correctly and possibly find some bugs. (See RISC-V insttest)
>>>
>>> Long-term things we may want to discuss:
>>> 1. Revamping the test infrastructure
>>> 2. Replacing scons, possibly with Bazel (see https://bazel.build/)
>>>
>>> Please respond with any ideas you have! We definitely won't get to
>>> everything, but throwing ideas out there now will give us a large base
>>>of
>>> options for the coding sprint.
>>>
>>> Thanks,
>>> Jason
>>
>>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
>>http://m5sim.org/mailman/listinfo/gem5-dev
>
>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
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3781: riscv: Remove ECALL tests from insttest

[Andreas Hansson]

Hi Alec,

Don’t worry about it. It is the reviewboard being silly.

Andreas

On 24/01/2017, 16:34, "gem5-dev on behalf of Alec Roelke"
 wrote:

>
>
>> On Jan. 24, 2017, 9:43 a.m., Andreas Sandberg wrote:
>> > Did you remove all files from the reference output directory? In that
>>case, you'll need to add a an empty placeholder file called EMPTY in the
>>reference directories. Some VCS systems (git being one of them) don't
>>track empty directories, which would interfere with test discovery.
>
>I did add them; I'm not sure why it didn't put them into the patch.  Does
>the file need to contain text for it to work?
>
>
>- Alec
>
>
>---
>This is an automatically generated e-mail. To reply, visit:
>http://reviews.gem5.org/r/3781/#review9301
>---
>
>
>On Jan. 24, 2017, 4:33 p.m., Alec Roelke wrote:
>>
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> http://reviews.gem5.org/r/3781/
>> ---
>>
>> (Updated Jan. 24, 2017, 4:33 p.m.)
>>
>>
>> Review request for Default.
>>
>>
>> Repository: gem5
>>
>>
>> Description
>> ---
>>
>> Changeset 11796:1c03f7dcaa8c
>> ---
>> riscv: Remove ECALL tests from insttest
>>
>> The system calls tested in rv64i.cpp in RISC-V's insttest suite have
>> different behavior depending on the operating system and file system
>>they
>> are run on. This patch removes those tests from the regression.
>>
>> [Change deletion of ECALL test to block comment.]
>> [Restore ECALL test but remove test output to test only for completion
>> without error.]
>>
>>
>> Diffs
>> -
>>
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/config.ini
>>97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/config.json
>> 97eebddaae84
>>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/simerr
>>97eebddaae84
>>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/simout
>>97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/stats.txt
>>97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/config.ini
>> 97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/config.jso
>>n 97eebddaae84
>>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/simerr
>>97eebddaae84
>>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/simout
>>97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/stats.txt
>>97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/confi
>>g.ini 97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/confi
>>g.json 97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/simer
>>r 97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/simou
>>t 97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/stats
>>.txt 97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/config.ini
>> 97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/config.jso
>>n 97eebddaae84
>>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/simerr
>>97eebddaae84
>>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/simout
>>97eebddaae84
>>
>>tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/stats.txt
>>97eebddaae84
>>
>> Diff: http://reviews.gem5.org/r/3781/diff/
>>
>>
>> Testing
>> ---
>>
>>
>> Thanks,
>>
>> Alec Roelke
>>
>>
>
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression --scratch all

[Andreas Hansson]

Hi Joel,

We have been stalling on getting http://reviews.gem5.org/r/3781/ shipped.
Once that is done we can update the stats.

If Jason can help the patch then I am happy to bump the stats.

Andreas

On 24/01/2017, 06:09, "gem5-dev on behalf of Joel Hestness"
 wrote:

>Ping! Can someone help us out with fixing up these regressions, or do we
>have a plan for how to proceed with them?
>
>I have at least one non-trivial Ruby patch incoming, and I'm worried about
>validating its correctness.
>
>  Thanks!
>  Joel
>
>
>
>On Thu, Dec 29, 2016 at 11:44 AM, Joel Hestness 
>wrote:
>
>> Hi Arthur and Jason,
>>   I just bisected and tracked down where these regressions changed. It
>> looks like changeset 11781:1ae84c76066b
>>  on Dec. 21st
>> caused the branch predictor to change its baseline prediction accuracy,
>> causing a few of the regression tests to show changed stats.
>>
>>   Can you please let us know if you're able to update the stats to get
>> these to pass?
>>
>>   Thanks!
>>   Joel
>>
>> On Sun, Dec 25, 2016 at 5:03 PM, Cron Daemon
>>
>> wrote:
>>
>>> *
>>>build/SPARC/tests/opt/long/fs/80.solaris-boot/sparc/solaris/t1000-simple
>>>-atomic:
>>> FAILED!
>>> * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing:
>>> CHANGED!
>>> * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing:
>>> CHANGED!
>>> *
>>>build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt:
>>> CHANGED!
>>> *
>>>build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3:
>>> CHANGED!
>>> *
>>>build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3-dual:
>>> CHANGED!
>>> * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing:
>>> CHANGED!
>>> * build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing:
>>> CHANGED!
>>> * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing:
>>> CHANGED!
>>> *
>>>build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/o3-t
>>>iming-mp:
>>> CHANGED!
>>> * build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing:
>>>CHANGED!
>>> *
>>>build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-minor:
>>> CHANGED!
>>> * build/X86/tests/opt/long/se/10.mcf/x86/linux/o3-timing: CHANGED!
>>> * build/X86/tests/opt/long/se/70.twolf/x86/linux/o3-timing:
>>>CHANGED!
>>> * build/ARM/tests/opt/quick/se/00.hello/arm/linux/minor-timing:
>>> CHANGED!
>>> *
>>>build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview-minor-dual:
>>> CHANGED!
>>> * build/ARM/tests/opt/long/se/50.vortex/arm/linux/o3-timing:
>>>CHANGED!
>>> *
>>>build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview-o3-dual:
>>> CHANGED!
>>> *
>>>build/ARM/tests/opt/quick/se/00.hello/arm/linux/o3-timing-checker:
>>> CHANGED!
>>> * build/ARM/tests/opt/long/se/70.twolf/arm/linux/o3-timing:
>>>CHANGED!
>>> * build/ARM/tests/opt/long/se/40.perlbmk/arm/linux/o3-timing:
>>> CHANGED!
>>> * build/ARM/tests/opt/quick/se/00.hello/arm/linux/o3-timing:
>>>CHANGED!
>>> * build/ARM/tests/opt/long/se/50.vortex/arm/linux/minor-timing:
>>> CHANGED!
>>> * build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview-o3:
>>> CHANGED!
>>> * build/X86/tests/opt/long/se/20.parser/x86/linux/o3-timing:
>>>CHANGED!
>>> * build/ARM/tests/opt/long/se/30.eon/arm/linux/minor-timing:
>>>CHANGED!
>>> *
>>>build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-minor-dua
>>>l:
>>> CHANGED!
>>> *
>>>build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview-minor:
>>> CHANGED!
>>> * build/ARM/tests/opt/long/se/10.mcf/arm/linux/o3-timing: CHANGED!
>>> * build/ARM/tests/opt/long/se/20.parser/arm/linux/o3-timing:
>>>CHANGED!
>>> *
>>>build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-minor:
>>> CHANGED!
>>> *
>>>build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3-dual:
>>> CHANGED!
>>> * build/ARM/tests/opt/long/se/30.eon/arm/linux/o3-timing: CHANGED!
>>> * build/ARM/tests/opt/long/se/10.mcf/arm/linux/minor-timing:
>>>CHANGED!
>>> * build/ARM/tests/opt/long/se/20.parser/arm/linux/minor-timing:
>>> CHANGED!
>>> * build/ARM/tests/opt/long/se/70.twolf/arm/linux/minor-timing:
>>> CHANGED!
>>> *
>>>build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3:
>>> CHANGED!
>>> * build/ARM/tests/opt/long/se/40.perlbmk/arm/linux/minor-timing:
>>> CHANGED!
>>> * build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/minor-timing:
>>> CHANGED!
>>> *
>>>build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64m/minor-timin
>>>g:
>>> CHANGED!
>>> *
>>>build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/minor-timin
>>>g:
>>> CHANGED!
>>> *
>>>build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/minor-timin
>>>g:
>>> 

Re: [gem5-dev] Review Request 3781: riscv: Remove ECALL tests from insttest

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3781/#review9298
---

Ship it!


Ship It!

- Andreas Hansson


On Jan. 23, 2017, 7:36 p.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3781/
> ---
> 
> (Updated Jan. 23, 2017, 7:36 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11796:3cec8d75cd13
> ---
> riscv: Remove ECALL tests from insttest
> 
> The system calls tested in rv64i.cpp in RISC-V's insttest suite have
> different behavior depending on the operating system and file system they
> are run on. This patch removes those tests from the regression.
> 
> [Change deletion of ECALL test to block comment.]
> [Restore ECALL test but remove test output to test only for completion
> without error.]
> 
> 
> Diffs
> -
> 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/stats.txt 
> 97eebddaae84 
>   tests/test-progs/insttest/src/riscv/rv64i.cpp 97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/config.json
>  97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/simout 
> 97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/stats.txt 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/config.json 
> 97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/config.ini
>  97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/stats.txt 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/stats.txt 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/simout 
> 97eebddaae84 
> 
> Diff: http://reviews.gem5.org/r/3781/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alec Roelke
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3781: riscv: Remove ECALL tests from insttest

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3781/#review9294
---


Another option is to remove the stats.txt from the stats results directory. 
This will turn the test into a functional-only test.

In fact that may be there better option here as we also don't have to worry 
about distributing a new binary.

- Andreas Hansson


On Jan. 18, 2017, 4:42 p.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3781/
> ---
> 
> (Updated Jan. 18, 2017, 4:42 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11796:aaf914ea5a83
> ---
> riscv: Remove ECALL tests from insttest
> 
> The system calls tested in rv64i.cpp in RISC-V's insttest suite have
> different behavior depending on the operating system and file system they
> are run on. This patch removes those tests from the regression.
> 
> [Change deletion of ECALL test to block comment.]
> 
> 
> Diffs
> -
> 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/stats.txt 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/stats.txt 
> 97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/config.ini
>  97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/config.json
>  97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/simout 
> 97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/stats.txt 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/stats.txt 
> 97eebddaae84 
>   tests/test-progs/insttest/src/riscv/rv64i.cpp 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/simout 
> 97eebddaae84 
> 
> Diff: http://reviews.gem5.org/r/3781/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alec Roelke
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Ideas for sprint projects

[Andreas Hansson]

Hi all,

Another medium-sized idea: Embed the generated system SVG in a web page
that can be used to interactively navigate the simulation results

This should be fairly easy for anyone skilled in client-side scripting. It
may even be used to view incremental results while the simulation is
running.

Andreas

On 23/01/2017, 15:57, "gem5-dev on behalf of Andreas Sandberg"
 wrote:

>Hi Everyone,
>
>Thanks for organising this! See below for some of my ideas.
>
>Small projects:
>   * Clean up serialization code for better code reuse (particularly
>container helpers)
>   * Create a separate test classification for CI smoke tests (faster
>than quick)
>
>Medium-sized projects:
>   * New test binaries based on the LLVM test suite
>   * Mini-DSL for param overrides from the command line
>   * Config cleanups. E.g., move some of config/common/ to a m5.config
>name space.
>   * Proper support for pthreads in SE mode
>   * Implement a fast mode in the HDLCD controller to support graphical
>worklaods (e.g., Android) in KVM
>
>Large projects:
>   * Get scons to build basic components only once and share them
>between architectures
>
>
>I'd like to throw cmake in to the build system mix as well. I started
>hacking on a small prototype a while back, but it isn't able to build
>gem5 yet.
>
>
>Cheers,
>Andreas
>
>
>On 17/01/17 16:12, Jason Lowe-Power wrote:
>> Hi gem5 Developers!
>>
>> As you're probably aware, I'm going to be running a gem5 coding sprint
>>in
>> the afternoon after the Learning gem5 tutorial at HPCA on Sunday Feb 5.
>>
>> I'm looking for ideas for small projects that could be started (or even
>> better, completed) in a few hours. Do you have any small bugs that have
>> been bothering you? Any little features that would be nice, but you
>>haven't
>> had the time to work on? Now's the time to get these things done!
>>
>> Also, if you have any bigger projects that you think it would be good
>>for
>> people to chat about in the same room to come up with a plan of attack,
>>we
>> may be able to fit one or two of those in, too.
>>
>> Some examples that I have so far:
>>
>> Little projects:
>> 1. Fix TLB warmup for x86. (See http://reviews.gem5.org/r/3474/)
>> 2. Modify EventWrapper to understand C++11 lambdas so you can pass
>> parameters to simple process() functions without creating a new class.
>> 3. Develop some ISA instruction tests to find out what is implemented
>> correctly and possibly find some bugs. (See RISC-V insttest)
>>
>> Long-term things we may want to discuss:
>> 1. Revamping the test infrastructure
>> 2. Replacing scons, possibly with Bazel (see https://bazel.build/)
>>
>> Please respond with any ideas you have! We definitely won't get to
>> everything, but throwing ideas out there now will give us a large base
>>of
>> options for the coding sprint.
>>
>> Thanks,
>> Jason
>
>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
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3783: mem: Update DRAM configuration names

[Andreas Hansson]

Hi Jason,

I don’t see a reason why it could not be refactored as you suggest.
Definitely something to consider going forward.

Andreas

On 18/01/2017, 07:21, "gem5-dev on behalf of Jason Lowe-Power"
 wrote:

>
>---
>This is an automatically generated e-mail. To reply, visit:
>http://reviews.gem5.org/r/3783/#review9254
>---
>
>Ship it!
>
>
>While you're on this code, I have a question. Maybe Andreas H. can answer
>too. Why are all of the configurations for the memory controllers in
>src/mem/DRAMCtrl.py? They could all be in configs/dram_ctrls/*.py, right?
>
>It seems to me that the DRAMCtrl.py file is getting a little out of hand.
>Is there any reason not to move all of the specific DRAM controller
>timing definitions to new files in the config/ directory?
>
>- Jason Lowe-Power
>
>
>On Jan. 17, 2017, 10:04 p.m., Curtis Dunham wrote:
>>
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> http://reviews.gem5.org/r/3783/
>> ---
>>
>> (Updated Jan. 17, 2017, 10:04 p.m.)
>>
>>
>> Review request for Default and Matthias Jung.
>>
>>
>> Repository: gem5
>>
>>
>> Description
>> ---
>>
>> mem: Update DRAM configuration names
>>
>> Names of DRAM configurations were updated to reflect both
>> the channel and device data width.
>>
>> Previous naming format was:
>> __
>>
>> The following nomenclature is now used:
>> __x
>> where n = The number of devices per rank on the channel
>>   x = Device width
>>
>> Total channel width can be calculated by n*w
>>
>> Example:
>> A 64-bit DDR4, 2400 channel consisting of 4-bit devices:
>> n = 16
>> w = 4
>> The resulting configuration name is:
>> DDR4_2400_16x4
>>
>> Updated scripts to match new naming convention.
>>
>> Added unique configurations for DDR4 for:
>> 1) 16x4
>> 2) 8x8
>> 3) 4x16
>>
>> Change-Id: Ibd7f763b7248835c624309143cb9fc29d56a69d1
>> Reviewed-by: Radhika Jagtap 
>> Reviewed-by: Curtis Dunham 
>>
>>
>> Diffs
>> -
>>
>>   tests/configs/realview-simple-timing-dual.py 97eebddaae84
>>   tests/configs/realview-simple-timing.py 97eebddaae84
>>   tests/configs/realview-switcheroo-full.py 97eebddaae84
>>   tests/configs/realview-switcheroo-o3.py 97eebddaae84
>>   tests/configs/realview-switcheroo-timing.py 97eebddaae84
>>   tests/configs/realview64-minor-dual.py 97eebddaae84
>>   tests/configs/realview64-minor.py 97eebddaae84
>>   tests/configs/realview64-o3-checker.py 97eebddaae84
>>   tests/configs/o3-timing-checker.py 97eebddaae84
>>   tests/configs/o3-timing-mp.py 97eebddaae84
>>   tests/configs/o3-timing-mt.py 97eebddaae84
>>   tests/configs/o3-timing.py 97eebddaae84
>>   tests/configs/pc-o3-timing.py 97eebddaae84
>>   tests/configs/pc-simple-timing.py 97eebddaae84
>>   tests/configs/pc-switcheroo-full.py 97eebddaae84
>>   tests/configs/realview-minor-dual.py 97eebddaae84
>>   tests/configs/realview-minor.py 97eebddaae84
>>   tests/configs/realview-o3-checker.py 97eebddaae84
>>   tests/configs/realview-o3-dual.py 97eebddaae84
>>   tests/configs/realview-o3.py 97eebddaae84
>>   src/mem/DRAMCtrl.py 97eebddaae84
>>   tests/configs/minor-timing-mp.py 97eebddaae84
>>   tests/configs/minor-timing.py 97eebddaae84
>>   configs/example/memcheck.py 97eebddaae84
>>   configs/learning_gem5/part1/simple.py 97eebddaae84
>>   configs/learning_gem5/part1/two_level.py 97eebddaae84
>>   configs/common/HMC.py 97eebddaae84
>>   configs/common/MemConfig.py 97eebddaae84
>>   configs/common/Options.py 97eebddaae84
>>   configs/dram/lat_mem_rd.py 97eebddaae84
>>   configs/dram/sweep.py 97eebddaae84
>>   configs/example/hmctest.py 97eebddaae84
>>   tests/configs/realview64-o3-dual.py 97eebddaae84
>>   tests/configs/realview64-o3.py 97eebddaae84
>>   tests/configs/realview64-simple-timing-dual.py 97eebddaae84
>>   tests/configs/realview64-simple-timing.py 97eebddaae84
>>   tests/configs/realview64-switcheroo-full.py 97eebddaae84
>>   tests/configs/realview64-switcheroo-o3.py 97eebddaae84
>>   tests/configs/realview64-switcheroo-timing.py 97eebddaae84
>>   tests/configs/tgen-dram-ctrl.py 97eebddaae84
>>   tests/configs/tsunami-minor-dual.py 97eebddaae84
>>   tests/configs/tsunami-minor.py 97eebddaae84
>>   tests/configs/tsunami-o3-dual.py 97eebddaae84
>>   tests/configs/tsunami-o3.py 97eebddaae84
>>   tests/configs/tsunami-simple-timing-dual.py 97eebddaae84
>>   tests/configs/tsunami-simple-timing.py 97eebddaae84
>>   tests/configs/tsunami-switcheroo-full.py 97eebddaae84
>>
>> Diff: http://reviews.gem5.org/r/3783/diff/
>>
>>
>> Testing
>> ---
>>
>>
>> Thanks,
>>
>> Curtis Dunham
>>
>>
>
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

IMPORTANT 

Re: [gem5-dev] changeset in gem5: syscall_emul: add support for x86 statfs syst...

[Andreas Hansson]

Hi Tony,

As a way of avoiding breakage, how about using OpenBSD (or similar) on a
VM in VirtualBox. It does not cost any $$ and Bjoern may even be able to
help set it up(?). It would be good to have such a setup available for
anyone who’s patches are likely to cause problems on BSD (i.e. anything
involving syscalls). If it works there, OSX should be fine. For now it
would be good to get things building again, even if that means reverting
temporarily. Makes sense?

I do not know how to best solve the bigger issue of “forking” the
functionality based on the underlying OS. Do we really need to have the
bits that would not work on BSD? If so, then perhaps just a
syscall_linux.cc/hh and then a single ifdef?

Andreas


On 12/01/2017, 17:01, "gem5-dev on behalf of Gutierrez, Anthony"
<gem5-dev-boun...@gem5.org on behalf of anthony.gutier...@amd.com> wrote:

>We do not have access to BSD or OSX, so unless somebody can give Brandon
>access to such a machine he would have no way to test any potential fix.
>
>From a high level, the only easy solution I see is to guard OS-specific
>code with #ifdefs or something similar. It seems that if we are going to
>support more advanced OS features and syscalls in SE mode a fundamental
>refactoring of SE code may be necessary, and will require help from
>everybody. Brandon has already done a lot down this path, adding support
>for dynamic linking, pthreads, and has done a lot of refactoring here.
>
>Could somebody who is more familiar with BSD, and has access, try to come
>up with a fix? Brandon is merely adding a feature here, and the fact that
>it breaks support for some other feature is an artifact of the simulator
>design, and I don't want to put the onus on individual contributors to
>fix fundamental flaws when adding useful features. Hopefully we can come
>up with a solution as a community.
>
>-Original Message-
>From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas
>Hansson
>Sent: Thursday, January 12, 2017 12:45 AM
>To: gem5 Developer List <gem5-dev@gem5.org>; Potter, Brandon
><brandon.pot...@amd.com>
>Cc: gem5-...@m5sim.org
>Subject: Re: [gem5-dev] changeset in gem5: syscall_emul: add support for
>x86 statfs syst...
>
>Hi Brandon,
>
>Could you have a look at this and come up with some form of solution so
>that gem5 compiles on BSD and OSX as well?
>
>Thanks,
>
>Andreas
>
>On 22/12/2016, 10:30, "gem5-dev on behalf of Bjoern A. Zeeb"
><gem5-dev-boun...@gem5.org on behalf of bzeeb-li...@lists.zabbadoz.net>
>wrote:
>
>>On 15 Dec 2016, at 18:17, Brandon Potter wrote:
>>
>>> changeset deaf82fd2e7c in /z/repo/gem5
>>> details: http://repo.gem5.org/gem5?cmd=changeset;node=deaf82fd2e7c
>>> description:
>>> syscall_emul: add support for x86 statfs system calls
>>>
>>
>>Does this compile on anything but Linux?   statfs.h doesn’t exists
>>elsewhere I guess?   statfs is historic and still more or less OS
>>specific.
>>
>>Did you actually implement statfs, or is this statvfs as in
>>http://pubs.opengroup.org/onlinepubs/95399/basedefs/sys/statvfs.h.h
>>tml
>>
>>?   Not sure what the linux syscall does there?
>>
>>
>>
>>> diffstat:
>>>
>>>  src/arch/x86/linux/linux.hh   |  18 ++
>>>  src/arch/x86/linux/process.cc |   2 +-
>>>  src/sim/syscall_emul.hh   |  32 ++--
>>>  3 files changed, 49 insertions(+), 3 deletions(-)
>>>
>>> diffs (110 lines):
>>>
>>> diff -r 104a404d426e -r deaf82fd2e7c src/arch/x86/linux/linux.hh
>>> --- a/src/arch/x86/linux/linux.hhThu Dec 15 13:14:41 2016 -0500
>>> +++ b/src/arch/x86/linux/linux.hhThu Dec 15 13:16:03 2016 -0500
>>> @@ -67,6 +67,24 @@
>>>  int64_t unused0[3];
>>>  } tgt_stat64;
>>>
>>> +typedef struct {
>>> +long val[2];
>>> +} tgt_fsid;
>>> +
>>> +typedef struct {
>>> +long f_type;
>>> +long f_bsize;
>>> +long f_blocks;
>>> +long f_bfree;
>>> +long f_bavail;
>>> +long f_files;
>>> +long f_ffree;
>>> +tgt_fsid f_fsid;
>>> +long f_namelen;
>>> +long f_frsize;
>>> +long f_spare[5];
>>> +} tgt_statfs;
>>> +
>>>  static const int TGT_SIGHUP = 0x01;
>>>  static const int TGT_SIGINT = 0x02;
>>>  static const int TGT_SIGQUIT= 0x03;
>>> diff -r 104a404d426e -r deaf82fd2e7c src/arc

Re: [gem5-dev] changeset in gem5: syscall_emul: add support for x86 statfs syst...

[Andreas Hansson]

Hi Brandon,

Could you have a look at this and come up with some form of solution so
that gem5 compiles on BSD and OSX as well?

Thanks,

Andreas

On 22/12/2016, 10:30, "gem5-dev on behalf of Bjoern A. Zeeb"

wrote:

>On 15 Dec 2016, at 18:17, Brandon Potter wrote:
>
>> changeset deaf82fd2e7c in /z/repo/gem5
>> details: http://repo.gem5.org/gem5?cmd=changeset;node=deaf82fd2e7c
>> description:
>> syscall_emul: add support for x86 statfs system calls
>>
>
>Does this compile on anything but Linux?   statfs.h doesn’t exists
>elsewhere I guess?   statfs is historic and still more or less OS
>specific.
>
>Did you actually implement statfs, or is this statvfs as in
>http://pubs.opengroup.org/onlinepubs/95399/basedefs/sys/statvfs.h.html
>
>?   Not sure what the linux syscall does there?
>
>
>
>> diffstat:
>>
>>  src/arch/x86/linux/linux.hh   |  18 ++
>>  src/arch/x86/linux/process.cc |   2 +-
>>  src/sim/syscall_emul.hh   |  32 ++--
>>  3 files changed, 49 insertions(+), 3 deletions(-)
>>
>> diffs (110 lines):
>>
>> diff -r 104a404d426e -r deaf82fd2e7c src/arch/x86/linux/linux.hh
>> --- a/src/arch/x86/linux/linux.hhThu Dec 15 13:14:41 2016 -0500
>> +++ b/src/arch/x86/linux/linux.hhThu Dec 15 13:16:03 2016 -0500
>> @@ -67,6 +67,24 @@
>>  int64_t unused0[3];
>>  } tgt_stat64;
>>
>> +typedef struct {
>> +long val[2];
>> +} tgt_fsid;
>> +
>> +typedef struct {
>> +long f_type;
>> +long f_bsize;
>> +long f_blocks;
>> +long f_bfree;
>> +long f_bavail;
>> +long f_files;
>> +long f_ffree;
>> +tgt_fsid f_fsid;
>> +long f_namelen;
>> +long f_frsize;
>> +long f_spare[5];
>> +} tgt_statfs;
>> +
>>  static const int TGT_SIGHUP = 0x01;
>>  static const int TGT_SIGINT = 0x02;
>>  static const int TGT_SIGQUIT= 0x03;
>> diff -r 104a404d426e -r deaf82fd2e7c src/arch/x86/linux/process.cc
>> --- a/src/arch/x86/linux/process.ccThu Dec 15 13:14:41 2016 -0500
>> +++ b/src/arch/x86/linux/process.ccThu Dec 15 13:16:03 2016 -0500
>> @@ -355,7 +355,7 @@
>>  /* 134 */ SyscallDesc("uselib", unimplementedFunc),
>>  /* 135 */ SyscallDesc("personality", unimplementedFunc),
>>  /* 136 */ SyscallDesc("ustat", unimplementedFunc),
>> -/* 137 */ SyscallDesc("statfs", unimplementedFunc),
>> +/* 137 */ SyscallDesc("statfs", statfsFunc),
>>  /* 138 */ SyscallDesc("fstatfs", unimplementedFunc),
>>  /* 139 */ SyscallDesc("sysfs", unimplementedFunc),
>>  /* 140 */ SyscallDesc("getpriority", unimplementedFunc),
>> diff -r 104a404d426e -r deaf82fd2e7c src/sim/syscall_emul.hh
>> --- a/src/sim/syscall_emul.hhThu Dec 15 13:14:41 2016 -0500
>> +++ b/src/sim/syscall_emul.hhThu Dec 15 13:16:03 2016 -0500
>> @@ -62,6 +62,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -451,6 +452,7 @@
>>  //
>>  //
>>
>> +typedef struct statfs hst_statfs;
>>  #if NO_STAT64
>>  typedef struct stat hst_stat;
>>  typedef struct stat hst_stat64;
>> @@ -556,6 +558,32 @@
>>  tgt.copyOut(mem);
>>  }
>>
>> +template 
>> +static void
>> +copyOutStatfsBuf(SETranslatingPortProxy , Addr addr,
>> + hst_statfs *host)
>> +{
>> +TypedBufferArg tgt(addr);
>> +
>> +#if defined(__OpenBSD__) || defined(__APPLE__) ||
>> defined(__FreeBSD__)
>> +tgt->f_type = 0;
>> +#else
>> +tgt->f_type = TheISA::htog(host->f_type);
>> +#endif
>> +tgt->f_bsize = TheISA::htog(host->f_bsize);
>> +tgt->f_blocks = TheISA::htog(host->f_blocks);
>> +tgt->f_bfree = TheISA::htog(host->f_bfree);
>> +tgt->f_bavail = TheISA::htog(host->f_bavail);
>> +tgt->f_files = TheISA::htog(host->f_files);
>> +tgt->f_ffree = TheISA::htog(host->f_ffree);
>> +memcpy(>f_fsid, >f_fsid, sizeof(host->f_fsid));
>> +tgt->f_namelen = TheISA::htog(host->f_namelen);
>> +tgt->f_frsize = TheISA::htog(host->f_frsize);
>> +memcpy(>f_spare, >f_spare, sizeof(host->f_spare));
>> +
>> +tgt.copyOut(mem);
>> +}
>> +
>>  /// Target ioctl() handler.  For the most part, programs call ioctl()
>>  /// only to find out if their stdout is a tty, to determine whether
>> to
>>  /// do line or block buffering.  We always claim that output fds are
>> @@ -1156,7 +1184,7 @@
>>  if (result < 0)
>>  return -errno;
>>
>> -OS::copyOutStatfsBuf(tc->getMemProxy(), bufPtr, );
>> +copyOutStatfsBuf(tc->getMemProxy(), bufPtr, );
>>
>>  return 0;
>>  }
>> @@ -1182,7 +1210,7 @@
>>  if (result < 0)
>>  return -errno;
>>
>> -OS::copyOutStatfsBuf(tc->getMemProxy(), bufPtr, );
>> +copyOutStatfsBuf(tc->getMemProxy(), bufPtr, );
>>
>>  return 0;
>>  }
>> ___
>> gem5-dev 

Re: [gem5-dev] A complete gem5 <-> SystemC TLM bridge

[Andreas Hansson]

Hi Christian,

Great work! Thanks for getting this in shape.

Regarding your question on delays, the packet.hh header has a fairly
elaborate description (and yes, I am to blame). The delays are set and
incremented by the CoherentXBar and Cache for cases where the request
packets must make immediate progress due to the coherency protocol
implementation in gem5. Normally the delays are then actually added as
part of the response path. See for example the CoherentXBar and
recvTimingResp.

If a packet reaches the TLM bridge and these fields are non-zero, the best
thing to do would be to pay for it then and there, delay the packet, and
zero the fields. That way we 1) put the delays closer to where they really
should occur, and 2) avoid having to remember what packet should have what
delay fields.

Does that make sense?

Andreas

On 09/01/2017, 13:58, "Christian Menard" 
wrote:

>Dear all,
>
>I worked on series of patches [1-6] that implement a complete gem5 <->
>SystemC-TLM bridge. This is based on the previous work in util/tlm by
>Matthias
>Jung. Please see the README in the last patch [6] for more details.
>
>I would like to ask you to review the patches and to push them to
>mainline
>soon if there are no major issues found.
>
>I also have a small question that I would like to resolve before the
>final
>submission. When translating between gem5 Packets and TLM Transactions, I
>wonder how to handle the delays that are annotated to gem5 Packets
>(headerDelay, payloadDelay). What exactly are these delays used for and
>how
>should a Sender/Receiver handle these delays?
>
>The patch series depends on some other small patches. There are two
>patches
>from Matthias Jung [7,8], an old patch from me that gives the
>ExternalMaster a
>MasterID [9], and a new patch that does a small change in util/systemc
>[10].
>
>During my work on the bridge, I noticed a problem with the
>CxxConfigManager.
>Please see my post on the mailing list [11] and the corresponding patch
>[12].
>
>Thanks!
>
>Kind regards,
>Christian
>
>[1] http://reviews.gem5.org/r/3527/
>[2] http://reviews.gem5.org/r/3528/
>[3] http://reviews.gem5.org/r/3686/
>[4] http://reviews.gem5.org/r/3695/
>[5] http://reviews.gem5.org/r/3775/
>[6] http://reviews.gem5.org/r/3777/
>
>[7] http://reviews.gem5.org/r/3478/
>[8] http://reviews.gem5.org/r/3479/
>[9] http://reviews.gem5.org/r/3480/
>[10] http://reviews.gem5.org/r/3774/
>
>[11] http://www.mail-archive.com/gem5-dev@gem5.org/msg21318.html
>[12] http://reviews.gem5.org/r/3778/
>
>--
>Dipl.-Ing. Christian Menard
>Research Assistant
>
>TU Dresden
>Faculty of Computer Science
>Chair for Compiler Construction
>01062 Dresden
>
>Phone: +49 351 463-42441
>e-Mail: christian.men...@tu-dresden.de
>

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] protobuf error

[Andreas Hansson]

Hi Kritik,

Thanks for all the diligence. To me this sounds like an issue in the
protobuf headers, do you not think so?

Andreas


On 06/01/2017, 17:09, "gem5-dev on behalf of kritik bhimani"
 wrote:

>I got the following as error after doing a fresh clone and fresh build in
>the following case for RISCV . The error also persist while building for
>X86 and ARM
>scons build/RISCV/gem5.opt -j4
>
>In file included from build/RISCV/mem/probes/mem_trace.cc:46:0:
>build/RISCV/proto/packet.pb.h:324:6: error:
>"PROTOBUF_INLINE_NOT_IN_HEADERS" is not defined [-Werror=undef]
> #if !PROTOBUF_INLINE_NOT_IN_HEADERS
>  ^~
>cc1plus: all warnings being treated as errors
>scons: *** [build/RISCV/mem/probes/mem_trace.o] Error 1
>scons: building terminated because of errors.
>
>The above error can be rectified by making the following changes in
>SConstruct file in the root of repo
>
>@@ -652,7 +652,7 @@
> # Enable -Wall and -Wextra and then disable the few warnings that
> # we consistently violate
> main.Append(CCFLAGS=['-Wall', '-Wundef', '-Wextra',
>- '-Wno-sign-compare', '-Wno-unused-parameter'])
>+ '-Wno-sign-compare',
>'-Wno-unused-parameter','-DPROTOBUF_INLINE_NOT_IN_HEADERS=0'])
> # We always compile using C++11
> main.Append(CXXFLAGS=['-std=c++11'])
>
>For more context on the above error
>http://stackoverflow.com/questions/34474091/protobuf-inline-not-in-headers
>/34485004#34485004
>
>https://github.com/Open-Transactions/opentxs/issues/647
>
>I request to please verify the above changes by compiling it on Ubuntu
>16.10 and make the appropriate changes to SConscript since it might save
>some time for new non MAC users.
>
>I also checked that version of libprotobuf-dev and other associated
>packages installed on my system is the latest from
>https://launchpad.net/ubuntu/+source/protobuf
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

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
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2691: mem: implement x86 locked accesses in timing-mode classic cache

[Andreas Hansson]

> On Jan. 5, 2017, 4:32 p.m., Tony Gutierrez wrote:
> > Is there anything holding this up from being shipped?

In my view the patch needs two things:

1) Some thought around the design. I am still hoping there is a less invasive 
way of accommodating the functionality, possibly with some changes to the 
existing functions of the cache.

2) A way to test it. This should preferably include both synthetic and real 
use-cases. The memtester and memchecker may be a good starting point for the 
synthetic part.

It would be great if someone could dig into these issues.


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2691/#review9228
---


On April 15, 2016, 5:42 a.m., Steve Reinhardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2691/
> ---
> 
> (Updated April 15, 2016, 5:42 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11444:8a1419dbbfa6
> ---
> mem: implement x86 locked accesses in timing-mode classic cache
> 
> Add LockedRMW(Read|Write)(Req|Resp) commands.  In timing mode,
> use a combination of clearing permission bits and leaving
> an MSHR in place to prevent accesses & snoops from touching
> a locked block between the read and write parts of an locked
> RMW sequence.
> 
> 
> Diffs
> -
> 
>   src/mem/cache/cache.cc df24b9af42c72606f1fa8e5aa0502b53e81ea176 
>   src/mem/cache/mshr.hh df24b9af42c72606f1fa8e5aa0502b53e81ea176 
>   src/mem/packet.hh df24b9af42c72606f1fa8e5aa0502b53e81ea176 
>   src/mem/packet.cc df24b9af42c72606f1fa8e5aa0502b53e81ea176 
> 
> Diff: http://reviews.gem5.org/r/2691/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Steve Reinhardt
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: mem: Ensure InvalidateReq is considered isFor...

[Andreas Hansson]

changeset 3102db8903f5 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=3102db8903f5
description:
mem: Ensure InvalidateReq is considered isForward by MSHRs

This patch fixes an issue where an MSHR would incorrectly be perceived
to provide data to targets arriving after an InvalidateReq. To address
this the InvalidateReq is now treated as isForward, much like an
UpgradeReq that did not hit in the cache.

Change-Id: Ia878444d949539b5c33fd19f3e12b0b8a872275e
Reviewed-by: Andreas Hansson <andreas.hans...@arm.com>
Reviewed-by: Stephan Diestelhorst <stephan.diestelho...@arm.com>

diffstat:

 src/mem/cache/cache.cc |  6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diffs (23 lines):

diff -r 5d33c6972dda -r 3102db8903f5 src/mem/cache/cache.cc
--- a/src/mem/cache/cache.ccMon Dec 05 16:48:21 2016 -0500
+++ b/src/mem/cache/cache.ccMon Dec 05 16:48:23 2016 -0500
@@ -909,7 +909,8 @@
 bool blkValid = blk && blk->isValid();
 
 if (cpu_pkt->req->isUncacheable() ||
-(!blkValid && cpu_pkt->isUpgrade())) {
+(!blkValid && cpu_pkt->isUpgrade()) ||
+cpu_pkt->cmd == MemCmd::InvalidateReq) {
 // uncacheable requests and upgrades from upper-level caches
 // that missed completely just go through as is
 return nullptr;
@@ -936,8 +937,7 @@
 // where the determination the StoreCond fails is delayed due to
 // all caches not being on the same local bus.
 cmd = MemCmd::SCUpgradeFailReq;
-} else if (cpu_pkt->cmd == MemCmd::WriteLineReq ||
-   cpu_pkt->cmd == MemCmd::InvalidateReq) {
+} else if (cpu_pkt->cmd == MemCmd::WriteLineReq) {
 // forward as invalidate to all other caches, this gives us
 // the line in Exclusive state, and invalidates all other
 // copies
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3711: ruby: Detect garnet network-level deadlock.

[Andreas Hansson]

> On Nov. 17, 2016, 10:36 p.m., Andreas Hansson wrote:
> > src/mem/ruby/network/garnet2.0/NetworkInterface.cc, line 326
> > <http://reviews.gem5.org/r/3711/diff/2/?file=63632#file63632line326>
> >
> > this should not be a panic, perhaps a fatal?
> 
> Jieming Yin wrote:
> I think here should be a panic, since it's not an error caused by user. 
> If the condition satisfies, it is very likely to be a garnet routing problem.

Usually panic is for issues caused by a bug/error in the simulator itself. As 
you say, fatal is configuration/user related.

In this case I guess its somewhere in between. It is a bug in a protocol, not 
the simulator itself. I'm fine with either.


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3711/#review9118
---


On Dec. 1, 2016, 11:37 p.m., Jieming Yin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3711/
> ---
> 
> (Updated Dec. 1, 2016, 11:37 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11706:c2eb8893beb5
> ---
> ruby: Detect garnet network-level deadlock.
> 
> This patch detects garnet network deadlock by monitoring
> network interfaces. If a network interface continuously
> fails to allocate virtual channels for a message, a
> possible deadlock is detected.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.hh 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.cc 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   configs/network/Network.py c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/mem/ruby/network/garnet2.0/GarnetNetwork.py 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3711/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jieming Yin
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3747: ruby: Remove RubyMemoryControl and associated files

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3747/
---

Review request for Default.


Repository: gem5


Description
---

Changeset 11721:60b44b57fecb
---
ruby: Remove RubyMemoryControl and associated files

This patch removes the deprecated RubyMemoryControl. The DRAMCtrl
module should be used instead.


Diffs
-

  src/mem/ruby/structures/RubyMemoryControl.py 482900205561 
  src/mem/ruby/structures/SConscript 482900205561 
  src/mem/ruby/structures/RubyMemoryControl.hh 482900205561 
  src/mem/ruby/structures/RubyMemoryControl.cc 482900205561 
  src/mem/ruby/structures/MemoryNode.hh 482900205561 
  src/mem/ruby/structures/MemoryNode.cc 482900205561 
  src/mem/ruby/SConscript 482900205561 

Diff: http://reviews.gem5.org/r/3747/diff/


Testing
---


Thanks,

Andreas Hansson

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: tests: Check for TrafficGen as part of memche...

[Andreas Hansson]

changeset 482900205561 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=482900205561
description:
tests: Check for TrafficGen as part of memcheck regression

Since protobuf is still considered optional we do not always have the
TrafficGen. Check before running the memcheck regression.

diffstat:

 tests/configs/memcheck.py |  7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diffs (17 lines):

diff -r e832056deaed -r 482900205561 tests/configs/memcheck.py
--- a/tests/configs/memcheck.py Tue Nov 29 13:04:45 2016 -0500
+++ b/tests/configs/memcheck.py Wed Nov 30 11:15:21 2016 -0500
@@ -39,6 +39,13 @@
 # Authors: Jason Lowe-Power
 #  Andreas Hansson
 
+import m5
+from m5.objects import *
+
+# the traffic generator is only available if we have protobuf support,
+# so potentially skip this test
+require_sim_object("TrafficGen")
+
 # A wrapper around configs/example/memcheck.py
 
 # For some reason, this is implicitly needed by run.py
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3745: scons: fix how flags are passed to the compiler when more than one sanitizer at a time is enabled

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3745/#review9172
---

Ship it!


Looks ok, but the formatting of the patch summary is way outside the 65 char 
limit.

- Andreas Hansson


On Nov. 23, 2016, 10:25 p.m., Joe Gross wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3745/
> ---
> 
> (Updated Nov. 23, 2016, 10:25 p.m.)
> 
> 
> Review request for Default and Tony Gutierrez.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> scons: fix sanitizer flags with multiple sanitizers
> 
> There has been some problem when using address and undefined-behavior 
> sanitizers at the same time.
> This patch will look for the special case where both are enabled at once and 
> change the flags passed
> to the compiler to reflect this.
> 
> 
> Diffs
> -
> 
>   src/SConscript 9e5050028323260c6d2211d7158ac4a4145ed8bc 
> 
> Diff: http://reviews.gem5.org/r/3745/diff/
> 
> 
> Testing
> ---
> 
> local build
> 
> 
> Thanks,
> 
> Joe Gross
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3686: misc: use a simple_initiator_socket to implement the SystemC TLM Slave Port

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3686/#review9119
---

Ship it!


Ship It!

- Andreas Hansson


On Oct. 28, 2016, 4:55 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3686/
> ---
> 
> (Updated Oct. 28, 2016, 4:55 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11691:9733d3adf993
> ---
> misc: use a simple_initiator_socket to implement the SystemC TLM Slave Port
> 
> 
> Diffs
> -
> 
>   util/tlm/sc_slave_port.hh PRE-CREATION 
>   util/tlm/sc_slave_port.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3686/diff/
> 
> 
> Testing
> ---
> 
> Example applications are still running.
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3711: ruby: Detect garnet network-level deadlock.

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3711/#review9118
---



src/mem/ruby/network/garnet2.0/GarnetNetwork.py (line 49)
<http://reviews.gem5.org/r/3711/#comment7859>

what is the unit?

if it is time we should not use Uint



src/mem/ruby/network/garnet2.0/GarnetNetwork.py (line 62)
<http://reviews.gem5.org/r/3711/#comment7858>

what is the unit?



src/mem/ruby/network/garnet2.0/NetworkInterface.cc (line 73)
<http://reviews.gem5.org/r/3711/#comment7855>

just do it in the initialisation list



src/mem/ruby/network/garnet2.0/NetworkInterface.cc (line 326)
<http://reviews.gem5.org/r/3711/#comment7856>

this should not be a panic, perhaps a fatal?



src/mem/ruby/network/garnet2.0/NetworkInterface.cc (line 328)
<http://reviews.gem5.org/r/3711/#comment7857>

seems the arguments are wrong?

curTick should also be llu if I remember correctly


- Andreas Hansson


On Nov. 17, 2016, 6:37 p.m., Jieming Yin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3711/
> ---
> 
> (Updated Nov. 17, 2016, 6:37 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11706:527f77b1d6df
> ---
> ruby: Detect garnet network-level deadlock.
> 
> This patch detects garnet network deadlock by monitoring
> network interfaces. If a network interface continuously
> fails to allocate virtual channels for a message, a
> possible deadlock is detected.
> 
> 
> Diffs
> -
> 
>   configs/network/Network.py c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/mem/ruby/network/garnet2.0/GarnetNetwork.py 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.hh 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.cc 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3711/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jieming Yin
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: alpha: Remove ALPHA tru64 support and associa...

[Andreas Hansson]

changeset d40bdd3c5778 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=d40bdd3c5778
description:
alpha: Remove ALPHA tru64 support and associated tests

No one appears to be using it, and it is causing build issues
and increases the development and maintenance effort.

diffstat:

 src/arch/alpha/AlphaSystem.py  
   | 6 -
 src/arch/alpha/SConscript  
   | 3 -
 src/arch/alpha/kernel_stats.cc 
   |11 -
 src/arch/alpha/tru64/process.cc
   |   584 --
 src/arch/alpha/tru64/process.hh
   |60 -
 src/arch/alpha/tru64/system.cc 
   |92 -
 src/arch/alpha/tru64/system.hh 
   |76 -
 src/arch/alpha/tru64/tru64.cc  
   |94 -
 src/arch/alpha/tru64/tru64.hh  
   |   168 -
 src/kern/SConscript
   | 8 -
 src/kern/kernel_stats.cc   
   |21 -
 src/kern/kernel_stats.hh   
   | 5 -
 src/kern/tru64/dump_mbuf.cc
   |82 -
 src/kern/tru64/dump_mbuf.hh
   |40 -
 src/kern/tru64/mbuf.hh 
   |   100 -
 src/kern/tru64/printf.cc   
   |   272 -
 src/kern/tru64/printf.hh   
   |40 -
 src/kern/tru64/tru64.hh
   |  1222 -
 src/kern/tru64/tru64_events.cc 
   |   114 -
 src/kern/tru64/tru64_events.hh 
   |86 -
 src/kern/tru64/tru64_syscalls.cc   
   |   440 --
 src/kern/tru64/tru64_syscalls.hh   
   |   361 -
 src/sim/process.cc 
   | 5 -
 tests/long/se/20.parser/ref/alpha/tru64/NOTE   
   | 6 -
 tests/long/se/20.parser/ref/alpha/tru64/minor-timing/config.ini
   |   877 
 tests/long/se/20.parser/ref/alpha/tru64/minor-timing/simerr
   | 7 -
 tests/long/se/20.parser/ref/alpha/tru64/minor-timing/simout
   |72 -
 tests/long/se/20.parser/ref/alpha/tru64/minor-timing/stats.txt 
   |   833 ---
 tests/long/se/30.eon/ref/alpha/tru64/minor-timing/config.ini   
   |   877 
 tests/long/se/30.eon/ref/alpha/tru64/minor-timing/simerr   
   |53 -
 tests/long/se/30.eon/ref/alpha/tru64/minor-timing/simout   
   |17 -
 tests/long/se/30.eon/ref/alpha/tru64/minor-timing/stats.txt
   |   794 ---
 tests/long/se/30.eon/ref/alpha/tru64/o3-timing/config.ini  
   |   825 ---
 tests/long/se/30.eon/ref/alpha/tru64/o3-timing/simerr  
   |53 -
 tests/long/se/30.eon/ref/alpha/tru64/o3-timing/simout  
   |17 -
 tests/long/se/30.eon/ref/alpha/tru64/o3-timing/stats.txt   
   |  1059 
 tests/long/se/30.eon/ref/alpha/tru64/simple-timing/config.ini  
   |   366 -
 tests/long/se/30.eon/ref/alpha/tru64/simple-timing/simerr  
   |52 -
 tests/long/se/30.eon/ref/alpha/tru64/simple-timing/simout  
   |17 -
 tests/long/se/30.eon/ref/alpha/tru64/simple-timing/stats.txt   
   |   555 --
 tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/config.ini   
   |   877 
 tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/simerr   
   | 8 -
 tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/simout   
   |   653 ---
 tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/stats.txt
   |   829 ---
 tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/config.ini  
   |   825 ---
 

[gem5-dev] changeset in gem5: stats, alpha: Update ALPHA stats

[Andreas Hansson]

changeset 1d085f66c4ca in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=1d085f66c4ca
description:
stats, alpha: Update ALPHA stats

Reflect the removal of the syscall tracking.

diffstat:

 tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-minor/stats.txt
 |  41 +-
 tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/stats.txt  
 |  66 +
 tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3/stats.txt   
 |  43 +-
 
tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic-dual/stats.txt
   |  59 +
 tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/stats.txt   
 |  41 +-
 
tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/stats.txt
   |  54 +---
 tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/stats.txt   
 |  41 +-
 
tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/stats.txt
 |  53 +--
 8 files changed, 47 insertions(+), 351 deletions(-)

diffs (truncated from 590 to 300 lines):

diff -r 7339a92fffb5 -r 1d085f66c4ca 
tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-minor/stats.txt
--- a/tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-minor/stats.txt   
Thu Nov 17 04:54:16 2016 -0500
+++ b/tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-minor/stats.txt   
Thu Nov 17 04:54:18 2016 -0500
@@ -4,11 +4,11 @@
 sim_ticks1893220881500   # 
Number of ticks simulated
 final_tick   1893220881500   # 
Number of ticks from beginning of simulation (restored from checkpoints and 
never reset)
 sim_freq 1   # 
Frequency of simulated ticks
-host_inst_rate  27932   # 
Simulator instruction rate (inst/s)
-host_op_rate27932   # 
Simulator op (including micro ops) rate (op/s)
-host_tick_rate  941819152   # 
Simulator tick rate (ticks/s)
-host_mem_usage 393408   # 
Number of bytes of host memory used
-host_seconds  2010.17   # 
Real time elapsed on the host
+host_inst_rate  25399   # 
Simulator instruction rate (inst/s)
+host_op_rate25399   # 
Simulator op (including micro ops) rate (op/s)
+host_tick_rate  856404595   # 
Simulator tick rate (ticks/s)
+host_mem_usage 393548   # 
Number of bytes of host memory used
+host_seconds  2210.66   # 
Real time elapsed on the host
 sim_insts56147815   # 
Number of instructions simulated
 sim_ops  56147815   # 
Number of ops (including micro ops) simulated
 system.voltage_domain.voltage   1   # 
Voltage in Volts
@@ -443,37 +443,6 @@
 system.cpu.kern.ipl_used::221   # 
fraction of swpipl calls that actually changed the ipl
 system.cpu.kern.ipl_used::31 0.693386   # 
fraction of swpipl calls that actually changed the ipl
 system.cpu.kern.ipl_used::total  0.814825   # 
fraction of swpipl calls that actually changed the ipl
-system.cpu.kern.syscall::2  8  2.45%  2.45% # 
number of syscalls executed
-system.cpu.kern.syscall::3 30  9.20% 11.66% # 
number of syscalls executed
-system.cpu.kern.syscall::4  4  1.23% 12.88% # 
number of syscalls executed
-system.cpu.kern.syscall::6 42 12.88% 25.77% # 
number of syscalls executed
-system.cpu.kern.syscall::12 1  0.31% 26.07% # 
number of syscalls executed
-system.cpu.kern.syscall::15 1  0.31% 26.38% # 
number of syscalls executed
-system.cpu.kern.syscall::1715  4.60% 30.98% # 
number of syscalls executed
-system.cpu.kern.syscall::1910  3.07% 34.05% # 
number of syscalls executed
-system.cpu.kern.syscall::20 6  1.84% 35.89% # 
number of syscalls executed
-system.cpu.kern.syscall::23 4  1.23% 37.12% # 
number of syscalls executed
-system.cpu.kern.syscall::24 6  1.84% 38.96% # 
number of syscalls 

Re: [gem5-dev] Review Request 3705: dev: Fix buffer length when unserializing an eth pkt

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3705/#review9095
---


do we need a checkpoint updater, or does the call to paramIn return 0 if the 
parameter is not populated?

- Andreas Hansson


On Nov. 15, 2016, 9:22 p.m., Michael LeBeane wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3705/
> ---
> 
> (Updated Nov. 15, 2016, 9:22 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11705:008f04dcc085
> ---
> dev: Fix buffer length when unserializing an eth pkt
> Changeset 11701 only serialized the useful portion of of an ethernet packets'
> payload.  However, the device models expect each ethernet packet to contain
> a 16KB buffer, even if there is no data in it.  This patch adds a 'bufLength'
> field to EthPacketData so the original size of the packet buffer can always be
> unserialized.
> 
> Reported-by: Gabor Dozsa <gabor.do...@arm.com>
> 
> 
> Diffs
> -
> 
>   src/dev/net/etherpkt.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/dev/net/etherpkt.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3705/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Michael LeBeane
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3688: alpha: Remove ALPHA tru64 support and associated tests

[Andreas Hansson]

> On Nov. 14, 2016, 5:41 p.m., Brandon Potter wrote:
> > src/arch/alpha/kernel_stats.cc, line 185
> > <http://reviews.gem5.org/r/3688/diff/1/?file=62591#file62591line185>
> >
> > I think that all that the stats do is record mode switches between user 
> > and kernel space. There's a small tracker for kvm switches in arm, but this 
> > doesn't look like very useful information outside of someone needing it for 
> > a publication. At least, it's not useful enough to implement for other 
> > architectures apparently. The other architectures only have stubs for this 
> > class: src/arch/*/kernel_stats.hh.
> > 
> > Instead of worrying about the maintenance, can we remove this and stop 
> > tracking the kernel stats altogether? (If it is deemed useful, it probably 
> > needs to be implemented for the other architectures too.)

ok, i suggest we move forward with the current patch as is and then take it 
from there. could i get a few ship its?


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3688/#review9047
-------


On Oct. 27, 2016, 7:45 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3688/
> ---
> 
> (Updated Oct. 27, 2016, 7:45 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11705:6c2b4e24accf
> ---
> alpha: Remove ALPHA tru64 support and associated tests
> 
> No one appears to be using it, and it is causing build issues
> and increases the development and maintenance effort.
> 
> 
> Diffs
> -
> 
>   tests/long/se/30.eon/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/simerr c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/simout c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/stats.txt 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/stats.txt 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/stats.txt 
> c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/simerr c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/simout c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/smred.msg c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/smred.out c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/60

Re: [gem5-dev] Review Request 3528: misc: add a TLM to Gem5 Master Port

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3528/#review9081
---


Thanks for this. Some minor requests and style issues, then it's good to go.


util/tlm/sc_master_port.cc (line 74)
<http://reviews.gem5.org/r/3528/#comment7836>

It would be good to add a comment explaining where the request is deleted.



util/tlm/sc_master_port.cc (line 232)
<http://reviews.gem5.org/r/3528/#comment7837>

this is not a safe assumption

use SimClock::Int::ps for the "conversion"



util/tlm/sc_master_port.cc (line 289)
<http://reviews.gem5.org/r/3528/#comment7838>

do things work even if this is not TLM_UPDATED?


- Andreas Hansson


On Nov. 7, 2016, 2:56 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3528/
> ---
> 
> (Updated Nov. 7, 2016, 2:56 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11707:cb37987f081e
> ---
> misc: add a TLM to Gem5 Master Port
> 
> The current TLM code only provides a Slave Port that allows the gem5 world to
> send requests to the the TLM world. This patch adds a Master Port that allows
> the TLM world to send requests to the gem5 world. Furthermore, the patch
> provides a simple example application based on a TLM traffic generator.
> 
> 
> Diffs
> -
> 
>   util/tlm/sc_master_port.cc PRE-CREATION 
>   util/tlm/sim_control.cc PRE-CREATION 
>   util/tlm/examples/master_port/traffic_generator.hh PRE-CREATION 
>   util/tlm/examples/master_port/traffic_generator.cc PRE-CREATION 
>   util/tlm/sc_master_port.hh PRE-CREATION 
>   util/tlm/README b3d5f0e9e258 
>   util/tlm/examples/master_port/SConstruct PRE-CREATION 
>   util/tlm/examples/master_port/main.cc PRE-CREATION 
>   util/tlm/examples/master_port/tlm.py PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3528/diff/
> 
> 
> Testing
> ---
> 
> A simple example application consisting of a TLM traffic generator and a gem5 
> memory is part of the patch.
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Status of RISC-V patches

[Andreas Hansson]

Hi all,

Merely a thought when it comes to adding tests:

I would suggest we ditch all proprietary/closed-source tests and move in
the direction of something that is open and maintained. My proposal would
be to adopt a few of the tests from the llvm test suite. There are both
very short LLVM-specific tests that are BSD licensed, and a bunch of
smaller “apps” that maintain their original license. It would be great if
we could identify a few relevant tests from the tests suite and start
going in that direction. The source for the tests along with build scripts
etc should probably be in a repo on their own.

What do you think?

Andreas

On 28/10/2016, 22:12, "gem5-dev on behalf of Alec Roelke"
 wrote:

>I think I get it.  Thanks for your help!
>
>It looks like I won't be able to make use of any tests other than
>00.hello,
>because either they're multithreaded or pieces of them are missing.  I'm
>going to try to put my instruction tests into 02.insttest.
>
>On Fri, Oct 28, 2016 at 11:01 AM, Jason Lowe-Power 
>wrote:
>
>> Hi Alec,
>>
>> Our regression testing infrastructure is confusing, to say the least.
>> Honestly, it would take me at least a few hours to figure out how to add
>> new regressions again. But here's a little information that hopefully
>>will
>> help you save some time.
>>
>> You need to put reference outputs in tests/quick/se/> NAME>/ref/riscv/linux/.
>>
>> The config files are in tests/configs. One of these files (without the
>> .py) is what goes in  above. The  can be
>> anything. Using some of the same tests that are there make sense, but
>>you
>> may want to add other RISC-V specific tests as well.
>>
>> You *may* be able to use the config files in tests/configs without
>> changes, but maybe not. I'm not sure. You'll probably be able to use
>>some
>> but not others.
>>
>> Getting scons to run your regressions is totally black magic to me.
>>Here's
>> a couple of things I've learned, though.
>> 1) You should delete the build directory (e.g., build/RISCV/tests/
>> debug/quick/se/00.hello/riscv/) every time you want to re-run the
>> regression.
>> 2) The regression won't even try to run if you don't have dummy files in
>> tests/quick/se//ref/riscv/linux/.
>>
>> For the missing stats/changed stats, since this is first time you're
>> running the RISC-V stats, I would totally ignore all of that
>>information. I
>> would just look at the output (simout/simerr) and make sure it seems
>> reasonable (e.g., no errors). If you have an idea of a stat that you
>>expect
>> to see (e.g., floating point ops > 0) then you could look at the stats
>>file
>> too to make sure it's what you expect.
>>
>> There's no specific configuration you should be using. For the most
>>part,
>> all of the tests are just functional tests. The configurations for the
>> system are specified in the tests/configs () Python
>>files.
>>
>> Hopefully this will help you get started. Let us know if you have more
>> questions. Maybe someone with more regression tester experience will be
>> able to help more.
>>
>> Jason
>>
>> On Thu, Oct 27, 2016 at 8:23 PM Alec Roelke  wrote:
>>
>>> I'll start with converting as many from "quick" as I can.  If/when I
>>>end
>>> up creating my own, is there a convention for what they should be
>>>named and
>>> where they should go?
>>>
>>> Also, I'm having a bit of a problem with just 00.hello.  I compiled the
>>> source in tests/test-progs/hello/src into
>>>tests/test-progs/hello/bin/riscv/linux
>>> (for some reason mine disappeared), and then created
>>> tests/quick/se/00.hello/ref/riscv/linux/simple-atomic.  Then I compiled
>>> and ran build/RISCV/gem5.fast, configuring for the atomic CPU and
>>> redirecting the output stats, configuration, stdout, and stderr into
>>>that
>>> directory.  But when I run build/RISCV/tests/debug/quick/
>>> se/00.hello/riscv/linux/simple-atomic, it claims that it couldn't find
>>> several stats and that it found several other unexpected ones in
>>>stats.txt
>>> (and completely ignored the other files).  Is there some other
>>> configuration I should be using to generate the output for the
>>>regression?
>>> Actually, better yet, is there a way for me to figure out what the
>>> configuration I should be using is, since I imagine I'll run into this
>>> problem for the other CPU models?
>>>
>>> On Thu, Oct 27, 2016 at 6:38 PM, Jason Lowe-Power 
>>> wrote:
>>>
>>> Hi Alec,
>>>
>>> Thanks for taking the time for writing tests. It's something that we
>>>as a
>>> community need to get better at.
>>>
>>> To respond to your questions:
>>> - It is completely acceptable for you to include RISC-V only tests. In
>>> fact, I think it's a necessity.
>>> - Focusing just on the "quick" regressions makes sense to me. If you
>>>have
>>> one or two longer benchmarks, that would be good, but not required. If
>>>you
>>> could stay away from SPEC it would be better. I 

Re: [gem5-dev] Review Request 3688: alpha: Remove ALPHA tru64 support and associated tests

[Andreas Hansson]

> On Oct. 27, 2016, 7:47 a.m., Andreas Hansson wrote:
> > src/arch/alpha/kernel_stats.cc, line 185
> > <http://reviews.gem5.org/r/3688/diff/1/?file=62591#file62591line185>
> >
> > Could someone skilled in the arts help out with this?
> > 
> > Due to this removal, a number of Linux Tsunami regressions now have 
> > missing/removed stats.
> > 
> > Was the intention that these syscalls are both for linux and tru64? If 
> > so, they should be moved or re-added.
> > 
> > Please let me know asap.

Any input?


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3688/#review8992
-----------


On Oct. 27, 2016, 7:45 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3688/
> ---
> 
> (Updated Oct. 27, 2016, 7:45 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11705:6c2b4e24accf
> ---
> alpha: Remove ALPHA tru64 support and associated tests
> 
> No one appears to be using it, and it is causing build issues
> and increases the development and maintenance effort.
> 
> 
> Diffs
> -
> 
>   tests/long/se/30.eon/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/simerr c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/simout c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/stats.txt 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/stats.txt 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/stats.txt 
> c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/simerr c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/simout c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/smred.msg c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/smred.out c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/simerr c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/simout c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/simple-atomic/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/simple

Re: [gem5-dev] Review Request 3502: mem: Split the hit_latency into tag_latency and data_latency

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3502/#review8995
---

Ship it!


thanks for getting this in shape

- Andreas Hansson


On Oct. 27, 2016, 11:25 a.m., Sophiane SENNI wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3502/
> ---
> 
> (Updated Oct. 27, 2016, 11:25 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11688:1a792798e845
> ---
> mem: Split the hit_latency into tag_latency and data_latency
> 
> If the cache access mode is parallel, i.e. "sequential_access" parameter
> is set to "False", tags and data are accessed in parallel. Therefore,
> the hit_latency is the maximum latency between tag_latency and
> data_latency. On the other hand, if the cache access mode is
> sequential, i.e. "sequential_access" parameter is set to "True",
> tags and data are accessed sequentially. Therefore, the hit_latency
> is the sum of tag_latency plus data_latency.
> 
> 
> Diffs
> -
> 
>   configs/common/Caches.py 4aac82f10951 
>   configs/common/O3_ARM_v7a.py 4aac82f10951 
>   configs/example/arm/devices.py 4aac82f10951 
>   configs/learning_gem5/part1/caches.py 4aac82f10951 
>   src/mem/cache/Cache.py 4aac82f10951 
>   src/mem/cache/base.hh 4aac82f10951 
>   src/mem/cache/base.cc 4aac82f10951 
>   src/mem/cache/tags/Tags.py 4aac82f10951 
>   src/mem/cache/tags/base.hh 4aac82f10951 
>   src/mem/cache/tags/base.cc 4aac82f10951 
>   src/mem/cache/tags/base_set_assoc.hh 4aac82f10951 
>   src/mem/cache/tags/fa_lru.hh 4aac82f10951 
>   src/mem/cache/tags/fa_lru.cc 4aac82f10951 
> 
> Diff: http://reviews.gem5.org/r/3502/diff/
> 
> 
> Testing
> ---
> 
> Tested using --Debug-flags=Cache
> 
> 
> Thanks,
> 
> Sophiane SENNI
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3686: misc: use a simple_initiator_socket to implement the SystemC TLM slave port

[Andreas Hansson]

> On Oct. 26, 2016, 7:22 p.m., Andreas Hansson wrote:
> > Somehow the patch is not displaying. Did you use hg postreview?
> 
> Christian Menard wrote:
> Hi Andreas! Thanks for your reviews, I will give them a look soon. I 
> wanted to do some cleaning up anyway as there are still some inconsistencies 
> in master and slave port.
> 
> I uploaded the patches manually since I don't have the postreview 
> extension. Where can I get it? The link on the wiki is broken.

No worries. The link is updated.


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3686/#review8990
---


On Oct. 26, 2016, 4:26 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3686/
> ---
> 
> (Updated Oct. 26, 2016, 4:26 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> This patch simplifies the implementation of the SystemC TLM slave port.
> 
> 
> Diffs
> -
> 
>   util/tlm/sc_slave_port.hh c6e92c923a9e1c8cfd06ce9da1f61476ae4cb007 
>   util/tlm/sc_slave_port.cc c6e92c923a9e1c8cfd06ce9da1f61476ae4cb007 
> 
> Diff: http://reviews.gem5.org/r/3686/diff/
> 
> 
> Testing
> ---
> 
> Example applications are still running.
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3689: tests, ruby: Move rubytests from ALPHA (linux) to NULL (none)

[Andreas Hansson]

 
  
tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_CMP_token/config.ini
 PRE-CREATION 
  tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_CMP_token/simerr 
PRE-CREATION 
  tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_CMP_token/simout 
PRE-CREATION 
  
tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_CMP_token/stats.txt
 PRE-CREATION 
  
tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_hammer/config.ini 
PRE-CREATION 
  tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_hammer/simerr 
PRE-CREATION 
  tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_hammer/simout 
PRE-CREATION 
  tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_hammer/stats.txt 
PRE-CREATION 
  tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby/config.ini 
PRE-CREATION 
  tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby/simerr PRE-CREATION 
  
tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_Two_Level/simout
 c38fcdaa5fe5 
  
tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_Two_Level/stats.txt
 c38fcdaa5fe5 
  build_opts/NULL_MESI_Two_Level PRE-CREATION 
  build_opts/NULL_MOESI_CMP_directory PRE-CREATION 
  build_opts/NULL_MOESI_CMP_token PRE-CREATION 
  build_opts/NULL_MOESI_hammer PRE-CREATION 
  tests/configs/rubytest-ruby.py c38fcdaa5fe5 
  
tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_Two_Level/config.ini
 c38fcdaa5fe5 
  
tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_Two_Level/simerr
 c38fcdaa5fe5 

Diff: http://reviews.gem5.org/r/3689/diff/


Testing
---


Thanks,

Andreas Hansson

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3688: alpha: Remove ALPHA tru64 support and associated tests

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3688/#review8992
---



src/arch/alpha/kernel_stats.cc 
<http://reviews.gem5.org/r/3688/#comment7752>

Could someone skilled in the arts help out with this?

Due to this removal, a number of Linux Tsunami regressions now have 
missing/removed stats.

Was the intention that these syscalls are both for linux and tru64? If so, 
they should be moved or re-added.

Please let me know asap.


- Andreas Hansson


On Oct. 27, 2016, 7:45 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3688/
> ---
> 
> (Updated Oct. 27, 2016, 7:45 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11705:6c2b4e24accf
> ---
> alpha: Remove ALPHA tru64 support and associated tests
> 
> No one appears to be using it, and it is causing build issues
> and increases the development and maintenance effort.
> 
> 
> Diffs
> -
> 
>   tests/long/se/30.eon/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/simerr c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/simout c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/stats.txt 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/stats.txt 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/stats.txt 
> c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/simerr c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/simout c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/smred.msg c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/smred.out c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/simerr c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/simout c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/simple-atomic/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/simple-atomic/simerr c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/simple-atomic/simout c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/simple-atomic/stats.txt c38fcdaa5fe5 
>   tests/lo

Re: [gem5-dev] Review Request 3688: alpha: Remove ALPHA tru64 support and associated tests

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3688/#review8991
---


I don't want this particular part to stall due to the larger discussion around: 
http://reviews.gem5.org/r/3684/. It the tru64 removal is fine with everyone we 
can proceed with this patch and I'll rebase the complete removal for further 
discussion.

- Andreas Hansson


On Oct. 27, 2016, 7:45 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3688/
> ---
> 
> (Updated Oct. 27, 2016, 7:45 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11705:6c2b4e24accf
> ---
> alpha: Remove ALPHA tru64 support and associated tests
> 
> No one appears to be using it, and it is causing build issues
> and increases the development and maintenance effort.
> 
> 
> Diffs
> -
> 
>   tests/long/se/30.eon/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/simerr c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/simout c38fcdaa5fe5 
>   tests/long/se/30.eon/ref/alpha/tru64/simple-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/stats.txt 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/stats.txt 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/simerr c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/simout c38fcdaa5fe5 
>   tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/stats.txt 
> c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/simerr c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/simout c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/smred.msg c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/smred.out c38fcdaa5fe5 
>   tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/config.ini c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/simerr c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/simout c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/simple-atomic/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/simple-atomic/simerr c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/simple-atomic/simout c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/simple-atomic/stats.txt c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/simple-timing/config.ini 
> c38fcdaa5fe5 
>   tests/long/se/60.bzip2/ref/alpha/tru64/simple-timing/simerr c38

[gem5-dev] Review Request 3688: alpha: Remove ALPHA tru64 support and associated tests

[Andreas Hansson]

/tru64/simple-atomic/smred.sav c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-atomic/smred.sv2 c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-atomic/smred.twf c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-atomic/stats.txt c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-timing/config.ini c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-timing/simerr c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-timing/simout c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-timing/smred.out c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-timing/smred.pin c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-timing/smred.pl1 c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-timing/smred.pl2 c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-timing/smred.sav c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-timing/smred.sv2 c38fcdaa5fe5 
  
tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory/simout
 c38fcdaa5fe5 
  tests/long/se/70.twolf/ref/alpha/tru64/o3-timing/smred.out c38fcdaa5fe5 
  tests/long/se/70.twolf/ref/alpha/tru64/o3-timing/smred.pin c38fcdaa5fe5 
  tests/long/se/70.twolf/ref/alpha/tru64/o3-timing/smred.pl1 c38fcdaa5fe5 
  tests/long/se/70.twolf/ref/alpha/tru64/o3-timing/smred.pl2 c38fcdaa5fe5 
  tests/long/se/70.twolf/ref/alpha/tru64/o3-timing/smred.sav c38fcdaa5fe5 
  tests/long/se/70.twolf/ref/alpha/tru64/o3-timing/smred.sv2 c38fcdaa5fe5 
  tests/long/se/70.twolf/ref/alpha/tru64/o3-timing/smred.twf c38fcdaa5fe5 
  tests/long/se/70.twolf/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
  tests/quick/se/00.hello/ref/alpha/tru64/minor-timing/config.ini c38fcdaa5fe5 
  tests/quick/se/00.hello/ref/alpha/tru64/minor-timing/simerr c38fcdaa5fe5 
  tests/quick/se/00.hello/ref/alpha/tru64/minor-timing/simout c38fcdaa5fe5 
  tests/quick/se/00.hello/ref/alpha/tru64/minor-timing/stats.txt c38fcdaa5fe5 
  tests/quick/se/00.hello/ref/alpha/tru64/o3-timing/config.ini c38fcdaa5fe5 
  tests/quick/se/00.hello/ref/alpha/tru64/o3-timing/simerr c38fcdaa5fe5 
  tests/quick/se/00.hello/ref/alpha/tru64/o3-timing/simout c38fcdaa5fe5 
  tests/quick/se/00.hello/ref/alpha/tru64/o3-timing/stats.txt c38fcdaa5fe5 
  tests/quick/se/00.hello/ref/alpha/tru64/simple-atomic/config.ini c38fcdaa5fe5 
  tests/quick/se/00.hello/ref/alpha/tru64/simple-atomic/simerr c38fcdaa5fe5 
  tests/quick/se/00.hello/ref/alpha/tru64/simple-atomic/simout c38fcdaa5fe5 
  tests/quick/se/00.hello/ref/alpha/tru64/simple-atomic/stats.txt c38fcdaa5fe5 
  
tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_Two_Level/config.ini
 c38fcdaa5fe5 
  
tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_Two_Level/simerr
 c38fcdaa5fe5 
  
tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_Two_Level/simout
 c38fcdaa5fe5 
  
tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_Two_Level/stats.txt
 c38fcdaa5fe5 
  
tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory/config.ini
 c38fcdaa5fe5 
  
tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory/simerr
 c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-timing/smred.twf c38fcdaa5fe5 
  tests/quick/se/70.twolf/ref/alpha/tru64/simple-timing/stats.txt c38fcdaa5fe5 
  tests/test-progs/hello/bin/alpha/tru64/hello c38fcdaa5fe5 

Diff: http://reviews.gem5.org/r/3688/diff/


Testing
---


Thanks,

Andreas Hansson

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3686: misc: use a simple_initiator_socket to implement the SystemC TLM slave port

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3686/#review8990
---


Somehow the patch is not displaying. Did you use hg postreview?

- Andreas Hansson


On Oct. 26, 2016, 4:26 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3686/
> ---
> 
> (Updated Oct. 26, 2016, 4:26 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> This patch simplifies the implementation of the SystemC TLM slave port.
> 
> 
> Diffs
> -
> 
>   util/tlm/sc_slave_port.hh c6e92c923a9e1c8cfd06ce9da1f61476ae4cb007 
>   util/tlm/sc_slave_port.cc c6e92c923a9e1c8cfd06ce9da1f61476ae4cb007 
> 
> Diff: http://reviews.gem5.org/r/3686/diff/
> 
> 
> Testing
> ---
> 
> Example applications are still running.
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3528: misc: add a TLM to Gem5 Master Port implementation

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3528/#review8989
---


Some of the files are not displaying ok. Did you post the review using hg 
postreview?


util/tlm/examples/master_port/Makefile (line 37)
<http://reviews.gem5.org/r/3528/#comment7748>

Same as previous patch. This should use pkt-config.



util/tlm/examples/master_port/Makefile (line 40)
<http://reviews.gem5.org/r/3528/#comment7749>

An assignment to a name would be good for these paths. GEM5_ROOT or similar



util/tlm/examples/master_port/main.cc (line 101)
<http://reviews.gem5.org/r/3528/#comment7750>

gem5 has a random_mt that you should preferably use



util/tlm/examples/master_port/main.cc (line 187)
<http://reviews.gem5.org/r/3528/#comment7751>

Same as the other patch. Why not use the response string size?



util/tlm/sc_master_port.hh (line 32)
<http://reviews.gem5.org/r/3528/#comment7738>

Not convention



util/tlm/sc_master_port.hh (line 49)
<http://reviews.gem5.org/r/3528/#comment7739>

Could you provide a bit more comments here around what is assumed, how it 
does what it does, what it doesn't do, etc



util/tlm/sc_master_port.cc (line 32)
<http://reviews.gem5.org/r/3528/#comment7740>

Same as the header



util/tlm/sc_master_port.cc (line 73)
<http://reviews.gem5.org/r/3528/#comment7741>

Is it assumed that the request is deleted elsewhere?



util/tlm/sc_master_port.cc (line 81)
<http://reviews.gem5.org/r/3528/#comment7742>

comma on the line before

name,
other name



util/tlm/sc_master_port.cc (line 90)
<http://reviews.gem5.org/r/3528/#comment7743>

Why the re-interpret cast?



util/tlm/sc_master_port.cc (line 98)
<http://reviews.gem5.org/r/3528/#comment7744>

it is not a big problem, but technically gem5 can change mode during the 
simulation.

The API for this is involving calls to drain and drain resume etc. We don't 
have to fix it now, but it may be worth at least warning if any of these 
functions are called.



util/tlm/sc_master_port.cc (line 116)
<http://reviews.gem5.org/r/3528/#comment7745>

could we base this on the response string rather to avoid buffer overflows? 
:-)



util/tlm/sc_master_port.cc (line 126)
<http://reviews.gem5.org/r/3528/#comment7746>

odd indentation



util/tlm/sc_master_port.cc (line 138)
<http://reviews.gem5.org/r/3528/#comment7747>

what is this checking?


- Andreas Hansson


On Oct. 26, 2016, 4:23 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3528/
> ---
> 
> (Updated Oct. 26, 2016, 4:23 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> The current TLM code only provides a Slave Port that allows the gem5 world to 
> send requests to the the TLM world. This patch adds a Master Port that allows 
> the TLM world to send requests to the gem5 world. Furthermore, the patch 
> provides a simple example application based on a TLM traffic generator.
> 
> 
> Diffs
> -
> 
>   util/tlm/sc_master_port.cc PRE-CREATION 
>   util/tlm/sim_control.cc c6e92c923a9e1c8cfd06ce9da1f61476ae4cb007 
>   util/tlm/examples/master_port/Makefile PRE-CREATION 
>   util/tlm/examples/master_port/main.cc PRE-CREATION 
>   util/tlm/examples/master_port/tlm.py PRE-CREATION 
>   util/tlm/examples/slave_port/Makefile 
> c6e92c923a9e1c8cfd06ce9da1f61476ae4cb007 
>   util/tlm/sc_master_port.hh PRE-CREATION 
>   util/tlm/README c6e92c923a9e1c8cfd06ce9da1f61476ae4cb007 
> 
> Diff: http://reviews.gem5.org/r/3528/diff/
> 
> 
> Testing
> ---
> 
> A simple example application consisting of a TLM traffic generator and a gem5 
> memory is part of the patch.
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3527: misc: prepare the TLM sources for the addition of a TLM->Gem5 Master Port

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3527/#review8988
---


Thanks for this. There are a few minor issues and style questions.


util/tlm/Makefile (line 4)
<http://reviews.gem5.org/r/3527/#comment7717>

Just add the additional Copyright line before "All rights reserved."



util/tlm/Makefile (line 10)
<http://reviews.gem5.org/r/3527/#comment7718>

Please avoid changing whitespace (even if it is wrong). That should be done 
separately.



util/tlm/Makefile (line 35)
<http://reviews.gem5.org/r/3527/#comment7719>

Just leave Authors on the top line and indent your name.



util/tlm/Makefile (line 42)
<http://reviews.gem5.org/r/3527/#comment7720>

Both of these lines should use pkg-config.

I would suggest to do that as a separate patch though, and do it _before_ 
this patch.



util/tlm/Makefile (line 45)
<http://reviews.gem5.org/r/3527/#comment7722>

could you make a define for the directory rather?



util/tlm/Makefile (line 49)
<http://reviews.gem5.org/r/3527/#comment7721>

c++11



util/tlm/Makefile (line 86)
<http://reviews.gem5.org/r/3527/#comment7723>

This is a bit dubious, is it not?



util/tlm/examples/slave_port/main.cc (line 6)
<http://reviews.gem5.org/r/3527/#comment7737>

Same as before.



util/tlm/main.cc (line 6)
<http://reviews.gem5.org/r/3527/#comment7724>

Same as before



util/tlm/main.cc (line 97)
<http://reviews.gem5.org/r/3527/#comment7725>

keep the comma on the first line

name,
other name,
yet another name



util/tlm/main.cc (line 132)
<http://reviews.gem5.org/r/3527/#comment7726>

spurious change



util/tlm/main.cc (line 163)
<http://reviews.gem5.org/r/3527/#comment7727>

fits on the line? less than 78 char?



util/tlm/main.cc (line 195)
<http://reviews.gem5.org/r/3527/#comment7728>

again, spurious change



util/tlm/main.cc (line 206)
<http://reviews.gem5.org/r/3527/#comment7729>

i'm not sure why this has changed



util/tlm/main.cc (line 219)
<http://reviews.gem5.org/r/3527/#comment7730>

ame here



util/tlm/main.cc (line 228)
<http://reviews.gem5.org/r/3527/#comment7731>

yet another one



util/tlm/payload_event.hh (line 6)
<http://reviews.gem5.org/r/3527/#comment7732>

Same as before



util/tlm/payload_event.hh (line 50)
<http://reviews.gem5.org/r/3527/#comment7733>

Great. Could you provide a bit more comments though. At the moment it is 
difficult to grasp.



util/tlm/sc_port.hh (line 6)
<http://reviews.gem5.org/r/3527/#comment7734>

Same as before



util/tlm/sc_port.cc (line 89)
<http://reviews.gem5.org/r/3527/#comment7735>

You may want to call this SCSlavePort or TLMSlavePort or similar to avoid 
confusion.



util/tlm/sim_control.hh (line 6)
<http://reviews.gem5.org/r/3527/#comment7736>

Same as before


- Andreas Hansson


On Oct. 26, 2016, 4:11 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3527/
> ---
> 
> (Updated Oct. 26, 2016, 4:11 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> The current TLM code only provides a Slave Port that allows the gem5 world to 
> send requests to the the TLM world. This patch restructures the existing 
> source code in util/tlm in order to allow for code reuse and a clear file 
> structure whenn adding a master port implementation.
> 
> 
> Diffs
> -
> 
>   configs/common/MemConfig.py b3d5f0e9e258 
>   util/tlm/Makefile b3d5f0e9e258 
>   util/tlm/README b3d5f0e9e258 
>   util/tlm/examples/slave_port/main.cc PRE-CREATION 
>   util/tlm/main.cc b3d5f0e9e258 
>   util/tlm/payload_event.hh PRE-CREATION 
>   util/tlm/run_gem5.sh b3d5f0e9e258 
>   util/tlm/sc_port.hh b3d5f0e9e258 
>   util/tlm/sc_port.cc b3d5f0e9e258 
>   util/tlm/sc_target.hh b3d5f0e9e258 
>   util/tlm/sc_target.cc b3d5f0e9e258 
>   util/tlm/sim_control.hh PRE-CREATION 
>   util/tlm/tgen.cfg b3d5f0e9e258 
>   util/tlm/tlm.py b3d5f0e9e258 
>   util/tlm/tlm_elastic.py b3d5f0e9e258 
> 
> Diff: http://reviews.gem5.org/r/3527/diff/
> 
> 
> Testing
> ---
> 
> The examples provided in util/tlm (now util/tlm/examples/slave_port) still 
> compile and run error free.
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3480: misc: add a MasterId to the ExternalPort

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3480/#review8987
---

Ship it!


Ship It!

- Andreas Hansson


On Oct. 26, 2016, 4:06 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3480/
> ---
> 
> (Updated Oct. 26, 2016, 4:06 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> The Request constructor requires a MasterID. However, an external transactor 
> has no chance of getting a MasterID as it does not have a pointer to the 
> System. This patch adds a MasterID to ExternalMaster in order to allow 
> external modules to genrerate Packets.
> 
> 
> Diffs
> -
> 
>   src/mem/ExternalMaster.py b3d5f0e9e258 
>   src/mem/external_master.hh b3d5f0e9e258 
>   src/mem/external_master.cc b3d5f0e9e258 
> 
> Diff: http://reviews.gem5.org/r/3480/diff/
> 
> 
> Testing
> ---
> 
> Used in a SystemC transactor
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: config: Break out base options for usage with...

[Andreas Hansson]

changeset 725fef71f376 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=725fef71f376
description:
config: Break out base options for usage with NULL ISA

This patch breaks out the most basic configuration options into a set
of base options, to allow them to be used also by scripts that do not
involve any ISA, and thus no actual CPUs or devices.

The patch also fixes a few modules so that they can be imported in a
NULL build, and avoid dragging in FSConfig every time Options is
imported.

diffstat:

 configs/common/CpuConfig.py |2 +-
 configs/common/FSConfig.py  |2 +-
 configs/common/Options.py   |  141 +--
 configs/common/PlatformConfig.py|2 +-
 configs/common/Simulation.py|4 +-
 configs/example/garnet_synth_traffic.py |2 +-
 configs/example/ruby_direct_test.py |2 +-
 configs/example/ruby_gpu_random_test.py |2 +-
 configs/example/ruby_mem_test.py|2 +-
 configs/example/ruby_random_test.py |2 +-
 10 files changed, 87 insertions(+), 74 deletions(-)

diffs (truncated from 302 to 300 lines):

diff -r b3d5f0e9e258 -r 725fef71f376 configs/common/CpuConfig.py
--- a/configs/common/CpuConfig.py   Wed Oct 19 06:20:04 2016 -0400
+++ b/configs/common/CpuConfig.py   Wed Oct 26 14:50:54 2016 -0400
@@ -70,7 +70,7 @@
 return issubclass(cls, m5.objects.BaseCPU) and \
 not cls.abstract and \
 not issubclass(cls, m5.objects.CheckerCPU)
-except TypeError:
+except (TypeError, AttributeError):
 return False
 
 def get(name):
diff -r b3d5f0e9e258 -r 725fef71f376 configs/common/FSConfig.py
--- a/configs/common/FSConfig.pyWed Oct 19 06:20:04 2016 -0400
+++ b/configs/common/FSConfig.pyWed Oct 26 14:50:54 2016 -0400
@@ -42,7 +42,7 @@
 from m5.objects import *
 from Benchmarks import *
 from m5.util import *
-import PlatformConfig
+from common import PlatformConfig
 
 # Populate to reflect supported os types per target ISA
 os_types = { 'alpha' : [ 'linux' ],
diff -r b3d5f0e9e258 -r 725fef71f376 configs/common/Options.py
--- a/configs/common/Options.py Wed Oct 19 06:20:04 2016 -0400
+++ b/configs/common/Options.py Wed Oct 26 14:50:54 2016 -0400
@@ -41,13 +41,11 @@
 import m5
 from m5.defines import buildEnv
 from m5.objects import *
-from Benchmarks import *
+from common.Benchmarks import *
 
-import CpuConfig
-import MemConfig
-import PlatformConfig
-
-from FSConfig import os_types
+from common import CpuConfig
+from common import MemConfig
+from common import PlatformConfig
 
 def _listCpuTypes(option, opt, value, parser):
 CpuConfig.print_cpu_list()
@@ -61,15 +59,10 @@
 PlatformConfig.print_platform_list()
 sys.exit(0)
 
-def addCommonOptions(parser):
-# system options
-parser.add_option("--list-cpu-types",
-  action="callback", callback=_listCpuTypes,
-  help="List available CPU types")
-parser.add_option("--cpu-type", type="choice", default="atomic",
-  choices=CpuConfig.cpu_names(),
-  help = "type of cpu to run with")
-parser.add_option("--checker", action="store_true");
+# Add the very basic options that work also in the case of the no ISA
+# being used, and consequently no CPUs, but rather various types of
+# testers and traffic generators.
+def addNoISAOptions(parser):
 parser.add_option("-n", "--num-cpus", type="int", default=1)
 parser.add_option("--sys-voltage", action="store", type="string",
   default='1.0V',
@@ -79,6 +72,73 @@
   default='1GHz',
   help = """Top-level clock for blocks running at system
   speed""")
+
+# Memory Options
+parser.add_option("--list-mem-types",
+  action="callback", callback=_listMemTypes,
+  help="List available memory types")
+parser.add_option("--mem-type", type="choice", default="DDR3_1600_x64",
+  choices=MemConfig.mem_names(),
+  help = "type of memory to use")
+parser.add_option("--mem-channels", type="int", default=1,
+  help = "number of memory channels")
+parser.add_option("--mem-ranks", type="int", default=None,
+  help = "number of memory ranks per channel")
+parser.add_option("--mem-size", action="store", type="string",
+  default="512MB",
+  help="Specify the physical memory size (single memory)")
+
+
+parser.add_option("--memchecker", action="store_true")
+
+# Cache Options
+parser.add_option("--external-memory-system", type="string",
+  help="use external ports of this port_type for caches")
+parser.add_option("--tlm-memory", type="string",
+  help="use external port 

Re: [gem5-dev] Review Request 3502: mem: Split the hit_latency into tag_latency and data_latency

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3502/#review8986
---



src/mem/cache/tags/base_set_assoc.hh (line 233)
<http://reviews.gem5.org/r/3502/#comment7716>

If you don't mind changing it, could we keep the operator on the first line?

The same goes for the condition in the if statement.

I am not sure if this is actually captured in the style, but it is 
definitley convention.

The same goes for the copy in FA-LRU

Thanks!


- Andreas Hansson


On Oct. 25, 2016, 9:18 a.m., Sophiane SENNI wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3502/
> ---
> 
> (Updated Oct. 25, 2016, 9:18 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11688:74be5cba513a
> ---
> mem: Split the hit_latency into tag_latency and data_latency
> 
> If the cache access mode is parallel, i.e. "sequential_access" parameter
> is set to "False", tags and data are accessed in parallel. Therefore,
> the hit_latency is the maximum latency between tag_latency and
> data_latency. On the other hand, if the cache access mode is
> sequential, i.e. "sequential_access" parameter is set to "True",
> tags and data are accessed sequentially. Therefore, the hit_latency
> is the sum of tag_latency plus data_latency.
> 
> 
> Diffs
> -
> 
>   configs/common/Caches.py 4aac82f10951 
>   configs/common/O3_ARM_v7a.py 4aac82f10951 
>   configs/example/arm/devices.py 4aac82f10951 
>   configs/learning_gem5/part1/caches.py 4aac82f10951 
>   src/mem/cache/Cache.py 4aac82f10951 
>   src/mem/cache/base.hh 4aac82f10951 
>   src/mem/cache/base.cc 4aac82f10951 
>   src/mem/cache/tags/Tags.py 4aac82f10951 
>   src/mem/cache/tags/base.hh 4aac82f10951 
>   src/mem/cache/tags/base.cc 4aac82f10951 
>   src/mem/cache/tags/base_set_assoc.hh 4aac82f10951 
>   src/mem/cache/tags/fa_lru.hh 4aac82f10951 
>   src/mem/cache/tags/fa_lru.cc 4aac82f10951 
> 
> Diff: http://reviews.gem5.org/r/3502/diff/
> 
> 
> Testing
> ---
> 
> Tested using --Debug-flags=Cache
> 
> 
> Thanks,
> 
> Sophiane SENNI
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3684: alpha: Remove ALPHA support and supplemental files

[Andreas Hansson]

> On Oct. 25, 2016, 10:13 p.m., Jason Lowe-Power wrote:
> > util/regress, line 45
> > <http://reviews.gem5.org/r/3684/diff/1/?file=62482#file62482line45>
> >
> > I think this has been pointed out by Brad in the past, but we need to 
> > keep these tests for other Ruby protocols around. I think it's fine to just 
> > switch them to using x86 instead of Alpha. As far as I know, most Ruby 
> > users are using x86 anyway.
> 
> Andreas Hansson wrote:
> Why X86 and not NULL? I would suggest to let all the ruby testers simply 
> be part of NULL (as suggested in the patch summary). It would be even nicer 
> if we didn't have to compile gem5 for every protocol, but that may be asking 
> too much.
> 
> Jason Lowe-Power wrote:
> There's two components to testing the protocols. First, do they compile, 
> which the NULL ISA would test perfectly well. Second, do they work, which we 
> need to run some applications on the protocol (Linux boot is actually a 
> pretty good application for this).
> 
> I agree that it would be good if Ruby was a library, but I do think it's 
> too much to ask :).

Feel free to add Linux boot to Ruby+X86. Today all we do is "hello" and 
rubytest. For the latter we don't need an ISA, NULL will do just fine (we use 
NULL for all the memtest and traffic-gen tests of the classic memory system). 
Running "hello" seems fairly redundant to me. I would think adding some more 
synthetic tests should be just as good as "hello" if not better. No?


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3684/#review8981
---


On Oct. 24, 2016, 8:43 p.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3684/
> ---
> 
> (Updated Oct. 24, 2016, 8:43 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11689:e1835e5846b9
> ---
> alpha: Remove ALPHA support and supplemental files
> 
> This patch removes support for ALPHA, and correspondingly also removes
> any devices, tests, supporting functions, and configurations unique to
> ALPHA.
> 
> R.I.P.
> 
> A few things that are worth re-adding using something other than
> ALPHA:
> 
> 1) A two-system regresssion using Ethernet
> 
> 2) Ruby tester regressions using NULL for the variuos Ruby protocols
> 
> 
> Diffs
> -
> 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic-dual/system.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/config.ini 
> b3d5f0e9e258 
>   tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/simerr 
> b3d5f0e9e258 
>   tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/simout 
> b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/stats.txt 
> b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/system.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/config.ini
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/simerr
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/simout
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/stats.txt
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/system.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/config.ini 
> b3d5f0e9e258 
>   tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/simerr 
> b3d5f0e9e258 
>   tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/simout 
> b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/stats.txt 
> b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/system.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/config.ini
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/drivesys.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsuna

Re: [gem5-dev] Review Request 3684: alpha: Remove ALPHA support and supplemental files

[Andreas Hansson]

> On Oct. 25, 2016, 10:13 p.m., Jason Lowe-Power wrote:
> > SConstruct, line 421
> > <http://reviews.gem5.org/r/3684/diff/1/?file=62066#file62066line421>
> >
> > Clearly X86 should be the default, not ARM! ;)
> > 
> > Joking aside, maybe the default should be the same as the host system? 
> > Or we could remove the default entirely. I didn't even know a default 
> > existed.

It was based on ASCII distance (and the fact that I think it's fair to say that 
ARM is the best supported ISA).


> On Oct. 25, 2016, 10:13 p.m., Jason Lowe-Power wrote:
> > util/regress, line 45
> > <http://reviews.gem5.org/r/3684/diff/1/?file=62482#file62482line45>
> >
> > I think this has been pointed out by Brad in the past, but we need to 
> > keep these tests for other Ruby protocols around. I think it's fine to just 
> > switch them to using x86 instead of Alpha. As far as I know, most Ruby 
> > users are using x86 anyway.

Why X86 and not NULL? I would suggest to let all the ruby testers simply be 
part of NULL (as suggested in the patch summary). It would be even nicer if we 
didn't have to compile gem5 for every protocol, but that may be asking too much.


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3684/#review8981
---


On Oct. 24, 2016, 8:43 p.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3684/
> ---
> 
> (Updated Oct. 24, 2016, 8:43 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11689:e1835e5846b9
> ---
> alpha: Remove ALPHA support and supplemental files
> 
> This patch removes support for ALPHA, and correspondingly also removes
> any devices, tests, supporting functions, and configurations unique to
> ALPHA.
> 
> R.I.P.
> 
> A few things that are worth re-adding using something other than
> ALPHA:
> 
> 1) A two-system regresssion using Ethernet
> 
> 2) Ruby tester regressions using NULL for the variuos Ruby protocols
> 
> 
> Diffs
> -
> 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic-dual/system.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/config.ini 
> b3d5f0e9e258 
>   tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/simerr 
> b3d5f0e9e258 
>   tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/simout 
> b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/stats.txt 
> b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/system.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/config.ini
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/simerr
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/simout
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/stats.txt
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/system.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/config.ini 
> b3d5f0e9e258 
>   tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/simerr 
> b3d5f0e9e258 
>   tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/simout 
> b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/stats.txt 
> b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/system.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/config.ini
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/drivesys.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/simerr
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/simout
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/stats.txt
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/l

Re: [gem5-dev] Review Request 3684: alpha: Remove ALPHA support and supplemental files

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3684/#review8976
---



src/cpu/o3/rename_map.cc (line 99)
<http://reviews.gem5.org/r/3684/#comment7708>

It would be great if someone familiar with the o3 model could double check 
this modification.


- Andreas Hansson


On Oct. 24, 2016, 8:43 p.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3684/
> ---
> 
> (Updated Oct. 24, 2016, 8:43 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11689:e1835e5846b9
> ---
> alpha: Remove ALPHA support and supplemental files
> 
> This patch removes support for ALPHA, and correspondingly also removes
> any devices, tests, supporting functions, and configurations unique to
> ALPHA.
> 
> R.I.P.
> 
> A few things that are worth re-adding using something other than
> ALPHA:
> 
> 1) A two-system regresssion using Ethernet
> 
> 2) Ruby tester regressions using NULL for the variuos Ruby protocols
> 
> 
> Diffs
> -
> 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic-dual/system.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/config.ini 
> b3d5f0e9e258 
>   tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/simerr 
> b3d5f0e9e258 
>   tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/simout 
> b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/stats.txt 
> b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/system.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/config.ini
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/simerr
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/simout
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/stats.txt
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/system.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/config.ini 
> b3d5f0e9e258 
>   tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/simerr 
> b3d5f0e9e258 
>   tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/simout 
> b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/stats.txt 
> b3d5f0e9e258 
>   
> tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/system.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/config.ini
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/drivesys.terminal
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/simerr
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/simout
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/stats.txt
>  b3d5f0e9e258 
>   
> tests/quick/fs/80.netperf-stream/ref/alpha/linux/twosys-tsunami-simple-atomic/testsys.terminal
>  b3d5f0e9e258 
>   tests/quick/se/00.hello/ref/alpha/linux/minor-timing/config.ini 
> b3d5f0e9e258 
>   tests/quick/se/00.hello/ref/alpha/linux/minor-timing/simerr b3d5f0e9e258 
>   tests/quick/se/00.hello/ref/alpha/linux/minor-timing/simout b3d5f0e9e258 
>   tests/quick/se/00.hello/ref/alpha/linux/minor-timing/stats.txt b3d5f0e9e258 
>   tests/quick/se/00.hello/ref/alpha/linux/o3-timing/config.ini b3d5f0e9e258 
>   tests/quick/se/00.hello/ref/alpha/linux/o3-timing/simerr b3d5f0e9e258 
>   tests/quick/se/00.hello/ref/alpha/linux/o3-timing/simout b3d5f0e9e258 
>   tests/quick/se/00.hello/ref/alpha/linux/o3-timing/stats.txt b3d5f0e9e258 
>   tests/quick/se/00.hello/ref/alpha/linux/simple-atomic/config.ini 
> b3d5f0e9e258 
>   tests/quick/se/00.hello/ref/alpha/linux/simple-atomic/simerr b3d5f0e9e258 
>   tests/quick/se/00.hello/ref/alpha/linux/simple-atomic/simout b3d5f0e9e258 
>   tests/quick/se/00.hello/ref/alpha/linux/simple-atomic/stats.txt 
> b3d5f0e9e258 
>   
>

[gem5-dev] Removal of ALPHA from gem5

[Andreas Hansson]

Hi all,

The day has come.

As previously discussed, http://reviews.gem5.org/r/3684/ removes support for 
ALPHA from gem5. Ultimately this has to be a community decision. Thus, if 
anyone is actually relying on ALPHA for their work please let us know within 
the next two weeks.

If there are any questions or concerns, please speak up. Depending on the 
feedback, I aim to push this patch on November 14th.

Kind regards,

Andreas

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
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3684: alpha: Remove ALPHA support and supplemental files

[Andreas Hansson]

-minor/simout b3d5f0e9e258 
  src/arch/alpha/stacktrace.cc b3d5f0e9e258 
  src/arch/alpha/system.hh b3d5f0e9e258 
  tests/long/se/20.parser/ref/alpha/tru64/minor-timing/simout b3d5f0e9e258 
  tests/long/se/20.parser/ref/alpha/tru64/minor-timing/stats.txt b3d5f0e9e258 
  tests/long/se/30.eon/ref/alpha/tru64/minor-timing/config.ini b3d5f0e9e258 
  tests/long/se/20.parser/ref/alpha/tru64/minor-timing/config.ini b3d5f0e9e258 
  tests/long/se/20.parser/ref/alpha/tru64/minor-timing/simerr b3d5f0e9e258 
  tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3/system.terminal 
b3d5f0e9e258 
  tests/long/se/20.parser/ref/alpha/tru64/NOTE b3d5f0e9e258 
  tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3/simerr b3d5f0e9e258 
  tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3/simout b3d5f0e9e258 
  tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3/stats.txt b3d5f0e9e258 
  tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-minor/stats.txt 
b3d5f0e9e258 
  tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-minor/system.terminal 
b3d5f0e9e258 
  tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/config.ini 
b3d5f0e9e258 
  tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/simerr 
b3d5f0e9e258 
  tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/simout 
b3d5f0e9e258 
  tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/stats.txt 
b3d5f0e9e258 
  tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/system.terminal 
b3d5f0e9e258 
  tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini 
b3d5f0e9e258 
  build_opts/ALPHA_MESI_Two_Level b3d5f0e9e258 
  build_opts/ALPHA_MOESI_CMP_directory b3d5f0e9e258 
  SConstruct b3d5f0e9e258 
  build_opts/ALPHA b3d5f0e9e258 
  src/arch/alpha/idle_event.hh b3d5f0e9e258 
  src/arch/alpha/idle_event.cc b3d5f0e9e258 
  src/arch/alpha/interrupts.hh b3d5f0e9e258 
  src/arch/alpha/interrupts.cc b3d5f0e9e258 
  src/arch/alpha/ipr.hh b3d5f0e9e258 
  src/arch/alpha/ipr.cc b3d5f0e9e258 
  src/arch/alpha/isa.hh b3d5f0e9e258 
  src/arch/alpha/isa.cc b3d5f0e9e258 
  src/arch/alpha/isa/branch.isa b3d5f0e9e258 
  src/arch/alpha/isa/decoder.isa b3d5f0e9e258 
  src/arch/alpha/isa/fp.isa b3d5f0e9e258 
  src/arch/alpha/isa/int.isa b3d5f0e9e258 
  src/arch/alpha/isa/main.isa b3d5f0e9e258 
  src/arch/alpha/isa/mem.isa b3d5f0e9e258 
  src/arch/alpha/isa/opcdec.isa b3d5f0e9e258 
  src/arch/alpha/isa/pal.isa b3d5f0e9e258 
  src/arch/alpha/isa/unimp.isa b3d5f0e9e258 
  src/arch/alpha/isa/unknown.isa b3d5f0e9e258 
  src/arch/alpha/isa/util.isa b3d5f0e9e258 
  src/arch/alpha/isa_traits.hh b3d5f0e9e258 
  src/arch/alpha/kernel_stats.hh b3d5f0e9e258 
  src/arch/alpha/kernel_stats.cc b3d5f0e9e258 
  src/arch/alpha/linux/linux.hh b3d5f0e9e258 
  src/arch/alpha/linux/linux.cc b3d5f0e9e258 
  src/arch/alpha/linux/process.hh b3d5f0e9e258 
  src/arch/alpha/linux/process.cc b3d5f0e9e258 
  src/arch/alpha/linux/system.hh b3d5f0e9e258 
  src/arch/alpha/linux/system.cc b3d5f0e9e258 
  src/arch/alpha/locked_mem.hh b3d5f0e9e258 
  src/arch/alpha/microcode_rom.hh b3d5f0e9e258 
  src/arch/alpha/mmapped_ipr.hh b3d5f0e9e258 
  src/arch/alpha/mt.hh b3d5f0e9e258 
  src/arch/alpha/osfpal.hh b3d5f0e9e258 
  src/arch/alpha/osfpal.cc b3d5f0e9e258 
  src/arch/alpha/pagetable.hh b3d5f0e9e258 
  src/arch/alpha/pagetable.cc b3d5f0e9e258 
  src/arch/alpha/process.hh b3d5f0e9e258 
  src/arch/alpha/process.cc b3d5f0e9e258 
  src/arch/alpha/pseudo_inst.hh b3d5f0e9e258 
  src/arch/alpha/registers.hh b3d5f0e9e258 
  src/arch/alpha/regredir.hh b3d5f0e9e258 
  src/arch/alpha/regredir.cc b3d5f0e9e258 
  src/arch/alpha/remote_gdb.hh b3d5f0e9e258 
  src/arch/alpha/remote_gdb.cc b3d5f0e9e258 
  src/arch/alpha/stacktrace.hh b3d5f0e9e258 
  build_opts/ALPHA_MOESI_CMP_token b3d5f0e9e258 
  build_opts/ALPHA_MOESI_hammer b3d5f0e9e258 
  build_opts/Garnet_standalone b3d5f0e9e258 
  src/arch/alpha/AlphaISA.py b3d5f0e9e258 
  src/arch/alpha/AlphaInterrupts.py b3d5f0e9e258 
  src/arch/alpha/AlphaSystem.py b3d5f0e9e258 
  src/arch/alpha/AlphaTLB.py b3d5f0e9e258 
  src/arch/alpha/SConscript b3d5f0e9e258 
  src/arch/alpha/SConsopts b3d5f0e9e258 
  src/arch/alpha/aout_machdep.h b3d5f0e9e258 
  src/arch/alpha/decoder.hh b3d5f0e9e258 
  src/arch/alpha/decoder.cc b3d5f0e9e258 
  src/arch/alpha/ecoff_machdep.h b3d5f0e9e258 
  src/arch/alpha/ev5.hh b3d5f0e9e258 
  src/arch/alpha/ev5.cc b3d5f0e9e258 
  src/arch/alpha/faults.hh b3d5f0e9e258 
  src/arch/alpha/faults.cc b3d5f0e9e258 
  src/arch/alpha/freebsd/system.hh b3d5f0e9e258 
  src/arch/alpha/freebsd/system.cc b3d5f0e9e258 
  tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/simout b3d5f0e9e258 
  tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/smred.msg b3d5f0e9e258 
  tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/smred.out b3d5f0e9e258 

Diff: http://reviews.gem5.org/r/3684/diff/


Testing
---


Thanks,

Andreas Hansson

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo

Re: [gem5-dev] Review Request 3502: mem: Split the hit_latency into tag_latency and data_latency

[Andreas Hansson]

> On July 27, 2016, 4:52 p.m., Andreas Hansson wrote:
> > src/mem/cache/tags/base_set_assoc.hh, line 228
> > <http://reviews.gem5.org/r/3502/diff/12/?file=57342#file57342line228>
> >
> > Could you add a comment here?
> > 
> > It seems to me this code is not right, as it checks if the data is 
> > technically written now, but we only need the data at time T.
> > 
> > Should we not rather add the dataLatency to the blk->whenReady and then 
> > do the plus or max opteration?
> 
> Sophiane SENNI wrote:
> I actually don't really understand what this code represents, which was 
> already present before applying the patch. Because it seems to show a case 
> where the cache latency is greater than accessLatency, when the lat variable 
> is updated as follows:
> lat = cache->ticksToCycles(blk->whenReady - curTick())
> Can this situation actually occur ?
> 
> Andreas Hansson wrote:
> blk->whenReady represents the fact that the block is technically not 
> available yet. Due to how we do timing modelling we annotate the block when 
> it arrives, but have to remember when it is _actually_ availalbe. Thus, 
> anything we do here should add on top of the blk->whenReady. Same for fa_lru
> 
> Sophiane SENNI wrote:
> Ok. So if I understood, we actually need to apply the accessLatency on 
> top of the blk->whenReady. Hence, the good code would be as follows:
> 
> if (blk->whenReady > curTick()
> && cache->ticksToCycles(blk->whenReady - curTick())
> > accessLatency) {
> lat = cache->ticksToCycles(blk->whenReady - curTick()) + 
> accessLatency;
> }
> 
> Does this change make more sense ?

Yes. Also, could you add a comment to explain what is happening here.


> On July 27, 2016, 4:52 p.m., Andreas Hansson wrote:
> > src/mem/cache/tags/fa_lru.cc, line 188
> > <http://reviews.gem5.org/r/3502/diff/12/?file=57343#file57343line188>
> >
> > here we don't care about blk->whenReady?
> 
> Sophiane SENNI wrote:
> I we care about blk->whenReady in base_set_assoc.hh, I assume we have 
> also to care about it here.

Agreed.


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3502/#review8552
---


On Oct. 24, 2016, 2:56 p.m., Sophiane SENNI wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3502/
> ---
> 
> (Updated Oct. 24, 2016, 2:56 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11688:9dba209f1590
> ---
> mem: Split the hit_latency into tag_latency and data_latency
> 
> If the cache access mode is parallel, i.e. "sequential_access" parameter
> is set to "False", tags and data are accessed in parallel. Therefore,
> the hit_latency is the maximum latency between tag_latency and
> data_latency. On the other hand, if the cache access mode is
> sequential, i.e. "sequential_access" parameter is set to "True",
> tags and data are accessed sequentially. Therefore, the hit_latency
> is the sum of tag_latency plus data_latency.
> 
> 
> Diffs
> -
> 
>   src/mem/cache/tags/base.cc 4aac82f10951 
>   src/mem/cache/tags/base_set_assoc.hh 4aac82f10951 
>   src/mem/cache/tags/fa_lru.cc 4aac82f10951 
>   configs/common/Caches.py 4aac82f10951 
>   configs/common/O3_ARM_v7a.py 4aac82f10951 
>   configs/example/arm/devices.py 4aac82f10951 
>   configs/learning_gem5/part1/caches.py 4aac82f10951 
>   src/mem/cache/Cache.py 4aac82f10951 
>   src/mem/cache/base.hh 4aac82f10951 
>   src/mem/cache/base.cc 4aac82f10951 
>   src/mem/cache/tags/Tags.py 4aac82f10951 
>   src/mem/cache/tags/base.hh 4aac82f10951 
> 
> Diff: http://reviews.gem5.org/r/3502/diff/
> 
> 
> Testing
> ---
> 
> Tested using --Debug-flags=Cache
> 
> 
> Thanks,
> 
> Sophiane SENNI
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3683: config: Break out base options for usage with NULL ISA

[Andreas Hansson]

> On Oct. 20, 2016, 10:14 p.m., Jieming Yin wrote:
> > configs/common/FSConfig.py, line 45
> > <http://reviews.gem5.org/r/3683/diff/1/?file=61965#file61965line45>
> >
> > Should it be "from common import PlatformConfig" here as well, just 
> > like in Options.py? This script might cause a problem if 
> > /gem5/configs/common is not added to path.

Sorted. Any further comments? Note that I also changed the name of the function 
adding the non-ISA options, to avoid "base" and "common" saying roughly the 
same thing.


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3683/#review8958
-------


On Oct. 24, 2016, 9:10 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3683/
> ---
> 
> (Updated Oct. 24, 2016, 9:10 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11688:3b7d93ec1cf1
> ---
> config: Break out base options for usage with NULL ISA
> 
> This patch breaks out the most basic configuration options into a set
> of base options, to allow them to be used also by scripts that do not
> involve any ISA, and thus no actual CPUs or devices.
> 
> The patch also fixes a few modules so that they can be imported in a
> NULL build, and avoid dragging in FSConfig every time Options is
> imported.
> 
> 
> Diffs
> -
> 
>   configs/common/CpuConfig.py b3d5f0e9e258 
>   configs/common/FSConfig.py b3d5f0e9e258 
>   configs/common/Options.py b3d5f0e9e258 
>   configs/common/PlatformConfig.py b3d5f0e9e258 
>   configs/common/Simulation.py b3d5f0e9e258 
>   configs/example/garnet_synth_traffic.py b3d5f0e9e258 
>   configs/example/ruby_direct_test.py b3d5f0e9e258 
>   configs/example/ruby_gpu_random_test.py b3d5f0e9e258 
>   configs/example/ruby_mem_test.py b3d5f0e9e258 
>   configs/example/ruby_random_test.py b3d5f0e9e258 
> 
> Diff: http://reviews.gem5.org/r/3683/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3683: config: Break out base options for usage with NULL ISA

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3683/
---

(Updated Oct. 24, 2016, 9:10 a.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11688:3b7d93ec1cf1
---
config: Break out base options for usage with NULL ISA

This patch breaks out the most basic configuration options into a set
of base options, to allow them to be used also by scripts that do not
involve any ISA, and thus no actual CPUs or devices.

The patch also fixes a few modules so that they can be imported in a
NULL build, and avoid dragging in FSConfig every time Options is
imported.


Diffs (updated)
-

  configs/common/CpuConfig.py b3d5f0e9e258 
  configs/common/FSConfig.py b3d5f0e9e258 
  configs/common/Options.py b3d5f0e9e258 
  configs/common/PlatformConfig.py b3d5f0e9e258 
  configs/common/Simulation.py b3d5f0e9e258 
  configs/example/garnet_synth_traffic.py b3d5f0e9e258 
  configs/example/ruby_direct_test.py b3d5f0e9e258 
  configs/example/ruby_gpu_random_test.py b3d5f0e9e258 
  configs/example/ruby_mem_test.py b3d5f0e9e258 
  configs/example/ruby_random_test.py b3d5f0e9e258 

Diff: http://reviews.gem5.org/r/3683/diff/


Testing
---


Thanks,

Andreas Hansson

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3683: config: Break out base options for usage with NULL ISA

[Andreas Hansson]

> On Oct. 20, 2016, 2:11 p.m., Jason Lowe-Power wrote:
> > This is fine with me. However, I think this is just bandaging a broken 
> > system. IMO, we need to greatly simplify (maybe even totally remove) the 
> > command-line parameters in config/common.
> > 
> > What I've been telling people is this: gem5's interface is not the command 
> > line: it is Python scripts. You shouldn't think about "what options should 
> > I pass to gem5" when you are using it, you should instead say "what Python 
> > script should I write". 
> > 
> > My opinion is our scripts in configs/ should do two things:
> >  1. Break out commonalities between all Python configuration scripts. 
> > Things like DDR3 memory, basic cache coherence protocols, specific ARM CPU 
> > configurations, full system setup BS, etc.
> >  2. Give some basic examples of how to use Python configuration scripts, 
> > and give some starting points for new users to pick up gem5.
> > 
> > Sorry, this is off-topic for this patch, but it's something that's been 
> > bothering me for years now. This idea that many of our users have that you 
> > can just call gem5 with the "right" command line paramters to simulate what 
> > you need is harmful. It's harmful both to gem5 development as it makes 
> > these config scripts less maintainable (e.g., Ruby's scripts), and, in the 
> > worst case, produces bad architecture research since users can ignore 
> > important parameters.
> > 
> > /rant.
> > 
> > This isn't really a review of this patch, but I just wanted to say I don't 
> > think it's worth much of our time to try to bandage the current 
> > "Options.py" configuration style. Though, I'm not volunteering to fix this 
> > either. BTW, I think the ARM config scripts in configs/examples/arm are a 
> > step in the right direction, though I think they could be taken even 
> > further to make them cleaner and more maintainable.
> > 
> > Either way, thanks for making these changes, Andreas. We certainly can't 
> > have things that are generating errors for our users in the short term.

I completely agree that this is bandaid. I merely wanted to make sure things 
were somewhat less broken again and that people could use the existing scripts 
without things blowing up.


- Andreas


-----------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3683/#review8944
---


On Oct. 20, 2016, 11:07 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3683/
> ---
> 
> (Updated Oct. 20, 2016, 11:07 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11688:60b7de6442f3
> ---
> config: Break out base options for usage with NULL ISA
> 
> This patch breaks out the most basic configuration options into a set
> of base options, to allow them to be used also by scripts that do not
> involve any actual CPUs or devices. The patch also fixes a few modules
> so that they can be imported in a NULL build, and avoid dragging in
> FSConfig every time Options is imported.
> 
> 
> Diffs
> -----
> 
>   configs/common/CpuConfig.py b3d5f0e9e258 
>   configs/common/FSConfig.py b3d5f0e9e258 
>   configs/common/Options.py b3d5f0e9e258 
>   configs/common/PlatformConfig.py b3d5f0e9e258 
>   configs/example/garnet_synth_traffic.py b3d5f0e9e258 
> 
> Diff: http://reviews.gem5.org/r/3683/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3683: config: Break out base options for usage with NULL ISA

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3683/
---

Review request for Default.


Repository: gem5


Description
---

Changeset 11688:60b7de6442f3
---
config: Break out base options for usage with NULL ISA

This patch breaks out the most basic configuration options into a set
of base options, to allow them to be used also by scripts that do not
involve any actual CPUs or devices. The patch also fixes a few modules
so that they can be imported in a NULL build, and avoid dragging in
FSConfig every time Options is imported.


Diffs
-

  configs/common/CpuConfig.py b3d5f0e9e258 
  configs/common/FSConfig.py b3d5f0e9e258 
  configs/common/Options.py b3d5f0e9e258 
  configs/common/PlatformConfig.py b3d5f0e9e258 
  configs/example/garnet_synth_traffic.py b3d5f0e9e258 

Diff: http://reviews.gem5.org/r/3683/diff/


Testing
---


Thanks,

Andreas Hansson

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: stats: Update stats to reflect recent changes...

[Andreas Hansson]

changeset b3d5f0e9e258 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=b3d5f0e9e258
description:
stats: Update stats to reflect recent changes to floats

Mostly just splitting out the floats ops and corresponding
reads/writes.

diffstat:

 tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-minor/stats.txt
  |18 +-
 tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/stats.txt  
  |   198 +-
 tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-o3/stats.txt   
  |   104 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor-dual/stats.txt
  |26 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor/stats.txt 
  |18 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3-dual/stats.txt   
  |98 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3/stats.txt
  |46 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview64-minor-dual/stats.txt  
  |   104 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview64-minor/stats.txt   
  |32 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview64-o3-dual/stats.txt 
  |  6619 +
 tests/long/fs/10.linux-boot/ref/arm/linux/realview64-o3/stats.txt  
  |  2843 ++--
 
tests/long/fs/10.linux-boot/ref/arm/linux/realview64-simple-atomic-dual/stats.txt
|70 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview64-simple-atomic/stats.txt   
  |60 +-
 
tests/long/fs/10.linux-boot/ref/arm/linux/realview64-simple-timing-dual/stats.txt
|   104 +-
 tests/long/fs/10.linux-boot/ref/arm/linux/realview64-simple-timing/stats.txt   
  |60 +-
 tests/long/se/10.mcf/ref/arm/linux/minor-timing/stats.txt  
  |18 +-
 tests/long/se/10.mcf/ref/arm/linux/o3-timing/stats.txt 
  |40 +-
 tests/long/se/10.mcf/ref/sparc/linux/simple-timing/stats.txt   
  |18 +-
 tests/long/se/10.mcf/ref/x86/linux/o3-timing/stats.txt 
  |46 +-
 tests/long/se/10.mcf/ref/x86/linux/simple-timing/stats.txt 
  |18 +-
 tests/long/se/20.parser/ref/alpha/tru64/minor-timing/stats.txt 
  |18 +-
 tests/long/se/20.parser/ref/arm/linux/minor-timing/stats.txt   
  |16 +-
 tests/long/se/20.parser/ref/arm/linux/o3-timing/stats.txt  
  |38 +-
 tests/long/se/20.parser/ref/arm/linux/simple-atomic/stats.txt  
  |16 +-
 tests/long/se/20.parser/ref/arm/linux/simple-timing/stats.txt  
  |16 +-
 tests/long/se/20.parser/ref/x86/linux/o3-timing/stats.txt  
  |   100 +-
 tests/long/se/20.parser/ref/x86/linux/simple-atomic/stats.txt  
  |14 +-
 tests/long/se/20.parser/ref/x86/linux/simple-timing/stats.txt  
  |14 +-
 tests/long/se/30.eon/ref/alpha/tru64/minor-timing/stats.txt
  |18 +-
 tests/long/se/30.eon/ref/alpha/tru64/o3-timing/stats.txt   
  |   104 +-
 tests/long/se/30.eon/ref/alpha/tru64/simple-timing/stats.txt   
  |18 +-
 tests/long/se/30.eon/ref/arm/linux/minor-timing/stats.txt  
  |18 +-
 tests/long/se/30.eon/ref/arm/linux/o3-timing/stats.txt 
  |  1571 +-
 tests/long/se/30.eon/ref/arm/linux/simple-atomic/stats.txt 
  |18 +-
 tests/long/se/30.eon/ref/arm/linux/simple-timing/stats.txt 
  |18 +-
 tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/stats.txt
  |18 +-
 tests/long/se/40.perlbmk/ref/alpha/tru64/o3-timing/stats.txt   
  |   104 +-
 tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/stats.txt   
  |18 +-
 tests/long/se/40.perlbmk/ref/alpha/tru64/simple-timing/stats.txt   
  |18 +-
 tests/long/se/40.perlbmk/ref/arm/linux/minor-timing/stats.txt  
  |18 +-
 tests/long/se/40.perlbmk/ref/arm/linux/o3-timing/stats.txt 
  |   104 +-
 tests/long/se/40.perlbmk/ref/arm/linux/simple-atomic/stats.txt 
  |18 +-
 tests/long/se/40.perlbmk/ref/arm/linux/simple-timing/stats.txt 
  |18 +-
 tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/stats.txt 
  |18 +-
 tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/stats.txt
  |46 +-
 tests/long/se/50.vortex/ref/arm/linux/minor-timing/stats.txt   
  |18 +-
 

Re: [gem5-dev] FW: [gem5-users] scons build error for Garnet 2.0

[Andreas Hansson]

Hi all,

Why not grab the opportunity? Jason, what is the reason for the
weeks/months? Why couldn’t we remove Alpha this week if we decide that’s
the right thing to do?

Andreas

On 17/10/2016, 16:37, "gem5-dev on behalf of Gutierrez, Anthony"
<gem5-dev-boun...@gem5.org on behalf of anthony.gutier...@amd.com> wrote:

>I would like to see this clarified before we ask Brandon to go work on
>fixing ALPHA. If it is going to be phased out in a matter of months, I
>don't think we should be asking him to waste his time on fixing it.
>
>-Original Message-
>From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason
>Lowe-Power
>Sent: Monday, October 17, 2016 7:34 AM
>To: gem5 Developer List <gem5-dev@gem5.org>
>Subject: Re: [gem5-dev] FW: [gem5-users] scons build error for Garnet 2.0
>
>Hi Brandon,
>
>We've had this discussion before. See this thread:
>http://www.mail-archive.com/gem5-dev@gem5.org/msg19380.html
>
>In summary... I think we're planning on phasing out ALPHA, but that won't
>happen in the very short term (weeks), but may happen in the medium term
>(months).
>
>Cheers,
>Jason
>
>On Mon, Oct 17, 2016 at 9:28 AM Potter, Brandon <brandon.pot...@amd.com>
>wrote:
>
>> Switching this over to the dev mailing list since it seems more
>> suitable (and I don’t have a user account; need to rectify that at some
>>point).
>>
>> -Brandon
>>
>> From: Potter, Brandon
>> Sent: Monday, October 17, 2016 9:25 AM
>> To: 'Andreas Hansson' <andreas.hans...@arm.com>; gem5 users mailing
>> list < gem5-us...@gem5.org>
>> Subject: RE: [gem5-users] scons build error for Garnet 2.0
>>
>> Yes, I can fix it, but it’s difficult to know what values are for Tru64.
>>
>> Can we deprecate Alpha already?  It looks like the last commercial
>> product that came out with Alpha was in 2007, almost a decade ago. I
>> don’t think that I know anyone personally who uses a 10 year old
>> computer.  I don’t think that I’ve ever used an Alpha either to boot;
>> wondering why I need to go out of my way to try to support it.
>>
>> Does anyone use Alpha outside of running our regressions?
>>
>> -Brandon
>>
>> From: Andreas Hansson [mailto:andreas.hans...@arm.com]
>> Sent: Monday, October 17, 2016 3:29 AM
>> To: gem5 users mailing list <gem5-us...@gem5.org> gem5-us...@gem5.org>>
>> Cc: Potter, Brandon
>> <brandon.pot...@amd.com<mailto:brandon.pot...@amd.com
>> >>
>> Subject: Re: [gem5-users] scons build error for Garnet 2.0
>>
>> My bad, this is properly broken for ALPHA and tru64.
>>
>> In fact this was broken as part of:
>>
>> changeset:   11383:5ac090acd180
>> user:Brandon Potter <brandon.pot...@amd.com> brandon.pot...@amd.com>>
>> date:Thu Mar 17 10:24:17 2016 -0700
>> summary: syscall_emul: extend mmap system call to support file
>>backed
>> mmap
>>
>> It was later fixed for Linux, but not tru64 it appears.
>>
>> Brandon, could you get this resolved?
>>
>> Thanks,
>>
>> Andreas
>>
>> From: gem5-users <gem5-users-boun...@gem5.org> gem5-users-boun...@gem5.org>> on behalf of Andreas Hansson <
>> andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>>
>> Reply-To: gem5 users mailing list <gem5-us...@gem5.org> gem5-us...@gem5.org>>
>> Date: Monday, 17 October 2016 at 08:54
>> To: gem5 users mailing list <gem5-us...@gem5.org> gem5-us...@gem5.org>>
>> Subject: Re: [gem5-users] scons build error for Garnet 2.0
>>
>> Just use clang (i.e. the default OSX compiler).
>>
>> Andreas
>>
>> From: gem5-users <gem5-users-boun...@gem5.org> gem5-users-boun...@gem5.org>> on behalf of "F. A. Faisal" <
>> dipu.7...@gmail.com<mailto:dipu.7...@gmail.com>>
>> Reply-To: gem5 users mailing list <gem5-us...@gem5.org> gem5-us...@gem5.org>>
>> Date: Saturday, 15 October 2016 at 14:22
>> To: gem5 users mailing list <gem5-us...@gem5.org> gem5-us...@gem5.org>>
>> Subject: Re: [gem5-users] scons build error for Garnet 2.0
>>
>>
>> I tried with another gcc, but the result is the same...
>>
>>
>>
>> $ port select --set gccmp-gcc49
>>
>>
>>
>> $ port select --list gcc
>>
>> Warning: port definitions are more than two weeks old, consider
>> updating them by running 'port selfupdate'.
>>
>> Available versions for gcc:
>>
>> apple-gcc42
>>
>> mp-gcc47
>>
>> mp-gcc

[gem5-dev] changeset in gem5: config: Make configs/common a Python package

[Andreas Hansson]

, 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.
+#
+# Authors: Andreas Hansson
diff -r 074694750c5d -r 612f75cf36a0 configs/dist/sw.py
--- a/configs/dist/sw.pyFri Oct 14 09:02:03 2016 -0500
+++ b/configs/dist/sw.pyFri Oct 14 10:37:38 2016 -0400
@@ -37,10 +37,10 @@
 from m5.objects import *
 from m5.util import addToPath, fatal
 
-addToPath('../common')
+addToPath('../')
 
-import Simulation
-import Options
+from common import Simulation
+from common import Options
 
 def build_switch(options):
 # instantiate an EtherSwitch
diff -r 074694750c5d -r 612f75cf36a0 configs/dram/lat_mem_rd.py
--- a/configs/dram/lat_mem_rd.pyFri Oct 14 09:02:03 2016 -0500
+++ b/configs/dram/lat_mem_rd.pyFri Oct 14 10:37:38 2016 -0400
@@ -44,8 +44,8 @@
 from m5.util import addToPath
 from m5.internal.stats import periodicStatDump
 
-addToPath('../common')
-import MemConfig
+addToPath('../')
+from common import MemConfig
 
 addToPath('../../util')
 import protolib
@@ -258,7 +258,7 @@
 
 # create the actual cache hierarchy, for now just go with something
 # basic to explore some of the options
-from Caches import *
+from common.Caches import *
 
 # a starting point for an L3 cache
 class L3Cache(Cache):
diff -r 074694750c5d -r 612f75cf36a0 configs/dram/sweep.py
--- a/configs/dram/sweep.py Fri Oct 14 09:02:03 2016 -0500
+++ b/configs/dram/sweep.py Fri Oct 14 10:37:38 2016 -0400
@@ -42,9 +42,9 @@
 from m5.util import addToPath
 from m5.internal.stats import periodicStatDump
 
-addToPath('../common')
+addToPath('../')
 
-import MemConfig
+from common import MemConfig
 
 # this script is helpful to sweep the efficiency of a specific memory
 # controller configuration, by varying the number of banks accessed,
diff -r 074694750c5d -r 612f75cf36a0 configs/example/apu_se.py
--- a/configs/example/apu_se.py Fri Oct 14 09:02:03 2016 -0500
+++ b/configs/example/apu_se.py Fri Oct 14 10:37:38 2016 -0400
@@ -43,13 +43,12 @@
 from m5.util import addToPath
 
 addToPath('../')
-addToPath('../common')
 
 from ruby import Ruby
 
-import Options
-import Simulation
-import GPUTLBOptions, GPUTLBConfig
+from common import Options
+from common import Simulation
+from common import GPUTLBOptions, GPUTLBConfig
 
 ## Script Options 
 def setOption(parser, opt_str, value = 1):
diff -r 074694750c5d -r 612f75cf36a0 configs/example/arm/devices.py
--- a/configs/example/arm/devices.pyFri Oct 14 09:02:03 2016 -0500
+++ b/configs/example/arm/devices.pyFri Oct 14 10:37:38 2016 -0400
@@ -40,9 +40,9 @@
 
 import m5
 from m5.objects import *
-m5.util.addToPath('../../common')
-from Caches import *
-import CpuConfig
+m5.util.addToPath('../../')
+from common.Caches import *
+from common import CpuConfig
 
 class L1I(L1_ICache):
 hit_latency = 1
diff -r 074694750c5d -r 612f75cf36a0 configs/example/arm/fs_bigLITTLE.py
--- a/configs/example/arm/fs_bigLITTLE.py   Fri Oct 14 09:02:03 2016 -0500
+++ b/configs/example/arm/fs_bigLITTLE.py   Fri Oct 14 10:37:38 2016 -0400
@@ -46,9 +46,10 @@
 import m5
 from m5.objects import *
 
-m5.util.addToPath("../../common")
-import SysPaths
-import CpuConfig
+m5.util.addToPath("../../")
+
+from common import SysPaths
+from common import CpuConfig
 
 import devices
 
diff -r 074694750c5d -r 612f75cf36a0 configs/example/etrace_replay.py
--- a/configs/example/etrace_replay.py  Fri Oct 14 09:02:03 2016 -0500
+++ b/configs/example/etrace_replay.py  Fri Oct 14 10:37:38 2016 -0400
@@ -41,13 +41,13 @@
 
 from m5.util import addToPath, fatal
 
-addToPath('../common')
+addToPath('../')
 
-import Options
-import Simulation
-import CacheConfig
-import MemConfig
-from Caches import *
+from common import Options
+from common import Simulation
+from common import CacheConfig
+from common import MemConfig
+from common.Caches import *
 
 parser = optparse.OptionParser()
 O

Re: [gem5-dev] Review Request 3604: base: Output all AddrRange parameters to config.ini

[Andreas Hansson]

> On Aug. 17, 2016, 10:35 a.m., Andreas Hansson wrote:
> > No objections. We have been thinking of making this simpler, by creating a 
> > notion of PortGroups, and let the group be responsible for any 
> > hash/interleaving. Until we actually get to the point of implementing this 
> > I agree that we should proceed with your patch.

Should this be marked submitted? Also, was the CXX parser updated to 
accommodate the change?


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3604/#review8646
---


On Aug. 4, 2016, 5:56 p.m., Matthew Poremba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3604/
> ---
> 
> (Updated Aug. 4, 2016, 5:56 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11594:805067369ea7
> ---
> base: Output all AddrRange parameters to config.ini
> 
> Currently only 'start' and 'end' of AddrRange are printed in config.ini.
> This causes address ranges to be overlapping when loading a c++-only
> config with interleaved addresses using CxxConfigManger. This patch adds
> prints for the interleave and XOR bits to config.ini such that address
> ranges are properly setup with cxx config.
> 
> 
> Diffs
> -
> 
>   src/python/m5/params.py ba45735a726a4582e63561ab3dc741d7f0890447 
> 
> Diff: http://reviews.gem5.org/r/3604/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthew Poremba
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3663: config: Make configs/common a Python package

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3663/
---

(Updated Oct. 14, 2016, 11:19 a.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11681:a9f0fce013bb
---
config: Make configs/common a Python package

Continue along the same line as the recent patch that made the
Ruby-related config scripts Python packages and make also the
configs/common directory a package.

All affected config scripts are updated (hopefully).

Note that this change makes it apparent that the current organisation
and naming of the config directory and its subdirectories is rather
chaotic. We mix scripts that are directly invoked with scripts that
merely contain convenience functions. While it is not addressed in
this patch we should follow up with a re-organisation of the
config structure, and renaming of some of the packages.


Diffs (updated)
-

  configs/example/ruby_direct_test.py b4d943429dc6 
  configs/example/ruby_gpu_random_test.py b4d943429dc6 
  configs/example/ruby_mem_test.py b4d943429dc6 
  configs/example/ruby_random_test.py b4d943429dc6 
  configs/example/se.py b4d943429dc6 
  configs/learning_gem5/part1/caches.py b4d943429dc6 
  configs/learning_gem5/part1/two_level.py b4d943429dc6 
  configs/ruby/Ruby.py b4d943429dc6 
  configs/splash2/cluster.py b4d943429dc6 
  configs/splash2/run.py b4d943429dc6 
  tests/configs/alpha_generic.py b4d943429dc6 
  tests/configs/arm_generic.py b4d943429dc6 
  tests/configs/base_config.py b4d943429dc6 
  tests/configs/checkpoint.py b4d943429dc6 
  tests/configs/gpu-randomtest-ruby.py b4d943429dc6 
  tests/configs/gpu-ruby.py b4d943429dc6 
  tests/configs/learning-gem5-p1-two-level.py b4d943429dc6 
  tests/configs/memtest-filter.py b4d943429dc6 
  tests/configs/memtest-ruby.py b4d943429dc6 
  tests/configs/memtest.py b4d943429dc6 
  tests/configs/o3-timing-mp-ruby.py b4d943429dc6 
  tests/configs/o3-timing-mt.py b4d943429dc6 
  tests/configs/o3-timing-ruby.py b4d943429dc6 
  tests/configs/o3-timing.py b4d943429dc6 
  tests/configs/pc-simple-timing-ruby.py b4d943429dc6 
  tests/configs/realview-o3-checker.py b4d943429dc6 
  tests/configs/realview-o3-dual.py b4d943429dc6 
  tests/configs/realview-o3.py b4d943429dc6 
  tests/configs/realview64-o3-checker.py b4d943429dc6 
  tests/configs/realview64-o3-dual.py b4d943429dc6 
  tests/configs/realview64-o3.py b4d943429dc6 
  tests/configs/rubytest-ruby.py b4d943429dc6 
  tests/configs/simple-timing-mp-ruby.py b4d943429dc6 
  tests/configs/simple-timing-ruby.py b4d943429dc6 
  tests/configs/switcheroo.py b4d943429dc6 
  tests/configs/t1000-simple-atomic.py b4d943429dc6 
  tests/configs/twosys-tsunami-simple-atomic.py b4d943429dc6 
  tests/configs/x86_generic.py b4d943429dc6 
  configs/common/__init__.py b4d943429dc6 
  configs/dist/sw.py b4d943429dc6 
  configs/dram/lat_mem_rd.py b4d943429dc6 
  configs/dram/sweep.py b4d943429dc6 
  configs/example/apu_se.py b4d943429dc6 
  configs/example/arm/devices.py b4d943429dc6 
  configs/example/arm/fs_bigLITTLE.py b4d943429dc6 
  configs/example/etrace_replay.py b4d943429dc6 
  configs/example/fs.py b4d943429dc6 
  configs/example/garnet_synth_traffic.py b4d943429dc6 
  configs/example/hmctest.py b4d943429dc6 

Diff: http://reviews.gem5.org/r/3663/diff/


Testing
---


Thanks,

Andreas Hansson

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3624/#review8836
---

Ship it!


Looks good to me. It would be good if someone else could review this as well.

- Andreas Hansson


On Oct. 13, 2016, 4:48 p.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3624/
> ---
> 
> (Updated Oct. 13, 2016, 4:48 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11655:fce68047f694
> ---
> arch: [Patch 1/5] Added RISC-V base instruction set RV64I
> 
> First of five patches adding RISC-V to GEM5. This patch introduces the
> base 64-bit ISA (RV64I) in src/arch/riscv for use with syscall emulation.
> The multiply, floating point, and atomic memory instructions will be added
> in additional patches, as well as support for more detailed CPU models.
> The loader is also modified to be able to parse RISC-V ELF files, and a
> "Hello world!" example for RISC-V is added to test-progs.
> 
> Patch 2 will implement the multiply extension, RV64M; patch 3 will implement
> the floating point (single- and double-precision) extensions, RV64FD;
> patch 4 will implement the atomic memory instructions, RV64A, and patch 5
> will add support for timing, minor, and detailed CPU models that is missing
> from the first four patches (such as handling locked memory).
> 
> [Removed several unused parameters and imports from RiscvInterrupts.py,
> RiscvISA.py, and RiscvSystem.py.]
> [Fixed copyright information in RISC-V files copied from elsewhere that had
> ARM licenses attached.]
> [Reorganized instruction definitions in decoder.isa so that they are sorted
> by opcode in preparation for the addition of ISA extensions M, A, F, D.]
> [Fixed formatting of several files, removed some variables and
> instructions that were missed when moving them to other patches, fixed
> RISC-V Foundation copyright attribution, and fixed history of files
> copied from other architectures using hg copy.]
> [Fixed indentation of switch cases in isa.cc.]
> [Reorganized syscall descriptions in linux/process.cc to remove large
> number of repeated unimplemented system calls and added implmementations
> to functions that have received them since it process.cc was first
> created.]
> [Fixed spacing for some copyright attributions.]
> [Replaced the rest of the file copies using hg copy.]
> Signed-off by: Alec Roelke
> 
> 
> Diffs
> -
> 
>   build_opts/RISCV PRE-CREATION 
>   ext/libelf/elf_common.h 49cbf4bb0d36 
>   src/arch/riscv/RiscvISA.py PRE-CREATION 
>   src/arch/riscv/RiscvInterrupts.py PRE-CREATION 
>   src/arch/riscv/RiscvSystem.py PRE-CREATION 
>   src/arch/riscv/RiscvTLB.py PRE-CREATION 
>   src/arch/riscv/SConscript PRE-CREATION 
>   src/arch/riscv/SConsopts PRE-CREATION 
>   src/arch/riscv/decoder.hh PRE-CREATION 
>   src/arch/riscv/decoder.cc PRE-CREATION 
>   src/arch/riscv/faults.hh PRE-CREATION 
>   src/arch/riscv/faults.cc PRE-CREATION 
>   src/arch/riscv/idle_event.hh PRE-CREATION 
>   src/arch/riscv/idle_event.cc PRE-CREATION 
>   src/arch/riscv/interrupts.hh PRE-CREATION 
>   src/arch/riscv/interrupts.cc PRE-CREATION 
>   src/arch/riscv/isa.hh PRE-CREATION 
>   src/arch/riscv/isa.cc PRE-CREATION 
>   src/arch/riscv/isa/base.isa PRE-CREATION 
>   src/arch/riscv/isa/bitfields.isa PRE-CREATION 
>   src/arch/riscv/isa/decoder.isa PRE-CREATION 
>   src/arch/riscv/isa/formats/basic.isa PRE-CREATION 
>   src/arch/riscv/isa/formats/formats.isa PRE-CREATION 
>   src/arch/riscv/isa/formats/mem.isa PRE-CREATION 
>   src/arch/riscv/isa/formats/type.isa PRE-CREATION 
>   src/arch/riscv/isa/formats/unknown.isa PRE-CREATION 
>   src/arch/riscv/isa/includes.isa PRE-CREATION 
>   src/arch/riscv/isa/main.isa PRE-CREATION 
>   src/arch/riscv/isa/operands.isa PRE-CREATION 
>   src/arch/riscv/isa_traits.hh PRE-CREATION 
>   src/arch/riscv/kernel_stats.hh PRE-CREATION 
>   src/arch/riscv/linux/linux.hh PRE-CREATION 
>   src/arch/riscv/linux/linux.cc PRE-CREATION 
>   src/arch/riscv/linux/process.hh PRE-CREATION 
>   src/arch/riscv/linux/process.cc PRE-CREATION 
>   src/arch/riscv/locked_mem.hh PRE-CREATION 
>   src/arch/riscv/microcode_rom.hh PRE-CREATION 
>   src/arch/riscv/mmapped_ipr.hh PRE-CREATION 
>   src/arch/riscv/pagetable.hh PRE-CREATION 
>   src/arch/riscv/pagetable.cc PRE-CREATION 
>   src/arch/riscv/pra_constants.hh PRE-CREATION 
> 

Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

[Andreas Hansson]

On Oct. 12, 2016, 8:31 a.m., Alec Roelke wrote:
> > Some minor questions and cosmetic issues.
> > 
> > Could you please also confirm that the files that are copied (and then 
> > modified) started out as hg copy (as previously discussed).
> > 
> > Besides that I think this is looking really good. Thanks Alec!
> > 
> > Steve, can we retire Alpha now to make up for the additional build and test 
> > time? :-)
> 
> Alec Roelke wrote:
> I went through and made sure to use hg copy on files that I copied.  Ones 
> that were similar but were from the original GitHub I didn't do this with, 
> such as mmapped_ipr.hh (which I've learned is present in the other ISAs).  Is 
> there a way to check to make sure I did it right?
> 
> Also, as a heads up, I'm adding a sixth patch in the next few days that 
> will have a (more) proper implementation of the files in the linux/ 
> directory.  Currently the system calls technically work, but the structure of 
> the data structures for calls like stat aren't what RISC-V programs are 
> expecting.  So far I've only run into this for stat and fstat.
> 
> Andreas Hansson wrote:
> All sounds good. I'm not aware of any good way to check besides manually 
> inspecting the patch. If you have someone else's copyright and it says "new" 
> then clearly something is not right.
> 
> Could you close (fixed or drop) the issues that are open?
> 
> Alec Roelke wrote:
> I went through and did hg copy on all the files that could have been 
> copies (basically that didn't have my copyright on them).  There are a couple 
> of  problem files, though: vtophys.hh, types.hh, remote_gdb.cc, and 
> remote_gdb.hh.  I did not create them, but they aren't copies of any of the 
> other architectures since they're basically stubs (although in the RV64A 
> patch I do modify types.hh and have my copyright added).  Should I leave them 
> as is?

No objections from my end.

Thanks again for all the effort in getting this right.


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3624/#review8821
---


On Oct. 13, 2016, 4:48 p.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3624/
> ---
> 
> (Updated Oct. 13, 2016, 4:48 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11655:fce68047f694
> ---
> arch: [Patch 1/5] Added RISC-V base instruction set RV64I
> 
> First of five patches adding RISC-V to GEM5. This patch introduces the
> base 64-bit ISA (RV64I) in src/arch/riscv for use with syscall emulation.
> The multiply, floating point, and atomic memory instructions will be added
> in additional patches, as well as support for more detailed CPU models.
> The loader is also modified to be able to parse RISC-V ELF files, and a
> "Hello world!" example for RISC-V is added to test-progs.
> 
> Patch 2 will implement the multiply extension, RV64M; patch 3 will implement
> the floating point (single- and double-precision) extensions, RV64FD;
> patch 4 will implement the atomic memory instructions, RV64A, and patch 5
> will add support for timing, minor, and detailed CPU models that is missing
> from the first four patches (such as handling locked memory).
> 
> [Removed several unused parameters and imports from RiscvInterrupts.py,
> RiscvISA.py, and RiscvSystem.py.]
> [Fixed copyright information in RISC-V files copied from elsewhere that had
> ARM licenses attached.]
> [Reorganized instruction definitions in decoder.isa so that they are sorted
> by opcode in preparation for the addition of ISA extensions M, A, F, D.]
> [Fixed formatting of several files, removed some variables and
> instructions that were missed when moving them to other patches, fixed
> RISC-V Foundation copyright attribution, and fixed history of files
> copied from other architectures using hg copy.]
> [Fixed indentation of switch cases in isa.cc.]
> [Reorganized syscall descriptions in linux/process.cc to remove large
> number of repeated unimplemented system calls and added implmementations
> to functions that have received them since it process.cc was first
> created.]
> [Fixed spacing for some copyright attributions.]
> [Replaced the rest of the file copies using hg copy.]
> Signed-off by: Alec Roelke
> 
> 
> Diffs
> -
> 
>   build_opts/RISCV PRE-CREATION 
&g

[gem5-dev] Review Request 3663: config: Make configs/common a Python package

[Andreas Hansson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3663/
---

Review request for Default.


Repository: gem5


Description
---

Changeset 11671:6e5527f38e5b
---
config: Make configs/common a Python package

Continue along the same line as the recent patch that made the
Ruby-related config scripts Python packages and make also the
configs/common directory a package.

All affected config scripts are updated (hopefully).

Note that this change makes it apparent that the current organisation
and naming of the config directory and its subdirectories is rather
chaotic. We mix scripts that are directly invoked with scripts that
merely contain convenience functions. While it is not addressed in
this patch we should follow up with a re-organisation of the
config structure, and renaming of some of the packages.


Diffs
-

  configs/common/__init__.py 6ce719503eae 
  configs/dist/sw.py 6ce719503eae 
  configs/dram/lat_mem_rd.py 6ce719503eae 
  configs/dram/sweep.py 6ce719503eae 
  configs/example/apu_se.py 6ce719503eae 
  configs/example/arm/devices.py 6ce719503eae 
  configs/example/arm/fs_bigLITTLE.py 6ce719503eae 
  configs/example/etrace_replay.py 6ce719503eae 
  configs/example/fs.py 6ce719503eae 
  configs/example/garnet_synth_traffic.py 6ce719503eae 
  configs/example/hmctest.py 6ce719503eae 
  configs/example/ruby_direct_test.py 6ce719503eae 
  configs/example/ruby_gpu_random_test.py 6ce719503eae 
  configs/example/ruby_mem_test.py 6ce719503eae 
  configs/example/ruby_random_test.py 6ce719503eae 
  configs/example/se.py 6ce719503eae 
  configs/learning_gem5/part1/caches.py 6ce719503eae 
  configs/learning_gem5/part1/two_level.py 6ce719503eae 
  configs/ruby/Ruby.py 6ce719503eae 
  configs/splash2/cluster.py 6ce719503eae 
  configs/splash2/run.py 6ce719503eae 
  tests/configs/alpha_generic.py 6ce719503eae 
  tests/configs/arm_generic.py 6ce719503eae 
  tests/configs/base_config.py 6ce719503eae 
  tests/configs/checkpoint.py 6ce719503eae 
  tests/configs/gpu-randomtest-ruby.py 6ce719503eae 
  tests/configs/gpu-ruby.py 6ce719503eae 
  tests/configs/learning-gem5-p1-two-level.py 6ce719503eae 
  tests/configs/memtest-filter.py 6ce719503eae 
  tests/configs/memtest-ruby.py 6ce719503eae 
  tests/configs/memtest.py 6ce719503eae 
  tests/configs/o3-timing-mp-ruby.py 6ce719503eae 
  tests/configs/o3-timing-mt.py 6ce719503eae 
  tests/configs/o3-timing-ruby.py 6ce719503eae 
  tests/configs/o3-timing.py 6ce719503eae 
  tests/configs/pc-simple-timing-ruby.py 6ce719503eae 
  tests/configs/rubytest-ruby.py 6ce719503eae 
  tests/configs/simple-timing-mp-ruby.py 6ce719503eae 
  tests/configs/simple-timing-ruby.py 6ce719503eae 
  tests/configs/switcheroo.py 6ce719503eae 
  tests/configs/t1000-simple-atomic.py 6ce719503eae 
  tests/configs/twosys-tsunami-simple-atomic.py 6ce719503eae 
  tests/configs/x86_generic.py 6ce719503eae 

Diff: http://reviews.gem5.org/r/3663/diff/


Testing
---


Thanks,

Andreas Hansson

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev