Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@crhc.uiuc.edu (Andy Glew) Newsgroups: comp.arch Subject: Re: Object-Oriented Procedure Call (was: Smart I-cache?) Message-ID: Date: 26 Nov 90 20:21:36 GMT References: <2823@crdos1.crd.ge.COM> <1157@cameron.egr.duke.edu> <657720712@lear.cs.duke.edu> Sender: news@ux1.cso.uiuc.edu (News) Followup-To: comp.arch Organization: Center for Reliable and High-Performance Computing University of Illinois at Urbana Champaign Lines: 68 In-Reply-To: moss@cs.umass.edu's message of 24 Nov 90 23:17:41 GMT >Mention of architectural speedups via special branch target cache mechanisms, >and the fact that they do not apply to "object-oriented" procedure calls >because they are indirect, encouraged me to open up wider discussion of the >issues surrounding object-oriented procedure calls (OOPCs for short). BTC's will still help indirect procedure calls. Indirect procedure calls are, after all, LOAD r1 := M[oblist+proc] BRANCH [r1] The data cache supports the first operation. The BTC supports the second operation. Of course, this requires twice as much cache state, and two operations to perform. >First, a review of some of the linguistic features. A number of languages can >compile a "dynamically bound" (OO) procedure call into an indirect branch, >i.e., a branch through a compile-time-known offset in a run-time-known table. Warning: this is yet another of my blue-sky ideas. Many "AI" or "advanced" systems use indirection through an object table in accessing functions and data. Why not try an "indirect cache" ---- instead of a cache that responds to the address of an object, have a cache that responds to the address of the object table entry? Make it simple: support one level of indirection only (I don't want to get lost in the maze of reminesces about machines that supported arbitrary chains of indirection in hardware). A special "load-indirect" or "branch-indirect" function would be needed. load-indirect's function would be: load-indirect dest maddr (1) Look up maddr associatively in indirect cache. If found, then use it... Else, continue (2) Look up maddr in normal cache. If not found, cache miss to get it -> *maddr (3) Look up *maddr in normal cache If not found, cache miss to get it Place result in dest. Place result in indirect cache, indexed by maddr. The indirect cache probably would not need to be snooped on the basis of the direct address, since the direct addresses only change as the result of garbage collections. (Multiprocessor issues?) An indirect cache *might* be a win. How much I don't know, because I don't have any significant benchmark workloads that use such indirect accesses. I don't have any statistics on the frequency of such operations. As usual, what is needed are real numbers characterizing such "OOPS" applications. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]