[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ppc multlibs and BSP removal was Re: powerpc altivec support
- Date: 09 Feb 2005 19:27:10 +0300
- From: Sergei Organov <osv at topconrd dot ru>
- Subject: Re: ppc multlibs and BSP removal was Re: powerpc altivec support
Ralf Corsepius <email@example.com> writes:
> 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.
So the right solution is to eliminate both ;) I mean it, really.
Actually current powerpc port in RTEMS just misses the cpukit entirely,
-- almost everything is BSP-dependent, so any attempt to apply
cpukit-mulitilib idiom to this port will end up in a mess of huge amount
of variants, as you in fact end up building bspkit-multilib.
> As Joel and other clearly seem to favor the "new exception processing
IMHO, "old exception processing" is not very good w.r.t. to cpukit
separation, but the "new exception processing" is yet another step in
wrong direction, I believe, and it has in fact nothing to do with the
way exceptions are handled.
> I think the "old exception processing model" is condemned to die
> sooner or later ...
Well, even then I can keep it in my own CVS repository so please feel
free not to care about my preferences.
> > 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.
Well, disk space is cheap nowadays, but unfortunately shipping binaries
doesn't reduce overall system complexity and maintenance costs.
> Also it is not unlikely we will have to enforce multilibs in future
> (Not any time soon, but I won't exclude it).
I don't think that will be a problem for me. What I actually do is: I
build multilib gcc with only 2 variants (2 because I didn't find a way
to have 1 variant and still be "multilib"). This way, whatever RTEMS way
is, I'll end up with maximum 2 variants of RTEMS cpukits, as far as I