Mulhi operation bug

[Jacob Gersztyn]

If my understanding serves me correctly, mulhi is supposed to return the high order bits of a multiplication, the ones that wouldn't fit in the low order bits(overflow). It seems for values that would result in 1 in the high order, it displays something other than 1, such as 0xFFFFFFFE or 0xFFFFFFFF. I assume this is not on purpose, though I may be wrong. Has anyone else experienced this or understand why/how to fix it, if it needs it?

[Wira Mulia]

mulhi is a signed operation. The following is the implementation in the simulator:

case 0x11: return (((long)(int) a * (long)(int) b) & 0xffffffff00000000L) >> 32;

The sign of the operands in the ALU is treated pragmatically for most operations, i.e. we don't really care. But since mulhi is a signed operation, we need to sign extend the operands to 64-bit to make sure we get the correct signed answer (the ones you're getting).

The sign extension is done by typecasting the operand down to int primitive, and then up again so we can actually do a 32-bit signed multiply without the Java VM overflowing.

For testing, try the following two operations:

-> 0x40000000 and 0x4 should give you 0x1 in the mulhi destination register.

-> 0x80000000 and 0x2 should give you 0xFFFFFFFF because the first operand is sign extended to 0xFFFFFFFF80000000L

Of course there could also be a bug, we can check it out if you give us what your operands were.

On Mon, Jul 6, 2015 at 4:43 PM, Jacob Gersztyn <jab...@gmail.com> wrote:

If my understanding serves me correctly, mulhi is supposed to return the high order bits of a multiplication, the ones that wouldn't fit in the low order bits(overflow). It seems for values that would result in 1 in the high order, it displays something other than 1, such as 0xFFFFFFFE or 0xFFFFFFFF. I assume this is not on purpose, though I may be wrong. Has anyone else experienced this or understand why/how to fix it, if it needs it?

--
You received this message because you are subscribed to the Google Groups "progressive-learning-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to progressive-learning...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sohum Sohoni]

Thanks for the quick response.

[Jacob Gersztyn]

So this also means that mullo is signed and, since PLP uses two's complement for negative numbers, leading 1's will not change the value of a negative number.  So mulhi will return 0xFFFFFFFF for smaller negative numbers. I temporarily forgot about negatives.

As a side question, is there a reason you and the result with 0xFFFFFFFF00000000L before the shift? Is Java's shift wrapping?

To unsubscribe from this group and stop receiving emails from it, send an email to progressive-learning-platform+unsub...@googlegroups.com.

[Matthew Gaalswyk]

Shouldn't make a difference one way or the other with masking the multiplication with 0xFFFFFFFF00000000L. It just makes it more clear what part of the multiplication is retained for mulhi. Java's >> is a signed shift and will fill the higher order bits with the MSB of the left hand side. Java's >>> operator is unsigned and would fill the higher order bits of the result with zeroes, the lower order bits are discarded for both. There's another instruction that is implemented with >>> a couple lines up in SimCore.java

To unsubscribe from this group and stop receiving emails from it, send an email to progressive-learning...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "progressive-learning-platform" group.

To unsubscribe from this group and stop receiving emails from it, send an email to progressive-learning...@googlegroups.com.

[Karl]

On Monday, July 6, 2015 at 5:43:43 PM UTC-4, Jacob Gersztyn wrote:

If my understanding serves me correctly, mulhi is supposed to return the high order bits of a multiplication, the ones that wouldn't fit in the low order bits(overflow). It seems for values that would result in 1 in the high order, it displays something other than 1, such as 0xFFFFFFFE or 0xFFFFFFFF. I assume this is not on purpose, though I may be wrong. Has anyone else experienced this or understand why/how to fix it, if it needs it?

 Hi, Jacob:

I think it is confusing because it is only the hi half of the product.

These seem correct to me:
  0xFFFFFFFF  is  -1 for 0X80000000 * 0x2  (the same as << 2)  sign extended.
  0xFFFFFFFE  is -2  for 0X40000000 * 0x8  (the same as << 3)  sign extended.

[Karl]

On Monday, July 6, 2015 at 5:43:43 PM UTC-4, Jacob Gersztyn wrote:

If my understanding serves me correctly, mulhi is supposed to return the high order bits of a multiplication, the ones that wouldn't fit in the low order bits(overflow). It seems for values that would result in 1 in the high order, it displays something other than 1, such as 0xFFFFFFFE or 0xFFFFFFFF. I assume this is not on purpose, though I may be wrong. Has anyone else experienced this or understand why/how to fix it, if it needs it?

Sorry everyone,.

  0xFFFFFFFE  is -2  for 0X40000000 * 0x8  (the same as << 3)  sign extended. negative multiplicand

Is wrong, should be:

  0x00000002  is 2  for 0X40000000 * 0x8  (the same as << 3)  sign extended. positive multiplikcand