[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ppc multlibs and BSP removal was Re: powerpc altivec support
- Date: 14 Feb 2005 13:39:57 +0300
- From: Sergei Organov <osv at topconrd dot ru>
- Subject: Re: ppc multlibs and BSP removal was Re: powerpc altivec support
Eric Valette <firstname.lastname@example.org> writes:
> > As for the r2/r13 loading by the new exception processing code, sorry,
> > but I leave it as an exercise for those who believe new exception
> > processing is better than the old one.
> I still do and still believe you don't get it but anyway as you only use one
> platform, you cannot see how old execption code is broken...
I use 3 platforms, MPC509, MPC565, and MPC8260, quite happily with the
old exception processing code. What is broken is the new exception
processing due to its silly design choices. The main problem about it is
> > Let them change at least 5 separate files with almost identical
> > code. Well, if somebody believes something is inherently broken with
> > such an approach to the software development, ask Eric Valette about
> > it, or just read what he answered to a similar question before:
> > <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/msg00167.html>
> > If you use new exception processing, better make sure no code in your
> > executable tries to change r2/r13 even temporarily while interrupts are
> > enabled. I prefer to be on the safe side, so I stay with the old one for
> > now.
> Yes. At least you eat your own dog food. That's fair. Try to implement a
> debugger with old execption processing or separate execption handling
> (processor dependend) and IRQ handling (BSP dependend) as an exercice.
If *you* need an exercise, take a look at how it's done elsewhere. If
you don't find a good example in RTEMS, take a look at another free
RTOS. Believe me, you are not the first programmer on the Earth trying
to solve these problems. What I see is that your reinvented wheel is
somewhat rectangular, sorry.