Re: [Gems-users] Are direct-mapped caches disabled for a reason?

["Dan Gibson" <degibson@xxxxxxxx>]

I'm not entirely sure on this, but I would imagine the assert says 'assoc > 1' because there shouldn't *BE* a replacement policy for assoc = 1.

Regards,
Dan

On Tue, Aug 12, 2008 at 8:02 PM, Philip Garcia <pcgarcia@xxxxxxxx> wrote:

I was playing with some settings in Ruby today (in GEMS 2.1), and it
seems that direct mapped caches are disallowed by an assert statement
on line 42 of system/PseudoLRUPolicy.h (failed assertion 'num_sets > 0
&& assoc > 1 && assoc <= (Index) sizeof(uint64)*4' at fn
PseudoLRUPolicy::PseudoLRUPolicy(Index, Index) in system/
PseudoLRUPolicy.h:42).  While I can change this assert so that it says
assoc>=1, is there any reason why this was in effect?  Things seem to
run properly without it, but I don't really know for sure.

thanks,
Phil
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.

--
http://www.cs.wisc.edu/~gibson [esc]:wq!