Re: [Qemu-devel] [PATCH 08/10] target-avr: adding instruction translation

[Richard Henderson]

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 <stdio.h>

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~