This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: dcache


"J.T. Conklin" wrote:
> 
> The dcache_flush() routine throws away its contents.  I don't know
> about you guys, but to me flushing a cache implies writing out the
> contents, is there any objection to renaming this function to some-
> thing like dcache_invalidate()?  The dcache_writeback() function is
> a real cache flush, but writeback is just as descriptive.  I see no
> reason to rename it to dcache_flush().

Yes, long ago I thought I knew what a flush function did.  Since reading
GDB's code I've become very confused :-)
serial.c has exactly the same problem.  It's ``drain()'' function
implements flush().  Dig dig, hmm, serial's flush dates back to
1993/06/30 while dcache is around that same period (different authors
though :-).

> Implies that GDB writes reads and memory in small chunks instead of
> larger chunks, and the dcache speeds this up by coalescing multiple
> small transactions into larger ones.  Does anyone know the truth of
> this implication, especially for writes?

Ignoring the dcache() gdb definitly likes to perform small writes (1-4
bytes).  The easiest case to monitor would be an inferior function call.

> I ask because the current implementation is a writethrough cache ---
> small writes aren't going to be combined.  I suspect in most cases, if
> target memory is cached at all, this is the desired behavior.  (e.g. A
> user setting a global flag probably wants that change to be reflected
> immediately, so that another thread of execution can act upon it).

The behavour should be the same as with registers.  As far as the user
can see, operations are write through.
However, internally, gdb would benefit from a write back mechanism when
implementing inferior function calls.

> Are there any circumstances where a writeback cache would be useful?
> While I'm fiddling around with dcache, it would not be difficult to
> add.  Every place there's a dcache_flush() in target code would be
> replaced with something like dcache_writebackinvalidate(), and the
> dcache_xfer_memory could avoid writing the data if the memory region
> was configured for a writeback behavior.

The test call-ar-st.exp would benefit significantly!

	Andrew

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]