Path: utzoo!utgpu!cunews!bnrgate!bwdls61.bnr.ca!bwdls58!mlord
From: mlord@bwdls58.UUCP (Mark Lord)
Newsgroups: comp.arch
Subject: Stack Cache with O/S driven copyback ?
Keywords: stack cache caching
Message-ID: <5229@bwdls58.UUCP>
Date: 14 Jan 91 22:59:22 GMT
Organization: Bell-Northern Research, Ottawa, CANADA
Lines: 44

How smart are the stack-cache designs that have been looked at?
I'm curious whether a proposal such as the following has already
been researched.
-------
The procedure call stack is probably the heaviest used chunk of memory
in most time sharing systems, such as *nix or whatever.  It therefore
follows that hardware optimization of this resource might provide 
significant performance improvements in just about any RISC/CISC system.

Specifically, how about an operating system controlled cache, devoted to
caching the call stack of the current task and/or interrupt handler?

This stack would have the following key characteristics:

	1) copyback cache - line size of 64bits. (determine optimum size ?)
	2) one-way direct mapping.
	3) O/S writes start & size registers for memory range to be cached,
		during context switches.
	4) cache size >= average task stack size  (4-8K ?)
	5) copyback has lowest bus priority - gets done only when nothing
		else wants the bus (reads, writes, dma, other caches).
	6) at context switch time, O/S uses hardware mechanism to
		clear the copyback flags for locations beyond top of stack.
		This could eliminate a lot of unnecessary copybacks.
		The same strategy could also be used by interrupt handlers,
		if the cache is to be shared.

So the idea is that, each context switch, the O/S purges the cache of any
pending copybacks for items no longer "on the stack", and then sets a new
range of addresses to be cached for the next task.  Stack locations do not
get copied back to memory until absolutely necessary (some other location
needs to be cached in the same slot of the cache.. gotta clear it first!),
unless there are free bus cycles that would otherwise be unused.

I've seen discussion of stack caching here in the past, but I don't recall
seeing suggestions 3/6) discussed.  Without it, stack caching appears to gain
nothing over simply using a larger general purpose cache.  But with it.. ?

Undoubtedly this has problems, but perhaps others here can help iron them out.
-- 
 ___Mark S. Lord__________________________________________
| ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) |
| MLORD@BNR.CA   Ottawa, Ontario | Personal views only.   |
|________________________________|________________________|