Discussion:
[gem5-dev] Review Request: MEM: Add the system port as a central access point
(too old to reply)
Andreas Hansson
2011-12-19 13:52:59 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/942/
-----------------------------------------------------------

Review request for Default.


Summary
-------

MEM: Add the system port as a central access point

The system port is used as a globally reachable access point to the
memory subsystem. The benefit of using an actual port is that the
usual infrastructure is used to resolve any access and thus makes the
overall system able to handle distributed memories in any
configuration, and also makes the accesses agnostic to the address
map. This patch only introduces the port and does not actually use it
for anything.


Diffs
-----

src/python/m5/SimObject.py ca98021c3f96
src/python/m5/simulate.py ca98021c3f96
src/sim/System.py ca98021c3f96
src/sim/sim_object.hh ca98021c3f96
src/sim/sim_object.cc ca98021c3f96
src/sim/system.hh ca98021c3f96
src/sim/system.cc ca98021c3f96

Diff: http://reviews.m5sim.org/r/942/diff


Testing
-------

util/regress all passing (disregarding t1000 and eio)


Thanks,

Andreas
Ali Saidi
2012-01-04 00:42:00 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/942/#review1802
-----------------------------------------------------------


Why do you need setParent()? You could make every simobject have a parameter called System and have the default value be Parent.any (see src/dev/Device.py).

- Ali
Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.m5sim.org/r/942/
-----------------------------------------------------------
(Updated 2011-12-19 05:52:59)
Review request for Default.
Summary
-------
MEM: Add the system port as a central access point
The system port is used as a globally reachable access point to the
memory subsystem. The benefit of using an actual port is that the
usual infrastructure is used to resolve any access and thus makes the
overall system able to handle distributed memories in any
configuration, and also makes the accesses agnostic to the address
map. This patch only introduces the port and does not actually use it
for anything.
Diffs
-----
src/python/m5/SimObject.py ca98021c3f96
src/python/m5/simulate.py ca98021c3f96
src/sim/System.py ca98021c3f96
src/sim/sim_object.hh ca98021c3f96
src/sim/sim_object.cc ca98021c3f96
src/sim/system.hh ca98021c3f96
src/sim/system.cc ca98021c3f96
Diff: http://reviews.m5sim.org/r/942/diff
Testing
-------
util/regress all passing (disregarding t1000 and eio)
Thanks,
Andreas
Andreas Hansson
2012-01-04 15:09:38 UTC
Permalink
Post by Andreas Hansson
Post by Ali Saidi
Why do you need setParent()? You could make every simobject have a parameter called System and have the default value be Parent.any (see src/dev/Device.py).
After attempting a "simple" implementation as suggested, with one line in SimObject.py my conclusion is that it is more complicated than what it seems. Conceptually it is a good idea (there is no inherent reason why the whole setParent() is needed), but I struggle to get Python to appreciate the Param and Parent objects. Do you have any suggestions on how to do this?


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/942/#review1802
-----------------------------------------------------------
Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.m5sim.org/r/942/
-----------------------------------------------------------
(Updated 2011-12-19 05:52:59)
Review request for Default.
Summary
-------
MEM: Add the system port as a central access point
The system port is used as a globally reachable access point to the
memory subsystem. The benefit of using an actual port is that the
usual infrastructure is used to resolve any access and thus makes the
overall system able to handle distributed memories in any
configuration, and also makes the accesses agnostic to the address
map. This patch only introduces the port and does not actually use it
for anything.
Diffs
-----
src/python/m5/SimObject.py ca98021c3f96
src/python/m5/simulate.py ca98021c3f96
src/sim/System.py ca98021c3f96
src/sim/sim_object.hh ca98021c3f96
src/sim/sim_object.cc ca98021c3f96
src/sim/system.hh ca98021c3f96
src/sim/system.cc ca98021c3f96
Diff: http://reviews.m5sim.org/r/942/diff
Testing
-------
util/regress all passing (disregarding t1000 and eio)
Thanks,
Andreas
Steve Reinhardt
2012-01-04 15:54:54 UTC
Permalink
Post by Ali Saidi
Post by Ali Saidi
Why do you need setParent()? You could make every simobject have a
parameter called System and have the default value be Parent.any (see
src/dev/Device.py).
After attempting a "simple" implementation as suggested, with one line in
SimObject.py my conclusion is that it is more complicated than what it
seems. Conceptually it is a good idea (there is no inherent reason why the
whole setParent() is needed), but I struggle to get Python to appreciate
the Param and Parent objects. Do you have any suggestions on how to do this?
Can you be more specific with what you tried and why/how it didn't work?

BTW, I intend to get to your other patches on reviewboard soon; between
work and the holidays I've been kind of swamped lately. Thanks for your
patience!

Steve
Andreas Hansson
2012-01-04 18:25:43 UTC
Permalink
Hi Steve (et al)

The issue is essentially that the System inherits from MemObject, and placing a system = Param.System(...) in MemObject creates a cycle. params/System.hh ends up including MemObject.hh and vice versa. I have tried a number of permutations of forward declarations etc using the cxx_predecls vs swig_decls for the System/MemObject but not managed to solve it so far. It is starting to look pretty nasty, but I will keep on going and see if I can solve the circular dependency this creates in a decent way.

Andreas

From: Steve Reinhardt [mailto:stever-***@public.gmane.org]
Sent: 04 January 2012 15:55
To: gem5 Developer List
Cc: Andreas Hansson; Ali Saidi
Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a central access point
Post by Ali Saidi
Why do you need setParent()? You could make every simobject have a parameter called System and have the default value be Parent.any (see src/dev/Device.py).
After attempting a "simple" implementation as suggested, with one line in SimObject.py my conclusion is that it is more complicated than what it seems. Conceptually it is a good idea (there is no inherent reason why the whole setParent() is needed), but I struggle to get Python to appreciate the Param and Parent objects. Do you have any suggestions on how to do this?

Can you be more specific with what you tried and why/how it didn't work?

BTW, I intend to get to your other patches on reviewboard soon; between work and the holidays I've been kind of swamped lately. Thanks for your patience!

Steve


-- 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.
Steve Reinhardt
2012-01-04 20:55:00 UTC
Permalink
It might be worth splitting up MemObject... right now this represents both
"object that has ports" and "object that's in the memory system".
Conceptually the problem as I see it is that System is the former but not
the latter. So maybe if we have an intermediate class like PortObject that
has ports but doesn't have the Param.System on it you could break the cycle.

I don't really like the name "PortObject" since it conveys an object that
is a port rather than an object that has ports, but I can't come up with a
non-awkward alternative at the moment.

