Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!apple.com!desnoyer
From: desnoyer@apple.com (Peter Desnoyers)
Newsgroups: comp.arch
Subject: Re: ABI and growth
Message-ID: <6197@internal.Apple.COM>
Date: 16 Jan 90 17:18:50 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 30
References:<6186@celit.fps.com> <2020@crdos1.crd.ge.COM>

In article <2020@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E 
Davidsen Jr) writes:
> | So here is a thought I was toying with.  How about allowing for library calls
> | to trap and re-write there calls as the appropriate instruction?  I can see
> | some problems right away with handling shared pages neatly, and having space
> | and parameters to re-write the call with.  
> 

This sounds like a variation on run-time loading. I'm not sure of the 
specifics, but I believe some variation on {link in call to loader, load 
function on first call, patch stub to jump to loaded function} is used in 
OS/2, the Macintosh, and TOPS-20. The patching is easier in this case, 
however, as you are always patching the same run-time load stub instead of 
arbitrary code.

>   It could work if you have copy on write. Or maybe not, since the page
> will still be valid for all processes using it. I think this requires
> some careful though about doing stuff with the MMU and paging. The usual
> practice is to overwrite a code page rather than swap it, since it
> (usually) hasn't been modified. I suppose this wouldn't be a problem,
> since if a new, unmodified, copy came back in it would become a modified
> copy quickly.

If the code page is used infrequently enough that it gets swapped out, 
then whether or not the optimized version of the instruction gets used is 
a moot point.

                                      Peter Desnoyers
                                      Apple ATG
                                      (408) 974-4469