Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!versatc!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: Optical computing reference (really: separate I & D) Message-ID: <18574@winchester.mips.COM> Date: 1 May 89 03:47:01 GMT References: <89@ <46500061@uxe.cso.uiuc.edu> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 39 In article <46500061@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: .... >I am NOT - read my lips - referring to what is usually called >"self modifying code", but rather "incremental compilation". .... >I would like to know why some designers would like to prohibit this. >I can not see ANY reason why it would be desirable to prevent it. >I can understand the reasons why it might take a system call at >run time (like in OS/2) or a specific declaration at link time >(like in VMS) and why on some architectures (80286, 80386) one >would have to use two overlapped segments, and even why on some >machine there might need to be a cache flush. But I cannot see >any possible ADVANTAGE to the designer in preventing it - why >remove from the list of possible purchasers of your hardware or >OS those users who need it? >Is it just basically that some designers are rooted in the >old fashioned "compile now, run later" philosophy that they can't >even conceive of this? That is the only RATIONAL answer I can think of. There are some advantages in prohibiting this. The old Burroughs B5xxx machines relied on the inability of a user program to generate code on the fly directly for certain protection assists. Some hardware may require overlapped segments, as you note, and certainly anybody with split I & D caches always considers this ugly. I do agree with you, though: it has to be supported somehow. (In fact, that leads to an interesting area for standardization: there are enough machines around now that require cache-flusing by a user program at some time or other, that it would be REALLY DESIRABLE to standardize the function calls used to accomplish this. Would anybody out there care to offer definitions of the cache-flushing calls they offer on their systems?) -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086