|Request for more info on trampolines email@example.com (1993-07-07)|
|Re: Request for more info on trampolines firstname.lastname@example.org (1993-07-07)|
|Re: Request for more info on trampolines email@example.com (1993-07-08)|
|Re: Request for more info on trampolines firstname.lastname@example.org (1993-07-08)|
|Re: Request for more info on trampolines email@example.com (1993-07-09)|
|Re: Request for more info on trampolines firstname.lastname@example.org (1993-07-10)|
|Re: Request for more info on trampolines chased@rbbb.Eng.Sun.COM (1993-07-16)|
|Re: Request for more info on trampolines email@example.com (1993-07-18)|
|From:||firstname.lastname@example.org (John F Carr)|
|Keywords:||code, optimize, architecture|
|Organization:||Massachusetts Institute of Technology|
|Date:||Sun, 18 Jul 1993 10:24:14 GMT|
email@example.com (David Keppel) writes:
>For each system architecture, often there are techniques that allow
>creation of new code fragments, though modifying existing fragments may be
>slow. For example, you can generate code in to a buffer shared between I
>and D. The whole buffer is initially flushed from the I cache. When a
>fragment is written to the buffer it can be executed directly without
>cache flushing operations, since, by construction, a part of the buffer
>that has just been written is also uncached. Cache coherence is needed
>only when the buffer is exhausted and (code) space is reused.
This doesn't work on the RS/6000 models with split cache and write back
data cache. On these systems the I cache is reloaded from main memory,
but the newly generated code may only be valid in the data cache.
It happens that this is not a problem on the RS/6000 because the standard
calling sequence loads a context pointer, so instead of trapoline code a
runtime generated function pointer can be used. If you don't want to use
this software convention, the hardware has an unprivileged cache flush
instruction which invalidates a line in the I cache and stores back the
corresponding line in the D cache if it is dirty.
John Carr (firstname.lastname@example.org)
Return to the
Search the comp.compilers archives again.