I-cache consistancy (WAS: Mixing virtual and real machine ...)

nickh@harlequin.co.uk (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
(ASPLOS-IV)
%D April 1991
%P 86-95


The implementation for a few machines is available via anonymous ftp:
`ftp.cs.washington.edu' (128.95.1.4) 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 comp.compilers page.
Search the comp.compilers archives again.