From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LHrTX-00013G-GV for qemu-devel@nongnu.org; Tue, 30 Dec 2008 22:10:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LHrTV-00012n-UW for qemu-devel@nongnu.org; Tue, 30 Dec 2008 22:10:27 -0500 Received: from [199.232.76.173] (port=46186 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LHrTV-00012k-Qj for qemu-devel@nongnu.org; Tue, 30 Dec 2008 22:10:25 -0500 Received: from mx20.gnu.org ([199.232.41.8]:31178) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LHrTV-0004bb-LC for qemu-devel@nongnu.org; Tue, 30 Dec 2008 22:10:25 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LHrTU-0006Td-6R for qemu-devel@nongnu.org; Tue, 30 Dec 2008 22:10:24 -0500 From: Nathan Froyd Date: Tue, 30 Dec 2008 19:09:42 -0800 Message-Id: <1230693022-18380-1-git-send-email-froydnj@codesourcery.com> Subject: [Qemu-devel] [PATCH] target-ppc: add integer Altivec instructions, take 2 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is a follow-on to: http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg01000.html as Aurelien asked me to modify the notation for defining instructions in target-ppc/translate.c. Since that change touched nearly every patch in the series, I figured I would also take the opportunity to eliminate the VECTOR_FOR macros that my patch used as well. I also fixed up various TCG errors that turned up under DEBUG_TCG. I did, however, leave the VECTOR_FOR_INORDER_I macros in place; I think they are the clearest way to indicate that vectors are being iterated over in target-endian order. Better than `#if defined(WORDS_BIGENDIAN)' all over the code, IMHO. As the message in: http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg01106.html indicated, m{f,t}vscr seems to be broken in some way; the code looks correct to me, but I can't seem to puzzle out what's wrong with it. All other instructions have been tested against an Altivec hardware implementation. Except for the VSCR issue above, the simulated instructions perform identically to their hardware-implemented versions. -Nathan