Brad,
Let's try to break the required changes into small portions. Given my
feeble knowledge of Ruby, it would be for me to visualize what change is
going to have what effect.
One question, should we use pointers to pass the cache entry around, or
should we make use of reference variables? Currently lookup functions
return references to cache entries.
Nilay
On Tue, 7 Dec 2010, Beckmann, Brad wrote:
Hi Nilay,
Yes, this is not an easy issue to fix. First to answer your other
question, I believe TBE stands for Transaction Buffer Entry, or
something to that effect. As you suggested, we can pass in the cache
entry and possibly even the TBE entry into the trigger function. Thus
all actions will implicitly include these two parameters as inputs and
not require continually lookups or even local variables. However, I
believe to make this work we need to change the semantics for allocating
and deallocating cache and TBE entries. In particular, these operations
probably should be handled by specialized operators (similar to trigger)
that correctly manage the pointers underneath.
Does that make sense? Let me know if you'd like to brainstorm more
about this over a phone conversation.
Brad
-----Original Message-----
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
Nilay Vaish
Sent: Tuesday, December 07, 2010 12:16 AM
To: M5 Developer List
Subject: Re: [m5-dev] Implementation of findTagInSet
I have made changes to SLICC to support local reference variables. I
think we should reference variables in functions where back to back
calls are made to lookup/getCacheEntry functions.
Overall, I am still unclear how can we handle this issue.
Nilay
On Tue, 30 Nov 2010, Nilay Vaish wrote:
Is it possible to have variables local to a function in .sm files. I
am thinking of storing getCacheEntry()'s return value in a local variable.
Nilay
On Mon, 29 Nov 2010, Beckmann, Brad wrote:
Hi Nilay,
I don't think we want to replace the implicit Address parameter inside
the state machines with the CacheEntry parameter, but we might want to
supplement the state machine functions to include both. I don't think
we can replace the Address parameter because certain transitions
within a state machine don't operate on a CacheEntry, but they do
operate on an Address. However, as we discussed last week, we might
be able to pass the CacheEntry into the trigger function along with
the Address, which is then implicitly included in all actions. The
key in my mind is that we want to maintain the current programming
invariant that SLICC does not expose pointers, but underneath the
generated code needs to manage that sometimes the CacheEntry pointer
may equal NULL. In particular, I would like to minimize any added
complexity we put on the setState function. I think we can make this
work, but we need to think through the details, including how
replacements are handled.
I have a few other things I need to take care of first, but I may be
able to look into the details of how to make this work by the end of the week.
Brad
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
