home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.96 / text0374.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  2.0 KB  |  45 lines
  1. >>>>> "Brian" == Brian Quinlan <quinlan@news.sfu.ca> writes:
  2. In article <4e65tt$4bq@morgoth.sfu.ca> quinlan@news.sfu.ca (Brian Quinlan) writes:
  3.  
  4.  
  5.     Brian> Clifford T. Matthews <ctm@ardi.com> writes:
  6.     >> In addition, Executor has to be aware of self-modifying code.
  7.     >> After all, if it memorizes that a particular set of m68k
  8.     >> instructions map into a set of x86 instructions, if the
  9.     >> original m68k instructions are changed then Executor needs to
  10.     >> throw away the mapped instructions and do another recompile.  I
  11.     >> don't know how MACCHESS 2.0 works, but if it dynamically builds
  12.     >> board evaluators and then jumps into them, then Executor's
  13.     >> performance will suffer for that.
  14.  
  15.     Brian> Why do you support instruction modification? The 040 and
  16.     Brian> PPC Macs won't always run programs which use instruction
  17.     Brian> modification due to their caches.
  18.  
  19. I wasn't clear.  On an '040 with both caches enabled, whenever new
  20. instructions are loaded into memory (including when a new program is
  21. loaded), the caches need to be flushed.  This is done either by
  22. directly accessing the cache control register or by calling one of a
  23. few different OS calls that Apple provides for this purpose.
  24.  
  25. Executor detects when the cache control register is modified or when
  26. these calls are made and then has to figure out which, if any,
  27. recompiled pieces of code need to be discarded.  This can be a
  28. substantial performance penalty.
  29.  
  30. Programs that properly flush the cache after they self-modify, or
  31. build code on the fly should work properly with '040s with the cache
  32. on and should work fine with Executor.  Programs that don't properly
  33. flush the cache may indeed break on '040s with the cache enabled and
  34. under Executor.
  35.  
  36. Again, I have no idea whether or not MACCHESS 2.0 actually creates
  37. code on the fly and jumps to it, but it is indeed a legitimate thing
  38. to do, as long as the program flushes the cache before making the
  39. jump.  If it *does* do that, then it would explain the major
  40. discrepancy between Speedometer numbers and MACCHESS 2.0.
  41.  
  42. --Cliff
  43. ctm@ardi.com
  44.  
  45.