mlock in cache

Christos xristos.tsop@gmail.com
Fri Aug 2 19:01:00 GMT 2013


On 08/02/2013 07:14 PM, Oleg Endo wrote:
> I'd say the available options depend on the processor architecture.
> Maybe it's better in your case to look at different architectures and
> not at the types of built-ins GCC has or doesn't have.
Definitely, this should be the core conclusion of the thread.
> For example, the
> SH4 CPU has some cache control instructions (not all of them are
> available through GCC built-in functions):
> movca.l - Reserves a cache line by marking it as valid for the specified
>            address.  Does not synchronize it with memory if it is dirty.
>
> ocbp - Write back and invalidate operand cache line
>
> ocbwb - Write back cache line but do not invalidate it
>
> pref - Prefetch cache line (no operation if it is already in the cache)
Very interesting, thanks for the info.
> In addition to that, memory accesses can either go through the cache or
> bypass the cache (there are special bits in the address for that when
> accessing memory without MMU, or settings in MMU pages).
> With these low level things something like what you described above
> could be constructed, but probably it will be difficult to do so in a
> multi tasking environment.
Why do you say so? I ask you because my main interest is a 
multiprocessing/multicore system.
I can't see why you can't do that if you work at a very low level, like 
the one you mentioned, as I said previously.
> If GCC doesn't have a built-in function
> ready for the particular special instruction it can be issued rather
> easily with inline asm.
Well, I think I mentioned this aspect before and it really has to do 
with finding the necessary asm directives.
> Also, there's no guarantee that e.g.
> __builtin_prefetch will actually emit a prefetch instruction.
Thanks a lot for that because it was another question of mine. Do you 
know at which part of the official documentation this thing is mentioned?

Once again, thanks a lot for the assistance, it was rather helpful...!

-- 
Christos Tsopokis



More information about the Gcc-help mailing list