Ruby: Updates MOESI CMP token protocol

Information
Submitter:	Nilay Vaish
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

Ruby: Updates MOESI CMP token protocol
This patch updates the MOESI CMP token protocol to conform with the new
interfaces of CacheMemory and TBETable classes, and the changes in SLICC.

Testing Done

Changes have been tested using ruby_random_test.py for 1,000,000 loads and 20 different seeds for random number generator.

src/mem/protocol/MOESI_CMP_token-L1cache.sm (Diff revision 2)

These functions that take multiple pointers just so the called function can test which one is valid are pretty unwieldy and also seem to cause a lot of redundant testing.  Can we factor out the check so we have a single test to set one valid entry_ptr variable, then use that in all these calls?  I see there are some similar calls in MOESI_CMP_directory too, though not as many.

Nilay Vaish Jan. 3, 2011, 2:18 a.m. (Jan. 3, 2011, 2:18 a.m.)

You should check my comment in the MOESI Hammer request why we cannot set just one valid entry pointer. I am of the view that we should generate the arguments for getCacheEntry() internally in SLICC.

Steve Reinhardt Jan. 3, 2011, 2:26 a.m. (Jan. 3, 2011, 2:26 a.m.)

I understand that you can't universally assume that there's just one valid pointer... I'm not asking to go all the way back to that.  But it appears to me that there are a lot of places (regions of code) where you know that only one of N pointers is valid, yet you have to repeatedly pass all N pointers to each low-level function to figure out which one to use.  It would be both more efficient and easier to read if, in those regions, there was one function up front that identified and selected the one valid pointer (maybe sticking it in a local variable), then the low-level functions were all passed that one valid pointer.  Auto-generating params in SLICC would solve the readability problem but not the efficiency problem.

Nilay Vaish Jan. 3, 2011, 6:39 a.m. (Jan. 3, 2011, 6:39 a.m.)

This is possible with a local variable. In fact I was thinking of letting SLICC generate such a local variable in each action. But then I decided I would let this issue be taken up during the review process.
I can make this change. The problem is I am not sure if the currently proposed changes would be acceptable to some one (read Brad) who has used SLICC extensively.

Summary:

-	Ruby: Update MOESI CMP token protocol
+	Ruby: Updates MOESI CMP token protocol

Description:

~		This request for reviewing the updates to implementation of the MOESI CMP token protocol. These updates have been carried out so as to conform with the changes made to CacheMemory and TBETable classes, and to SLICC.
	~	Ruby: Updates MOESI CMP token protocol
	+	This patch updates the MOESI CMP token protocol to conform with the new
	+	interfaces of CacheMemory and TBETable classes, and the changes in SLICC.

Branch:

+	default

Diff:

Revision 3 (+569 -448)

Show changes

	src/mem/protocol/MOESI_CMP_token-L1cache.sm
	src/mem/protocol/MOESI_CMP_token-L2cache.sm
	src/mem/protocol/MOESI_CMP_token-dir.sm

Please merge it with the other patches.

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Summary:

Description:

Branch:

Diff: