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 22.214.171.124, 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.
Xenomai-core mailing list