Zero-Extension of 32-bit Results in x86-64

2025-11-29T00:00:00+00:00

Zero-extension refers to the process of expanding a binary number by adding zeros to the higher-order bits. In this post, we will explore how zero-extension of 32-bit results works in the x86-64 architecture.

How does zero-extension in x86-64 work?</h1>

In general, byte and word operands are stored in the low 8 or 16 bits of GPRs without modifying their high 56 or 48 bits, respectively. Doubleword operands, however, are normally stored in the low 32 bits of GPRs and zero-extended to 64 bits. </blockquote>

From AMD64 Architecture Programmer’s Manual Volume 1: Application Programming</li> </ul>
For example, if the value in register RAX</code> is 0x0001000100010001, what will be the value of RAX</code> after the following instruction is executed?
add eax, eax</code></pre> The answer is - 0x0000000000020002</code>, as the higher 32 bits of register RAX</code> is automatically zero-extended (cleared). Tips and Tricks</h1> The zero idiom in IA-32 is using the XOR</code> instruction instead of MOV</code> to initialize a register to 0, as the former generates shorter opcode. For example, the following instruction is preferred when clearing register EAX</code>: xor eax, eax</code></pre> How about clearing register RAX</code> in the 64-bit mode of x86-64? Let's experiment with the following C code hello.c</code>: #include <stdio.h> int main() { printf("hello, world\n"); return 0; }</code></pre> Use gcc to generate the O2-optimized assembly code: gcc hello.c -O2 -S -o hello.S</code></pre> The content of hello.S</code> is shown as follows: .file "hello.c" .text .section .rodata.str1.1,"aMS",@progbits,1 .LC0: .string "hello, world" .section .text.startup,"ax",@progbits .p2align 4 .globl main .type main, @function main: .LFB11: .cfi_startproc subq $8, %rsp .cfi_def_cfa_offset 16 leaq .LC0(%rip), %rdi call puts@PLT xorl %eax, %eax addq $8, %rsp .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE11: .size main, .-main .ident "GCC: (GNU) 15.2.1 20251112" .section .note.GNU-stack,"",@progbits</code></pre> According to the x86-64 calling convention, integer return values are stored in RAX</code>. Therefore, the instruction of setting the return value to 0 is xorl %eax, %eax</code></pre> As mentioned earlier, the results of higher 32 bits of GPRs will be automatically zero-extended. Therefore, clearing EAX</code> implictly sets the higher 32 bits of RAX</code> to 0. But you may wonder, why does the compiler choose to generate assemebly code xor eax, eax</code> rather than xor rax, rax</code>? The reason lies in the difference in opcode length: Mnemonic</th> Opcode</th></tr></thead> xor eax, eax</td> 31 c0</td></tr> xor rax, rax</td> 48 31 c0</td></tr> </tbody></table> As you can see, the former instruction has shorter opcode. The prefix 0x48</code> in the opcode is called REX prefix, according to the AMD64 manual: For most instructions, the default operand size in 64-bit mode is 32 bits. To access 16-bit operand sizes, an instruction must contain an operand-size prefix (66h), as described in Section 3.2.3, “Operand Sizes and Overrides,” on page 41. To access the full 64-bit operand size, most instructions must contain a REX prefix. </blockquote> From AMD64 Architecture Programmer’s Manual Volume 1: Application Programming</li> </ul> Fix generic application icon under Wayland session 2024-12-13T00:00:00+00:00 A common problem in Wayland session is some apps show generic Wayland icon instead of the proper application icon. Here is an example: Fortunately, this problem is very easy to fix for common GUI libraries. Here are the solutions (replace APP_ID</code> with application ID): Qt</h1> C++</h2> #include <QGuiApplication> QGuiApplication::setDesktopFileName(APP_ID);</code></pre> or #include <QApplication> QApplication app(argc, argv); app.setDesktopFileName(APP_ID);</code></pre>PyQt (Python)</h2> from PyQt6.QtGui import QGuiApplication QGuiApplication.setDesktopFileName(APP_ID)</code></pre> or class Application(QtWidgets.QApplication): ... app = Application() app.setDesktopFileName(APP_ID)</code></pre>GTK</h1> C</h2> g_set_prgname(APP_ID);</code></pre>gtkmm (C++)</h2> Glib::set_prgname(APP_ID);</code></pre>gtk-rs (Rust)</h2> glib::set_prgname(Some(APP_ID));</code></pre>PyGObject (Python)</h2> from gi.repository import GLib GLib.set_prgname(APP_ID)</code></pre>GLFW</h1> glfwWindowHintString(GLFW_WAYLAND_APP_ID, APP_ID);</code></pre>wxWidgets >= 3.3.1</h1> #include <wx/app.h> SetClassName(APP_ID);</code></pre> According to wxAppConsole Class Reference</a>: Please note that SetClassName() must be called as early as possible and definitely before creating any top-level windows to have an effect. </blockquote> Slint</h1> use i_slint_backend_winit::winit::platform::wayland::WindowAttributesExtWayland; let backend = i_slint_backend_winit::Backend::builder() .with_window_attributes_hook(|attr| attr.with_name(APP_ID, "")) .build() .unwrap(); slint::platform::set_platform(Box::new(backend))</code></pre> Run Linux ELF binary file on Android 2024-06-24T00:00:00+00:00 Although usual Android apps are installed to your device as APK files, you still have the option to run native ELF binary file compiled for the architecture of your device. Prerequisites</h1> A Linux PC with gcc or other C compiler installed If you are trying to run the compiled ELF file on a device with an ISA that differs from your PC, a cross compiler is required The most common scenario is x86-64 PC + ARM64 (aka. AArch64) Android device, where aarch64-linux-gnu-gcc</code> is needed</li> </ul> </li> </ul> </li> An Android phone, container or emulator (I am using Waydroid</a>) with Termux</a> installed</li> </ul> Compilation</h1> Take the following "Hello world" program (test.c</code>) as an example: #include <stdio.h> int main() { printf("Hello world!\n"); return 0; }</code></pre> Use gcc to compile it: gcc test.c -static -o test</code></pre> If you intend to run the compiled binary on ARM64 (aka. AArch64) devices and your PC is not ARM64: aarch64-linux-gnu-gcc test.c -static -o test</code></pre> -static</code> option is needed to statically link the system C library as Android uses bionic as C library instead of glibc or musl. Next, copy the compiled ELF file to your Android device. Copy the compiled ELF file to the appropriate path</h1> As /storage</code> is mounted with option noexec</code>, you can't execute files under the /storage</code> directory even if they have been given executable permission with chmod +x</code>. Therefore, we need to find a directory without noexec</code> mounting option. A common choice is /data/local/tmp</code>. - $ mount ... tmpfs on /storage type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755,gid=1000,inode64) ...</code></pre> To access /data/local/tmp</code> directory, the root permission is needed for Termux. su cp test /data/local/tmp</code></pre>Execute the file</h1> chmod +x test ./test</code></pre> See also</h1> Run Binary Elf Executable File on Android (With Bugjaeger)</a></li> </ul> Year End Review of 2023 2023-12-31T00:00:00+00:00 It's almost 2024, so everyone should harvest something in 2023 :) In 2023, I have gone from being a pragmatic open-source software lover to a free software enthusiast. The ROM on my Android</a> phone was switched from MIUI</a> which is the stock firmware on my phone, to the AOSP-based crDroid</a>. I was struggling to use as little proprietary software as possible both on my phone and PC, minimizing my dependence on proprietary network services. </li> In February, I joined the FSF</a> by paying $5 membership fee on a monthly basis. When I discover a nice free software on Github</a>, if the developer has set up Github Sponsor</a>, I will probably financially support him/her (individual FOSS developers will be given $1 or $2 per month). </li> In March, I submitted my archlinuxcn</a> maintainer application to @lilydjwg</a> who is one of the founders of archlinuxcn</a> via email, and became an archlinuxcn</a> maintainer. In the following 9 months, I committed more than 900 times (initially I was unfamiliar with lilac</a> hence made a few mistakes). </li> Due to the poor battery life and hardship of portability with the peripherals of ROG Zephyrus M16</a>, I purchased a chromebook</a> at the end of March. After trying ChromeOS</a> for several hours, I flashed coreboot</a> and installed Arch Linux</a> on it (it's my first experience of an x86 PC with open-source UEFI firmware). Now I take this chromebook</a> with me when I go out, which is very portable weighing 1.3 kg. Instead of turning it off, most of the time I close the lid to make it suspend. </li> In May, I found a Tauri</a>-based and GPL-licensed</a> translation application on Github</a> (namely pot-desktop</a>). Nonetheless, after installing it from AUR</a>, I realized its Wayland</a> support is inferior. Therefore, I gave feedback to the developer</a>, and soon the Wayland</a> support became immaculate. The updated version of pot-desktop</a> added support for OCR and plugin functionality</a>, thus I participated in the development of its plugins</a>. </li> In June, I joined PLCT</a> and worked as an openEuler</a> packaging intern for 3 months, but I found this position was not suitable for me. From my perspective, its init</code> system, sysmaster</a>, is entirely a pointless refactoring product of systemd</a>. </li> In July, I participated in LLUG (Linux Lovers User Group) in Shanghai</a>, and met several friends with whom I get acquainted in the Arch Linux Chinese Community</a>. In a 5-minute lightning talk, I shared my experience from a Linux novice to an archlinuxcn</a> maintainer. </li> In September, I attended the Software Freedom Day hosted by USTC (University of Science and Technology of China)</a> online by means of Jitsi Meet</a>, and delivered a speech centered around FOSS. During my presentation, I shared my experience in the open source community, introduced the notion of free software and recommended notable free software including Mastodon</a> and Matrix</a>. Additionally, I got to meet some free software enthusiasts in USTC</a>. </li> Since the bug</a> I reported to Ark</a> (the archive software of KDE</a>) in September was not fixed in several weeks, I took the initiative to fix it myself and submitted my first merge request to KDE</a> in October. From then on, I have been learning Qt</a> and Kirigami</a> and trying to fix simple bugs in KDE</a> software (not capable of fixing the complex ones at all yet) </li> Overall, I had some regrets but also quite a few gains in 2023. Hankering for a more wonderful 2024 :) </li> Last but not least, happy new year! </li> </ul>

