> On Aug. 17, 2015, 9:37 p.m., Jieming Yin wrote: > > src/mem/ruby/common/NetDest.cc, line 113 > > <http://reviews.gem5.org/r/3014/diff/1/?file=48812#file48812line113> > > > > m_bits[i].getSize() returns NUMBER_BITS_PER_SET, which is 64 for all > > machine types. In case of broadcast, all bits are set in m_bits. Will it > > cause problem if the number of actual components is smaller than > > NUMBER_BITS_PER_SET? Perhapse in class Set, add a size parameter is a > > better idea to prevent such situation. > > Nilay Vaish wrote: > I have added back the m_nSize variable. > > Tony Gutierrez wrote: > Maybe I'm missing something here, but why is m_nSize necessary for > broadcast? It seemed to me that broadcast() only looks to see if all bits for > the set are set, and doesn't determine how many to components to broadcast > to. So it seems fine to me to have the logic of broadcast() be such that it > will be considered a broadcast if all bits are set, and not a broadcast > otherwise, the fact that there are extra bits set doesn't seem to matter.
On Thu, 3 Sep 2015, Tony Gutierrez wrote: > > Maybe I'm missing something here, but why is m_nSize necessary for > broadcast? It seemed to me that broadcast() only looks to see if all Because of the way broadcast is implemented by the on-chip network. > bits for the set are set, and doesn't determine how many to components > to broadcast to. So it seems fine to me to have the logic of broadcast() > be such that it will be considered a broadcast if all bits are set, and > not a broadcast otherwise, the fact that there are extra bits set > doesn't seem to matter. The on-chip will try to send the broadcast message to controllers corresponding to bits that are set. Hence, if there is no size variable to determine the maximum number of bits in use, then messages will be sent to non-existent controllers. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3014/#review6991 ----------------------------------------------------------- On Aug. 31, 2015, 2:58 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3014/ > ----------------------------------------------------------- > > (Updated Aug. 31, 2015, 2:58 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11077:0dfa7e7d62d0 > --------------------------- > ruby: set: reimplement using std::bitset > The current Set data structure is slow and therefore is being reimplemented > using std::bitset. A maximum limit of 64 is being set on the number of > controllers of each type. This means that for simulating a system with more > controllers of a given type, one would need to change the value of the > variable > NUMBER_BITS_PER_SET > > > Diffs > ----- > > src/mem/ruby/common/Set.hh 969113566d50 > src/mem/ruby/common/Set.cc 969113566d50 > src/mem/ruby/common/NetDest.hh 969113566d50 > src/mem/ruby/common/SConscript 969113566d50 > > Diff: http://reviews.gem5.org/r/3014/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
