The NO_FAULT behavior in Alpha is still the correct behavior model in my opinion (and corresponds to what Ali described). I had not realized that the implementation was Alpha-specific though; thanks for tracking that down, Gabe.
I'm also amazed that the PREFETCH flag is not used anywhere... that's an interesting oversight. I'm not sure it affects much since the memory hierarchy doesn't treat them any differently from demand requests at this point. > Thinking about this more, it also seems that NO_FAULT doesn't quite > > capture what a prefetch is. If you're doing a load that shouldn't > > fault > > but still (assuming it worked) return data, that's different from a > > prefetch that doesn't return anything. In one case you'd potentially > > block execution, and the other you wouldn't. > I don't know of anything that works quite like this... the only thing I can think of that's roughly similar is an IA64 "advanced load" (I think that's what it was called), but in that case it's treated like a load but if it faults that taints the destination register and then you fault if you read that reg (or something like that). So in that case the memory system shouldn't treat it like a prefetch anyway, and the CPU semantics are something we don't (and may never) support. > So my question to the > > memory guys is, do we care? Which flags do we actually want? How > > should > > they work within the CPU as far as how far faults get, etc? > > The idea behind NO_FAULT was to separate the behavior from the purpose. If there aren't any other instructions besides prefetches that ever want to suppress faults even when non-speculative (I can't think of any), and since the redundancy between setting PREFETCH and setting NO_FAULT is clearly problematic, I'm fine with getting rid of NO_FAULT, using PREFETCH to flag all prefetch instructions, and requiring the core models to ignore faults on instructions tagged PREFETCH. I think PF_EXCLUSIVE should be kept as a flag that can be set in addition to PREFETCH; it should be an error to set PF_EXCLUSIVE and not PREFETCH. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