Execute the file</h1>
`chmod +x test</span></span> ./test</span></span></code></pre> See also</h1> Run Binary Elf Executable File on Android (With Bugjaeger)</a></li> </ul>`

See also</h1>

Run Binary Elf Executable File on Android (With Bugjaeger)</a></li> </ul>

Integral's Blog

Zero-Extension of 32-bit Results in x86-64

Fix generic application icon under Wayland session

GTK</h1>

Run Linux ELF binary file on Android

Year End Review of 2023

Integral's Blog

Zero-Extension of 32-bit Results in x86-64

Fix generic application icon under Wayland session

GTK</h1>

Run Linux ELF binary file on Android

Compilation</h1> Take the following "Hello world" program (test.c</code>) as an example:</p>

Execute the file</h1> chmod +x test</span></span> ./test</span></span></code></pre> See also</h1> Run Binary Elf Executable File on Android (With Bugjaeger)</a></li> </ul>

See also</h1> Run Binary Elf Executable File on Android (With Bugjaeger)</a></li> </ul>

Year End Review of 2023

Execute the file</h1>
`chmod +x test</span></span> ./test</span></span></code></pre> See also</h1> Run Binary Elf Executable File on Android (With Bugjaeger)</a></li> </ul>`

See also</h1>

Run Binary Elf Executable File on Android (With Bugjaeger)</a></li> </ul>