Re: [Xenomai-core] RFC: 2.5 todo list.

[Philippe Gerum <rpm@xenomai.org>]

On Fri, 2009-10-02 at 21:59 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Fri, 2009-10-02 at 19:48 +0200, Gilles Chanteperdrix wrote:
> >> Philippe Gerum wrote:
> >>>> Ok. So, if we add the core skin fdtable, this leaves us with two items:
> >>>> - signals in primary domain
> >>>> - core skin fdtable
> >>>>
> >>> Ack. Add the following I-pipe stuff as well:
> >>>
> >>> - nios2 design upgrade. Those FPGA thingies require a bit of support to
> >>> be included into the soft-core in order to run a real-time system, like
> >>> a high precision timer and some stable monotonic clock source. Patrice
> >>> Kadionik (the guy who lives there: http://uuu.enseirb.fr/~kadionik/)
> >>> sent me an update for the FPGA design I used to do the initial port over
> >>> nios2. This is mostly a matter of a couple of hours to fix and validate
> >>> the I-pipe core accordingly, though.
> >> Maybe you could ask for a hardware implementation of mul64by64_high...
> > 
> > It looks like custom instructions are restricted to input(32bit x 2) =>
> > output(32bit).
> > 
> > Patrice, do you confirm, or would it be possible to implement such
> > instruction, that would return the highest 32 bits from a 64 x 64
> > multiply op? We need this to speed up some arithmetics, especially on a
> > 50Mhz CPU.
> 
> We want the highest 64 bits.

Yep, just noticed the glitch.

>  So, you need at least 4 registers. (4
> inputs, 2 outputs, but we may assume that the 2 outputs override 2
> inputs register).
> 
> > 
> > If we can't, well, I will likely have to subject myself to write a small
> > assembly block doing just this, because gcc's output is likely not going
> > to look like the way Gilles wants.
> 
> Well, maybe there is a way to modify the plain C version to generate
> better code by reducing the number of variables. But that is uncertain
> business. Anyway, I do not want anything, if you are happy with the
> plain C version, then by all means, keep it. You can measure the time
> that the whole thing takes using the unit test.
> 

Looking at the output of the arith unit test, gcc did not seem to be
that efficient producing code for llimd and friends, so I doubt we could
spare having nodiv_ullimd rewrote.

> > 
> >>> - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> >>> bits that prevent most alignment faults from triggering a secondary mode
> >>> switch. Andreas told me this works like a charm on 83xx, and I did not
> >>> see any issue on 52xx, 85xx or 86xx either.
> >>>
> >>> - probably blackfin updates. I need to have a closer look, but I'm
> >>> afraid I will have to resync with mainline before 2.5.0 is out. Blackfin
> >>> folks never sleep it seems.
> >>>
> >>> - x86* updates to issue patches for the 2.6.30-stable and 2.6.31-stable
> >>> series.
> >>>
> >>> You may have a few ARM patches brewing as well?
> >> Actually yes. The "pic mute" feature was disabled on AT91 because it was
> >> causing latency peaks, but I plan to enable it ultimately. I think the
> >> latency peaks were due to the fact that I was testing a 2.4 with the bug
> >> which we fixed in 2.4.9.1, I just need to check that. And if pic mute
> >> works on AT91, then I would implement it for other SOCs. And an upgrade
> >> to 2.6.31 would be fine too.
> >>
> > 
> > Ok. How many interrupt controllers would be impacted by the PIC mute
> > feature?
> 
> Most of the ARM PICs (with their cascaded GPIOs). I have to admit that I
> do not keep track of how many arm processors we actually support, but
> there's a handful. Or maybe two.
> 
> 
-- 
Philippe.