{"id":322208,"date":"2021-04-27T21:00:24","date_gmt":"2021-04-27T21:00:24","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=322208"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=322208","title":{"rendered":"On commutativity of addition"},"content":{"rendered":"\n
Does an assembly change, if we write (b + a) instead (a + b)?
Let’s check out.<\/p>\n

Let’s write: <\/p>\n

__int128 add1(__int128 a, __int128 b) {     return b + a; }<\/code><\/pre>\n
  and compile it with risc-v gcc 8.2.0:
  <\/a>
  add1(__int128, __int128):
  .LFB0:
   .cfi_startproc
   add a0,a2,a0
   sltu a2,a0,a2
   add a1,a3,a1
   add a1,a2,a1
   ret<\/code><\/p>\n
  Now write the following:<\/p>\n
__int128 add1(__int128 a, __int128 b) {     return a + b; }<\/code><\/pre>\n
  And get:<\/p>\n
  add1(__int128, __int128):
  .LFB0:
   .cfi_startproc
   mv a5,a0
   add a0,a0,a2
   sltu a5,a0,a5
   add a1,a1,a3
   add a1,a5,a1
   ret
  <\/code>
  The difference is obvious.<\/p>\n
  Now do the same using clang (rv64gc trunk). In both cases we get the same result:
  add1(__int128, __int128): # @add1(__int128, __int128)
   add a1, a1, a3
   add a0, a0, a2
   sltu a2, a0, a2
   add a1, a1, a2
   ret<\/code>
  The result is the same we got from gcc in the first case. Compilers are smart now, but not so smart yet.<\/p>\n
  Let’s try to find out, what happened here and why. Arguments of a function __int128 add1(__int128 a, __int128 b) are passed through registers a0-a3 in the following order: a0 is a low word of \u00aba\u00bb operand, a1 is a high word of \u00aba\u00bb, a2 is a low word of \u00abb\u00bb and a1 is the high word of \u00abb\u00bb. The result is returned in the same order, with a low word in a0 and a high word in a1.<\/p>\n
  Then high words of two arguments are added and the result is located in a1, and for low words, the result is located in a0. Then the result is compared against a2, i.e. the low word of \u00abb\u00bb operand. It is necessary to find out if an overflow has happened at an adding operation. If an overflow has happened, the result is less than any of the operands. Because the operand in a0 does not exist now, the a2 register is used for comparison. If a0 < a2, the overflow has happened, and a2 is set to \u00ab1\u00bb, and to \u00ab0\u00bb otherwise. Then this bit is added to the hight word of the result. Now the result is located in (a1, a0).<\/p>\n
  Completely similar text is generated by Clang (rv32gc trunk) for the 32-bit core, if the function has 64-bit arguments and the result:<\/p>\n
long long add1(long long a, long long b) {     return a + b; }<\/code><\/pre>\n
  The assembler:
  add1(long long, long long): # @add1(long long, long long)
   add a1, a1, a3
   add a0, a0, a2
   sltu a2, a0, a2
   add a1, a1, a2
   ret<\/code>
  There is absolutely the same code. Unfortunately, a type __int128 is not supported by compilers for 32-bit architecture.<\/p>\n
  Here there is a slight possibility for the core microarchitecture optimization. Considering the RISC-V architecture standard, a microarchitecture can (but not has to) detect instruction pairs (MULH[[S]U] rdh, rs1, rs2; MUL rdl, rs1, rs2) and (DIV[U] rdq, rs1, rs2; REM[U] rdr, rs1, rs2) to process them as one instruction. Similarly, it is possible to detect the pair (add rdl, rs1, rs2; sltu rdh, rdl, rs1\/rs2) and immediately set the overflow bit in the rdh register.<\/p><\/div>\n
 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438  https:\/\/habr.com\/ru\/post\/554760\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"\n
Does an assembly change, if we write (b + a) instead (a + b)?
  Let’s check out.<\/p>\n
  Let’s write:  <\/p>\n
__int128 add1(__int128 a, __int128 b) {     return b + a; }<\/code><\/pre>\n
  and compile it with risc-v gcc 8.2.0:  <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-322208","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/322208","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=322208"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/322208\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=322208"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=322208"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=322208"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}