On Tue, January 11, 2011 7:24 pm, Lisa Hsu wrote: > Hi Nilay, > > I've been talking with Brad here at work about some of these things so I > will finally jump into the conversation via email. First, great job on > this > - this has clearly been a substantial amount of work. I'm impressed. > > I've got some comments below. > > I'm not sure why having the trigger function implicitly set the cache > entries and tbe entries would require two calls to isTagPresent() if local > variables are involved. Is there some reason why something like the code > below would not be possible? > > local_var := getL1ICacheEntry(in_msg.LineAddress) > if (is_valid(local_var)) > trigger(Event, in_msg.LineAddress, local_var); > >
Are you sure you would call the above piece of code as __implicit__ setting of cache and tbe entry variables? In this case, the local variable has been __explicitly__ passed in the call to the trigger function. To me 'X is implicit' means that the programmer does not need to write 'X' in the protocol file for the compiler. For example, currently trigger function implicitly passes the state of the address as a parameter. Such code is possible, my only concern is that once the variable is set, it cannot be used again on the left hand side of the assignment operator. Entry local_var := getL1ICacheEntry(in_msg.LineAddress) /* Do some thing*/ local_var := getL1DCacheEntry(in_msg.LineAddress) This SLICC code will not generate correct C++ code, since we assume that a pointer variable can only be used in its dereferenced form, except when passed on as a parameter in a function call. > I don't see how having the entries being passed to the trigger function is > functionally different than having to explicitly set things using two > function calls is different - as long as there is a local variable > involved > to carry the value across some in_port logic it seems much cleaner and > more > consistent to eliminate the need to explicitly call two functions for > every > in_port. > > I just saw Brad's latest email go by with pseudocode and I think that is > both clean and flexible/functional - in certain cases you can explicitly > make the getCacheEntry call you want, depending on your protocol, in the > call to the trigger function, and in others you can set entries beforehand > into local variables and do arbitrary logic, then pass whatever entry you > want to the trigger function. > > Lisa > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > -- Nilay _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
