Xref: utzoo comp.sys.m88k:538 comp.arch:19773 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!samsung!olivea!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.sys.m88k,comp.arch Subject: Re: m88200 cache flushes on DG Aviion Message-ID: Date: 13 Dec 90 21:47:59 GMT References: <2308@io.UUCP> <1199@dg.dg.com> <4322@photon.oakhill.UUCP> Sender: aro@aber-cs.UUCP Followup-To: comp.arch Organization: Coleg Prifysgol Cymru Lines: 53 Nntp-Posting-Host: odin In-reply-to: jimk@oakhill.UUCP's message of 11 Dec 90 01:37:22 GMT Posting-Front-End: GNU Emacs 18.55.4 of Thu Nov 23 1989 on athene (berkeley-unix) I have corssposted to comp.arch, and redirected followups there too because this is a very general architectural question, not just limited to the 88k. On 11 Dec 90 01:37:22 GMT, jimk@oakhill.UUCP (Jim Klingshirn) said: jimk> We periodically receive requests to add user level instructions to jimk> generate cache control operations. The justification generally is jimk> centered around data caches - for instance how can you force data jimk> out so that it is guaranteed to get out to the graphics frame jimk> buffer when the cache is in copyback mode. To date, the only jimk> justification I've heard for instruction cache control is to jimk> support self modifying code (including breakpoints). jimk> Assuming there are alternate ways to support breakpoints - should jimk> we worry about instruction cache control operations? Oh yes, definitely. Self modifying code is of the essence. It is *vital* as a technique to support efficiently, especially on a RISC machine, many advanced programming language constructs. If you want to do just Fortran and C, no problem, but probably you don't want. Basically it is extremely important to be able to generate or modify small code sequences ("thunks") on the fly in many OO languages, and even in some older languages, and in many non OO languages as well, and in many other cases. Consider Self, as just a small example; also, virtual functions in C++ can be efficiently implemented with thunks, and one 386 compiler already uses them. Modern Smalltalk implementations generate code on the fly as well, and so on. Also, it is the easiest way to support languages that run in an environment, such as many Lisps, AI languages, which have an embedded compiler and generate compiled code in the workspace. Other applications may be graphic algorithms; in many cases one can produce thunks, ortmodify existing canned ones, so that certain repetitive drawing operations can be done by high speed code customized for the precise purpose. I guess this is why a guy from Interleaf is interested in self modifying code. Dynamic code generation, which is indistinguishable from self modifying code of old, is also especially suited to RISC machines to give sort of dynamic microprogramming; you synthetize higher level operations dynamically out of the simple RISC ones, without having to consider in advance all the cases. After all, consider that self modifying code was used most often in old machines to simulate index registers :-). -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk