Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucsdhub!celit!hutch
From: hutch@fps.com (Jim Hutchison)
Newsgroups: comp.arch
Subject: ABI and growth
Keywords: ABI expansion
Message-ID: <6186@celit.fps.com>
Date: 16 Jan 90 02:25:16 GMT
Sender: daemon@fps.com
Reply-To: hutch@fps.com (Jim Hutchison)
Organization: FPS Computing
Lines: 23

<>
When a "thing" gets off the drawing board and into practice, it seems
that there end up being one or two new features that people need almost
immediately (in days/weeks/months).  This is certainly understandable,
for the sake of simplicity we could call it growth.

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.  With many of
the vendors making "new" ABIs for there new feature, it would seem that the
purpose for the ABI will be lost.  So clearly that result would be bad.

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.  Also some fpa's need a setup call
to get themselves in order when the game starts, this could probably be done
in the "trap" handler presuming that it had a way to get the information it
needed.  It's a thought, what does anyone else think about this?

--
/*    Jim Hutchison   		{dcdwest,ucbvax}!ucsd!celerity!hutch  */
/*    Disclaimer:  I am not an official spokesman for FPS computing   */