Path: utzoo!mnetor!uunet!husc6!rutgers!mtunx!lzaz!lznv!jlw
From: jlw@lznv.ATT.COM (j.l.wood)
Newsgroups: comp.arch
Subject: Re: hard data on Motorola 88000
Message-ID: <1370@lznv.ATT.COM>
Date: 24 Apr 88 13:35:27 GMT
References: <9916@tekecs.TEK.COM> <833@mcdsun.UUCP>
Organization: AT&T ISL Middletown NJ USA
Lines: 30

In article <833@mcdsun.UUCP>, fnf@mcdsun.UUCP (Fred Fish) writes:
> In article <9916@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes:
> >The announcement is today, so I guess it's okay to talk hard data on
> >the Motorola 88000 architecture.
> 
> 
> I hope you have found this little example interesting.  I should note
> that the general idea of having the linker synthesize necessary instruction
> streams to hide the 16-bit literal constant problem was first proposed to
> me by a long time Motorolan architecture expert, Bob Greiner.
> 

Delaying the decision making this long looks like an interesting approach to
the problem.  This would, however, have consequences in two types of routines
used in, for example, UNIX SVR3.1.  They are the shared library and the loadable
device drivers.  The loadable device drivers could be fixed by using the same
methodology for fixing things up via the loader as the linker uses.  This
shouldn't slow up things too much except for rebooting which hopefully is
a rare uccurrence.  For the shared libraries, unless another register can
be "understood" to be pointing somewhere for them I don't see how they
could have any a priori knowledge of which register's pointing where.
The whole idea of reserving registers for this purpose is to avoid having
to be continuingly have to be munging registers. Ie. they'd be set on
a load module basis, but if the register fixing up were to be placed in
a special (csav/cret) pair for shared libraries then you lose a large part
of that savings.


Joe Wood
lznv!jlw