Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!aplcen!samsung!zaphod.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: comp.arch Subject: Re: ABI and growth Keywords: ABI expansion Message-ID: <2020@crdos1.crd.ge.COM> Date: 16 Jan 90 14:00:42 GMT References: <6186@celit.fps.com> Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen) Organization: GE Corp R&D Center, Schenectady NY Lines: 32 In article <6186@celit.fps.com> hutch@fps.com (Jim Hutchison) writes: | Now, here we have the ABI(s) and people already want them to grow to include | FPAs, Application Processors, and such. Sounds good. Unfortunately it seems | that to add these neat things, and it gets called a "new" ABI. That is the problem in a nutshell. | 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. 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. You would need to lock the page which writing it in a multi-CPU system, which might require a lot of MMU extensions. This is an old problem. The VAX gets around some of it by allowing "writable control store" (users defined microcode for certain instructions). A friend did a master's thesis based on implementing an FFT instruction in microcode. It was almost twice as fast as doing it with discrete instructions. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Stupidity, like virtue, is its own reward" -me