Duane Rettig  <duane@franz.com> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) writes:
| > However, note that on some machine architectures it is necessary
| > to explicitly flush the data cache and/or the instruction cache
| > (for at least the affected region) *after* putting the instructions
| > to be executed into the heap-allocated array but *before* calling
| > the function. Most operating systems provide a user-accessible call
| > to perform that function.
| 
| Ironically (because you're the one saying it), Irix is one of the
| very _few_ operating systems to actually provide a documented
| interface to flush a specified range of the icache.
+---------------

Yes, well, by the time I got to SGI I was already well-sensitized to
the issue, having just-previously consulted for several years for AMD
on a Unix port to the Am29000, which had *completely* separate I & D
memory busses! [...though the I & D busses shared a common address bus.]
Depending on the system design, it wasn't necessarily even *possible*
to execute data! [Think ROM-only I-space for embedded systems...]

The later Am29030 had only a single memory bus, but did have an 2-way
set-associative I-cache, evoking similar issues. So naturally when I got
to SGI I was pleased to discover that they had a documented interface
that worked across all their platforms (even when it was a no-op, as it
was on a few machines).

+---------------
| Most of the systems which require icache flushing either provide
| undocumented support that has to be flushed (sic :-) out, or they
| provide none at all and expect the stupid programmer (well, who would
| be so stupid as to try to execute in data space? :-) to perform the
| flush, and some architectures don't provide any way to flush anything
| but the entire cache (what a waste, especially when the caches get larger).
+---------------

Looking at the CMUCL source code, they seem to assume(!?!) that the
system call "mprotect(addr, len, PROT_READ|PROT_WRITE|PROT_EXEC)"
will flush the caches, which at least the FreeBSD "mprotect(2)" man
page does *not* guarantee. [In fact, it doesn't even promise page-level
granularity: "...protection changes may be as large as an entire region."]

It'd be "interesting" [to say the least!] to know of a system implementing
"mprotect()" where the caches *weren't* flushed...


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607