Storing a byte and word requires a series of three operations: Read the original data, modify the original data to incorporate the byte or word, then write the modified data back to memory. <\/p>\n
To assist with the modification are two groups of instructions known as insertion and masking. <\/p>\n
\n INSBL Ra, Rb\/#b, Rc ; Rc = (uint8_t)Ra << (Rb\/#b * 8 % 64)\n INSWL Ra, Rb\/#b, Rc ; Rc = (uint16_t)Ra << (Rb\/#b * 8 % 64)\n INSLL Ra, Rb\/#b, Rc ; Rc = (uint32_t)Ra << (Rb\/#b * 8 % 64)\n INSQL Ra, Rb\/#b, Rc ; Rc = (uint64_t)Ra << (Rb\/#b * 8 % 64)\n\n INSWH Ra, Rb\/#b, Rc ; Rc = (uint16_t)Ra >> ((64 - Rb\/#b * 8) % 64)\n INSLH Ra, Rb\/#b, Rc ; Rc = (uint32_t)Ra >> ((64 - Rb\/#b * 8) % 64)\n INSQH Ra, Rb\/#b, Rc ; Rc = (uint64_t)Ra >> ((64 - Rb\/#b * 8) % 64)\n<\/pre>\nThese are the inverse of the extraction instructions. Instead of extracting data from a 128-bit value, they move the data into position within a 128-bit value. For example, here’s a diagram of inserting the long
FGHI<\/code> into a 128-bit value: <\/p>\n\n high part low part\n --------- ---------\n 0000 0FGH -- INSLH\n I000 0000 -- INSLL\n<\/pre>\nThe last piece of the puzzle is the masking instructions. <\/p>\n
\n MSKBL Ra, Rb\/#b, Rc ; Rc = Ra & ~( (uint8_t)~0 << (Rb\/#b * 8 % 64))\n MSKWL Ra, Rb\/#b, Rc ; Rc = Ra & ~((uint16_t)~0 << (Rb\/#b * 8 % 64))\n MSKWL Ra, Rb\/#b, Rc ; Rc = Ra & ~((uint32_t)~0 << (Rb\/#b * 8 % 64))\n MSKWL Ra, Rb\/#b, Rc ; Rc = Ra & ~((uint64_t)~0 << (Rb\/#b * 8 % 64))\n\n MSKWH Ra, Rb\/#b, Rc ; Rc = Ra & ~((uint16_t)~0 >> ((64 - Rb\/#b * 8) % 64))\n MSKWH Ra, Rb\/#b, Rc ; Rc = Ra & ~((uint32_t)~0 >> ((64 - Rb\/#b * 8) % 64))\n MSKWH Ra, Rb\/#b, Rc ; Rc = Ra & ~((uint64_t)~0 >> ((64 - Rb\/#b * 8) % 64))\n<\/pre>\nThese instructions zero out the bytes of a 128-bit value that are about to be replaced by an insertion. <\/p>\n
For example, here’s how the masking of a long would work: <\/p>\n
\n high part low part\n --------- ---------\n ABCD EFGH IJKL MNOP -- 16-byte value\n ^^^ ^ -- 4 bytes to be inserted here\n ABCD E000 -- MSKLH\n 0JKL MNOP -- MSKLL\n<\/pre>\nPutting the pieces together, we see that in order to replace a long in the middle of a 128-bit value, you would use the insertion instructions to place the new value in the correct position, the masking instructions to zero out the bits that used to be there, and then “or” the pieces together. <\/p>\n
\n ; store an unaligned long in t1 to (t0)\n ; first read the 128-bit value currently in memory\n LDQ_U t2,3(t0) ; t2 = yyyy yyyD\n LDQ_U t5,(t0) ; t5 = CBAx xxxx\n\n ; build the values to insert\n INSLH t1,t0,t4 ; t4 = 0000 000d\n INSLL t1,t0,t3 ; t3 = cba0 0000\n\n ; mask out the values to be replaced\n MSKLH t2,t0,t2 ; t2 = yyyy yyy0\n MSKLL t5,t0,t5 ; t5 = 000x xxxx\n\n ; \"or\" the new values into place\n BIS t2,t4,t2 ; t2 = yyyy yyyd\n BIS t5,t3,t5 ; t5 = cbax xxxx\n\n ; and write the results back out\n STQ_U t2,3(t0) ; must store high then low\n STQ_U t5,(t0) ; in case there was no straddling\n<\/pre>\nExtending this pattern to quads and words is left as an exercise. <\/p>\n
Notice that in the case where t0<\/var> does not straddle two quads, we perform two reads from the same location, and two writes to the same location. Let’s walk through what happens: <\/p>\n
\n ; first read the 128-bit value currently in memory\n ; (which is really the same 64-bit value twice)\n LDQ_U t2,3(t0) ; t2 = yyDC BAxx\n LDQ_U t5,(t0) ; t5 = yyDC BAxx\n\n ; build the values to insert\n INSLH t1,t0,t4 ; t4 = 00dc ba00\n INSLL t1,t0,t3 ; t3 = 0000 0000\n\n ; mask out the values to be replaced\n MSKLH t2,t0,t2 ; t2 = yy00 00xx\n MSKLL t5,t0,t5 ; t5 = yyDC BAxx\n\n ; \"or\" the new values into place\n BIS t2,t4,t2 ; t2 = yydc baxx\n BIS t5,t3,t5 ; t5 = yyDC BAxx\n\n ; and write the results back out\n STQ_U t2,3(t0) ; write same value back\n STQ_U t5,(t0) ; write updated value\n<\/pre>\nThis highlights some of the weird memory effects of the Alpha AXP. If another thread snuck in and modified the memory at t0 & ~7<\/var>, those changes would be reverted at the first
STQ_U<\/code>, and then the updated value gets written next. This means that the value changes fromyyyyDCBAxx<\/code> tozzzzDCBAww<\/code>, and then back toyyyyDCBAxx<\/code>, and then finally toyyyydcbaxx<\/code>. The value changes, and then appears to change back to the old value, before finally being updated to a new (sort-of) value. <\/p>\nWe’ll learn more about the Alpha AXP memory model later. <\/p>\n
In the case where you are writing a word and you know that it is aligned, then you can avoid having to deal with the 128-bit value and operate within a 64-bit value (because an aligned word will never straddle two quads). <\/p>\n
\n ; store an aligned word in t1 to (t0)\n ; first read the 64-bit value currently in memory\n LDQ_U t5,(t0) t5 = yyBA xxxx\n\n ; build the value to insert\n INSWL t1,t0,t3 t3 = 00ba 0000\n\n ; mask out the values to be replaced\n MSKWL t5,t0,t5 t5 = yy00 xxxx\n\n ; \"or\" the new values into place\n BIS t5,t3,t5 t5 = yyba xxxx\n\n ; and write the results back out\n STQ_U t5,(t0)\n<\/pre>\nOkay, but what about bytes? Well, bytes can never be misaligned, so we always go through the “known aligned” shortcut. <\/p>\n
\n ; store a byte in t1 to (t0)\n ; first read the 64-bit value currently in memory\n LDQ_U t5,(t0) t5 = yyyA xxxx\n\n ; build the value to insert\n INSBL t1,t0,t3 t3 = 000a 0000\n\n ; mask out the values to be replaced\n MSKBL t5,t0,t5 t5 = yyy0 xxxx\n\n ; \"or\" the new values into place\n BIS t5,t3,t5 t5 = yyya xxxx\n\n ; and write the results back out\n STQ_U t5,(t0)\n<\/pre>\nDealing with unaligned memory on the Alpha AXP is very annoying. Notice that updates to words and bytes, even aligned words, is not atomic. We read the entire quad from memory, perform some register calculations, and then write the entire quad back out. If somebody made a change to another byte within the quad, we will wipe out that change when we complete our word or byte update. <\/p>\n
Next time, we’ll look at atomic memory operations. <\/p>\n
Bonus chatter<\/b>: There is one more pair of instructions which operate on the bytes within a register:
ZAP<\/code> andZAPNOT<\/code>. <\/p>\n\n ZAP Ra, Rb\/#b, Rc ; Rc = Ra after zeroing the bytes selected by Rb\/#b\n ZAPNOT Ra, Rb\/#b, Rc ; Rc = Ra after zeroing the bytes selected by ~Rb\/#b\n<\/pre>\nThe
ZAP<\/code> andZAPNOT<\/code> instructions treat the low-order 8 bits of the second parameter as references to the corresponding bytes of the Ra<\/var> register: Bit n<\/var> of Rb<\/var>\/#b corresponds to bits N<\/var> × 8 through N<\/var> × 8 + 7. TheZAP<\/code> instruction sets the byte to zero if the corresponding bit is set; theZAPNOT<\/code> instruction sets the byte to zero if the corresponding bit is clear. The other 56 bits of the second parameter are ignored. <\/p>\nFor example,
ZAP v0, #128, v0<\/code> clears the top byte of v0<\/var>, andZAPNOT v0, #128, v0<\/code> clears all but the top byte of v0<\/var>. (For some reason, I had trouble remembering which way is which. My trick was to pretend that theZAPNOT<\/code> instruction is calledKEEP<\/code>.) <\/p>\nAs a special case, these instructions provide a handy way to zero-extend a register. <\/p>\n
\n ZAPNOT Ra, #1, Rc ; zero-extend byte from Ra to Rc\n ZAPNOT Ra, #3, Rc ; zero-extend word from Ra to Rc\n ZAPNOT Ra, #15, Rc ; zero-extend long from Ra to Rc\n<\/pre>\nNote that in the last case, zero-extending a negative long will result in a 32-bit value in non-canonical form. But you hopefully were expecting that; if you want to sign-extend the value (in order to ensure a value in canonical form), you would have done
ADDL Ra, #0, Rc<\/code>. <\/p>\n","protected":false},"excerpt":{"rendered":"Those little pieces.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-96825","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Those little pieces.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/96825","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=96825"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/96825\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=96825"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=96825"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=96825"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}