|Mixing virtual and real machine code in an interpreter email@example.com (1994-03-16)|
|Re: Mixing virtual and real machine code in an interpreter firstname.lastname@example.org (1994-03-22)|
|I-cache consistancy (WAS: Mixing virtual and real machine ...) email@example.com (1994-03-24)|
|From:||firstname.lastname@example.org (David Keppel)|
|Organization:||Computer Science & Engineering, U. of Washington, Seattle|
|Date:||Thu, 24 Mar 1994 03:48:22 GMT|
email@example.com (Nick Haines) writes:
>[Many machines have separate instruction and data caches, but also
> provide an OS routine to invalidate the instruction cache (or some
> part thereof); used when creating (during compilation) or moving
> (during GC) code objects.]
Yes, most systems provide a mechanism for ensuring I-cache consistancy.
That raises the question ``how do you make use of it?''
Sometimes the `flush' is provided directly by a hardware instruction,
sometimes by an OS routine; in addition the interface may be the same from
machine to machine, but individual platforms may have e.g., different
cache sizes and thus different `best' flushing strategies depending on
whether you're changing a little bit of code or a lot.
For a more detailed analysis and a portable interface that hides machine
dependencies while optimizing around details of both the hardware and the
size of the region being flushed see (blowing my own horn again...):
%A David Keppel
%T A Portable Interface for On-The-Fly Instruction Space Modification
%J Proceedings of the Fourth International Conference on
Architectural Support for Programming Languages and Operating Systems
%D April 1991
The implementation for a few machines is available via anonymous ftp:
`ftp.cs.washington.edu' (220.127.116.11) in `pub/pardo/fly-1.0..tar.Z'. (Be
sure to do the transfer in binary mode.)
;-D on ( Destruction caches ) Pardo
Return to the
Search the comp.compilers archives again.