Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!lpi.liant.com!drilex!dricejb From: dricejb@drilex.UUCP (Craig Jackson drilex1) Newsgroups: comp.arch Subject: Re: m88200 cache flushes on DG Aviion Message-ID: <19767@drilex.UUCP> Date: 19 Dec 90 15:22:33 GMT References: <1990Dec14.031745.8840@ux1.cso.uiuc.edu> <44118@mips.mips.COM> <1990Dec15.143354.8493@ux1.cso.uiuc.edu> Organization: DRI/McGraw-Hill, Lexington, MA Lines: 53 In article <1990Dec15.143354.8493@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >In article <44118@mips.mips.COM> mash@mips.COM (John Mashey) writes: >>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... > >This is not a job for the OS (the standardization, that is). It >is a job for the languages. In some, like Fortran 77, of course, you >can't execute data. But in C you can. Almost. The "almost" is >unequivocally the worst failure of the ANSI C spec: it should have >included a routine (or macro) that makes a section of data into >a code area and returns a code pointer to it. Such a routine would have made ANSI C unimplementable (or expensive to implement) on some machines. Contrary to Mr. McDonald's beliefs, a few architectures have been commercially successful over the years without the ability for an arbitrary program to store instructions in memory and execute them. In particular, the architecture of the Burroughs B6700 and its descendents, which is still marketed and used as the Unisys A-Series, does not have that ability. This architecture incorporates one of Per Brinch Hansen's ideas from Concurrent Pascal, several years before he had it: put the protection in the compilers, not the hardware. Therefore any thing which acts as a compiler is system-security-sensitive. Actually, such a system call *could* be implemented on the A-Series. It would simply have to syntactically vet the supposed 'code',make any necessary translations/modifications for the target environment, and then bind it to a function-object in the calling program. Note that the area of memory offered need not contain actual machine instructions for the current machine; it could just as well contain C code, since we're going to have to parse it in any case. The set of OS code which performs this function will be known as a 'compiler'. (Such a capability has indeed been put in recent versions of the A-Series operating system. The language compiled is called 'Scode', and has not yet been documented outside of Unisys. I don't think it is callable from A-Series C.) This is somewhat far afield of the original cache-purging thread, and I'm certain the semantics described above aren't what Mr. McDonald had in mind. However, if you think about it, they are actually equivalent semantics to a 'give me a pointer-to-function from this pointer-to-data' system call. Which is what would be needed, in general, in the C language, or in POSIX. (A simple cache-synchronize isn't sufficient; what you have is a pointer-to-data, and only pointers-to-function are executable.) -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}