From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSnfY-0003l0-Bx for qemu-devel@nongnu.org; Sat, 04 Jun 2011 06:01:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSnfW-0003vQ-LU for qemu-devel@nongnu.org; Sat, 04 Jun 2011 06:01:24 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:62878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSnfW-0003vL-9m for qemu-devel@nongnu.org; Sat, 04 Jun 2011 06:01:22 -0400 Received: by pzk30 with SMTP id 30so1249743pzk.4 for ; Sat, 04 Jun 2011 03:01:20 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110603204722.GE14583@volta.aurel32.net> References: <1303311120-3424-1-git-send-email-peter.maydell@linaro.org> <20110603204722.GE14583@volta.aurel32.net> Date: Sat, 4 Jun 2011 11:01:20 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] target-arm: Move VLD/VST multiple into helper functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: qemu-devel@nongnu.org, patches@linaro.org On 3 June 2011 21:47, Aurelien Jarno wrote: > Does this patch fixes a real issue (ie most probably a crash), or it is > just to make the arm target compliant with the README? I haven't actually generated a test case which would make qemu abort, but it shouldn't be hard to do so. > Two remarks there: > - The guidance in tcg/README is probably true for complex helpers in the > =C2=A0sense of doing a lot of logic/arithmetic operations for which the T= CG > =C2=A0instruction set if not really rich and for which the compiler can d= o > =C2=A0a lot better. When the instruction is emulated mostly by load/store > =C2=A0ops, there isn't much possible optimizations left. Yes. The 96 op limit to avoid overrunning the buffer is a hard one, though. > - Your patch calls the slow version of the _mmu functions, which doesn't > =C2=A0use the QEMU TLB. It is therefore normal to expect a slow down. ...even for linux-user mode? That doesn't use softmmu... Anyway, this patch is on my list to rework when I can figure out what the right approach to it is. -- PMM