Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!rutgers!dimacs.rutgers.edu!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: m88200 cache flushes on DG Aviion Message-ID: <44118@mips.mips.COM> Date: 15 Dec 90 02:44:04 GMT References: <1199@dg.dg.com> <4322@photon.oakhill.UUCP> <1990Dec14.031745.8840@ux1.cso.uiuc.edu> Sender: news@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 52 In article <1990Dec14.031745.8840@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: .... >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. I think I agree, in the sense that there always must be some way to do this. However, if anybody thinks that there must be a way to generate instructions, then jump to them, without doing anything else, is doomed to increasing heartbreak, as: 1) More and more implementations use split Instruction and Data caches, for rational technical reasons. 2) Most implementations provide no automatic way to keep I-caches instantaneously coherent with D-cache changes, for rational technical reasons. 3) Even when it's possible, the OS usually turns such synchronization off, given the performance hit implied. Of course, some designs are willing to pay the price, given the need to run large amounts of existing code that did self-modification. For example, I think the Amdahl machines use split I & D caches, but synchronize them. The 486 uses a single joint cache, and does pretty well at hiding the overhead by other means. Current RISC architectures would pay a much higher price to have automatic synchronization of split caches, which is why they don't do it. All of this means that most UNIXes based on these things have some system call, or otherwise programmatic interface that at least causes a specified chunk of memory to become synchronized. Here's a good discussion topic, and in fact, maybe this is something where it would be AWFULLY nice to get standardized among people that do it: WHAT'S THE PROGRAMMATIC INTERFACE FOR CACHE-FLUSHING (and any other cache-manipulation operations) on your favorite machine? ARE THERE ANY STANDARDS FOR SCUH THINGS ACROSS VENDORS? (I can hope :-) If nobody is working on standardizing the programmatic interface, we probably should be, as a service to the industry... -- -john mashey DISCLAIMER: UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086