From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bA01X-0006gl-Av for qemu-devel@nongnu.org; Mon, 06 Jun 2016 15:17:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bA01R-0002Ca-9N for qemu-devel@nongnu.org; Mon, 06 Jun 2016 15:17:18 -0400 Received: from mail-qt0-x22c.google.com ([2607:f8b0:400d:c0d::22c]:32918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bA01R-0002CL-4G for qemu-devel@nongnu.org; Mon, 06 Jun 2016 15:17:13 -0400 Received: by mail-qt0-x22c.google.com with SMTP id 23so16248118qtq.0 for ; Mon, 06 Jun 2016 12:17:12 -0700 (PDT) Sender: Richard Henderson References: <1464898022-97990-1-git-send-email-rolnik@amazon.com> <1464898022-97990-8-git-send-email-rolnik@amazon.com> From: Richard Henderson Message-ID: Date: Mon, 6 Jun 2016 12:17:09 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 08/10] target-avr: adding instruction translation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Rolnik Cc: QEMU Developers , Michael Rolnik On 06/05/2016 11:52 PM, Michael Rolnik wrote: > truth table shows that these computations are different. You're not giving the right inputs to the truth table. > you can't look onto 4th bit because 4th bits in the input were not 0s. What did you think the xor's do? They remove the non-zero input bits. #include static int orig(int r, int d, int s) { return (((d & s) | (d & ~r) | (s & ~r)) & 2) != 0; } static int mine(int r, int d, int s) { return (((d ^ s) ^ r) & 4) != 0; } int main() { int s, d; for (s = 0; s < 8; ++s) for (d = 0; d < 8; ++d) { int r = d + s; int o = orig(r, d, s); int m = mine(r, d, s); if (o != m) printf("%2d = %d + %d (o=%d, m=%d)\n", r, d, s, o, m); } return 0; } This performs tests on 3-bit inputs, testing for carry-out on bit 1, just like Hf computes carry-out on bit 3. > Then you've got the order of the stores wrong. Your code pushes the LSB > before pushing the MSB, which results in the MSB at the lower address, > which means big-endian. > > this is right. However as far as I understand AVR is neither little nor big > endian because there it's 8 bit architecture (see > here http://www.avrfreaks.net/forum/endian-issue). for time being I defined the > platform to be little endian with ret address exception True, AVR is an 8-bit core, where endianness doesn't (normally) apply. And you are right that ADIW does treat the registers as little-endian. But the only multi-byte store to memory is in big-endian order. So why wouldn't you want to take advantage of that fact? > You have swapped the overflow conditions for INC and DEC. ... > this is how it's defined in the document. No, it isn't. Look again, you've swapped them. r~