Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!unisoft!cjohnson From: cjohnson@unisoft.UUCP (Christopher Lyle Johnson) Newsgroups: comp.arch Subject: Re: Self-modifying code Summary: The performance win may not always exist. Keywords: Caching problems, mmu's, S&M, etc. Message-ID: <1217@unisoft.UUCP> Date: 15 Jul 88 00:03:02 GMT Reply-To: cjohnson@binary.UUCP (Christopher Lyle Johnson) Organization: UniSoft Systems, 6121 Hollis St., Emeryville, CA 94608 Lines: 41 As has been already pointed out, one of the problems with self modifying code stems from separate instruction and data caches. Even on Harvard architectures, if it is possible to mark an area of code with a cache inhibit bit SM code doesn't cause too many problems. In kernel mode or on systems where user processes can access the mmu, SM code may make sense in certain situations. I have no major aesthetic complaint if the performance win is large enough. Of course, if the code isn't cached, perhaps the win is less significant. If we want to toggle the don't cache bit (i.e. set while modifying the code, clear after the code is written), it may be difficult to claim a performance win for non-supervisor processes. If it takes two system calls per SM operation, the overhead is pretty high. (If it is faster to flush the caches, that may be an option, but there may be very little control over the granularity. How would you implement a 'flush_address(base, bounds)' system call on your favorite mmu/cache system?) However..., if a user process can't get to the mmu the operating system has a bit of a problem. I guess the trick is to write protect program text and execute protect the data. Of course, this causes a execute protect fault on the modified code page(s). The kernel could then flush the caches and write protect the page. Again, this is a lot of overhead. (Yes, I know some mmus don't have an execute protect mode. Work arounds may exist, eg. the function code mode on the 030. Ugh.) All in all, a person had better have a good reason for writing self modifying code. In some cases the performance win from the code may be lost in overhead. There are many other facets to this problem, too. Cheers, cj* ========================================================= This message does not reflect the views of UniSoft Corp but this sentence does.