summaryrefslogtreecommitdiff
path: root/src/mem/slicc/ast/FuncCallExprAST.py
AgeCommit message (Collapse)Author
2015-08-30ruby: slicc: avoid duplicate code for function argument checkNilay Vaish
Both FuncCallExprAST and MethodCallExprAST had code for checking the arguments with which a function is being called. The patch does away with this duplication. Now the code for checking function call arguments resides in the Func class.
2015-08-19ruby: reverts to changeset: bf82f1f7b040Nilay Vaish
2015-08-14ruby: slicc: avoid duplicate code for function argument checkNilay Vaish
Both FuncCallExprAST and MethodCallExprAST had code for checking the arguments with which a function is being called. The patch does away with this duplication. Now the code for checking function call arguments resides in the Func class.
2015-07-20slicc: enable overloading in functions not in classesBrad Beckmann
For many years the slicc symbol table has supported overloaded functions in external classes. This patch extends that support to functions that are not part of classes (a.k.a. no parent). For example, this support allows slicc to understand that mapAddressToRange is overloaded and the NodeID is an optional parameter.
2015-07-20slicc: improved stalling support in protocolsBrad Beckmann
Adds features to allow protocols to reschedule controllers when conditionally stalling within inport logic or actions. Also insures that resource and protocol stalls are re-evaluated the next cycle.
2015-07-20slicc: support for arbitrary DPRINTF flags (not just RubySlicc)David Hashe
This patch allows DPRINTFs to be used in SLICC state machines similar to how they are used by the rest of gem5. Previously all DPRINTFs in the .sm files had to use the RubySlicc flag.
2014-01-08ruby: slicc: remove variable 'addr' used in calls to doTransitionNilay Vaish
This variable causes trouble if a variable of same name is declared in a protocol file. Hence it is being eliminated.
2013-08-07ruby: slicc: remove double trigger, continueProcessingNilay Vaish
These constructs are not in use and are not being maintained by any one. In addition, it is not known if doubleTrigger works correctly with Ruby now.
2013-07-11ruby: removed the very old double trigger hackBrad Beckmann
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
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.
2012-10-02ruby: remove some unused things in sliccNilay Vaish
This patch removes the parts of slicc that were required for multi-chip protocols. Going ahead, it seems multi-chip protocols would be implemented by playing with the network itself.
2012-09-18ruby: avoid using g_system_ptr for event schedulingNilay Vaish
This patch removes the use of g_system_ptr for event scheduling. Each consumer object now needs to specify upfront an EventManager object it would use for scheduling events. This makes the ruby memory system more amenable for a multi-threaded simulation.
2012-08-27Ruby: Remove RubyEventQueueNilay Vaish
This patch removes RubyEventQueue. Consumer objects now rely on RubySystem or themselves for scheduling events.
2012-07-10imported patch jason/slicc-external-structure-fixBrad Beckmann
2011-03-31Ruby: Simplify SLICC and Entry/TBE handling.Lisa Hsu
Before this changeset, all local variables of type Entry and TBE were considered to be pointers, but an immediate use of said variables would not be automatically deferenced in SLICC-generated code. Instead, deferences occurred when such variables were passed to functions, and were automatically dereferenced in the bodies of the functions (e.g. the implicitly passed cache_entry). This is a more general way to do it, which leaves in place the assumption that parameters to functions and local variables of type AbstractCacheEntry and TBE are always pointers, but instead of dereferencing to access member variables on a contextual basis, the dereferencing automatically occurs on a type basis at the moment a member is being accessed. So, now, things you can do that you couldn't before include: Entry foo := getCacheEntry(address); cache_entry.DataBlk := foo.DataBlk; or cache_entry.DataBlk := getCacheEntry(address).DataBlk; or even cache_entry.DataBlk := static_cast(Entry, pointer, cache.lookup(address)).DataBlk;
2011-01-17Change interface between coherence protocols and CacheMemoryNilay Vaish
The purpose of this patch is to change the way CacheMemory interfaces with coherence protocols. Currently, whenever a cache controller (defined in the protocol under consideration) needs to carry out any operation on a cache block, it looks up the tag hash map and figures out whether or not the block exists in the cache. In case it does exist, the operation is carried out (which requires another lookup). As observed through profiling of different protocols, multiple such lookups take place for a given cache block. It was noted that the tag lookup takes anything from 10% to 20% of the simulation time. In order to reduce this time, this patch is being posted. I have to acknowledge that the many of the thoughts that went in to this patch belong to Brad. Changes to CacheMemory, TBETable and AbstractCacheEntry classes: 1. The lookup function belonging to CacheMemory class now returns a pointer to a cache block entry, instead of a reference. The pointer is NULL in case the block being looked up is not present in the cache. Similar change has been carried out in the lookup function of the TBETable class. 2. Function for setting and getting access permission of a cache block have been moved from CacheMemory class to AbstractCacheEntry class. 3. The allocate function in CacheMemory class now returns pointer to the allocated cache entry. Changes to SLICC: 1. Each action now has implicit variables - cache_entry and tbe. cache_entry, if != NULL, must point to the cache entry for the address on which the action is being carried out. Similarly, tbe should also point to the transaction buffer entry of the address on which the action is being carried out. 2. If a cache entry or a transaction buffer entry is passed on as an argument to a function, it is presumed that a pointer is being passed on. 3. The cache entry and the tbe pointers received __implicitly__ by the actions, are passed __explicitly__ to the trigger function. 4. While performing an action, set/unset_cache_entry, set/unset_tbe are to be used for setting / unsetting cache entry and tbe pointers respectively. 5. is_valid() and is_invalid() has been made available for testing whether a given pointer 'is not NULL' and 'is NULL' respectively. 6. Local variables are now available, but they are assumed to be pointers always. 7. It is now possible for an object of the derieved class to make calls to a function defined in the interface. 8. An OOD token has been introduced in SLICC. It is same as the NULL token used in C/C++. If you are wondering, OOD stands for Out Of Domain. 9. static_cast can now taken an optional parameter that asks for casting the given variable to a pointer of the given type. 10. Functions can be annotated with 'return_by_pointer=yes' to return a pointer. 11. StateMachine has two new variables, EntryType and TBEType. EntryType is set to the type which inherits from 'AbstractCacheEntry'. There can only be one such type in the machine. TBEType is set to the type for which 'TBE' is used as the name. All the protocols have been modified to conform with the new interface.
2010-12-08ruby: remove Ruby asserts for m5.fastBrad Beckmann
This diff is for changing the way ASSERT is handled in Ruby. m5.fast compiles out the assert statements by using the macro NDEBUG. Ruby uses the macro RUBY_NO_ASSERT to do so. This macro has been removed and NDEBUG has been put in its place.
2010-12-01ruby: Converted old ruby debug calls to M5 debug callsNilay Vaish
This patch developed by Nilay Vaish converts all the old GEMS-style ruby debug calls to the appropriate M5 debug calls.
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