From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philippe Gerum In-Reply-To: <4AC65B9C.4010303@domain.hid> References: <4AC2448B.1080500@domain.hid> <1254396765.2703.234.camel@domain.hid> <4AC62883.1080908@domain.hid> <1254505304.2703.347.camel@domain.hid> <4AC63CF0.7090001@domain.hid> <1254511088.2703.367.camel@domain.hid> <4AC65B9C.4010303@domain.hid> Content-Type: text/plain Date: Fri, 02 Oct 2009 22:09:51 +0200 Message-Id: <1254514191.2703.381.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] RFC: 2.5 todo list. List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Patrice Kadionik , Xenomai core 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.