home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.95 / text2457.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  6.6 KB  |  146 lines
  1. Hi Folks,
  2.  
  3. Summary: Use Cmd-Shift-5 to check the "Flush Cache Often" check-box if
  4.          you're having trouble with HyperCard under 1.99p6 and HyperCard will
  5.          run better (but still not perfectly) under 1.99p7.
  6.  
  7. Below are three letters about HyperCard -- two people for whom
  8. Executor crashed when HyperCard was run and one person who suggested
  9. turning on "Flush Cache Often".  Assuming that Executor isn't memory
  10. starved (executor -info should give a hint) or starved for file
  11. descriptors (config.sys should have FILES=30 or more), then Executor
  12. *should* mostly run HyperCard 2.1 and 2.2, at least with "Flush Cache
  13. Often" turned on, as Stephane suggested.
  14.  
  15. Once HyperCard is running, it may be possible for you to turn "Flush
  16. Cache Often" (FCO) back off and see a good speed improvement, although
  17. there's no guarantee that doing so won't result in a sudden crash.  If
  18. you're just browsing a stack and the crash won't result in loss of
  19. data, it's worth trying.
  20.  
  21. BEGIN RIDICULOUSLY TECHNICAL EXPLANATION (but there's no *simple* explanation)
  22.  
  23. Executor is as fast as it is because it takes sets of motorola 68k
  24. instructions and translates them into Intel x86 instructions.
  25. Executor then remembers the translated instructions and uses them
  26. whenever it is told to run the original, untranslated 68k
  27. instructions.  This works very well until the memory that had the
  28. original instructions is changed.  At that point, Executor needs to
  29. know that the memory has been changed so it can throw away the
  30. translated instructions that no longer match the now changed m68k
  31. instructions.
  32.  
  33. *Luckily* the mc68040 has an instruction cache that is similar in
  34. theory to what I just described, so whenver *any* program changes
  35. memory that may contain instructions, the program needs to tell the
  36. mc68040 to flush the cache.  We just watch for the cache flush
  37. instruction and use that as a hint that we should check to see if any
  38. of our translated code needs to be thrown away.
  39.  
  40. Internally there are cases where Executor itself needs to modify
  41. memory that may contain instructions.  In this case, since Executor is
  42. doing the modifications, we know exactly which ranges of memory might
  43. need to be retranslated, so Executor can quickly examine the memory
  44. that is being changed, rather than all of memory.
  45.  
  46. Here's the tricky part.  Some programs rely on the side effect that
  47. some Operating System calls have that results in the cache being
  48. flushed.  Since a total cache flush is so time consuming, Executor
  49. normally does the limited range cache flushing when the cache flush is
  50. an implicit flush and Executor knows exactly which locations have
  51. changed.  But poorly written, or excessively tricky programs may count
  52. on the entire cache being flushed, so we provide the Flush Cache Often
  53. check-box so you can make Executor do the time consuming total cache
  54. flushes.
  55.  
  56. Example: A program alters instructions at in the range 0x1200 to
  57. 0x1300.  Normally it would then need to explicitly tell the processor
  58. to either flush things in that range or flush the entire cache, but
  59. instead, since the program continues, knowing that before those
  60. instructions are ever accessed again, a disk buffer will be read into
  61. memory location 0x2500 to 0x2700, and even though these locations
  62. don't intersect, the "tricky" program could count on (perhaps
  63. inadvertantly) the disk read process flushing the entire cache.
  64.  
  65. Without FCO enabled, Executor will do the disk read, notice that
  66. locations 0x2500 through 0x2700 have been modified, look to see if
  67. there is any code in that memory range and discard remembered
  68. translations that came from that range of memory.  However, the memory
  69. locations between 0x1200 and 0x1300 have never been examined, so the
  70. next time a subroutine at location 0x1200 is called, the old, outdated
  71. translation is used rather than the new code.
  72.  
  73. With FCO enabled, when the disk read is done, Executor checks *all* of
  74. the memory that might contain code and checks for any mismatches and
  75. discards the mismatches it finds.  This is considerably slower and is
  76. rarely needed.  Off the top of my head, Lemmings and occasionally
  77. HyperCard are the only two apps that I know of that do this.
  78.  
  79. END RIDICULOUSLY TECHNICAL EXPLANATION
  80.  
  81. In other HyperCard news, as I was trying out HyperCard 2.2, I noticed
  82. that the appointment book stack would cause Executor to die because it
  83. used an unimplemented trap.  The traps that HyperCard 2.2 uses are all
  84. part of Apple's Internationalization code which we won't support in
  85. Executor 2.  However, I put in *enough* support so that particular
  86. stack no longer crashes, but it still has a number of fairly obvious
  87. problems associated with dates and times.  These mods will be in
  88. 1.99p7.
  89.  
  90. I can't estimate when 1.99p7 will be out because the holidays and our
  91. new e-mail topology and the newsgroup gateway have had us tied up for
  92. the last week and will continue to tie us up for a little longer.
  93.  
  94. --Cliff
  95. ctm@ardi.com
  96.  
  97.  
  98. >>>>> "David" == David Danziger <danziger@chelsea.ios.com> writes:
  99.  
  100.     David> I just tried to run a HyperCard Player 2.2 with E/D 1.99p6
  101.     David> under Windows 95. Executor GPF'd, and gave me the error:
  102.     David> General Protection Fault at eip=008f0327 eax=002fbdb0
  103.     David> ebx=002c008b ecx=001f1a20 edx=009304a8 esi=20040036
  104.     David> edi=008b2f3a ebp=001a9cd0 esp=001ed67c cs=00a7 ds=00b7
  105.     David> es=00b7 fs=00e7 gs=00d7 ss=00b7 Call frame traceback EIPs:
  106.     David> 0x008f0327 If anyone has a suggestion, please tell me.
  107.     David> Thank you very much-
  108.  
  109.     David> C:\>David
  110.  
  111. >>>>> "Gonzalo" == Juan Carlos Servat <jservat@ozemail.com.au> writes:
  112.  
  113.     Gonzalo> Hello.. I got HyperCard and i'm trying to install it and
  114.     Gonzalo> it wouldn't work..  it installed OK but it doesn't run!
  115.  
  116.     Gonzalo> Any ideas?
  117.  
  118.     Gonzalo> Regards, Gonzalo
  119.  
  120. >>>>> "Stephane" == Rieppi  <iso-8859-1> writes:
  121.  
  122.     Stephane> At 22:53 24/11/1995 +1100, Juan Carlos Servat wrote:
  123.     >> Hello.. I got HyperCard and i'm trying to install it and it
  124.     >> wouldn't work..  it installed OK but it doesn't run!
  125.     >> 
  126.     >> Any ideas?
  127.     >> 
  128.     >> Regards, Gonzalo
  129.     >> 
  130.     Stephane> Try this: the Flush Cache Often switch in the control
  131.     Stephane> panel (shift+alt+5) should be on (HC player runs quite
  132.     Stephane> well on my 486DXII-80 with 8 megs and Executor/Dos
  133.     Stephane> 1.99p6, even if it is sometimes slow).
  134.  
  135.     Stephane> BTW, Cliff, Mat & co, I know this switch must be
  136.     Stephane> activated to run HC, but can you explain what it changes
  137.     Stephane> actually? Is there a way to avoid this huge slowdown?
  138.  
  139.     Stephane> Cheers,
  140.  
  141.     Stephane> ------------------------------ Stephane Rieppi, Law
  142.     Stephane> student, Universite de Liege, Belgique.
  143.     Stephane> s940348@student.ulg.ac.be ------------------------------
  144.  
  145.  
  146.