peter fuerst <post@xxxxxxxx> writes:
>> compile-time base+offset addresses. And as I said, the compiler is
>> free to make up accesses that aren't in fact valid for cases where
>> the access isn't made. E.g. if you had a loop with a stride of 128,
>> the compiler could unroll the loop as many times as it likes. Some
>> of the unrolled iterations might access areas outside the stack frame.
>
> You mean, the compiler would generate $sp+const_int accesses here, whose
> validity is not known at compile-time - similar to foo() above ?
Right.
>> I think you're missing my point. If you access an I/O-mapped device
>> through KSEG2 or an uncached XKPHYS address, is it not also physically
>> possible (though clearly unwise) to access it through KSEG0 or a cached
>> XKPHYS address too? So can you guarantee that every const_int cached
>> address in a multi-platform kernel is not I/O-mapped on any of the r10k
>> platforms? Or can you guarantee that the compiler will not manufacture
>> such an address from an otherwise harmless address?
> Hmm, it's not quite clear, how it could be manufactured.
Similar to the above really, for combinations of suitably bizarre input
code and compiler behaviour. Again, the problem isn't that such a thing
is _likely_ to happen, just that it wouldn't be wrong for it to happen in
non-r10k situations (and thus not likely to be treated as a "wrong-code"
bug by gcc developers).
>> Again, the key thing
>> is to think about what the compiler can validly do on non-r10k platforms,
>> however silly it might seem, and then make sure the workarounds cope
>> with it.
>
> Do you think of accesses that essentially look like this ?
>
> if (machine_x)
> *uncached(const_addr) = val;
> else
> *cached(const_addr) = val;
Well, more generally, I was thinking of something like:
if (machine_x)
*cached(const_addr1) = ...;
else
...blah...
where const_addr1 might be harmful if !machine_x.
> Fortunately (at least? even?) on IP28 cached access (hence a block read
> request) to an I/O-device address is a non-issue. In this respect the
> hardware design seems to follow the recommendations from the R10000 manual
> (NACK from external agent?):
> - if such an access graduates (i.e. a "real" access), a bus-error will occur.
> - if not (i.e. mis-speculated), nothing happens.
Ah, OK. That's what I was missing, thanks. (I suspect you and Ralf
have explained that to me before, but it hadn't sunk in. Sorry!)
> However, i don't yet know, how O2 behaves, or, if there exists any other
> R10k-machine, which would need the software-workaround.
OK.
In that case, for the IP28 at least, I think the only issue with excluding
cachable const_int addresses is that the compiler might somehow conspire to
create an address that turns out to be, for some runs at least, an address
in a DMA buffer.
> Well, the option spec could be as listed above. With "store" as default
> for an empty option-string ("none" as default if the option isn't given
> at all).
Sounds good.
Thanks, it seems we have a plan ;)
Richard
