On Tue, 23 Jun 2015, Beckmann, Brad wrote:
Nilay,
Please be more professional when responding to questions. If you have a
particular idea on how to fix the problem, we would appreciate if you
described it rather than leaving us a trail of breadcrumbs.
First, this is the second time you have used the word "professional" in past
month or so. I don't know what it means to be a professional. You should
enlighten me.
Over years, I have developed a sense of what is right and what is wrong and how
I should behave. It is my personal preference that people learn things rather
than things be told to them. I feel good whenever I learn something or I am
able to make others learn. I think, but I am not sure, the method I use to
impart my knowledge to others is what is known as the Socratic way of learning
/ teaching. You may not like it, but I find it good enough.
Please note that your patch, 10311, is the one that breaks the tenet that
ClockedObjects, which include ports, are MemObjects. It is unfortunate that
our regression tester does not test config.ini loading with ruby and did not
realize that the SimpleNetwork is different than all other ClockedObjects.
However, I do not believe revision 10458 is at fault here. Rather it is
SimpleNetwork's unconventional use of ports.
I am guessing patches time travel in your world. Revision 10458 added the
ability to load config file in C++. Surely 10311 was committed before it. How
can 10311 break something that did not exist when it was committed?
I don't know about the tenet. Reading the code it seems, MemObject ==> Clocked
Object + Ports. What you are suggesting is Clocked Object + Ports
==> MemObject. Those two statements are not equivalent.
I agree that Ruby uses ports in an unconventional fashion. But that's because
Ruby uses MessageBuffers and not ports in C++. Ports are only used in the
python code. Had Ruby been using ports in C++ as well, I think it would have
used them in the same fashion as the classic memory system.
We appreciate your help on this matter. Important work is currently blocked
on this bug.
I am surprised people at AMD failed to realize the functions I pointed to in
the previous mail are essentially doing the same thing. If you add the
following code from the pyobject.cc to the beginning of
cxx_manager.cc:bindPort(), I feel things should work for you. Ofcourse, I have
not tested anything.
// These could be objects from the ruby memory system. If yes, then at
// least one of them should be an abstract controller. Do a type check.
AbstractController *ac1, *ac2;
ac1 = dynamic_cast<AbstractController*>(o1);
ac2 = dynamic_cast<AbstractController*>(o2);
if ((ac1 || ac2) && name1 != "memory" && name2 != "memory") {
MessageBuffer *b = new MessageBuffer();
// set the message buffer associated with the provided names
if (ac1) {
ac1->setNetQueue(name1, b);
}
if (ac2) {
ac2->setNetQueue(name2, b);
}
return;
}
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
