From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <46681C38.2070504@domain.hid> Date: Thu, 07 Jun 2007 16:54:48 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <46649F7E.3060104@domain.hid> <46651F7D.9090702@domain.hid> <18021.58231.177931.286548@domain.hid> <46668CC3.8050002@domain.hid> <4666ACE5.7030200@domain.hid> <4666AFB3.6040602@domain.hid> <4666B4C7.6020308@domain.hid> <4666B716.6010909@domain.hid> <18022.64424.836736.431121@domain.hid> <46670109.7070408@domain.hid> <4667FF8E.2000207@domain.hid> <466801CD.8010909@domain.hid> <466810EC.3030707@domain.hid> <46681512.7060102@domain.hid> <466818F2.3010908@domain.hid> In-Reply-To: <466818F2.3010908@domain.hid> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] [PATCH-STACK] Updates, timerstats, rtdm-timers List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai-core Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > >>Jan Kiszka wrote: >> >>>Gilles Chanteperdrix wrote: >>> >>> >>>>Jan Kiszka wrote: >>>> >>>> >>>>>Jan Kiszka wrote: >>>>> >>>>> >>>>> >>>>>>Gilles Chanteperdrix wrote: >>>>>> >>>>>> >>>>>> >>>>>>>So, Ok, I will try to do something for x86 (either reduce the numbers of >>>>>>>registers used by the C code, or reduce the assembly to the bare >>>>>>>minimum). But, please, pick my generic implementation of llmulshft, it >>>>>>>was carefully written. >>>>>> >>>>>>Yes, it is the better choice for 32 bit archs (my previous tests didn't >>>>>>reflect the usage in Xenomai truely, redoing them made my generic >>>>>>version fall behind yours). Will include it. >>>>> >>>>>Done, see -v6. Then I added that two-liner for x86_64 rthal_llmulshft, >>>>>fixed the BITS_PER_LONG bug, and enabled generic-based support for ARM >>>>>(testing welcome!). >>>>> >>>>>At this chance: My series now also includes rthal_llimd for x86_64, >>>>>another two-liner. >>>> >>>>v6 is not in the download area. >>>> >>> >>>Mpf, forgot to press "update". Done. >> >>Ok, I agree with the fast-tsc-to-ns patch: I could not get gcc to >>generate code with less moves on x86 (which is, for me, if it was still >>needed, yet another proof that these register moves are harmless). > > > No question -- from the average performance POV. > > >>However, I do not agree with the x86_64 llimd: it will not work if m is >>greater than 2G, that is why we implement llimd in terms of ullimd on >>other architectures. >> > > > Please help me, I don't see it yet: > > m is 32 bit and gets extended to 64 bit without considering any sign (as > it should be). Then we multiply 64x64 bit signed, but we know for sure > that the second multiplier is always positive. Same for division. Basic > tests ((-1*1000000000)/2 vs. (-1*3000000000)/2) confirmed this on the > target. No, you are right. It works. -- Gilles Chanteperdrix