Accessing memory is done primarily through load and store instructions.<\/p>\n
; load word or doubleword register\r\n ldr Rn\/zr, [...]\r\n\r\n ; load unsigned byte\r\n ldrb Wn\/zr, [...]\r\n\r\n ; load signed byte\r\n ldrsb Rn\/zr, [...]\r\n\r\n ; load unsigned halfword\r\n ldrh Wn\/zr, [...]\r\n\r\n ; load signed halfword\r\n ldrsh Rn\/zr, [...]\r\n\r\n ; load signed word\r\n ldrsw Xn\/zr, [...]\r\n\r\n ; load pair of registers\r\n ldp Rd1\/zr, Rd2\/zr, [...]\r\n\r\n ; load pair of registers as signed word\r\n ldpsw Xd1\/zr, Xd2\/zr, [...]\r\n<\/pre>\nAArch64 does not have AArch32’s
LDM<\/code> instruction for loading up to 13 registers at once. As a consolation present, it gives you aLDP<\/code> instruction for loading two registers, either 32-bit or 64-bit, from consecutive bytes of memory. (The first register uses the lower address.) TheLDP<\/code> instruction is commonly used with the 64-bit registers to load spilled registers from the stack.<\/p>\nThere is a corresponding selection of instructions for storing to memory, but obviously the sign extension variations are not relevant.<\/p>\n
; store word or doubleword register\r\n str Rn\/zr, [...]\r\n\r\n ; store byte\r\n strb Wn\/zr, [...]\r\n\r\n ; store halfword\r\n strh Wn\/zr, [...]\r\n\r\n ; store pair of registers\r\n stp Rd1\/zr, Rd2\/zr, [...]\r\n<\/pre>\nNot all addressing modes are available for all variations. This is not something you worry about when reading assembly language, but it’s something you need to keep in mind when writing it.<\/p>\n
\n\n
\n Size<\/th>\n [Xn\/sp, #imm]<\/code>
\n(\u2212256 \u2026 +255)<\/span><\/th>\n[Xn\/sp, #imm]<\/code>
\n[Xn\/sp, #imm]!<\/code>
\n[Xn\/sp], #imm<\/code><\/th>\n[pc, #imm]<\/code>
\n(\u00b11MB)<\/span><\/th>\n[Xn\/sp, Rn\/zr, extend]<\/code><\/th>\n<\/tr>\n\n byte<\/td>\n \u2022<\/td>\n \u2022<\/td>\n <\/td>\n \u2022<\/td>\n<\/tr>\n \n halfword<\/td>\n \u2022<\/td>\n \u2022<\/td>\n <\/td>\n \u2022<\/td>\n<\/tr>\n \n word<\/td>\n \u2022<\/td>\n \u2022<\/td>\n loads only<\/td>\n \u2022<\/td>\n<\/tr>\n \n doubleword<\/td>\n \u2022<\/td>\n \u2022<\/td>\n loads only<\/td>\n \u2022<\/td>\n<\/tr>\n \n pair<\/td>\n \u00a0<\/td>\n \u2022<\/td>\n <\/td>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The reach of the second column is is (0 \u2026 4095) \u00d7 size<\/var>, except that the reach of the the register pairs is (\u221264 \u2026 63) \u00d7 size<\/var>.<\/p>\n
All operand sizes support register indirect with offset. Only word and doubleword support pc<\/var>-relative (and even those are supported only for loads). And register pairs support only register indirect with offset.<\/p>\n
There are some ambiguous encodings, because a constant offset in the range 0 \u2026 255 that is a multiple of the operand size can be encoded either as a 9-bit signed byte offset, or as a 12-bit unsigned element offset. By default, assemblers will use the 12-bit unsigned element offset, but you can force the 9-bit signed byte offset by changing the opcode from
LDxxx<\/code> andSTxxx<\/code> toLDUxxx<\/code> andSTUxxx<\/code>. TheU<\/code> stands for unscaled<\/i>.<\/p>\nWindows enables automatic unaligned access fixups. Simple unaligned memory accesses are fixed up automatically by the processor, but you lose atomicity: It is possible for an unaligned memory access to read a torn value. Any such tearing is at the byte level.<\/p>\n
\n\n
\n Original value<\/td>\n 12<\/code><\/td>\n34<\/code><\/td>\n56<\/code><\/td>\n78<\/code><\/td>\naligned<\/td>\n<\/tr>\n \n \u00a0<\/td>\n<\/tr>\n \n Processor 1 reads<\/td>\n <\/td>\n \u00a0<\/td>\n \u00a0<\/td>\n <\/td>\n misaligned<\/td>\n<\/tr>\n \n \u00a0<\/td>\n<\/tr>\n \n Processor 2 writes<\/td>\n AB<\/code><\/td>\nCD<\/code><\/td>\nEF<\/code><\/td>\n01<\/code><\/td>\naligned<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The misaligned halfword read from processor 1 could produce
34|56<\/code>,34|EF<\/code>,CD|56<\/code>, orCD|EF<\/code>. But it won’t produce3D|EF<\/code>.<\/p>\nYou can still take alignment faults if the misaligned memory access is fancy, such as a locked load, store exclusive, or a load with a memory barrier. We’ll learn about these special memory accesses next time.<\/p>\n","protected":false},"excerpt":{"rendered":"
The load and store part of the load\/store architecture.<\/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":[2],"class_list":["post-106958","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-history"],"acf":[],"blog_post_summary":"
The load and store part of the load\/store architecture.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106958","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=106958"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106958\/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=106958"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=106958"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=106958"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}