zero-extension | 易学教程

Why movzbl is used in assembly when casting unsigned char to signed data types?

阅读更多关于 Why movzbl is used in assembly when casting unsigned char to signed data types?

问题 I'm learning data movement( MOV ) in assembly. I tried to compile some code to see the assembly in a x86_64 Ubuntu 18.04 machine: typedef unsigned char src_t; typedef xxx dst_t; dst_t cast(src_t *sp, dst_t *dp) { *dp = (dst_t)*sp; return *dp; } where src_t is unsigned char . As for the dst_t , I tried char , short , int and long . The result is shown below: // typedef unsigned char src_t; // typedef char dst_t; // movzbl (%rdi), %eax // movb %al, (%rsi) // typedef unsigned char src_t; //

Why movzbl is used in assembly when casting unsigned char to signed data types?

阅读更多关于 Why movzbl is used in assembly when casting unsigned char to signed data types?

Moving a value of a lesser size into a register

阅读更多关于 Moving a value of a lesser size into a register

问题 I have stored a one-byte value of 8 and I'd like to move that into the rax register. I'm currently doing this with movzx to zero-extend the byte: .globl main main: push %rbp mov %rsp, %rbp movb $8, -1(%rbp) movzx -1(%rbp), %rax <-- here ... How does the movzx instruction 'know' that the value at -1(%rbp) is only one byte long? From here is says, if I'm reading it properly, that it can work on both a byte and a word , but how would it know? For example, if I added a two-byte value at -2(%rbp)

andi vs. addi instruction in MIPS with negative immediate constant

阅读更多关于 andi vs. addi instruction in MIPS with negative immediate constant

问题 Assume $t2= 0x55555550 , then executing the following instruction: andi $t2, $t2, -1 $t2 becomes 0x0005550 This is confirmed by the MIPS emulator 1 However, it is not what I expected. I think the answer should be 0x55555550 & 0xFFFFFFFF = 0x55555550. I think the constant -1 was sign extended to 0xFFFFFFFF before the and logic. But it appears that the answer was 0x55555550 & 0x0000FFFF Why -1 is sign extended to 0x0000FFFF instead of 0xFFFFFFFF Footnote 1: Editor's note: MARS with "extended

MOV 8 bit to 16 bit register (al to bx)

阅读更多关于 MOV 8 bit to 16 bit register (al to bx)

问题 How can I fix the problem of moving 8 bit value to the BX register (16 bit)? mov al, 10h mov bx, al for this I get: operands do not match: 16 bit and 8 bit register 回答1: The answer depends on whether you want to zero extend or sign extend the value and on whether you can or cannot use instructions available starting with the 80386. For better performance, the 80386 or later code should be used if movzx and movsx are available. zero extend on an 8086 or 80286 Zero the upper half, then move to

Why do x86-64 instructions on 32-bit registers zero the upper part of the full 64-bit register?

阅读更多关于 Why do x86-64 instructions on 32-bit registers zero the upper part of the full 64-bit register?

问题 In the x86-64 Tour of Intel Manuals, I read Perhaps the most surprising fact is that an instruction such as MOV EAX, EBX automatically zeroes upper 32 bits of RAX register. The Intel documentation (3.4.1.1 General-Purpose Registers in 64-Bit Mode in manual Basic Architecture) quoted at the same source tells us: 64-bit operands generate a 64-bit result in the destination general-purpose register. 32-bit operands generate a 32-bit result, zero-extended to a 64-bit result in the destination

Zero/sign-extend are no-op, why then instructions for each size type?

阅读更多关于 Zero/sign-extend are no-op, why then instructions for each size type?

问题 For x86 and x64 compilers generate similar zero/sign extend MOVSX and MOVZX. The expansion itself is not free, but allows processors to perform out-of-order magic speed up. But on RISC-V: Consequently, conversion between unsigned and signed 32-bit integers is a no-op, as is conversion from a signed 32-bit integer to a signed 64-bit integer. A few new instructions (ADD[I]W/SUBW/SxxW) are required for addition and shifts to ensure reasonable performance for 32-bit values. (C) RISC-V Spec But at

Can “mov eax, 0x1” always be used instead of “mov rax, 0x1”?

阅读更多关于 Can “mov eax, 0x1” always be used instead of “mov rax, 0x1”?

问题 When assembling this code with nasm : BITS 64 mov eax, 0x1 mov rax, 0x1 I get this output: b8 01 00 00 00 b8 01 00 00 00 which is the opcode for mov eax, 0x1 repeated twice. Does this mean that mov rax, 0x1 can always be replaced by mov eax, 0x1 or is it just in this case? If this is correct wouldn't it be better to use than: xor rax, rax inc rax as that becomes 6 bytes when assembled while mov eax, 0x1 is only 5 bytes? 回答1: Always. Most (if not all) 32-bit MOVs and ALU operations clear bits

Zero/sign-extend are no-op, why then instructions for each size type?

阅读更多关于 Zero/sign-extend are no-op, why then instructions for each size type?

For x86 and x64 compilers generate similar zero/sign extend MOVSX and MOVZX. The expansion itself is not free, but allows processors to perform out-of-order magic speed up. But on RISC-V: Consequently, conversion between unsigned and signed 32-bit integers is a no-op, as is conversion from a signed 32-bit integer to a signed 64-bit integer. A few new instructions (ADD[I]W/SUBW/SxxW) are required for addition and shifts to ensure reasonable performance for 32-bit values. (C) RISC-V Spec But at the same time, the new modern RISC-V 64-bit processors contains instructions for 32-bit signed

MASM Assembly move 8 bit register to the 16 bit register (ie. mov cx, ch) [duplicate]

阅读更多关于 MASM Assembly move 8 bit register to the 16 bit register (ie. mov cx, ch) [duplicate]

问题 This question already has an answer here : MOV 8 bit to 16 bit register (al to bx) (1 answer) Closed 12 days ago . I decided to learn an assembly programming language. I am using this 8086 tutorial. At the bottom the exercise is to find an error in some instructions and one of them is mov cx, ch I found some similar question on SO on this topic explaining how to achieve it but now I'd like to know why this operation is forbidden? Let's assume I have 10d = 00001010b in CH and want to put it to