Subject: Re: Implementing Lisp in C?
From: (Rob Warnock)
Date: Fri, 09 Apr 2004 18:52:08 -0500
Newsgroups: comp.lang.lisp
Message-ID: <>
Duane Rettig  <> wrote:
| (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: " 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			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607