>> /** >> * Clock cycle count type. >> * @note using an unsigned breaks the cache. >> */ >> typedef int64_t Tick; >> >> though offhand I'm not sure why that's true. I just grepped through the >> code and it looks like there are places where the code subtracts two tick >> values and may expect the difference to be less than zero if the first one >> is smaller than the second... that's probably at least part of it. > > I can't remember if I created UTick, but I think I did, and I'm pretty > sure that I did it because I couldn't change the type of Tick. Do we > care? The safe thing to do is just use UTick in assertion "Tick" checks but it seems like a Tick should be unsigned anyway and since we are going to a Ruby memory system, then this time might be a good time to change Tick officially to unsigned.
However, if there is code that actually relies on Tick values being negative then I would agree that the hassle is probably just too much to go through some kind of big overhaul for. -- - Korey _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
