From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=35053 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q2oz8-0001xq-B1
	for qemu-devel@nongnu.org; Thu, 24 Mar 2011 14:10:15 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1Q2oz7-0000m0-14
	for qemu-devel@nongnu.org; Thu, 24 Mar 2011 14:10:14 -0400
Received: from cantor.suse.de ([195.135.220.2]:38595 helo=mx1.suse.de)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1Q2oz6-0000lk-MT
	for qemu-devel@nongnu.org; Thu, 24 Mar 2011 14:10:12 -0400
References: <1300982333-12802-1-git-send-email-agraf@suse.de>
	<1300982333-12802-15-git-send-email-agraf@suse.de>
	<AANLkTi=6dGucz1sjwWLxVqY2JsO=SWd=E4_z6R-T1krS@mail.gmail.com>
	<4D8B8264.7090605@twiddle.net>
In-Reply-To: <4D8B8264.7090605@twiddle.net>
Mime-Version: 1.0 (iPhone Mail 8C148)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <58A09969-EF59-43B8-983C-68AE2A858871@suse.de>
From: Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH 14/17] s390x: Implement opcode helpers
Date: Thu, 24 Mar 2011 19:09:48 +0100
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Henderson <rth@twiddle.net>
Cc: Peter Maydell <peter.maydell@linaro.org>, QEMU-devel Developers <qemu-devel@nongnu.org>, Aurelien Jarno <aurelien@aurel32.net>


Am 24.03.2011 um 18:41 schrieb Richard Henderson <rth@twiddle.net>:

> On 03/24/2011 10:29 AM, Peter Maydell wrote:
>> On 24 March 2011 15:58, Alexander Graf <agraf@suse.de> wrote:
>>=20
>> This is more random comments in passing than a thorough review; sorry.
>>=20
>>> +#if HOST_LONG_BITS =3D=3D 64 && defined(__GNUC__)
>>> +        /* assuming 64-bit hosts have __uint128_t */
>>> +        __uint128_t dividend =3D (((__uint128_t)env->regs[r1]) << 64) |=

>>> +                               (env->regs[r1+1]);
>>> +        __uint128_t quotient =3D dividend / divisor;
>>> +        env->regs[r1+1] =3D quotient;
>>> +        __uint128_t remainder =3D dividend % divisor;
>>> +        env->regs[r1] =3D remainder;
>>> +#else
>>> +        /* 32-bit hosts would need special wrapper functionality - just=
 abort if
>>> +           we encounter such a case; it's very unlikely anyways. */
>>> +        cpu_abort(env, "128 -> 64/64 division not implemented\n");
>>> +#endif
>>=20
>> ...I'm still using a 32 bit system :-)
>=20
> A couple of options:
>=20
> (1) Steal code from gcc's __[u]divdi3 for implementing double-word divisio=
n via
>    single-word division.  In this case, your "single-word" will be long lo=
ng.
>=20
> (2) Implement a simple bit reduction loop.  This is probably easiest.
>=20
> (3) Reuse some of the softfloat code that manipulates 128bit quantities.  T=
his
>    is probably the best option, particularly if the availability of __uint=
128
>    is taught to softfloat so that it doesn't always open-code stuff that t=
he
>    compiler could take care of.

In all applications I've run so far this abort has _never_ fired. I'm not su=
re gcc even emits it.

So IMHO this abort doesn't hurt. Once we get a bug report of a user hitting i=
t, we can think of ways to implement the missing bits. For now, it's not wor=
se than a not implemented opcode (of which we still have quite a number).


Alex

>=20