From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <490ABF6D.5090806@domain.hid> Date: Fri, 31 Oct 2008 09:18:53 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <49076E08.5060708@domain.hid> <49077D56.8040908@domain.hid> <49098653.7060709@domain.hid> In-Reply-To: <49098653.7060709@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD5894495DBA88403E68EBC61" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-core] llimd. List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Xenomai core This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD5894495DBA88403E68EBC61 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Hi Jan, >>> >>> I see that the implementation of rthal_llmulshft seems to account for= >>> the first argument sign. Does it work ? Namely, in the generic >>> implementation will __rthal_u96shift propagate the sign bit ? >> Yes, this works (given there is no overflow, of course). If you consid= er >> a high word of 0xfffffff0 and a (right) shift of 8, we effectively cut= >> off all the leading 1s: high << (32-8) =3D 0xf0000000. But this only w= orks >> because we replace a right shift with a left shift (plus some OR'ing >> later on). If we had to do a real right shift, we would also have to >> take signed vs. unsigned into account (ie. shift in zeros or the sign >> bit from the left?). >> >>> If yes, do you see a way llimd could be made to work the same way ? T= his >>> way we would avoid inline ullimd twice in llimd code. >> As the basic building block here is a multiplication, we cannot get >> around telling apart signed from unsigned (or converting signed into >> unsigned): the underlying multiplication logic is different. >> >> But what about this approach: >> >> static inline __attribute__((__const__)) long long >> __rthal_generic_llimd (long long op, unsigned m, unsigned d) >> { >> int signed =3D 0; >> long long ret; >> >> if (op < 0LL) { >> op =3D -op; >> signed =3D 1; >> } >> ret =3D __rthal_generic_ullimd(op, m, d); >> return signed ? -ret : ret; >> } >> >> However, I guess writing this in assembly for archs that suffer should= >> be more efficient. >=20 > Hi Jan, >=20 > You may have noticed that we played a bit with arithmetic operations > (namely, we use an llimd without division to make the reverse of > llmulshft), and it pays off on slow machines, such as ARM, where the > division is done in software. >=20 > At this chance, I looked at the code generated by this soluion, and I a= m > not sure that it is better: on ARM, and I suspect this is true on other= > architectures, the operations needed to negate a long long clobbers the= > code conditions, which means we can not make these operations > conditionals without a conditional jump, so the hand-coded assembler is= > not better than what the compiler does: it uses two conditional jumps > whereas the original solution uses only one. Of course we could set sig= n > to -1 or 1, and multiply by sign at the end, but the multiplication is > probably even heavier than conditional jump. Yes, on the archs that matter here (32-bit). >=20 > So, would you have any idea of a better solution ? In an assembly version, one could save 'sign' in form of a jump target that should be taken after __rthal_generic_ullimd (ie. jump to the negation, or jump over it). Specifically when that address is kept in a register, I think smart branch prediction units will be able to do the right forecast. Jan --------------enigD5894495DBA88403E68EBC61 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkKv3cACgkQniDOoMHTA+nKXQCfRz1T0hxRmCjjM0W+Ulu8R4j3 JIEAoILJHswDPbInfgswOAxdlj7g8cO+ =WWMS -----END PGP SIGNATURE----- --------------enigD5894495DBA88403E68EBC61--