Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool2.mu.edu!news.cs.indiana.edu!ux1.cso.uiuc.edu!aries!mcdonald From: mcdonald@aries.scs.uiuc.edu (Doug McDonald) Newsgroups: comp.arch Subject: Re: m88200 cache flushes on DG Aviion Message-ID: <1990Dec14.031745.8840@ux1.cso.uiuc.edu> Date: 14 Dec 90 03:17:45 GMT References: <1199@dg.dg.com> <4322@photon.oakhill.UUCP> Sender: news@ux1.cso.uiuc.edu (News) Organization: School of Chemical Sciences, Univ. of Illinois at Urbana-Champaign Lines: 37 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > > >jimk> We periodically receive requests to add user level instructions to >jimk> generate cache control operations. >jimk> 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. This last is really, absolutely, true. >[various other excellent reasons] >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. > Another use for this is simply the incremental compiler. I have two vital programs that depend on efficient, easy, inclemental compilation: the user imputs various expressions (arithmetic) that are then compiled and exectued as part of the application. For this we need to have the code generated on the fly inside the application program itself. This is trivial so long as the OS doesn't simply prevent it and you can guarantee that stuff you write as data will execute correctly as code. I agree that any machine that prohibits any of this is terminally broken. Doug McDonald