Duane Rettig <email@example.com> wrote:
| firstname.lastname@example.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 Warnock <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607