Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!tut!santra!kampi.hut.fi!jmunkki
From: jmunkki@kampi.hut.fi (Juri Munkki)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Tail patches
Message-ID: <26693@santra.UUCP>
Date: 15 Nov 89 09:58:43 GMT
References: <1459@sequent.cs.qmc.ac.uk> <36250@apple.Apple.COM> <5056@internal.Apple.COM> <1989Nov7.212837.5146@oracle.com> <26596@santra.UUCP> <5148@internal.Apple.COM>
Sender: news@santra.UUCP
Reply-To: jmunkki@kampi.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology, Finland
Lines: 92

In article <5148@internal.Apple.COM> chewy@apple.com (Paul Snively) writes:
>In article <26596@santra.UUCP> jmunkki@kampi.hut.fi (Juri Munkki) writes:
>> The best thing would of course be to change the way apple patches those
>> long routines, but since they have started doing something stupid, it is
>> very unlikely that they will ever stop.
>
>Momentum isn't the primary reason that we haven't changed the scheme; the 
>original rationale is.
>
>Larry Rosenstein has already explained that rationale in this forum quite 
>cogently; I suggest that you re-read some of the old messages in this 
>thread to find it.

Ok, so I re-read some of the old messages and found the article that
you seem refer to.

Larry Rosenstein wrote:
<Also, the whole idea of Apple's patches checking the return address is to
<determine where the *original* call came from.  The patch is intended to
<be activate only in one particular case, when it knows the state of the
<world and can fix the problem.
<
<Suppose there is a bug in the ROM.  The System S/W people find a trap call
<in the ROM that occurs before the bug manifests itself.  They install a
<patch that watches for this particular call and fixes up the state of the
<machine to correct the problem.  This might involve changing a register or
<changing some value on the stack.  (I've never tried fixing bugs in the
<ROM, so I'm guessing at the exact process.)
<
<The trap that's patches bears no relationship to the trap that contains
<the bug.  In fact, patches are likely to appear in frequently called
<routines (eg, Memory Manager routines, BlockMove, etc.), since they tend
<to be called in a lot of different places.
<
<The only way to avoid patches that look at the return address would be to
<replace entire pieces of the ROM.  This would make bug fixes take up more
<RAM space that they do now.

Paul Snively continues:
>In particular, I can think of some really evil compatibility problems that 
>your suggested fix could provoke; that's one reason that we aren't likely 
>to use it in the future.

Please tell us what the problems are so that we can work them out. I find
it very interesting that you find that you can just say "it can't be done"
without explaining yourself. Just because you work at Apple doesn't mean
that you are right just because you say so. Just because I say I'm right
doesn't mean I'm right, but you have to prove me wrong first!

The discussion on tail patching and come-from patching has always been
theoretical. I've never really believed that Apple would ever fix anything
that they have decided to break... So, let's say that everything I write
is just theoretical. That way no one will get offended, right?

If you want to get totally rid of come-from patching, you might consider
the following possibilities.

1) Suggestion:	Throw away the ROM. Just keep everything you patch in RAM.
   Pros:	RAM is cheap and you are already using a lot of it...
		Since there are no patches, you OS will run somewhat faster.
   Cons:	A lot of people will disagree and say that they can't afford it.
		(They'll say they don't have the disk or RAM space)

2) Suggestion:	Write a new set of ROMs so that long traps are split into
		smaller subroutines.
   Pros:	You no longer have to use come-from patching and your patches
		only have to replace short subroutines.
   Cons:	You will have to maintain a separate set of patches for every
		ROM version, but that's what you are already doing...sort of.
		(Take a look at FixMul on a Mac II: the come-from patch points
		to GetFontInfo, but GetFontInfo doesn't even contain a FixMul!)

3)  Suggestion:	Use the MMU to remap certain parts of the ROM to RAM.
    Pros:	You can effectively rewrite ROM!
    Cons:	Only 68020 or 68030 users can do this, which means that you
		can't do this and we shouldn't consider this even theoretically.

4)  Suggestion:	Rewrite the OS so that it doesn't contain bugs...
    Pros:	Great!
    Cons:	Ok, who wants to do it? (Who CAN do it?)

5)  Suggestion:	<<Insert ideas here>>

I'd really like comments on my previous article. The contents of that article
is slightly less theoretical than the above ideas. In that article I presented
a way that in my opinion would allow tail-patches and come-from patches to
co-exist.

_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
|     Juri Munkki jmunkki@hut.fi  jmunkki@fingate.bitnet        I Want   Ne   |
|     Helsinki University of Technology Computing Centre        My Own   XT   |
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^