{"id":105324,"date":"2021-06-18T07:00:00","date_gmt":"2021-06-18T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=105324"},"modified":"2021-06-18T07:39:32","modified_gmt":"2021-06-18T14:39:32","slug":"20210618-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20210618-00\/?p=105324","title":{"rendered":"The ARM processor (Thumb-2), part 15: Miscellaneous instructions"},"content":{"rendered":"

There are far more ARM instructions than I’m going to cover here. I’ve skipped over the floating point instructions, the SIMD instructions, and some other specialty instructions that I haven’t yet seen come out of the compiler.<\/p>\n

Here are a few that are still interesting, even if I haven’t seen the compiler generate them.<\/p>\n

    ; count leading zeroes (high order bits)\r\n    clz     Rd, Rm          ; Rd = number of leading zeroes in Rm\r\n\r\n    ; reverse bits\r\n    rbit    Rd, Rm          ; Rd = Rm bitwise reversed\r\n\r\n    ; reverse bytes\r\n    rev     Rd, Rm          ; Rd = Rm bytewise reversed\r\n\r\n    ; reverse bytes in each halfword\r\n    rev16   Rd, Rm          ; Rd[31:24] = Rm[23:16]\r\n                            ; Rd[23:16] = Rm[31:24]\r\n                            ; Rd[15: 8] = Rm[ 7: 0]\r\n                            ; Rd[ 7: 0] = Rm[15: 8]\r\n\r\n    ; reverse bytes in lower halfword and sign extend\r\n    revsh   Rd, Rm          ; Rd[31:8] = Rm[ 7:0] sign extended\r\n                            ; Rd[ 7:0] = Rm[15:8]\r\n<\/pre>\n
A few miscellaneous bit-fiddling instructions. The reversal instructions are primarily for changing data endianness.<\/p>\n
The next few instructions provide multiprocessing hints.<\/p>\n
    ; yield to other threads\r\n    yield\r\n\r\n    ; wait for interrupt\r\n    wfi\r\n<\/pre>\n
The YIELD<\/code> instruction is a hint to multi-threading processors that the current thread should be de-prioritized in favor of other threads. You typically see this instruction dropped into spin loops, via the intrinsic __yield()<\/code>.<\/p>\n
The WFI<\/code> instruction instructs the processor to go into a low-power state until an interrupt occurs. There are other instructions related to “events” which I won’t bother going into.<\/p>\n
The next few instructions are for communicating with the operating system:<\/p>\n
        svc     #imm8       ; system call\r\n        bkpt    #imm8       ; software breakpoint\r\n        udf     #imm8       ; undefined opcode\u00b9\r\n<\/pre>\n
The system call and breakpoint instructions both carry an 8-bit immediate that the operating system can choose to use for whatever purpose it desires. The breakpoint instruction breaks the rules and always executes even if an encompassing IT<\/code> instruction would normally cause it to be ignored. In other words, bkpt<\/code> overrides IT<\/code>.<\/p>\n
The undefined opcode is a block of 256 instructions from 0xde00<\/code> through 0xdeff<\/code> that are architecturally set aside as undefined instructions and which will not be given meaning in future versions of the processor.<\/p>\n
But just because the processor leaves them undefined doesn’t mean that operating system can’t  give them special meaning<\/a>. Windows defines custom artificial instructions in the undefined space.\u00b2<\/p>\n
    __debugbreak            ; udf #0xFE\r\n    __debugservice          ; udf #0xFD\r\n    __assertfail            ; udf #0xFC\r\n    __fastfail              ; udf #0xFB\r\n    __rdpmccntr64           ; udf #0xFA\r\n    __brkdiv0               ; udf #0xF9\r\n<\/pre>\n
Most of these are special ways of manually generating specific exceptions.<\/p>\n\n\n\n\n\n\n\n\n
Opcode<\/th>\nException<\/th>\nNotes<\/th>\n<\/tr>\n
__debugbreak<\/code><\/td>\nSTATUS_BREAKPOINT<\/code><\/td>\nThe “real” breakpoint instruction.<\/td>\n<\/tr>\n
__debugservice<\/code><\/td>\nSTATUS_BREAKPOINT<\/code><\/td>\nCommunicate with debugger, r12<\/var> is function code.<\/td>\n<\/tr>\n
__assertfail<\/code><\/td>\nSTATUS_ASSERTION_FAILURE<\/code><\/td>\n <\/td>\n<\/tr>\n
__fastfail<\/code><\/td>\nSTATUS_STACK_BUFFER_OVERRUN<\/code><\/td>\n Misleadingly-named<\/a>.<\/td>\n<\/tr>\n
__brkdiv0<\/code><\/td>\nSTATUS_INTEGER_DIVIDE_BY_ZERO<\/code><\/td>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The __brkdiv0<\/code> instruction is emitted by the compiler if it detects a zero denominator.<\/p>\n
    cbnz    r0, @F          ; jump if denominator is nonzero\r\n    __brkdiv0               ; oops: manually raise div0 exception\r\n@@: bl      __rt_sdiv       ; software divide\/remainder\r\n                            ; (r0, r1) = (r1 \u00f7 r0, r1 mod r0)\r\n<\/pre>\n
The last artificial instruction is __rdpmccntr64<\/code>, which reads a 64-bit cycle counter. This special instruction has a dedicated fast path through the trap handler, so it can produce the result in around 60 cycles.<\/p>\n
There is also an instruction to access coprocessor registers.<\/p>\n
    ; move register from coprocessor\r\n    mrc (a bunch of stuff)\r\n<\/pre>\n
The coprocessor registers are encoded in a totally wacky way. There’s no point learning what each of the values means. All that matters is that they represent the register you want to read.<\/p>\n
There are a few coprocessor registers named software thread ID register<\/i> which are not used by the processor, but are provided with the intention that operating systems use them to record per-thread information. The two available from user mode are named TPIDRURW<\/code> and TPIDRURO<\/code>; the first is read-write and the second is read-only. Windows uses TPIDRURW<\/code> to hold the thread information.<\/p>\n
And of course, we have this guy:<\/p>\n
    nop\r\n<\/pre>\n
Actually, there are two of this guy, a 16-bit NOP<\/code> and a 32-bit NOP<\/code>. The NOP<\/code> instruction does nothing but occupy space. Use it to pad code to meet alignment requirements, but do not use it for timing because processors are allowed to optimize it out, or even run faster<\/i>.<\/p>\n
Now that we have the basic instruction set under our belt, we’ll look at the calling convention next time.<\/p>\n
Bonus chatter<\/b>: Why doesn’t Windows use udf #0xff<\/code>? The gcc toolchain uses udf #0xff<\/code> as its “We should never get here” trap instruction. Putting an artificial instruction there would cause such a program to continue executing after it thought it had triggered a fatal exception.<\/p>\n
\u00b9 Although the ARM documentation provides the udf<\/code> mnemonic for the undefined instruction, not all assemblers recognize it, so you may be forced to encode the hex value directly into your code if that’s what you want.<\/p>\n
\u00b2 I don’t know why Windows chose the udf<\/code> space for these artificial opcodes instead of using the svc<\/code> space. Maybe there’s some fine print in the processor manual that makes svc<\/code> unsuitable for this sort of thing. We know that bkpt<\/code> is a bad choice for an artificial opcode because bkpt<\/code> executes even if an encompassing IT<\/code> instruction would have skipped it.<\/p>\n
Then again, use of udf<\/code> to create artificial instructions is explicitly listed in the processor architecture manual as a valid use of the udf<\/code> instruction, so at least it’s not breaking any unwritten rules.<\/p>\n","protected":false},"excerpt":{"rendered":"
The stuff that didn’t fit anywhere else.<\/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-105324","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-history"],"acf":[],"blog_post_summary":"
The stuff that didn’t fit anywhere else.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/105324","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=105324"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/105324\/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=105324"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=105324"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=105324"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}