No problem. It is a bit ambiguous, but my interpretation is that if you're doing work that we'll be distributing with M5 to other people, that goes on m5-dev. If you're doing development work but it's for your own projects that goes on m5-users. I don't think we have an actual official policy, but that's probably a good rule of thumb.
Gabe Javier Jose wrote: > Nate: Thanks that was the problem. > > Gabe: Cool, from now on I will post everything in m5-users. I posted > here since it was concerning my on going development. It was a little > confusing where to past what. > > Thanks both again, > Javier > > > On Wed, Apr 22, 2009 at 11:57 PM, <[email protected] > <mailto:[email protected]>> wrote: > > Send m5-dev mailing list submissions to > [email protected] <mailto:[email protected]> > > To subscribe or unsubscribe via the World Wide Web, visit > http://m5sim.org/mailman/listinfo/m5-dev > or, via email, send a message with subject or body 'help' to > [email protected] <mailto:[email protected]> > > You can reach the person managing the list at > [email protected] <mailto:[email protected]> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of m5-dev digest..." > > > Today's Topics: > > 1. Histograms and Distributions (nathan binkert) > 2. Stats changes (nathan binkert) > 3. Adding New Param error (Javier Jose) > 4. Re: Adding New Param error (Gabriel Michael Black) > 5. Re: Adding New Param error (nathan binkert) > 6. Re: [PATCH 03 of 10] Expose memory access size and flags > through instruction object (Korey Sewell) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 Apr 2009 13:45:23 -0700 > From: nathan binkert <[email protected] <mailto:[email protected]>> > Subject: [m5-dev] Histograms and Distributions > To: M5 Developer List <[email protected] <mailto:[email protected]>> > Message-ID: > > <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Everyone, > > I have a question about statistics for you all. > > Daniel pointed out that GEMS has a Historgram statistics type similar > to M5's Distribution with one difference. M5's distribution (which > was modeled on simplescalar) has a fixed number of buckets which are > fixed in size at initialization time. Additionally, it has an > overflow and underflow bucket to capture samples that are out of the > distribution's range. The GEMS Histogram has a fixed number of > variable sized buckets. Initially, each bucket would be very small, > and if you get a new sample that doesn't have a bucket to go into, you > double the size of the buckets (and shift the values around) until > there is a bucket which can accept the sample. > > I've implemented the Histogram statistic type because it will be > useful for Ruby integration and seems like a useful concept. My > question is, does the Distribution make sense if we have the > Histogram? Should I move all Distributions to Histograms and drop > Distribution? I can keep both, but I'm inclined to believe that this > Histogram is superior in most cases. > > Does anyone have any opinion? > > Nate > > > ------------------------------ > > Message: 2 > Date: Wed, 22 Apr 2009 13:53:27 -0700 > From: nathan binkert <[email protected] <mailto:[email protected]>> > Subject: [m5-dev] Stats changes > To: M5 Developer List <[email protected] <mailto:[email protected]>> > Message-ID: > > <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Everyone, > > I wanted to let everyone know that the format of the statistics file > has changed with a recent commit that I made. Up until today, M5 had > an option to print statistics in a simplescalar compatible output > format. The default was usually to use this compatibility mode, but > due to an initialization bug, sometimes this wouldn't happen. There > were even examples of committed tests where some of the tests were in > one mode and some were in another. The combination of this bug, the > fact that the compatibility mode isn't that important, and the fact > that it just made the code more complicated, I've removed the > compatibility mode. All statistics outputs should be consistent now. > > As a side benefit, I believe that people will find that the new text > format is much easier to parse now. One notable change was that > "<err: div-0>" and "no value" are both now "no_value". This makes the > new format easily parsed using white space to separate into three > colums: stat name, value, and an option comment/description. > > Nate > > > ------------------------------ > > Message: 3 > Date: Wed, 22 Apr 2009 22:30:55 -0400 > From: Javier Jose <[email protected] > <mailto:[email protected]>> > Subject: [m5-dev] Adding New Param error > To: [email protected] <mailto:[email protected]> > Message-ID: > > <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Everyone, > > As part of the Adaptive Dyanmic ROB implementation I am trying to > add 2 new > parameters to be accessed on cpu.cc > > I added the parameters in build/ALPHA_SE/params/DerivO3CPU.hh > I also modified src/cpu/o3/O3CPU.py to add the parameters > > In conifgs/example/se.py I added this code > > CPUClass.robEvalPeriod = Param.Unsigned(152000, "ROB Eval Period") > CPUClass.allocations_per_thread = Param.Unsigned(4, "Allocations > per thread > ROB partition") > > The variables are declared in src/cpu/o3/cpu.hh as unsigned int > > However When i run the se.py script I get the following error: > > Traceback (most recent call last): > File "<string>", line 1, in <module> > File "/home/javier/m5/src/python/m5/main.py", line 359, in main > exec filecode in scope > File "/home/javier/m5/configs/example/se.py", line 142, in <module> > CPUClass.robEvalPeriod = Param.Unsigned(152000, "ROB Eval Period") > File "/home/javier/m5/src/python/m5/SimObject.py", line 325, in > __setattr__ > cls._set_param(attr, value, param) > File "/home/javier/m5/src/python/m5/SimObject.py", line 274, in > _set_param > cls._values[name] = param.convert(value) > File "/home/javier/m5/src/python/m5/params.py", line 152, in convert > return self.ptype(value) > File "/home/javier/m5/src/python/m5/params.py", line 358, in __init__ > % type(value).__name__ > TypeError: Can't convert object of type ParamDesc to CheckedInt > Error setting param TmpClass.robEvalPeriod to <m5.params.ParamDesc > object at > 0xb770614c> > > I also tried: > > CPUClass.robEvalPeriod = Param.Int(152000, "ROB Eval Period") > CPUClass.allocations_per_thread = Param.Int(4, "Allocations per > thread ROB > partition") > > But, got the same errors. > > I appreciate the help. > Javier Malave > Texas A&M University > Computer Science & Engineering Department > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > http://m5sim.org/mailman/private/m5-dev/attachments/20090422/3c7edd41/attachment-0001.htm > > ------------------------------ > > Message: 4 > Date: Wed, 22 Apr 2009 22:49:19 -0400 > From: Gabriel Michael Black <[email protected] > <mailto:[email protected]>> > Subject: Re: [m5-dev] Adding New Param error > To: M5 Developer List <[email protected] <mailto:[email protected]>> > Message-ID: <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; > format="flowed" > > This sort of question should go to the m5-users mailing list. The > information on > http://m5sim.org/wiki/index.php/Simulation_Scripts_Explained might > help you. You should never need to modify files in build since those > are all either simlinked to files in other places or are generated by > the build process. build/ALPHA_SE/params/DerivO3CPU.hh is a generated > file. > > Gabe > > Quoting Javier Jose <[email protected] > <mailto:[email protected]>>: > > > Hi Everyone, > > > > As part of the Adaptive Dyanmic ROB implementation I am trying > to add 2 new > > parameters to be accessed on cpu.cc > > > > I added the parameters in build/ALPHA_SE/params/DerivO3CPU.hh > > I also modified src/cpu/o3/O3CPU.py to add the parameters > > > > In conifgs/example/se.py I added this code > > > > CPUClass.robEvalPeriod = Param.Unsigned(152000, "ROB Eval Period") > > CPUClass.allocations_per_thread = Param.Unsigned(4, "Allocations > per thread > > ROB partition") > > > > The variables are declared in src/cpu/o3/cpu.hh as unsigned int > > > > However When i run the se.py script I get the following error: > > > > Traceback (most recent call last): > > File "<string>", line 1, in <module> > > File "/home/javier/m5/src/python/m5/main.py", line 359, in main > > exec filecode in scope > > File "/home/javier/m5/configs/example/se.py", line 142, in > <module> > > CPUClass.robEvalPeriod = Param.Unsigned(152000, "ROB Eval > Period") > > File "/home/javier/m5/src/python/m5/SimObject.py", line 325, in > > __setattr__ > > cls._set_param(attr, value, param) > > File "/home/javier/m5/src/python/m5/SimObject.py", line 274, > in _set_param > > cls._values[name] = param.convert(value) > > File "/home/javier/m5/src/python/m5/params.py", line 152, in > convert > > return self.ptype(value) > > File "/home/javier/m5/src/python/m5/params.py", line 358, in > __init__ > > % type(value).__name__ > > TypeError: Can't convert object of type ParamDesc to CheckedInt > > Error setting param TmpClass.robEvalPeriod to > <m5.params.ParamDesc object at > > 0xb770614c> > > > > I also tried: > > > > CPUClass.robEvalPeriod = Param.Int(152000, "ROB Eval Period") > > CPUClass.allocations_per_thread = Param.Int(4, "Allocations per > thread ROB > > partition") > > > > But, got the same errors. > > > > I appreciate the help. > > Javier Malave > > Texas A&M University > > Computer Science & Engineering Department > > > > > > > ------------------------------ > > Message: 5 > Date: Wed, 22 Apr 2009 20:55:46 -0700 > From: nathan binkert <[email protected] <mailto:[email protected]>> > Subject: Re: [m5-dev] Adding New Param error > To: M5 Developer List <[email protected] <mailto:[email protected]>> > Message-ID: > <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset=ISO-8859-1 > > The "Param.Unsigned(..." code only goes with the SimObject definition > (in O3CPU.py) to set a value other than the default, you'd simply > say: > CPUClass.robEvalPeriod = 152000 > CPUClass.allocations_per_thread = 4 > > Nate > > 2009/4/22 Javier Jose <[email protected] > <mailto:[email protected]>>: > > Hi Everyone, > > > > As part of the Adaptive Dyanmic ROB implementation I am trying > to add 2 new parameters to be accessed on cpu.cc > > > > I added the parameters in build/ALPHA_SE/params/DerivO3CPU.hh > > I also modified src/cpu/o3/O3CPU.py to add the parameters > > > > In conifgs/example/se.py I added this code > > > > CPUClass.robEvalPeriod = Param.Unsigned(152000, "ROB Eval Period") > > CPUClass.allocations_per_thread = Param.Unsigned(4, "Allocations > per thread ROB partition") > > > > The variables are declared in src/cpu/o3/cpu.hh as unsigned int > > > > However When i run the se.py script I get the following error: > > > > Traceback (most recent call last): > > ? File "<string>", line 1, in <module> > > ? File "/home/javier/m5/src/python/m5/main.py", line 359, in main > > ??? exec filecode in scope > > ? File "/home/javier/m5/configs/example/se.py", line 142, in > <module> > > ??? CPUClass.robEvalPeriod = Param.Unsigned(152000, "ROB Eval > Period") > > ? File "/home/javier/m5/src/python/m5/SimObject.py", line 325, > in __setattr__ > > ??? cls._set_param(attr, value, param) > > ? File "/home/javier/m5/src/python/m5/SimObject.py", line 274, > in _set_param > > ??? cls._values[name] = param.convert(value) > > ? File "/home/javier/m5/src/python/m5/params.py", line 152, in > convert > > ??? return self.ptype(value) > > ? File "/home/javier/m5/src/python/m5/params.py", line 358, in > __init__ > > ??? % type(value).__name__ > > TypeError: Can't convert object of type ParamDesc to CheckedInt > > Error setting param TmpClass.robEvalPeriod to > <m5.params.ParamDesc object at 0xb770614c> > > > > I also tried: > > > > CPUClass.robEvalPeriod = Param.Int(152000, "ROB Eval Period") > > CPUClass.allocations_per_thread = Param.Int(4, "Allocations per > thread ROB partition") > > > > But, got the same errors. > > > > I appreciate the help. > > Javier Malave > > Texas A&M University > > Computer Science & Engineering Department > > > > > > _______________________________________________ > > m5-dev mailing list > > [email protected] <mailto:[email protected]> > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > ------------------------------ > > Message: 6 > Date: Thu, 23 Apr 2009 00:52:22 -0400 > From: Korey Sewell <[email protected] <mailto:[email protected]>> > Subject: Re: [m5-dev] [PATCH 03 of 10] Expose memory access size and > flags through instruction object > To: M5 Developer List <[email protected] <mailto:[email protected]>> > Message-ID: > > <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset="iso-8859-1" > > OK, > it looks like I'm caught in the trap of implementing functionality > that > doesnt buy us enough to get away with significantly breaking the > current M5 > way of instruction<->cpu interaction and similarly isn't useful enough > (considering realistic usage & other architectural inaccuracies) > to encode a > special instruction function (like translate()) to handle this case. > Unfortunately my reasons weren't strong enough to keep that > feature, but > that's OK, the discussion cleared up some things for me... > > (Steve's spiel about wasting time coding "general" features still > haunts my > dreams! ... haha) > > In initially designing the model, I was trying to allow objects > within the > CPU model to be as independent as possible in order to allow the > future > flexibility of people to add new things or edit things. One of the > reasons > O3 might seem so daunting for new users is that it has so many > tightly-weaved objects that interact that it's hard to tweak > anything with > confidence (but I do admit, modeling an out-of-order simulator in > itself is > complicated)... > > Anyway, I can conform to what people seem to want and that is just > merge the > TLB access with the Memory access, no biggie :) > > Doing so will be relatively quick to implement, but I plan on > holding off on > it a bit, since I'm so close with these regressions I dont want to > waste too > much time just merging code upstream into patches. > > If anyone needs a peek at what I have now for the InOrder model, > just let me > know and there are about 10 patches or so that you can fix up your > tree and > so far get the gzip regression working right. Currently, I am > debugging eon > and some of the FP instructions that are causing problems. > > > On Wed, Apr 22, 2009 at 12:47 AM, Steve Reinhardt > <[email protected] <mailto:[email protected]>> wrote: > > > > > > > On Tue, Apr 21, 2009 at 6:26 PM, Korey Sewell <[email protected] > <mailto:[email protected]>> wrote: > > > >> > >> That's not what I mean. What I'm saying is, simulate the > timing of a > >>> TLB stage, but do the functional access with the memory stage. > I.e. > >>> split it for timing purposes, but leave it together for functional > >>> reasons. I'd be surprised if this does not work since the > timing of > >>> TLB accesses at that granularity shouldn't have much of an > impact on > >>> the program. I think Steve agreed with me on this one. (right > Steve?) > >> > >> Yea, I think we are misunderstanding each other here. I guess > I'm not > >> exactly sure what you are getting at or what point you are > arguing for > >> (since the conversation got restarted again I may be lost in > translation) > >> > >> For your point about TLB accesses and timing, I thought that we had > >> resolved that the timing of TLBs does have a impact on the > program which is > >> why Gabe went through making a "translateTiming" access for the > TLB and then > >> also making SE mode use a TLB. > >> > > > > The timing of a TLB miss definitely has an impact. For all the > ISAs we've > > done prior to x86, TLB misses were handled in software; the > translate() > > method either was a hit or just signaled a miss to be handled > later, so we > > didn't need to do anything special to model their latency. For > x86, TLB > > misses are handled in hardware, and translate() could encapsulate a > > HW-serviced TLB miss and page table walk. That's why we needed > to add > > translateTiming(). > > > > The timing of TLB hits doesn't matter as much; it's a small > fixed delay > > like integer ALU accesses or L1 cache hits, and that latency is > pretty much > > designed into the pipeline, so as long as your pipeline design > accounts for > > that latency properly you don't have to model it very explicitly. > > > > Nate's point is that the spot in the pipeline where you account > for the > > latency of a TLB hit doesn't need to be exactly the same spot > where you > > functionally do the TLB access. For hits, I don't think there's > any loss of > > accuracy at all. Likewise for misses on ISAs with SW TLB miss > handling, > > since the TLB miss handler won't get invoked until the > instruction commits > > anyway. The only case where there might be a slight inaccuracy > is for TLB > > misses on x86, which might get kicked off a cycle or two later > than they > > should, but relative to the overall cost of a TLB miss this is > very much in > > the noise (and certainly swamped by other inaccuracies we don't > even know > > about). > > > > > >> Also, I figure that if there are situations where you dont want > to use the > >> TLB then it makes sense to not continously access the TLB object. > >> > > > > I'd be willing to bet that there are no longer any interesting > platforms > > anywhere that don't use TLBs at all. Really low-end systems may > play some > > tricks with a small number of fixed large pages to eliminate > most TLB > > misses, but anything that wants to provide security among > multiple processes > > needs virtual memory of some form, and even relatively cheap > cell phones > > still let you download java games, so I bet they're using their > TLBs. > > > > > >> And then lastly, in situations where you have a a situation of > a # of > >> dependent memory accesses waiting, it might be better for them > to translate > >> early if there is going to possibly be a time associated with a > TLB miss/hit > >> (situation that gets exacerbated with more threads on 1 CPU I would > >> assume)... > >> > > > > This seems like a pretty unlikely design, but even if you did > want to model > > this, you could still just model the timing effects of the early > TLB access > > and defer the functional TLB access until later, with the same > impact on > > timing accuracy I mentioned above: I believe only x86 TLB misses > would see > > any inaccuracy at all, and even then it would be minor. > > > > > >> So thats why currently I have instructions being having to > request the TLB > >> and the Cache as separate entities and which forced me to add > "getMemFlags" > >> and "memAccSize" to the Instruction. That implementation I have > now works > >> well but potentially there's a better non-intrusive solution to the > >> instruction object. > >> > >> Or it sounds like people want to just X out that functionality > and always > >> force a memory access to be tied to a TLB access on that same > cycle. > >> > > > > It's not that we *want* the TLB access to be tied to the memory > access, > > just that what you have now is a significant departure from the > way the > > StaticInst objects currently interact with the CPU model, and > what we're > > arguing is that these new functions and this additional > complication seem > > unnecessary. If it was the case that it seemed truly important > to be able > > to separate the functional TLB access from the functional memory > access, or > > that there was a clean way to do that consistent with the way > things work > > currently, then I don't think we'd be objecting. > > > > Steve > > > > > > > > > > _______________________________________________ > > m5-dev mailing list > > [email protected] <mailto:[email protected]> > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > -- > ---------- > Korey L Sewell > Graduate Student - PhD Candidate > Computer Science & Engineering > University of Michigan > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > http://m5sim.org/mailman/private/m5-dev/attachments/20090423/a0fbf4ef/attachment.htm > > ------------------------------ > > _______________________________________________ > m5-dev mailing list > [email protected] <mailto:[email protected]> > http://m5sim.org/mailman/listinfo/m5-dev > > > End of m5-dev Digest, Vol 24, Issue 86 > ************************************** > > > ------------------------------------------------------------------------ > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
