summaryrefslogtreecommitdiff
path: root/src/mem/slicc/ast/EnqueueStatementAST.py
AgeCommit message (Collapse)Author
2014-10-16mem: Use shared_ptr for Ruby Message classesAndreas Hansson
This patch transitions the Ruby Message and its derived classes from the ad-hoc RefCountingPtr to the c++11 shared_ptr. There are no changes in behaviour, and the code modifications are mainly replacing "new" with "make_shared". The cloning of derived messages is slightly changed as they previously relied on overriding the base-class through covariant return types.
2014-04-08ruby: slicc: change enqueue statementNilay Vaish
As of now, the enqueue statement can take in any number of 'pairs' as argument. But we only use the pair in which latency is the key. This latency is allowed to be either a fixed integer or a member variable of controller in which the expression appears. This patch drops the use of pairs in an enqueue statement. Instead, an expression is allowed which will be interpreted to be the latency of the enqueue. This expression can anything allowed by slicc including a constant integer or a member variable.
2013-02-10ruby: enable multiple clock domainsNilay Vaish
This patch allows ruby to have multiple clock domains. As I understand with this patch, controllers can have different frequencies. The entire network needs to run at a single frequency. The idea is that with in an object, time is treated in terms of cycles. But the messages that are passed from one entity to another should contain the time in Ticks. As of now, this is only true for the message buffers, but not for the links in the network. As I understand the code, all the entities in different networks (simple, garnet-fixed, garnet-flexible) should be clocked at the same frequency. Another problem is that the directory controller has to operate at the same frequency as the ruby system. This is because the memory controller does not make use of the Message Buffer, and instead implements a buffer of its own. So, it has no idea of the frequency at which the directory controller is operating and uses ruby system's frequency for scheduling events.
2013-02-10ruby: replaces Time with Cycles in many placesNilay Vaish
The patch started of with replacing Time with Cycles in the Consumer class. But to get ruby to compile, the rest of the changes had to be carried out. Subsequent patches will further this process, till we completely replace Time with Cycles.
2013-01-14Ruby: remove reference to g_system_ptr from class MessageNilay Vaish
This patch was initiated so as to remove reference to g_system_ptr, the pointer to Ruby System that is used for getting the current time. That simple change actual requires changing a lot many things in slicc and garnet. All these changes are related to how time is handled. In most of the places, g_system_ptr has been replaced by another clock object. The changes have been done under the assumption that all the components in the memory system are on the same clock frequency, but the actual clocks might be distributed.
2010-06-10ruby: get rid of RefCnt and Allocator stuff use base/refcnt.hhNathan Binkert
This was somewhat tricky because the RefCnt API was somewhat odd. The biggest confusion was that the the RefCnt object's constructor that took a TYPE& cloned the object. I created an explicit virtual clone() function for things that took advantage of this version of the constructor. I was conservative and used clone() when I was in doubt of whether or not it was necessary. I still think that there are probably too many instances of clone(), but hopefully not too many. I converted several instances of const MsgPtr & to a simple MsgPtr. If the function wants to avoid the overhead of creating another reference, then it should just use a regular pointer instead of a ref counting ptr. There were a couple of instances where refcounted objects were created on the stack. This seems pretty dangerous since if you ever accidentally make a reference to that object with a ref counting pointer, bad things are bound to happen.
2009-09-22slicc: Pure python implementation of slicc.Nathan Binkert
This is simply a translation of the C++ slicc into python with very minimal reorganization of the code. The output can be verified as nearly identical by doing a "diff -wBur". Slicc can easily be run manually by using util/slicc