Steve
Hi Steve (et al)****
** **
The issue is essentially that the System inherits from MemObject, and
placing a system = Param.System(...) in MemObject creates a cycle.
params/System.hh ends up including MemObject.hh and vice versa. I have
tried a number of permutations of forward declarations etc using the
cxx_predecls vs swig_decls for the System/MemObject but not managed to
solve it so far. It is starting to look pretty nasty, but I will keep on
going and see if I can solve the circular dependency this creates in a
decent way.****
** **
Andreas****
** **
*Sent:* 04 January 2012 15:55
*To:* gem5 Developer List
*Cc:* Andreas Hansson; Ali Saidi
*Subject:* Re: [gem5-dev] Review Request: MEM: Add the system port as a
central access point****
** **
** **
wrote:****
Post by Ali Saidi
Why do you need setParent()? You could make every simobject have a
parameter called System and have the default value be Parent.any (see
src/dev/Device.py).****
After attempting a "simple" implementation as suggested, with one line in
SimObject.py my conclusion is that it is more complicated than what it
seems. Conceptually it is a good idea (there is no inherent reason why the
whole setParent() is needed), but I struggle to get Python to appreciate
the Param and Parent objects. Do you have any suggestions on how to do this?
****
** **
Can you be more specific with what you tried and why/how it didn't work?**
**
** **
BTW, I intend to get to your other patches on reviewboard soon; between
work and the holidays I've been kind of swamped lately. Thanks for your
patience!****
** **
Steve****
****
-- 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.
nathan binkert
2012-01-04 21:53:19 UTC
Permalink
Post by Andreas Hansson
The issue is essentially that the System inherits from MemObject, and placing a system = Param.System(...) in MemObject creates a cycle. params/System.hh ends up including MemObject.hh and vice versa. I have tried a number of permutations of forward declarations etc using the cxx_predecls vs swig_decls for the System/MemObject but not managed to solve it so far. It is starting to look pretty nasty, but I will keep on going and see if I can solve the circular dependency this creates in a decent way.
The standard way of doing this is to break the cycle in C++. The
reason you have a cycle (I believe) is that System has the physmem
parameter and the memories parameter which are both PhysicalMemory
objects which are in turn MemObjects. So, to do this the standard
way, you'd put the system = Param.System stuff into MemObject and
remove the physmem and memories parameters from System. Then in C++
during the constructor of PhysicalMemory, you'd call
params()->system->registerPhysicalMemory (you'd have to write that
function). The only hangup I see is that physmem is only one of
potentially many PhysicalMemory Objects, so to make this work, you'd
probably have to add a boolean parameter to PhysicalMemory that's like
system_memory so that one object would get written back.

It may just be better to allow cycles and enforce a more rigorous
split between the constructors and init() (which I've wanted to do for
a long time), but that's a much more complicated fix. Something else
that would be possible and would make things easier for this sort of
thing would be to add support for traversing the object tree in C++.
It probably wouldn't be all that difficult.


Nate
Andreas Hansson
2012-01-05 09:06:45 UTC
Permalink
Steve, Nate,

Thanks for the feedback! I hope we can reach consensus on this soon.

To start with Nate's suggestion: It is not the members of System or MemObject that cause the problem, this is already in place. The issue is with the parameter header generation and SWIG wrapper generation. This would happen also without the PhysicalMemory, since System inherits from MemObject, and not a MemObject has a System pointer. Note that the latter could be fixed in c++ by forward declaring System in MemObject.hh. This, however, requires some serious modifications of the cxx_predecls, swig_predecls etc.

A more general way of traversing the object hierarchy (I feel design patterns coming on :-) would definitely solve the problem and the setParent is really the not-so-general solution to this problem. Are there any other obvious good uses of this hierarchy that have been implemented in other (more inconvenient) ways?

Steve's suggestion: Very much seems doable, with an additional class in the hierarchy. I also struggle with the naming, but I'll give it a quick bash and see how it goes.

Andreas


