-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/#review747
-----------------------------------------------------------


Hi Nilay,

This patch looks great!  Once you take care of the missing headers, consider it 
done from my perspective.  I believe this was mentioned before, but it would be 
best if you merged all the protocol patches with this patch and checked them in 
as one patch.

Brad


src/mem/slicc/ast/IsValidPtrExprAST.py
<http://reviews.m5sim.org/r/358/#comment1010>

    Please add the license header and Wisconsin copyright to this file.



src/mem/slicc/ast/LocalVariableAST.py
<http://reviews.m5sim.org/r/358/#comment1011>

    Please add the license header and Wisconsin copyright to this file.



src/mem/slicc/ast/OodAST.py
<http://reviews.m5sim.org/r/358/#comment1012>

    Please add the license header and Wisconsin copyright to this file.


- Brad


On 2011-01-16 16:00:05, Nilay Vaish wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/358/
> -----------------------------------------------------------
> 
> (Updated 2011-01-16 16:00:05)
> 
> 
> Review request for Default.
> 
> 
> Summary
> -------
> 
> Change interface between coherence protocols and CacheMemory
> 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.
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   src/mem/protocol/RubySlicc_Types.sm 696063d6ed04 
>   src/mem/ruby/slicc_interface/AbstractCacheEntry.hh 696063d6ed04 
>   src/mem/ruby/slicc_interface/AbstractCacheEntry.cc 696063d6ed04 
>   src/mem/ruby/system/CacheMemory.hh 696063d6ed04 
>   src/mem/ruby/system/CacheMemory.cc 696063d6ed04 
>   src/mem/ruby/system/TBETable.hh 696063d6ed04 
>   src/mem/slicc/ast/ActionDeclAST.py 696063d6ed04 
>   src/mem/slicc/ast/FormalParamAST.py 696063d6ed04 
>   src/mem/slicc/ast/FuncCallExprAST.py 696063d6ed04 
>   src/mem/slicc/ast/IfStatementAST.py 696063d6ed04 
>   src/mem/slicc/ast/InPortDeclAST.py 696063d6ed04 
>   src/mem/slicc/ast/IsValidPtrExprAST.py PRE-CREATION 
>   src/mem/slicc/ast/LocalVariableAST.py PRE-CREATION 
>   src/mem/slicc/ast/MethodCallExprAST.py 696063d6ed04 
>   src/mem/slicc/ast/OodAST.py PRE-CREATION 
>   src/mem/slicc/ast/ReturnStatementAST.py 696063d6ed04 
>   src/mem/slicc/ast/StaticCastAST.py 696063d6ed04 
>   src/mem/slicc/ast/TypeDeclAST.py 696063d6ed04 
>   src/mem/slicc/ast/__init__.py 696063d6ed04 
>   src/mem/slicc/parser.py 696063d6ed04 
>   src/mem/slicc/symbols/Func.py 696063d6ed04 
>   src/mem/slicc/symbols/StateMachine.py 696063d6ed04 
> 
> Diff: http://reviews.m5sim.org/r/358/diff
> 
> 
> Testing
> -------
> 
> These changes have been tested with five different protocols,
> namely, MI, MOESI CMP directory, token, MOESI hammer and
> MESI CMP directory. The testing was carried out using
> ruby_random_tester.py. Multiple random seeds were used, number 
> of loads was varied from 4,000,000 to 10,000,000, number of processors
> was varied from 1 to 4.
> 
> 
> Thanks,
> 
> Nilay
> 
>

_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to