Executor 2.0/executorv2.0.iso/pc/dos/extra/docs/maillist/text/archive.95/text7211.txt

Internet Message Format | 1996-03-31 | 7.8 KB

Received: from ftp.ardi.com (ftp.ardi.com [204.134.8.1]) by nacm.com (8.6.10/8.6.9) with SMTP id XAA25285 for <[e-mail]>; Sun, 26 Nov 1995 23:21:45 -0800
Received: from gwar.ardi.com by ftp.ardi.com with bsmtp
    (Smail3.1.29.1 #3) id m0tJxtE-0007q2C; Mon, 27 Nov 95 00:22 MST
Received: from beaut.ardi.com by gwar.ardi.com with smtp
    (Smail3.1.29.1 #3) id m0tJxn1-000GPkC; Mon, 27 Nov 95 00:15 MST
Received: by beaut.ardi.com (linux Smail3.1.29.1 #3)
    id m0tJxn0-00027CC; Mon, 27 Nov 95 00:15 MST
Message-Id: <[e-mail]>
Date: Mon, 27 Nov 95 00:15 MST
From: [e-mail] (Clifford T. Matthews)
To: David Danziger <[e-mail]>,
        [e-mail] (Juan Carlos Servat),
        =?iso-8859-1?Q?St=E9phane?= Rieppi <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: HyperCard under Executor
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Hi Folks,

Summary: Use Cmd-Shift-5 to check the "Flush Cache Often" check-box if
         you're having trouble with HyperCard under 1.99p6 and HyperCard will
         run better (but still not perfectly) under 1.99p7.

Below are three letters about HyperCard -- two people for whom
Executor crashed when HyperCard was run and one person who suggested
turning on "Flush Cache Often".  Assuming that Executor isn't memory
starved (executor -info should give a hint) or starved for file
descriptors (config.sys should have FILES=30 or more), then Executor
*should* mostly run HyperCard 2.1 and 2.2, at least with "Flush Cache
Often" turned on, as Stephane suggested.

Once HyperCard is running, it may be possible for you to turn "Flush
Cache Often" (FCO) back off and see a good speed improvement, although
there's no guarantee that doing so won't result in a sudden crash.  If
you're just browsing a stack and the crash won't result in loss of
data, it's worth trying.

BEGIN RIDICULOUSLY TECHNICAL EXPLANATION (but there's no *simple* explanation)

Executor is as fast as it is because it takes sets of motorola 68k
instructions and translates them into Intel x86 instructions.
Executor then remembers the translated instructions and uses them
whenever it is told to run the original, untranslated 68k
instructions.  This works very well until the memory that had the
original instructions is changed.  At that point, Executor needs to
know that the memory has been changed so it can throw away the
translated instructions that no longer match the now changed m68k
instructions.

*Luckily* the mc68040 has an instruction cache that is similar in
theory to what I just described, so whenver *any* program changes
memory that may contain instructions, the program needs to tell the
mc68040 to flush the cache.  We just watch for the cache flush
instruction and use that as a hint that we should check to see if any
of our translated code needs to be thrown away.

Internally there are cases where Executor itself needs to modify
memory that may contain instructions.  In this case, since Executor is
doing the modifications, we know exactly which ranges of memory might
need to be retranslated, so Executor can quickly examine the memory
that is being changed, rather than all of memory.

Here's the tricky part.  Some programs rely on the side effect that
some Operating System calls have that results in the cache being
flushed.  Since a total cache flush is so time consuming, Executor
normally does the limited range cache flushing when the cache flush is
an implicit flush and Executor knows exactly which locations have
changed.  But poorly written, or excessively tricky programs may count
on the entire cache being flushed, so we provide the Flush Cache Often
check-box so you can make Executor do the time consuming total cache
flushes.

Example: A program alters instructions at in the range 0x1200 to
0x1300.  Normally it would then need to explicitly tell the processor
to either flush things in that range or flush the entire cache, but
instead, since the program continues, knowing that before those
instructions are ever accessed again, a disk buffer will be read into
memory location 0x2500 to 0x2700, and even though these locations
don't intersect, the "tricky" program could count on (perhaps
inadvertantly) the disk read process flushing the entire cache.

Without FCO enabled, Executor will do the disk read, notice that
locations 0x2500 through 0x2700 have been modified, look to see if
there is any code in that memory range and discard remembered
translations that came from that range of memory.  However, the memory
locations between 0x1200 and 0x1300 have never been examined, so the
next time a subroutine at location 0x1200 is called, the old, outdated
translation is used rather than the new code.

With FCO enabled, when the disk read is done, Executor checks *all* of
the memory that might contain code and checks for any mismatches and
discards the mismatches it finds.  This is considerably slower and is
rarely needed.  Off the top of my head, Lemmings and occasionally
HyperCard are the only two apps that I know of that do this.

END RIDICULOUSLY TECHNICAL EXPLANATION

In other HyperCard news, as I was trying out HyperCard 2.2, I noticed
that the appointment book stack would cause Executor to die because it
used an unimplemented trap.  The traps that HyperCard 2.2 uses are all
part of Apple's Internationalization code which we won't support in
Executor 2.  However, I put in *enough* support so that particular
stack no longer crashes, but it still has a number of fairly obvious
problems associated with dates and times.  These mods will be in
1.99p7.

I can't estimate when 1.99p7 will be out because the holidays and our
new e-mail topology and the newsgroup gateway have had us tied up for
the last week and will continue to tie us up for a little longer.

--Cliff
[e-mail]


>>>>> "David" == David Danziger <[e-mail]> writes:

    David> I just tried to run a HyperCard Player 2.2 with E/D 1.99p6
    David> under Windows 95. Executor GPF'd, and gave me the error:
    David> General Protection Fault at eip=008f0327 eax=002fbdb0
    David> ebx=002c008b ecx=001f1a20 edx=009304a8 esi=20040036
    David> edi=008b2f3a ebp=001a9cd0 esp=001ed67c cs=00a7 ds=00b7
    David> es=00b7 fs=00e7 gs=00d7 ss=00b7 Call frame traceback EIPs:
    David> 0x008f0327 If anyone has a suggestion, please tell me.
    David> Thank you very much-

    David> C:\>David

>>>>> "Gonzalo" == Juan Carlos Servat <[e-mail]> writes:

    Gonzalo> Hello.. I got HyperCard and i'm trying to install it and
    Gonzalo> it wouldn't work..  it installed OK but it doesn't run!

    Gonzalo> Any ideas?

    Gonzalo> Regards, Gonzalo

>>>>> "Stephane" == Rieppi  <iso-8859-1> writes:

    Stephane> At 22:53 24/11/1995 +1100, Juan Carlos Servat wrote:
    >> Hello.. I got HyperCard and i'm trying to install it and it
    >> wouldn't work..  it installed OK but it doesn't run!
    >>
    >> Any ideas?
    >>
    >> Regards, Gonzalo
    >>
    Stephane> Try this: the Flush Cache Often switch in the control
    Stephane> panel (shift+alt+5) should be on (HC player runs quite
    Stephane> well on my 486DXII-80 with 8 megs and Executor/Dos
    Stephane> 1.99p6, even if it is sometimes slow).

    Stephane> BTW, Cliff, Mat & co, I know this switch must be
    Stephane> activated to run HC, but can you explain what it changes
    Stephane> actually? Is there a way to avoid this huge slowdown?

    Stephane> Cheers,

    Stephane> ------------------------------ Stephane Rieppi, Law
    Stephane> student, Universite de Liege, Belgique.
    Stephane> [e-mail] ------------------------------