-----Original Message-----
From: gem5-dev-bounces-1Gs4CP2/***@public.gmane.org [mailto:gem5-dev-bounces-1Gs4CP2/***@public.gmane.org] On Behalf Of nathan binkert
Sent: 04 January 2012 21:53
To: gem5 Developer List
Cc: Ali Saidi
Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a central access point
Post by Andreas Hansson
The issue is essentially that the System inherits from MemObject, and placing a system = Param.System(...) in MemObject creates a cycle. params/System.hh ends up including MemObject.hh and vice versa. I have tried a number of permutations of forward declarations etc using the cxx_predecls vs swig_decls for the System/MemObject but not managed to solve it so far. It is starting to look pretty nasty, but I will keep on going and see if I can solve the circular dependency this creates in a decent way.
The standard way of doing this is to break the cycle in C++. The
reason you have a cycle (I believe) is that System has the physmem
parameter and the memories parameter which are both PhysicalMemory
objects which are in turn MemObjects. So, to do this the standard
way, you'd put the system = Param.System stuff into MemObject and
remove the physmem and memories parameters from System. Then in C++
during the constructor of PhysicalMemory, you'd call
params()->system->registerPhysicalMemory (you'd have to write that
function). The only hangup I see is that physmem is only one of
potentially many PhysicalMemory Objects, so to make this work, you'd
probably have to add a boolean parameter to PhysicalMemory that's like
system_memory so that one object would get written back.

It may just be better to allow cycles and enforce a more rigorous
split between the constructors and init() (which I've wanted to do for
a long time), but that's a much more complicated fix. Something else
that would be possible and would make things easier for this sort of
thing would be to add support for traversing the object tree in C++.
It probably wouldn't be all that difficult.


Nate
_______________________________________________
gem5-dev mailing list
gem5-dev-1Gs4CP2/***@public.gmane.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.
Steve Reinhardt
2012-01-05 15:53:06 UTC
Permalink
I think we all agree that being able to traverse the hierarchy in C++ seems
reasonable is something we'll probably add eventually. I don't want to add
it for something that doesn't really need it though, because our general
rule has been to do as much in python as we reasonably can, and I'd rather
fix things on the python side to make this work there than to punt and
force it into C++.

As far as changing the object hierarchy: what about just taking all the
port support (what I was proposing be split off into the poorly named
PortObject) and push it up into SimObject? Then instead of having a
separate class for objects that have ports, we just say that every object
can have ports, but some have zero of them.

We'd still need MemObject to distingush objects that get a pointer back to
the System from those that don't. Though if that's the only distinction,
MemObject isn't the greatest name either; maybe it should be
SystemComponentObject or something like that (though that's too long IMO:
maybe SysObject, or SysComponent, or something like that). Then most
things would probably derive from SysComponent, and only things that
clearly aren't proper elements of a single system (like System itself, and
maybe EthernetLink, and maybe some of the fake SimObjects that aren't
really component models) would derive directly from SimObject.

So my proposal is:
1. Move MemObject methods into SimObject (getPort() etc.) and get rid of
MemObject entirely.
2. Replace MemObject with SimObject in mem/port.{cc,hh} and similar places
where it's just used to indicate a class that can have ports.
3. Create a new class SysComponent (I'm open to other names) that derives
from SimObject, and doesn't do anything but add a system =
Param.System(Parent.any) param.
4. Replace MemObject with SysComponent anywhere it's used as a base class.
5. (optional, but very desirable) Track down any non-MemObject derived
class that has its own Param.System(Parent.any) param, make it derive from
SysComponent too, and get rid of that explicit param.

Thoughts?

Steve
Post by Andreas Hansson
Steve, Nate,
Thanks for the feedback! I hope we can reach consensus on this soon.
To start with Nate's suggestion: It is not the members of System or
MemObject that cause the problem, this is already in place. The issue is
with the parameter header generation and SWIG wrapper generation. This
would happen also without the PhysicalMemory, since System inherits from
MemObject, and not a MemObject has a System pointer. Note that the latter
could be fixed in c++ by forward declaring System in MemObject.hh. This,
however, requires some serious modifications of the cxx_predecls,
swig_predecls etc.
A more general way of traversing the object hierarchy (I feel design
patterns coming on :-) would definitely solve the problem and the setParent
is really the not-so-general solution to this problem. Are there any other
obvious good uses of this hierarchy that have been implemented in other
(more inconvenient) ways?
Steve's suggestion: Very much seems doable, with an additional class in
the hierarchy. I also struggle with the naming, but I'll give it a quick
bash and see how it goes.
Andreas
-----Original Message-----
Behalf Of nathan binkert
Sent: 04 January 2012 21:53
To: gem5 Developer List
Cc: Ali Saidi
Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a central access point
Post by Andreas Hansson
The issue is essentially that the System inherits from MemObject, and
placing a system = Param.System(...) in MemObject creates a cycle.
params/System.hh ends up including MemObject.hh and vice versa. I have
tried a number of permutations of forward declarations etc using the
cxx_predecls vs swig_decls for the System/MemObject but not managed to
solve it so far. It is starting to look pretty nasty, but I will keep on
going and see if I can solve the circular dependency this creates in a
decent way.
The standard way of doing this is to break the cycle in C++. The
reason you have a cycle (I believe) is that System has the physmem
parameter and the memories parameter which are both PhysicalMemory
objects which are in turn MemObjects. So, to do this the standard
way, you'd put the system = Param.System stuff into MemObject and
remove the physmem and memories parameters from System. Then in C++
during the constructor of PhysicalMemory, you'd call
params()->system->registerPhysicalMemory (you'd have to write that
function). The only hangup I see is that physmem is only one of
potentially many PhysicalMemory Objects, so to make this work, you'd
probably have to add a boolean parameter to PhysicalMemory that's like
system_memory so that one object would get written back.
It may just be better to allow cycles and enforce a more rigorous
split between the constructors and init() (which I've wanted to do for
a long time), but that's a much more complicated fix. Something else
that would be possible and would make things easier for this sort of
thing would be to add support for traversing the object tree in C++.
It probably wouldn't be all that difficult.
Nate
_______________________________________________
gem5-dev mailing list
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
http://m5sim.org/mailman/listinfo/gem5-dev
Andreas Hansson
2012-01-05 16:04:17 UTC
Permalink
I like it! #5 I will definitely do as part of this.

Suggestions:
6. Make SysComponent a SysModule instead?
7. Keep MemObject in the hierarchy between SimObject and SysComponent/SysModule and let the System be a MemObject?
8. Assuming 7, alternatively rename the MemObject StructuralObject or StructObject to distinguish the fact that it is a "real" structural entity, compared to SimObjects like processes etc.

Andreas

-----Original Message-----
From: gem5-dev-bounces-1Gs4CP2/***@public.gmane.org [mailto:gem5-dev-bounces-1Gs4CP2/***@public.gmane.org] On Behalf Of Steve Reinhardt
Sent: 05 January 2012 15:53
To: gem5 Developer List
Cc: Ali Saidi
Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a central access point

I think we all agree that being able to traverse the hierarchy in C++ seems
reasonable is something we'll probably add eventually. I don't want to add
it for something that doesn't really need it though, because our general
rule has been to do as much in python as we reasonably can, and I'd rather
fix things on the python side to make this work there than to punt and
force it into C++.

As far as changing the object hierarchy: what about just taking all the
port support (what I was proposing be split off into the poorly named
PortObject) and push it up into SimObject? Then instead of having a
separate class for objects that have ports, we just say that every object
can have ports, but some have zero of them.

We'd still need MemObject to distingush objects that get a pointer back to
the System from those that don't. Though if that's the only distinction,
MemObject isn't the greatest name either; maybe it should be
SystemComponentObject or something like that (though that's too long IMO:
maybe SysObject, or SysComponent, or something like that). Then most
things would probably derive from SysComponent, and only things that
clearly aren't proper elements of a single system (like System itself, and
maybe EthernetLink, and maybe some of the fake SimObjects that aren't
really component models) would derive directly from SimObject.

So my proposal is:
1. Move MemObject methods into SimObject (getPort() etc.) and get rid of
MemObject entirely.
2. Replace MemObject with SimObject in mem/port.{cc,hh} and similar places
where it's just used to indicate a class that can have ports.
3. Create a new class SysComponent (I'm open to other names) that derives
from SimObject, and doesn't do anything but add a system =
Param.System(Parent.any) param.
4. Replace MemObject with SysComponent anywhere it's used as a base class.
5. (optional, but very desirable) Track down any non-MemObject derived
class that has its own Param.System(Parent.any) param, make it derive from
SysComponent too, and get rid of that explicit param.

Thoughts?

Steve
Post by Andreas Hansson
Steve, Nate,
Thanks for the feedback! I hope we can reach consensus on this soon.
To start with Nate's suggestion: It is not the members of System or
MemObject that cause the problem, this is already in place. The issue is
with the parameter header generation and SWIG wrapper generation. This
would happen also without the PhysicalMemory, since System inherits from
MemObject, and not a MemObject has a System pointer. Note that the latter
could be fixed in c++ by forward declaring System in MemObject.hh. This,
however, requires some serious modifications of the cxx_predecls,
swig_predecls etc.
A more general way of traversing the object hierarchy (I feel design
patterns coming on :-) would definitely solve the problem and the setParent
is really the not-so-general solution to this problem. Are there any other
obvious good uses of this hierarchy that have been implemented in other
(more inconvenient) ways?
Steve's suggestion: Very much seems doable, with an additional class in
the hierarchy. I also struggle with the naming, but I'll give it a quick
bash and see how it goes.
Andreas
-----Original Message-----
Behalf Of nathan binkert
Sent: 04 January 2012 21:53
To: gem5 Developer List
Cc: Ali Saidi
Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a central access point
Post by Andreas Hansson
The issue is essentially that the System inherits from MemObject, and
placing a system = Param.System(...) in MemObject creates a cycle.
params/System.hh ends up including MemObject.hh and vice versa. I have
tried a number of permutations of forward declarations etc using the
cxx_predecls vs swig_decls for the System/MemObject but not managed to
solve it so far. It is starting to look pretty nasty, but I will keep on
going and see if I can solve the circular dependency this creates in a
decent way.
The standard way of doing this is to break the cycle in C++. The
reason you have a cycle (I believe) is that System has the physmem
parameter and the memories parameter which are both PhysicalMemory
objects which are in turn MemObjects. So, to do this the standard
way, you'd put the system = Param.System stuff into MemObject and
remove the physmem and memories parameters from System. Then in C++
during the constructor of PhysicalMemory, you'd call
params()->system->registerPhysicalMemory (you'd have to write that
function). The only hangup I see is that physmem is only one of
potentially many PhysicalMemory Objects, so to make this work, you'd
probably have to add a boolean parameter to PhysicalMemory that's like
system_memory so that one object would get written back.
It may just be better to allow cycles and enforce a more rigorous
split between the constructors and init() (which I've wanted to do for
a long time), but that's a much more complicated fix. Something else
that would be possible and would make things easier for this sort of
thing would be to add support for traversing the object tree in C++.
It probably wouldn't be all that difficult.
Nate
_______________________________________________
gem5-dev mailing list
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
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
gem5-dev-1Gs4CP2/***@public.gmane.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.
Steve Reinhardt
2012-01-05 16:32:27 UTC
Permalink
Post by Andreas Hansson
I like it! #5 I will definitely do as part of this.
Great!
Post by Andreas Hansson
6. Make SysComponent a SysModule instead?
SysModule sounds OK; I like SysObject too (more parallel with SimObject and
MemObject) though it is slightly more ambiguous than SysModule. I'd hold
off on finalizing a name until we get another opinion or two.
Post by Andreas Hansson
7. Keep MemObject in the hierarchy between SimObject and
SysComponent/SysModule and let the System be a MemObject?
I guess great minds think alike, as they say...
Post by Andreas Hansson
8. Assuming 7, alternatively rename the MemObject StructuralObject or
StructObject to distinguish the fact that it is a "real" structural entity,
compared to SimObjects like processes etc.
If we're going to keep the class, I'd prefer to keep the same name... one
of the main reasons I'd lean toward keeping the class is to minimize the
changes to the existing hierarchy, and changing the name loses that benefit.

Steve
Post by Andreas Hansson
Andreas
-----Original Message-----
Behalf Of Steve Reinhardt
Sent: 05 January 2012 15:53
To: gem5 Developer List
Cc: Ali Saidi
Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a central access point
I think we all agree that being able to traverse the hierarchy in C++ seems
reasonable is something we'll probably add eventually. I don't want to add
it for something that doesn't really need it though, because our general
rule has been to do as much in python as we reasonably can, and I'd rather
fix things on the python side to make this work there than to punt and
force it into C++.
As far as changing the object hierarchy: what about just taking all the
port support (what I was proposing be split off into the poorly named
PortObject) and push it up into SimObject? Then instead of having a
separate class for objects that have ports, we just say that every object
can have ports, but some have zero of them.
We'd still need MemObject to distingush objects that get a pointer back to
the System from those that don't. Though if that's the only distinction,
MemObject isn't the greatest name either; maybe it should be
maybe SysObject, or SysComponent, or something like that). Then most
things would probably derive from SysComponent, and only things that
clearly aren't proper elements of a single system (like System itself, and
maybe EthernetLink, and maybe some of the fake SimObjects that aren't
really component models) would derive directly from SimObject.
1. Move MemObject methods into SimObject (getPort() etc.) and get rid of
MemObject entirely.
2. Replace MemObject with SimObject in mem/port.{cc,hh} and similar places
where it's just used to indicate a class that can have ports.
3. Create a new class SysComponent (I'm open to other names) that derives
from SimObject, and doesn't do anything but add a system =
Param.System(Parent.any) param.
4. Replace MemObject with SysComponent anywhere it's used as a base class.
5. (optional, but very desirable) Track down any non-MemObject derived
class that has its own Param.System(Parent.any) param, make it derive from
SysComponent too, and get rid of that explicit param.
Thoughts?
Steve
Post by Andreas Hansson
Steve, Nate,
Thanks for the feedback! I hope we can reach consensus on this soon.
To start with Nate's suggestion: It is not the members of System or
MemObject that cause the problem, this is already in place. The issue is
with the parameter header generation and SWIG wrapper generation. This
would happen also without the PhysicalMemory, since System inherits from
MemObject, and not a MemObject has a System pointer. Note that the latter
could be fixed in c++ by forward declaring System in MemObject.hh. This,
however, requires some serious modifications of the cxx_predecls,
swig_predecls etc.
A more general way of traversing the object hierarchy (I feel design
patterns coming on :-) would definitely solve the problem and the
setParent
Post by Andreas Hansson
is really the not-so-general solution to this problem. Are there any
other
Post by Andreas Hansson
obvious good uses of this hierarchy that have been implemented in other
(more inconvenient) ways?
Steve's suggestion: Very much seems doable, with an additional class in
the hierarchy. I also struggle with the naming, but I'll give it a quick
bash and see how it goes.
Andreas
-----Original Message-----
Behalf Of nathan binkert
Sent: 04 January 2012 21:53
To: gem5 Developer List
Cc: Ali Saidi
Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a
central access point
Post by Andreas Hansson
The issue is essentially that the System inherits from MemObject, and
placing a system = Param.System(...) in MemObject creates a cycle.
params/System.hh ends up including MemObject.hh and vice versa. I have
tried a number of permutations of forward declarations etc using the
cxx_predecls vs swig_decls for the System/MemObject but not managed to
solve it so far. It is starting to look pretty nasty, but I will keep on
going and see if I can solve the circular dependency this creates in a
decent way.
The standard way of doing this is to break the cycle in C++. The
reason you have a cycle (I believe) is that System has the physmem
parameter and the memories parameter which are both PhysicalMemory
objects which are in turn MemObjects. So, to do this the standard
way, you'd put the system = Param.System stuff into MemObject and
remove the physmem and memories parameters from System. Then in C++
during the constructor of PhysicalMemory, you'd call
params()->system->registerPhysicalMemory (you'd have to write that
function). The only hangup I see is that physmem is only one of
potentially many PhysicalMemory Objects, so to make this work, you'd
probably have to add a boolean parameter to PhysicalMemory that's like
system_memory so that one object would get written back.
It may just be better to allow cycles and enforce a more rigorous
split between the constructors and init() (which I've wanted to do for
a long time), but that's a much more complicated fix. Something else
that would be possible and would make things easier for this sort of
thing would be to add support for traversing the object tree in C++.
It probably wouldn't be all that difficult.
Nate
_______________________________________________
gem5-dev mailing list
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
Post by Andreas Hansson
information in any medium. Thank you.
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
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
http://m5sim.org/mailman/listinfo/gem5-dev
nathan binkert
2012-01-05 17:40:20 UTC
Permalink
Post by Steve Reinhardt
SysModule sounds OK; I like SysObject too (more parallel with SimObject and
MemObject) though it is slightly more ambiguous than SysModule.  I'd hold
off on finalizing a name until we get another opinion or two.
I'm not sure that Module is less ambiguous than object. (Especially
now that I write a lot of python code and a module refers to something
else :)
Post by Steve Reinhardt
If we're going to keep the class, I'd prefer to keep the same name... one
of the main reasons I'd lean toward keeping the class is to minimize the
changes to the existing hierarchy, and changing the name loses that benefit.
He who is the master of perl -pi -e 's/foo/bar/' ?!



To me, the object with both port and system should be MemObject (which
really minimizes the amount of code that has to change) and the thing
in-between should be something like SimObjectWithPort or PortedObject
or something like that. I do prefer that we not collapse this into
SimObject though. I'd really like SimObject to be stuff that is for
the simulator engine, not the simulator components. I know we're
failing already with the switchOut and takeOverFrom stuff (and
potentially the drain code depending on how you argue), but I'd rather
not make it worse.

Nate
Steve Reinhardt
2012-01-05 20:28:46 UTC
Permalink
Post by nathan binkert
Post by Steve Reinhardt
SysModule sounds OK; I like SysObject too (more parallel with SimObject
and
Post by Steve Reinhardt
MemObject) though it is slightly more ambiguous than SysModule. I'd hold
off on finalizing a name until we get another opinion or two.
I'm not sure that Module is less ambiguous than object. (Especially
now that I write a lot of python code and a module refers to something
else :)
Good point...
Post by nathan binkert
Post by Steve Reinhardt
If we're going to keep the class, I'd prefer to keep the same name... one
of the main reasons I'd lean toward keeping the class is to minimize the
changes to the existing hierarchy, and changing the name loses that
benefit.
He who is the master of perl -pi -e 's/foo/bar/' ?!
I wasn't arguing this because it's hard to make sweeping changes... more to
avoid confusing people ("What happened to my old friend MemObject?")...
though I suppose our users are less intimate with these things than I think.
Post by nathan binkert
To me, the object with both port and system should be MemObject (which
really minimizes the amount of code that has to change) and the thing
in-between should be something like SimObjectWithPort or PortedObject
or something like that.
You're right, that would avoid changing the base class in lots of places,
vs. avoiding changing the MemObject code itself (which is what I was
minimizing).

The challenge is that there are a number of objects that have a system
param but don't have ports (I see at least IntrControl, SimpleDisk, and all
the Platform derivatives (T1000, Tsunami, etc.)), and if we leverage this
new base class to factor that out, then we have a lot of things deriving
from MemObject that aren't really memory objects.

If we were real OO purists, we'd have SysObject and PortedObject both
derive directly from SimObject, and MemObject would derive from both of
them. However, though I'm probably not quite as dead set against MI as I
used to be, I'm not going to push over that easily.

So I think we're agreed on the hierarchy, and are down to three general
naming conventions:

1. SimObject > PortedObject > SysObject
2. SimObject > PortedObject > MemObject
3. SimObject > MemObject > SysObject

with minor variants where we substitute other new names for PortedObject or
SysObject (though those are my current favorites).

#2 keeps existing children of MemObject as MemObject, but changes what
MemObject is.
#3 keeps the MemObject class itself unchanged, but requires reparenting
current MemObjects to SysObject.

In any case, objects that want to enjoy the inherited System param but
don't need ports get stuck inheriting the port code anyway. I don't have a
problem with this. In case #2, those objects also end up being derived
from MemObject, which seems odd since they're not in the memory system.
Case #3 has a similar problem in that SysObject derives from MemObject
even though not all SysObjects are in the memory system; somehow that's
less objectionable to me because it only happens once.

So maybe after all this I've talked myself into option #1...

A fourth approach that comes to mind is to go with #2 above, but *not* have
other non-memory objects that want a System parameter derive from
MemObject. Instead, as a separate task, we could add a SysObject that
derives directly from SimObject but has the System param, and the objects
that need the param but not ports could derive from that. It's not elegant
(I think I still prefer #1) but I could live with this.

Sorry for the length here... mostly just thinking through this myself as I
type.

Steve
Gabe Black
2012-01-06 09:30:25 UTC
Permalink
Post by Steve Reinhardt
Post by nathan binkert
Post by Steve Reinhardt
SysModule sounds OK; I like SysObject too (more parallel with SimObject
and
Post by Steve Reinhardt
MemObject) though it is slightly more ambiguous than SysModule. I'd hold
off on finalizing a name until we get another opinion or two.
I'm not sure that Module is less ambiguous than object. (Especially
now that I write a lot of python code and a module refers to something
else :)
Good point...
Post by nathan binkert
Post by Steve Reinhardt
If we're going to keep the class, I'd prefer to keep the same name... one
of the main reasons I'd lean toward keeping the class is to minimize the
changes to the existing hierarchy, and changing the name loses that
benefit.
He who is the master of perl -pi -e 's/foo/bar/' ?!
I wasn't arguing this because it's hard to make sweeping changes... more to
avoid confusing people ("What happened to my old friend MemObject?")...
though I suppose our users are less intimate with these things than I think.
Post by nathan binkert
To me, the object with both port and system should be MemObject (which
really minimizes the amount of code that has to change) and the thing
in-between should be something like SimObjectWithPort or PortedObject
or something like that.
You're right, that would avoid changing the base class in lots of places,
vs. avoiding changing the MemObject code itself (which is what I was
minimizing).
The challenge is that there are a number of objects that have a system
param but don't have ports (I see at least IntrControl, SimpleDisk, and all
the Platform derivatives (T1000, Tsunami, etc.)), and if we leverage this
new base class to factor that out, then we have a lot of things deriving
from MemObject that aren't really memory objects.
If we were real OO purists, we'd have SysObject and PortedObject both
derive directly from SimObject, and MemObject would derive from both of
them. However, though I'm probably not quite as dead set against MI as I
used to be, I'm not going to push over that easily.
So I think we're agreed on the hierarchy, and are down to three general
1. SimObject > PortedObject > SysObject
2. SimObject > PortedObject > MemObject
3. SimObject > MemObject > SysObject
with minor variants where we substitute other new names for PortedObject or
SysObject (though those are my current favorites).
#2 keeps existing children of MemObject as MemObject, but changes what
MemObject is.
#3 keeps the MemObject class itself unchanged, but requires reparenting
current MemObjects to SysObject.
In any case, objects that want to enjoy the inherited System param but
don't need ports get stuck inheriting the port code anyway. I don't have a
problem with this. In case #2, those objects also end up being derived
from MemObject, which seems odd since they're not in the memory system.
Case #3 has a similar problem in that SysObject derives from MemObject
even though not all SysObjects are in the memory system; somehow that's
less objectionable to me because it only happens once.
So maybe after all this I've talked myself into option #1...
A fourth approach that comes to mind is to go with #2 above, but *not* have
other non-memory objects that want a System parameter derive from
MemObject. Instead, as a separate task, we could add a SysObject that
derives directly from SimObject but has the System param, and the objects
that need the param but not ports could derive from that. It's not elegant
(I think I still prefer #1) but I could live with this.
Sorry for the length here... mostly just thinking through this myself as I
type.
Steve
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
I think there weren't very many places where the system pointer was
actually used, so making a whole class to avoid adding system parameters
where necessary seems like overkill. There may be more instances than
I'm thinking, but maybe they all already share a common ancestor like
the Platform class. Is it so they can check the memory system mode? Do
we really need that to be attached to the system object since it's
really global across the simulation?

Gabe
Steve Reinhardt
2012-01-06 13:27:04 UTC
Permalink
Post by Ali Saidi
Post by Steve Reinhardt
So I think we're agreed on the hierarchy, and are down to three general
1. SimObject > PortedObject > SysObject
2. SimObject > PortedObject > MemObject
3. SimObject > MemObject > SysObject
with minor variants where we substitute other new names for PortedObject
or
Post by Steve Reinhardt
SysObject (though those are my current favorites).
#2 keeps existing children of MemObject as MemObject, but changes what
MemObject is.
#3 keeps the MemObject class itself unchanged, but requires reparenting
current MemObjects to SysObject.
In any case, objects that want to enjoy the inherited System param but
don't need ports get stuck inheriting the port code anyway. I don't
have a
Post by Steve Reinhardt
problem with this. In case #2, those objects also end up being derived
from MemObject, which seems odd since they're not in the memory system.
Case #3 has a similar problem in that SysObject derives from MemObject
even though not all SysObjects are in the memory system; somehow that's
less objectionable to me because it only happens once.
So maybe after all this I've talked myself into option #1...
A fourth approach that comes to mind is to go with #2 above, but *not*
have
Post by Steve Reinhardt
other non-memory objects that want a System parameter derive from
MemObject. Instead, as a separate task, we could add a SysObject that
derives directly from SimObject but has the System param, and the objects
that need the param but not ports could derive from that. It's not
elegant
Post by Steve Reinhardt
(I think I still prefer #1) but I could live with this.
Sorry for the length here... mostly just thinking through this myself as
I
Post by Steve Reinhardt
type.
Steve
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
I think there weren't very many places where the system pointer was
actually used, so making a whole class to avoid adding system parameters
where necessary seems like overkill.
Sounds like an argument for my option #4 (which is really a variant of #2).
I'm OK with that.
Post by Ali Saidi
There may be more instances than
I'm thinking, but maybe they all already share a common ancestor like
the Platform class.
As I said above, there's IntrControl and SimpleDisk that have system params
and aren't derived from Platform. The only other case I can find is
Process, which is sort of interesting in that it's not really a "system
component" in the hardware sense.

Certainly if we go with option #4 then a small improvement would be to put
factor the system param out from all the Platform-derived objects into
Platform itself.
Post by Ali Saidi
Is it so they can check the memory system mode? Do
we really need that to be attached to the system object since it's
really global across the simulation?
Memory mode is not global across the simulation. In a multi-system
simulation it's perfectly OK to have one system in timing mode and the
other in atomic.

Steve
Andreas Hansson
2012-01-06 13:30:10 UTC
Permalink
I am actually in the process of seeing it the systemPort introduction can be done relying entirely on the existing system parameter in Process etc, and I think it might just work. In other words, the only objects that need to get a pointer to the port has the system as a parameter. I'll get back to you with an outcome within an hour or two.

Andreas

-----Original Message-----
From: gem5-dev-bounces-1Gs4CP2/***@public.gmane.org [mailto:gem5-dev-bounces-1Gs4CP2/***@public.gmane.org] On Behalf Of Steve Reinhardt
Sent: 06 January 2012 13:27
To: gem5 Developer List
Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a central access point
Post by Ali Saidi
Post by Steve Reinhardt
So I think we're agreed on the hierarchy, and are down to three general
1. SimObject > PortedObject > SysObject
2. SimObject > PortedObject > MemObject
3. SimObject > MemObject > SysObject
with minor variants where we substitute other new names for PortedObject
or
Post by Steve Reinhardt
SysObject (though those are my current favorites).
#2 keeps existing children of MemObject as MemObject, but changes what
MemObject is.
#3 keeps the MemObject class itself unchanged, but requires reparenting
current MemObjects to SysObject.
In any case, objects that want to enjoy the inherited System param but
don't need ports get stuck inheriting the port code anyway. I don't
have a
Post by Steve Reinhardt
problem with this. In case #2, those objects also end up being derived
from MemObject, which seems odd since they're not in the memory system.
Case #3 has a similar problem in that SysObject derives from MemObject
even though not all SysObjects are in the memory system; somehow that's
less objectionable to me because it only happens once.
So maybe after all this I've talked myself into option #1...
A fourth approach that comes to mind is to go with #2 above, but *not*
have
Post by Steve Reinhardt
other non-memory objects that want a System parameter derive from
MemObject. Instead, as a separate task, we could add a SysObject that
derives directly from SimObject but has the System param, and the objects
that need the param but not ports could derive from that. It's not
elegant
Post by Steve Reinhardt
(I think I still prefer #1) but I could live with this.
Sorry for the length here... mostly just thinking through this myself as
I
Post by Steve Reinhardt
type.
Steve
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
I think there weren't very many places where the system pointer was
actually used, so making a whole class to avoid adding system parameters
where necessary seems like overkill.
Sounds like an argument for my option #4 (which is really a variant of #2).
I'm OK with that.
Post by Ali Saidi
There may be more instances than
I'm thinking, but maybe they all already share a common ancestor like
the Platform class.
As I said above, there's IntrControl and SimpleDisk that have system params
and aren't derived from Platform. The only other case I can find is
Process, which is sort of interesting in that it's not really a "system
component" in the hardware sense.

Certainly if we go with option #4 then a small improvement would be to put
factor the system param out from all the Platform-derived objects into
Platform itself.
Post by Ali Saidi
Is it so they can check the memory system mode? Do
we really need that to be attached to the system object since it's
really global across the simulation?
Memory mode is not global across the simulation. In a multi-system
simulation it's perfectly OK to have one system in timing mode and the
other in atomic.

Steve
_______________________________________________
gem5-dev mailing list
gem5-dev-1Gs4CP2/***@public.gmane.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.
Andreas Hansson
2012-01-06 14:10:48 UTC
Permalink
...and as you will see in the latest edition of the patch (http://reviews.m5sim.org/r/942/) it is now reduced to adding the port in the System along with a "getter".

Thanks for all the input, I'm glad we could strip it down to what was really needed.

Andreas

-----Original Message-----
From: gem5-dev-bounces-1Gs4CP2/***@public.gmane.org [mailto:gem5-dev-bounces-1Gs4CP2/***@public.gmane.org] On Behalf Of Andreas Hansson
Sent: 06 January 2012 13:30
To: gem5 Developer List
Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a central access point

I am actually in the process of seeing it the systemPort introduction can be done relying entirely on the existing system parameter in Process etc, and I think it might just work. In other words, the only objects that need to get a pointer to the port has the system as a parameter. I'll get back to you with an outcome within an hour or two.

Andreas

-----Original Message-----
From: gem5-dev-bounces-1Gs4CP2/***@public.gmane.org [mailto:gem5-dev-bounces-1Gs4CP2/***@public.gmane.org] On Behalf Of Steve Reinhardt
Sent: 06 January 2012 13:27
To: gem5 Developer List
Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a central access point
Post by Ali Saidi
Post by Steve Reinhardt
So I think we're agreed on the hierarchy, and are down to three general
1. SimObject > PortedObject > SysObject
2. SimObject > PortedObject > MemObject
3. SimObject > MemObject > SysObject
with minor variants where we substitute other new names for PortedObject
or
Post by Steve Reinhardt
SysObject (though those are my current favorites).
#2 keeps existing children of MemObject as MemObject, but changes what
MemObject is.
#3 keeps the MemObject class itself unchanged, but requires reparenting
current MemObjects to SysObject.
In any case, objects that want to enjoy the inherited System param but
don't need ports get stuck inheriting the port code anyway. I don't
have a
Post by Steve Reinhardt
problem with this. In case #2, those objects also end up being derived
from MemObject, which seems odd since they're not in the memory system.
Case #3 has a similar problem in that SysObject derives from MemObject
even though not all SysObjects are in the memory system; somehow that's
less objectionable to me because it only happens once.
So maybe after all this I've talked myself into option #1...
A fourth approach that comes to mind is to go with #2 above, but *not*
have
Post by Steve Reinhardt
other non-memory objects that want a System parameter derive from
MemObject. Instead, as a separate task, we could add a SysObject that
derives directly from SimObject but has the System param, and the objects
that need the param but not ports could derive from that. It's not
elegant
Post by Steve Reinhardt
(I think I still prefer #1) but I could live with this.
Sorry for the length here... mostly just thinking through this myself as
I
Post by Steve Reinhardt
type.
Steve
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
I think there weren't very many places where the system pointer was
actually used, so making a whole class to avoid adding system parameters
where necessary seems like overkill.
Sounds like an argument for my option #4 (which is really a variant of #2).
I'm OK with that.
Post by Ali Saidi
There may be more instances than
I'm thinking, but maybe they all already share a common ancestor like
the Platform class.
As I said above, there's IntrControl and SimpleDisk that have system params
and aren't derived from Platform. The only other case I can find is
Process, which is sort of interesting in that it's not really a "system
component" in the hardware sense.

Certainly if we go with option #4 then a small improvement would be to put
factor the system param out from all the Platform-derived objects into
Platform itself.
Post by Ali Saidi
Is it so they can check the memory system mode? Do
we really need that to be attached to the system object since it's
really global across the simulation?
Memory mode is not global across the simulation. In a multi-system
simulation it's perfectly OK to have one system in timing mode and the
other in atomic.

Steve
_______________________________________________
gem5-dev mailing list
gem5-dev-1Gs4CP2/***@public.gmane.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-1Gs4CP2/***@public.gmane.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.
Steve Reinhardt
2012-01-05 16:05:58 UTC
Permalink
Post by Steve Reinhardt
1. Move MemObject methods into SimObject (getPort() etc.) and get rid of
MemObject entirely.
2. Replace MemObject with SimObject in mem/port.{cc,hh} and similar places
where it's just used to indicate a class that can have ports.
3. Create a new class SysComponent (I'm open to other names) that derives
from SimObject, and doesn't do anything but add a system =
Param.System(Parent.any) param.
4. Replace MemObject with SysComponent anywhere it's used as a base class.
5. (optional, but very desirable) Track down any non-MemObject derived
class that has its own Param.System(Parent.any) param, make it derive from
SysComponent too, and get rid of that explicit param.
Alternatively, we could keep MemObject to keep the distinction between
objects with and without ports, and have the hierarchy look like this:

SimObject
v
MemObject (adds the ability to have ports)
v
SysComponent (adds default system param)

Then System would probably be the only thing that derives directly from
MemObject and not SysComponent.

I'm not sure this is worth the mental complexity of maintaining three
classes where two would probably do, but it's a smaller change in the sense
that MemObject doesn't go away. I'm somewhat ambivalent between these two.

Steve
nathan binkert
2012-01-05 17:42:48 UTC
Permalink
Post by Andreas Hansson
To start with Nate's suggestion: It is not the members of System or MemObject that cause the problem, this is already in place. The issue is with the parameter header generation and SWIG wrapper generation. This would happen also without the PhysicalMemory, since System inherits from MemObject, and not a MemObject has a System pointer. Note that the latter could be fixed in c++ by forward declaring System in MemObject.hh. This, however, requires some serious modifications of the cxx_predecls, swig_predecls etc.
Ah, I forgot that the system was to become a MemObject. Makes sense
that you don't want the system to point to itself, no? (Though
perhaps for consistency, it should.

Gabe ran into this a while ago. I should really try to fix it.
Unfortunately, it is non-trivial, but I do understand the problem a
lot better now than when I first found out about gabe's problem. I'll
try to make it work, though it won't be today.

Nate
Andreas Hansson
2012-01-06 14:07:29 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/942/
-----------------------------------------------------------

(Updated 2012-01-06 06:07:29.891326)


Review request for Default.


Summary
-------

MEM: Add the system port as a central access point

The system port is used as a globally reachable access point to the
memory subsystem. The benefit of using an actual port is that the
usual infrastructure is used to resolve any access and thus makes the
overall system able to handle distributed memories in any
configuration, and also makes the accesses agnostic to the address
map. This patch only introduces the port and does not actually use it
for anything.


Diffs (updated)
-----

src/sim/System.py 58885e2e8a88
src/sim/system.hh 58885e2e8a88
src/sim/system.cc 58885e2e8a88

Diff: http://reviews.m5sim.org/r/942/diff


Testing
-------

util/regress all passing (disregarding t1000 and eio)


Thanks,

Andreas
Andreas Hansson
2012-01-06 14:16:04 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/942/
-----------------------------------------------------------

(Updated 2012-01-06 06:16:04.184990)


Review request for Default.


Summary
-------

MEM: Add the system port as a central access point

The system port is used as a globally reachable access point to the
memory subsystem. The benefit of using an actual port is that the
usual infrastructure is used to resolve any access and thus makes the
overall system able to handle distributed memories in any
configuration, and also makes the accesses agnostic to the address
map. This patch only introduces the port and does not actually use it
for anything.


Diffs (updated)
-----

src/sim/System.py 58885e2e8a88
src/sim/system.hh 58885e2e8a88
src/sim/system.cc 58885e2e8a88

Diff: http://reviews.m5sim.org/r/942/diff


Testing
-------

util/regress all passing (disregarding t1000 and eio)


Thanks,

Andreas
Ali Saidi
2012-01-10 17:18:08 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/942/#review1881
-----------------------------------------------------------

Ship it!


great!

- Ali
Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.m5sim.org/r/942/
-----------------------------------------------------------
(Updated 2012-01-06 06:16:04)
Review request for Default.
Summary
-------
MEM: Add the system port as a central access point
The system port is used as a globally reachable access point to the
memory subsystem. The benefit of using an actual port is that the
usual infrastructure is used to resolve any access and thus makes the
overall system able to handle distributed memories in any
configuration, and also makes the accesses agnostic to the address
map. This patch only introduces the port and does not actually use it
for anything.
Diffs
-----
src/sim/System.py 58885e2e8a88
src/sim/system.hh 58885e2e8a88
src/sim/system.cc 58885e2e8a88
Diff: http://reviews.m5sim.org/r/942/diff
Testing
-------
util/regress all passing (disregarding t1000 and eio)
Thanks,
Andreas
Steve Reinhardt
2012-01-11 06:37:04 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/942/#review1891
-----------------------------------------------------------



src/sim/system.hh
<http://reviews.m5sim.org/r/942/#comment2402>

Do we need a special function for this, as opposed to other objects just calling getPort("system_port")?



- Steve
Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.m5sim.org/r/942/
-----------------------------------------------------------
(Updated 2012-01-06 06:16:04)
Review request for Default.
Summary
-------
MEM: Add the system port as a central access point
The system port is used as a globally reachable access point to the
memory subsystem. The benefit of using an actual port is that the
usual infrastructure is used to resolve any access and thus makes the
overall system able to handle distributed memories in any
configuration, and also makes the accesses agnostic to the address
map. This patch only introduces the port and does not actually use it
for anything.
Diffs
-----
src/sim/System.py 58885e2e8a88
src/sim/system.hh 58885e2e8a88
src/sim/system.cc 58885e2e8a88
Diff: http://reviews.m5sim.org/r/942/diff
Testing
-------
util/regress all passing (disregarding t1000 and eio)
Thanks,
Andreas
Andreas Hansson
2012-01-11 10:05:44 UTC
Permalink
Post by Andreas Hansson
src/sim/system.hh, line 110
<http://reviews.m5sim.org/r/942/diff/3/?file=17377#file17377line110>
Do we need a special function for this, as opposed to other objects just calling getPort("system_port")?
I want to get away from using getPort(const std::string&) in the C++ code all together as the "magic" names like system_port, icache_port, dcache_port etc refer to persistent and very specific ports that the objects would not be complete without. Thus, for the few objects where we get pointers to ports in the C++ code I eventually want to end up with similar functions like getDataPort() and getInstPort() on a CPU. If a port name changes that is then limited to the Python "assembly" scripts and the mapping of those names to port pointers when connecting them up.


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/942/#review1891
-----------------------------------------------------------
Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.m5sim.org/r/942/
-----------------------------------------------------------
(Updated 2012-01-06 06:16:04)
Review request for Default.
Summary
-------
MEM: Add the system port as a central access point
The system port is used as a globally reachable access point to the
memory subsystem. The benefit of using an actual port is that the
usual infrastructure is used to resolve any access and thus makes the
overall system able to handle distributed memories in any
configuration, and also makes the accesses agnostic to the address
map. This patch only introduces the port and does not actually use it
for anything.
Diffs
-----
src/sim/System.py 58885e2e8a88
src/sim/system.hh 58885e2e8a88
src/sim/system.cc 58885e2e8a88
Diff: http://reviews.m5sim.org/r/942/diff
Testing
-------
util/regress all passing (disregarding t1000 and eio)
Thanks,
Andreas
Steve Reinhardt
2012-01-11 17:39:28 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/942/#review1901
-----------------------------------------------------------

Ship it!


Good answer...

- Steve
Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.m5sim.org/r/942/
-----------------------------------------------------------
(Updated 2012-01-06 06:16:04)
Review request for Default.
Summary
-------
MEM: Add the system port as a central access point
The system port is used as a globally reachable access point to the
memory subsystem. The benefit of using an actual port is that the
usual infrastructure is used to resolve any access and thus makes the
overall system able to handle distributed memories in any
configuration, and also makes the accesses agnostic to the address
map. This patch only introduces the port and does not actually use it
for anything.
Diffs
-----
src/sim/System.py 58885e2e8a88
src/sim/system.hh 58885e2e8a88
src/sim/system.cc 58885e2e8a88
Diff: http://reviews.m5sim.org/r/942/diff
Testing
-------
util/regress all passing (disregarding t1000 and eio)
Thanks,
Andreas
Continue reading on narkive:
Loading...