🚀 go-pugleaf

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: <generic disclaimer, I speak for me only, etc>
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