Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!usc!srhqla!demott!kdq From: kdq@demott.COM (Kevin D. Quitt) Newsgroups: comp.sys.m68k Subject: Re: mc68040 I/D coherency Message-ID: <273@demott.COM> Date: 2 Jun 90 22:31:04 GMT References: Reply-To: kdq@demott.COM (Kevin D. Quitt) Organization: DeMott Electronics Co., Van Nuys CA Lines: 36 In article Christopher.Hoover@CS.CMU.EDU writes: >kdq@demott.COM (Kevin D. Quitt) writes: >> >> It should be impossible for any user-level code. Priveleged code like >> a debugger must be smart enough to invalidate the cache, and that has nothing >> to do with I vs D. >> > >No, user-level code must be able to flush the I-cache. Languages like >Lisp which manage their heaps using a copying garbage collector need >to flush the I-cache after a GC as objects containing code may be >moved by the garbage collector. > Yes, they do. What does this have to do with user-level code? If the code in interpreted, moving it doesn't matter. I don't think compiled lisp code (that is actually compiled to machine code) is moved (not in the lisps I've written). In that case, though, the GC should run setuid to do its very-machine-dependent memory manipulation. I don't mean to be a pedant. What I'm trying to say is that cache management, along with memory management, belong to the operating system. Just as there are calls to allow a user program to manipulate memory mapping, there should be calls for cache control (possibly just invalidate_my_cache). -- _ Kevin D. Quitt Manager, Software Development 34 12 N 118 27 W DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 Telebit PEP last demott!kdq kdq@demott.com 96.37% of the statistics used in arguments are made up.