[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ppc multlibs and BSP removal was Re: powerpc altivec support
On Wed, 2005-02-09 at 18:00 +0300, Sergei Organov wrote:
> "Joel Sherrill <joel@OARcorp.com>" <joel.sherrill@OARcorp.com> writes:
> > I think old exception process is now done to 4xx and a few 6xx BSPs. I
> > know of one old exception 6xx BSP which is in use and needs to be
> > updated. They have offered to do the conversion but that project has
> > been up to its eyeballs the past 6 months and has barely made
> > deadlines close enough to keep managment happy on required tasks. If
> > someone can mechanically update it to the new exception model, I will
> > be happy to merge that and kill the 6xx BSPs. I might even be willing
> > to consider killing all the old exception 6xx BSPs except that and
> > quit building it for a while.
> Well, I use old exception processing for my own MPC509, MPC56x, and
> MPC8270 BSPs. I don't in fact care about multilib variants provided
> old exception processing support code remains in the source tree.
Let me put that clear:
It's my goal to eliminate one of the exception processing variants
inside of the source-tree, but I don't actually care which one, because
the powerpc port in RTEMS is a maintenance nightmare.
As Joel and other clearly seem to favor the "new exception processing
model", I think the "old exception processing model" is condemned to die
sooner or later ...
> In general, I consider multilib support in RTEMS to be too much overhead
> for an end-user that probably has to deal with 1-2 processor variants
> total. For example, I use single-lib gcc for all the above processor
> variants, and 3 BSPs total.
Well, nothing prevents you from doing this, but "times-are-a-changing".
I expect us to start shipping binary cpukits for rtems-4.7, so end users
will not have to rebuild them. Also it is not unlikely we will have to
enforce multilibs in future (Not any time soon, but I won't exclude
> BTW, I'd wish to switch to *a new* exception processing, but
> unfortunately *the new* exception processing is a mess, -- just notice
> how much of similar code every BSP using it has. There are other weak
> points about this "new" exception processing that make it a step back
> for me even compared to the "old" one.
<sigh> I also can't deny having the impression the "new exception model"
not necessarily being superior to the "old exception model".
... Joel and others however do not seem to share this opinion, so I'll
further-on keep my face shut on this issue and leave sorting out this to
actual powerpc users :-)