How is the sign flag calculated with the imul instruction?

7
votes

The documentation for imul states that:

SF is updated according to the most significant bit of the operand-size-truncated result in the destination.

For a 64-bit operation, then, my understanding is that SF = (a * b) >> 63, or more simply if a and b are signed, SF = a * b < 0.

However, I'm getting an unexpected result multiplying two large numbers:

mov rax, 0x9090909090909095
mov rdx, 0x4040404040404043
imul rax, rdx

The result of 0x9090909090909095 * 0x4040404040404043 is 0xefcba7835f3b16ff. It has the sign bit set, however the SF flag is cleared after the imul instruction. What's going on?

This was cross-posted to the Intel forums some time ago.

1
assemblyx86
I spy an error in that documentation: SF ← TMP_XP[32];, should be 31 obviously. What does Intel have to say about this instruction, by the way? – Jongware
@Jongware, that's true. I'll check if the most up-to-date Volume 2A still has that. This documentation was automatically extracted from the September 2014 version, so that's what Intel had to say about it at that time. – zneak
@Jongware, the most current version of Volume 2A still has that error. – zneak
@PeterCordes, I edited my answer to say that. Regarding the current state of the IMUL translation on my site, I'm working on it and will probably have something better to show in a few days. HJLebbink's conversion script is a fork of mine and shares some issues (the lists are broken, for instance; which is probably a step up from missing, but that type of mis-translation is the reason I'm working on a new version of it). Regarding being up-to-date, I can't find the December 2017 revision that this is apparently coming from; the most recent I can find is September 2016. – zneak
I'm acutely aware of a lot of problems with the latest update that I did and I believe that I can address a lot of them. If you want to talk about it, you can grab an email that I check by cloning the git repo for the project and checking git log. – zneak

1 Answers

5
votes

Other sources say that SF is undefined after imul. This most likely means that the result of SF is well-defined on newer processors, but older ones don't offer the feature. My computer being 5 years old, I probably fall with the second category.

EDIT: using Archive.org's Wayback Machine, I found that the documentation changed from stating that SF is undefined to SF is defined in the September 2014 revision. The previous revision, June 2014, still says that SF is undefined. This is documented in the accompanying Documentation Changes document, though the rationale for the change is not.

EDIT 2 My CPU is an i7 M 620. I had access to an even older Core2Duo P7550 and was able to confirm that imul doesn't set SF on it either.

EDIT 3 Starting from the September 2016 edition, IMUL says that SF is undefined, so this resolves the issue.