>> 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.
I think SPARC has an ASI that behaves like that as well. > > >> 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 > Ok. I'll do that. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
