# Assembly

Assembly is a low-level programming language whose instructions assemble into machine-language instructions and differ across computer architectures.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Why is the x86 undefined instruction called ud2? Why 2?

DevFeed: [Why is the x86 undefined instruction called ud2? Why 2?](<https://devfeed.tech/articles/why-is-the-x86-undefined-instruction-called-ud2-why-2-21760.md>)

Original publisher: [Read original article](<https://devblogs.microsoft.com/oldnewthing/20260910-00/?p=112689>)

Author: Raymond Chen

Published: 2026-09-10T14:00:00Z

Content type: article

Language: en

Sources: [Raymond Chen](<https://devfeed.tech/sources/raymond-chen.md>)

Topics: [x86](<https://devfeed.tech/topics/x86.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Exception](<https://devfeed.tech/topics/exception.md>), [intel](<https://devfeed.tech/topics/intel.md>)

Tags: [compiler](<https://devfeed.tech/tags/compiler.md>), [exception](<https://devfeed.tech/tags/exception.md>), [intel](<https://devfeed.tech/tags/intel.md>), [old-new-thing](<https://devfeed.tech/tags/old-new-thing.md>), [other](<https://devfeed.tech/tags/other.md>), [processor](<https://devfeed.tech/tags/processor.md>), [x86](<https://devfeed.tech/tags/x86.md>)

### AI overview

The article explains why the x86 undefined instruction is called ud2. It describes how software used byte sequences that reliably raised an invalid opcode exception, how Intel later provided a standardized instruction, and how compiler output can use it to mark unreachable code and cause a deliberate crash.

### Source excerpt

It came after ud0 and ud1. The post Why is the x86 undefined instruction called <CODE>ud2</CODE>? Why 2? appeared first on The Old New Thing.

## A deep dive into SmallVector::push\_back

DevFeed: [A deep dive into SmallVector::push\_back](<https://devfeed.tech/articles/a-deep-dive-into-smallvector-push-back-31123.md>)

Original publisher: [Read original article](<https://maskray.me/blog/a-deep-dive-into-smallvector-push-back>)

Published: 2026-06-27T07:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [LLVM](<https://devfeed.tech/topics/llvm.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [clang](<https://devfeed.tech/topics/clang.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [gcc](<https://devfeed.tech/topics/gcc.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [clang](<https://devfeed.tech/tags/clang.md>), [codegen](<https://devfeed.tech/tags/codegen.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [performance](<https://devfeed.tech/tags/performance.md>)

### AI overview

This article examines an LLVM SmallVector::push_back optimization for approximately trivially copyable element types. It explains how tail-calling the slow growth path reduces the fast path from 14 to 7 instructions and avoids callee-saved registers, while noting tradeoffs for out-of-line calls and overall build size.

### Source excerpt

tl;dr This blog post describes a recent SmallVector::push_back optimization for approximately trivially copyable element types. SmallVector is LLVM's most-used container, and push_back its hot operation. For the trivially-copyable specialization the fast path should be fast. 1 2 3 #include <llvm/ADT/SmallVector.h> void f(llvm::SmallVectorImpl<int> &v, int x) { v.push_back(x); } clang -S --target=x86_64 -O2 -DNDEBUG a.cc generates: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 push rbp # callee-saved spills + a stack realignment, push rbx # all on the fast path push rax mov eax, [rdi + 8] # size cmp eax, [rdi + 12] # vs capacity jae .Lgrow .Lstore: # reached from the fast path AND from .Lgrow mov rcx, [rdi] mov [rcx + rax*4], esi inc dword ptr [rdi + 8] add rsp, 8 pop rbx pop rbp ret .Lgrow: mov rbx, rdi # keep `this`/`x` alive across the call mov ebp, esi call SmallVectorBase<unsigned>::grow_pod ... jmp .Lstore

## WebAssembly interpreter performance depends on the runtime, not just the code pattern

DevFeed: [WebAssembly interpreter performance depends on the runtime, not just the code pattern](<https://devfeed.tech/articles/the-value-of-a-performance-oracle-35035.md>)

Original publisher: [Read original article](<https://wingolog.org/archives/2026/04/07/the-value-of-a-performance-oracle>)

Author: Andy Wingo

Published: 2026-04-07T12:49:39Z

Content type: article

Language: en

Sources: [wingolog](<https://devfeed.tech/sources/wingolog.md>)

Topics: [Rust](<https://devfeed.tech/topics/rust.md>), [WebAssembly](<https://devfeed.tech/topics/web-assembly.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [toolchain](<https://devfeed.tech/topics/toolchain.md>), [V8](<https://devfeed.tech/topics/v8.md>), [Chrome](<https://devfeed.tech/topics/chrome.md>), [Firefox](<https://devfeed.tech/topics/firefox.md>)

Tags: [assembler](<https://devfeed.tech/tags/assembler.md>), [assembly](<https://devfeed.tech/tags/assembly.md>), [chrome](<https://devfeed.tech/tags/chrome.md>), [firefox](<https://devfeed.tech/tags/firefox.md>), [oracles](<https://devfeed.tech/tags/oracles.md>), [performance](<https://devfeed.tech/tags/performance.md>), [performance-oracles](<https://devfeed.tech/tags/performance-oracles.md>), [raven](<https://devfeed.tech/tags/raven.md>), [rust](<https://devfeed.tech/tags/rust.md>), [tail-calls](<https://devfeed.tech/tags/tail-calls.md>), [toolchain](<https://devfeed.tech/tags/toolchain.md>), [wasm](<https://devfeed.tech/tags/wasm.md>), [wasmtime](<https://devfeed.tech/tags/wasmtime.md>), [wastrel](<https://devfeed.tech/tags/wastrel.md>), [webassembly](<https://devfeed.tech/tags/webassembly.md>)

### AI overview

The article revisits a comparison of switch-based and tail-calling bytecode interpreters. Its measurements confirm earlier native and Wasmtime results but report that Wastrel substantially reduces the apparent WebAssembly penalty, suggesting that the poor performance is runtime-specific rather than inherent to WebAssembly.

### Source excerpt

Over on his excellent blog, Matt Keeter posts some results from having ported a bytecode virtual machine to tail-calling style. He finds that his tail-calling interpreter written in Rust beats his switch-based interpreter, and even beats hand-coded assembly on some platforms. He also compares tail-calling versus switch-based interpreters on WebAssembly, and concludes that performance of tail-calling interpreters in Wasm is terrible: 1.2x slower on Firefox, 3.7x slower on Chrome, and 4.6x slower in wasmtime. I guess patterns which generate good assembly don't map well to the WASM stack machine, and the JITs aren't smart enough to lower it to optimal machine code. In this article, I would like to argue the opposite: patterns that generate good assembly map just fine to the Wasm stack machine, and the underperformance of V8, SpiderMonkey, and Wasmtime is an accident. some numbers I re-ran Matt's experiment locally on my x86-64 machine (AMD Ryzen Threadripper PRO 5955WX). I tested three toolchains: Compiled natively via cargo / rustc Compiled to WebAssembly, then run with Wasmtime Compiled to WebAssembly, then run with Wastrel For each of these toolchains, I tested Raven as implemented in Rust in both "switch-based" and "tail-calling" modes. Additionally, Matt has a Raven implementation written directly in assembly; I test this as well, for the native toolchain. All results use nightly/git toolchains from 7 April 2026. My results confirm Matt's for the native and wasmtime toolchains, but wastrel puts them in context: We can read this chart from left to right: a switch-based interpreter written in Rust is 1.5x slower than a tail-calling interpreter, and the tail-calling interpreter just about reaches the speed of hand-written assembler. (Testing on AArch64, Matt even sees the tail-calling interpreter beating his hand-written assembler.) Then moving to WebAssembly run using Wasmtime, we see that Wasmtime takes 4.3x as much time to run the switch-based interpreter, compare

## AI-generated ARM assembly optimization reduces instruction count eightfold in a C++ string-counting test

DevFeed: [AI-generated ARM assembly optimization reduces instruction count eightfold in a C++ string-counting test](<https://devfeed.tech/articles/can-your-ai-rewrite-your-code-in-assembly-29399.md>)

Original publisher: [Read original article](<https://lemire.me/blog/2026/04/05/can-your-ai-rewrite-your-code-in-assembly/>)

Author: Daniel Lemire

Published: 2026-04-05T21:16:14Z

Content type: opinion

Language: en

Sources: [Daniel Lemire](<https://devfeed.tech/sources/daniel-lemire.md>)

Topics: [Assembly](<https://devfeed.tech/topics/assembly.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [assembly](<https://devfeed.tech/tags/assembly.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [claude](<https://devfeed.tech/tags/claude.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [performance](<https://devfeed.tech/tags/performance.md>), [prompting](<https://devfeed.tech/tags/prompting.md>)

### AI overview

The article describes an experiment using Grok and Claude to repeatedly optimize an ARM assembly function that counts a character across strings. On random strings of up to 1 kilobyte, the optimized versions reduced instructions by a factor of eight and achieved similar running-time reductions, though the author notes that the code was not closely examined for mistakes. The best version could be rewritten in C using SIMD intrinsics, so assembly provided no benefit in this case.

### Source excerpt

Suppose you have several strings and you want to count the number of instances of the character ! in your strings. In C++, you might solve the problem as follows if you are an old-school programmer. size_t c = 0; for (const auto &str : strings) { c += std::count(str.begin(), str.end(), '!'); } You can ... Continue reading Can your AI rewrite your code in assembly?

## Supporting RISC-V P Extension Instructions in IDA Pro

DevFeed: [Supporting RISC-V P Extension Instructions in IDA Pro](<https://devfeed.tech/articles/simd-ida-pro-risc-v-p-extension-23059.md>)

Original publisher: [Read original article](<https://habr.com/ru/companies/kaspersky/articles/1005630/>)

Author: Kaspersky\_Lab ("Лаборатория Касперского")

Published: 2026-03-02T15:13:48Z

Content type: tutorial

Language: ru

Sources: ["Лаборатория Касперского" RU](<https://devfeed.tech/sources/ru-2.md>)

Topics: [RISC-V](<https://devfeed.tech/topics/riscv.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [Extension](<https://devfeed.tech/topics/extension.md>)

Tags: [extension](<https://devfeed.tech/tags/extension.md>), [ida-pro](<https://devfeed.tech/tags/ida-pro.md>), [python](<https://devfeed.tech/tags/python.md>), [risc-v](<https://devfeed.tech/tags/risc-v.md>), [rv32i](<https://devfeed.tech/tags/rv32i.md>), [simd-extension](<https://devfeed.tech/tags/simd-extension.md>), [tag-083e778de188](<https://devfeed.tech/tags/tag-083e778de188.md>), [tag-6066cd7c03f8](<https://devfeed.tech/tags/tag-6066cd7c03f8.md>), [tag-85443682aea4](<https://devfeed.tech/tags/tag-85443682aea4.md>), [tag-db5a2ccdff76](<https://devfeed.tech/tags/tag-db5a2ccdff76.md>), [tag-fc48bdbb07ff](<https://devfeed.tech/tags/tag-fc48bdbb07ff.md>)

### AI overview

The article describes how Kaspersky security researchers analyzed a RISC-V device using the RV32I base instruction set and an early version of the P Packed-SIMD extension, then added support for some of its instructions and lifting to IDA Pro.

### Source excerpt

У нас в "Лаборатории Касперского" есть команда анализа защищенности, занимающаяся поиском уязвимостей в самых разнообразных системах. В ней работают эксперты, способные исследовать практически любое устройство (и публикующие технические заметки о своих находках). Но в жизни практически каждого исследователя безопасности прошивок однажды наступает момент, когда он или она сталкивается с новым или не особо известным микроконтроллером или свежей процессорной архитектурой с кастомными расширениями. В последнее время такие моменты наступают все чаще -- за прошедшие несколько лет рынок наполнился огромным количеством новых чипов из Поднебесной, в частности, на базе RISC-V, со своими собственными расширениями и реализациями ядер. И вот не так давно на анализ нашим исследователям попало устройство c таким чипом на базе RISC-V, c базовым набором инструкций RV32I и расширением P (причем еще и не последней версии), добавляющим короткие SIMD-операции (Packed-SIMD Instructions). То, что наши эксперты видели его впервые -- абсолютно нормально. Но, по всей видимости, его впервые видел и IDA Pro -- инструмент, которым пользуются наши исследователи. Поэтому им пришлось не только изучить ранний черновик расширения P (оно же Packed-SIMD Extension), но также реализовать поддержку IDA Pro ряда инструкций из него и произвести лифтинг, то есть трансляцию инструкций в промежуточное представление или язык, понятные декомпилятору. Именно этим опытом они и решили поделиться в данной статье. Но прежде чем переходить к описанию решения этих задач, стоит понять, с чем мы имеем дело, поэтому начать следует со знакомства с документацией по архитектуре RISC-V. Читать далее

## Call relocation types

DevFeed: [Call relocation types](<https://devfeed.tech/articles/call-relocation-types-31126.md>)

Original publisher: [Read original article](<https://maskray.me/blog/call-relocation-types>)

Published: 2026-02-16T08:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [x86](<https://devfeed.tech/topics/x86.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [architectures](<https://devfeed.tech/tags/architectures.md>), [binutils](<https://devfeed.tech/tags/binutils.md>), [function](<https://devfeed.tech/tags/function.md>), [linker](<https://devfeed.tech/tags/linker.md>), [static-linking](<https://devfeed.tech/tags/static-linking.md>), [symbols](<https://devfeed.tech/tags/symbols.md>), [x86](<https://devfeed.tech/tags/x86.md>), [x86-64](<https://devfeed.tech/tags/x86-64.md>)

### AI overview

This technical post explains why some architectures use separate ELF relocation types for direct function calls and tail calls. It contrasts static linking, where a PC-relative relocation can often be reused, with dynamic linking, where calls may use PLT indirection and therefore require relocation types that encode call semantics.

### Source excerpt

Most architectures encode direct branch/call instructions with a PC-relative displacement. This post discusses a specific category of branch relocations: those used for direct function calls and tail calls. Some architectures use two ELF relocation types for a call instruction: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # i386, x86-64 call foo # R_386_PC32, R_X86_64_PC32 call foo@plt # R_386_PLT32, R_X86_64_PLT32 # m68k bsr.l foo # R_68K_PC32 bsr.l foo@plt # R_68K_PLT32 # s390/s390x brasl %r14, foo # R_390_PC32DBL brasl %r14, foo@plt # R_390_PLT32DBL # sparc call foo, 0 # not PIC: R_SPARC_WDISP30 call foo, 0 # gas -KPIC: R_SPARC_WPLT30

## Long branches in compilers, assemblers, and linkers

DevFeed: [Long branches in compilers, assemblers, and linkers](<https://devfeed.tech/articles/long-branches-in-compilers-assemblers-and-linkers-31133.md>)

Original publisher: [Read original article](<https://maskray.me/blog/long-branches-in-compilers-assemblers-and-linkers>)

Published: 2026-01-25T08:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [toolchain](<https://devfeed.tech/topics/toolchain.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>)

Tags: [architectures](<https://devfeed.tech/tags/architectures.md>), [article](<https://devfeed.tech/tags/article.md>), [assembler](<https://devfeed.tech/tags/assembler.md>), [binutils](<https://devfeed.tech/tags/binutils.md>), [compilers](<https://devfeed.tech/tags/compilers.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [linker](<https://devfeed.tech/tags/linker.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [toolchain](<https://devfeed.tech/tags/toolchain.md>)

### AI overview

This article explains how compilers, assemblers, and linkers handle branch instructions whose PC-relative targets exceed the supported range. It describes the division of responsibility across toolchain stages and compares branch-range limitations across architectures, including AArch32, AArch64, and LoongArch.

### Source excerpt

Branch instructions on most architectures use PC-relative addressing with a limited range. When the target is too far away, the branch becomes "out of range" and requires special handling. Consider a large binary where main() at address 0x10000 calls foo() at address 0x8010000-over 128MiB away. On AArch64, the bl instruction can only reach ±128MiB, so this call cannot be encoded directly. Without proper handling, the linker would fail with an error like "relocation out of range." The toolchain must handle this transparently to produce correct executables. This article explores how compilers, assemblers, and linkers work together to solve the long branch problem. Compiler (IR to assembly): Handles branches within a function that exceed the range of conditional branch instructions Assembler (assembly to relocatable file): Handles branches within a section where the distance is known at assembly time Linker: Handles cross-section and cross-object branches discovered during final layout

## Frankenwine: Multiple personas in a Wine process

DevFeed: [Frankenwine: Multiple personas in a Wine process](<https://devfeed.tech/articles/frankenwine-multiple-personas-in-a-wine-process-20510.md>)

Original publisher: [Read original article](<https://nullprogram.com/blog/2026/01/19/>)

Published: 2026-01-19T21:51:38Z

Content type: article

Language: en

Sources: [Chris Wellons](<https://devfeed.tech/sources/chris-wellons.md>)

Topics: [WINE](<https://devfeed.tech/topics/wine.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [Processes](<https://devfeed.tech/topics/processes.md>), [toolchain](<https://devfeed.tech/topics/toolchain.md>), [C](<https://devfeed.tech/topics/c.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [Git](<https://devfeed.tech/topics/git.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [c](<https://devfeed.tech/tags/c.md>), [git](<https://devfeed.tech/tags/git.md>), [linux](<https://devfeed.tech/tags/linux.md>), [processes](<https://devfeed.tech/tags/processes.md>), [toolchain](<https://devfeed.tech/tags/toolchain.md>), [win32](<https://devfeed.tech/tags/win32.md>), [wine](<https://devfeed.tech/tags/wine.md>), [x86](<https://devfeed.tech/tags/x86.md>), [x86-64](<https://devfeed.tech/tags/x86-64.md>)

### AI overview

This article describes building a Windows binary that behaves as a native pkg-config program on Windows but adopts a Linux-program persona when run under Wine. It detects Wine, invokes Linux system calls directly through x86-64 inline assembly, and applies the approach to u-config as a cross-toolchain pkg-config implementation.

### Source excerpt

I came across a recent article on making Linux system calls from a Wine process. Windows programs running under Wine are still normal Linux processes and may interact with the Linux kernel like any other process. None of this was surprising, and the demonstration works just as I expect. Still, it got the wheels spinning and I realized an almost practical application: build my pkg-config implementation such that on Windows pkg-config.exe behaves as a native pkg-config, but when run under Wine this same binary takes the persona of a Linux program and becomes a cross toolchain pkg-config, bypassing Win32 and talking directly with the Linux kernel. Cosmopolitan Libc cleverly does this out-of-the-box, but in this article we'll mash together a couple existing sources with a bit of glue. The results are in the merge-demo branch of u-config, and took hardly any work: $ git show --stat ... main_linux_amd64.c | 8 ++--- main_wine.c | 101 +++++++++++++++++++++++++++++++++++++++++ src/linux_noarch.c | 16 ++++----- src/u-config.c | 1 + 4 files changed, 114 insertions(+), 12 deletions(-) A platform layer, main_wine.c, is a merge of two existing platform layers, one of which required unavoidable tweaks. We'll get to those details in a moment. First we'll need to detect if we're running under Wine, and the best solution I found was to locate ntdll!wine_get_version. If this function exists, we're in Wine. That works out to a pretty one-liner because ntdll.dll is already loaded: bool running_on_wine() { return GetProcAddress(GetModuleHandleA("ntdll"), "wine_get_version"); } An x86-64 Linux syscall wrapper with thorough inline assembly: ptrdiff_t syscall3(int n, ptrdiff_t a, ptrdiff_t b, ptrdiff_t c) { ptrdiff_t r; asm volatile ( "syscall" : "=a"(r) : "a"(n), "D"(a), "S"(b), "d"(c) : "rcx", "r11", "memory" ); return r; } ptrdiff_t write(int fd, void *buf, ptrdiff_t len) { return syscall3(SYS_write, fd, (ptrdiff_t)buf, len); } I'd normally use long for all these integers because Linux i

## IOCCC/mullender revisited, position-independent code, shellcode

DevFeed: [IOCCC/mullender revisited, position-independent code, shellcode](<https://devfeed.tech/articles/ioccc-mullender-revisited-position-independent-code-shellcode-20545.md>)

Original publisher: [Read original article](<https://yurichev.com/blog/PIC/>)

Published: 2026-01-04T23:00:00Z

Content type: tutorial

Language: en

Sources: [Dennis Yurichev](<https://devfeed.tech/sources/dennis-yurichev.md>)

Topics: [Assembly](<https://devfeed.tech/topics/assembly.md>), [Code](<https://devfeed.tech/topics/code.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Linux](<https://devfeed.tech/topics/linux.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [code](<https://devfeed.tech/tags/code.md>), [linux](<https://devfeed.tech/tags/linux.md>), [programming](<https://devfeed.tech/tags/programming.md>)

### AI overview

This article revisits an IOCCC entry and explains position-independent code using arrays placed in executable sections. It demonstrates Linux x64 and ARM64 assembly examples, including shellcode-related syscall and PIC techniques, and describes code that can run across x64 and ARM64.

### Source excerpt

IOCCC/mullender revisited, position-independent code, shellcode

## Compiling Ruby To Machine Language

DevFeed: [Compiling Ruby To Machine Language](<https://devfeed.tech/articles/compiling-ruby-to-machine-language-31808.md>)

Original publisher: [Read original article](<https://patshaughnessy.net/2025/11/17/compiling-ruby-to-machine-language>)

Author: Pat Shaughnessy

Published: 2025-11-17T00:00:00Z

Content type: article

Language: en

Sources: [Pat Shaughnessy](<https://devfeed.tech/sources/pat-shaughnessy.md>)

Topics: [Ruby](<https://devfeed.tech/topics/ruby.md>), [JIT](<https://devfeed.tech/topics/jit.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [compiler](<https://devfeed.tech/tags/compiler.md>), [jit](<https://devfeed.tech/tags/jit.md>), [machine](<https://devfeed.tech/tags/machine.md>), [performance](<https://devfeed.tech/tags/performance.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [rust](<https://devfeed.tech/tags/rust.md>), [updating-ruby-under-a-microscope](<https://devfeed.tech/tags/updating-ruby-under-a-microscope.md>)

### AI overview

This excerpt explains how Ruby's YJIT compiler identifies frequently called functions and blocks, counts executions, and compiles hot YARV instruction sequences into machine language. It also describes thresholds used for small Ruby programs and Ruby on Rails web applications, along with YJIT blocks.

### Source excerpt

I've started working on a new edition of Ruby Under a Microscope that covers Ruby 3.x. I'm working on this in my spare time, so it will take a while. Leave a comment or drop me a line and I'll email you when it's finished. Here's an excerpt

## \[RevEng\] Toy decompiler

DevFeed: [\[RevEng\] Toy decompiler](<https://devfeed.tech/articles/reveng-toy-decompiler-20582.md>)

Original publisher: [Read original article](<https://yurichev.com/blog/toy_decompiler/>)

Published: 2025-11-16T23:00:00Z

Content type: article

Language: en

Sources: [Dennis Yurichev](<https://devfeed.tech/sources/dennis-yurichev.md>)

Topics: [Assembly](<https://devfeed.tech/topics/assembly.md>), [Code](<https://devfeed.tech/topics/code.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Python](<https://devfeed.tech/topics/python.md>), [C](<https://devfeed.tech/topics/c.md>), [gcc](<https://devfeed.tech/topics/gcc.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [c](<https://devfeed.tech/tags/c.md>), [code](<https://devfeed.tech/tags/code.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [experimental](<https://devfeed.tech/tags/experimental.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [python](<https://devfeed.tech/tags/python.md>), [rewrite](<https://devfeed.tech/tags/rewrite.md>)

### AI overview

This article describes a toy decompiler for Xilinx MicroBlaze assembly. It manually and programmatically rewrites chains of addk and rsubk instructions into multiplication expressions, using Python regular expressions and tests, then discusses limitations including GCC optimization and the experimental nature of the implementation.

### Source excerpt

[RevEng] Toy decompiler

## Working for a Vendor with David Gee

DevFeed: [Working for a Vendor with David Gee](<https://devfeed.tech/articles/working-for-a-vendor-with-david-gee-11272.md>)

Original publisher: [Read original article](<https://blog.ipspace.net/2025/10/working-for-vendor-david-gee/>)

Published: 2025-10-07T06:23:00Z

Content type: article

Language: en

Sources: [ipSpace.net blog](<https://devfeed.tech/sources/ipspace-net-blog.md>)

Topics: [networking](<https://devfeed.tech/topics/networking.md>), [Development](<https://devfeed.tech/topics/development.md>), [C](<https://devfeed.tech/topics/c.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [c](<https://devfeed.tech/tags/c.md>), [development](<https://devfeed.tech/tags/development.md>), [networking](<https://devfeed.tech/tags/networking.md>), [podcast](<https://devfeed.tech/tags/podcast.md>), [software-gone-wild](<https://devfeed.tech/tags/software-gone-wild.md>)

### AI overview

An interview with David Gee examines his career across system integrators, networking vendors, software vendors, and his own systems integration business. The article also includes his reflections on creating software, learning from flawed code, and an early control-system project written in C and assembly.

### Source excerpt

When I first met David Gee, he worked for a large system integrator. A few years later, he moved to a networking vendor, worked for a few of them, then for a software vendor, and finally decided to start his own system integration business. Obviously, I wanted to know what drove him to make those changes, what lessons he learned working in various parts of the networking industry, and what (looking back with perfect hindsight) he would have changed. Read more ...

## Inside Go -- Part 1: The Compilation Pipeline

DevFeed: [Inside Go -- Part 1: The Compilation Pipeline](<https://devfeed.tech/articles/inside-go-part-1-the-compilation-pipeline-39763.md>)

Original publisher: [Read original article](<https://furkankolcu.com/post/inside-go-part-1-the-compilation-pipeline>)

Author: Furkan Kolcu

Published: 2025-09-11T10:34:38Z

Content type: tutorial

Language: en

Sources: [Furkan Kolcu - Software Engineer Blog](<https://devfeed.tech/sources/furkan-kolcu-software-engineer-blog.md>)

Topics: [Go Language](<https://devfeed.tech/topics/go-language.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Parsing](<https://devfeed.tech/topics/parsing.md>), [Parser](<https://devfeed.tech/topics/parser.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [Code generation](<https://devfeed.tech/topics/code-generation.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [ast](<https://devfeed.tech/tags/ast.md>), [code-generation](<https://devfeed.tech/tags/code-generation.md>), [compilation](<https://devfeed.tech/tags/compilation.md>), [go](<https://devfeed.tech/tags/go.md>), [go-ast](<https://devfeed.tech/tags/go-ast.md>), [go-compilation](<https://devfeed.tech/tags/go-compilation.md>), [go-compiler](<https://devfeed.tech/tags/go-compiler.md>), [go-internals](<https://devfeed.tech/tags/go-internals.md>), [go-lexer](<https://devfeed.tech/tags/go-lexer.md>), [go-parser](<https://devfeed.tech/tags/go-parser.md>), [go-ssa](<https://devfeed.tech/tags/go-ssa.md>), [golang](<https://devfeed.tech/tags/golang.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [parsing](<https://devfeed.tech/tags/parsing.md>), [ssa](<https://devfeed.tech/tags/ssa.md>), [technology](<https://devfeed.tech/tags/technology.md>)

### AI overview

This tutorial explains how Go source code is transformed into a native executable. It covers lexing and parsing, abstract syntax trees, type checking, SSA, optimization, code generation, and linking, with simple examples and analogies.

### Source excerpt

In this first part of the "Inside Go" series, I'll walk through how Go source code transforms into a binary. From lexing and parsing to ASTs, SSA, and optimizations, we'll explore the steps of the Go compilation pipeline with simple code examples and analogies to make sense of it all.

## Underrust: What is the cost of Mutex, RwLock and AtomicPtr?

DevFeed: [Underrust: What is the cost of Mutex, RwLock and AtomicPtr?](<https://devfeed.tech/articles/underrust-what-is-the-cost-of-mutex-rwlock-and-atomicptr-35479.md>)

Original publisher: [Read original article](<https://darkcoding.net/software/underrust-mutual-exclusion/>)

Author: Graham King

Published: 2025-05-05T20:05:00Z

Content type: tutorial

Language: en

Sources: [Graham King](<https://devfeed.tech/sources/graham-king.md>)

Topics: [Rust](<https://devfeed.tech/topics/rust.md>), [Concurrent Programming](<https://devfeed.tech/topics/concurrent-programming.md>), [x86](<https://devfeed.tech/topics/x86.md>), [cpu](<https://devfeed.tech/topics/cpu.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [concurrent](<https://devfeed.tech/tags/concurrent.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [cycles](<https://devfeed.tech/tags/cycles.md>), [locking](<https://devfeed.tech/tags/locking.md>), [performance](<https://devfeed.tech/tags/performance.md>), [rust](<https://devfeed.tech/tags/rust.md>), [software](<https://devfeed.tech/tags/software.md>), [synchronization](<https://devfeed.tech/tags/synchronization.md>), [underrust](<https://devfeed.tech/tags/underrust.md>)

### AI overview

A Rust-focused analysis uses assembly output to examine the cost of Mutex, RwLock, and atomic operations for many concurrent readers and an occasional writer. It scopes the discussion to Linux and x86, noting that the fast-path operations discussed are roughly in the range of 20 to 30 CPU cycles.

### Source excerpt

With many concurrent readers and a single occasional writer, which mutual exclusion primitive should you use? Let's look at the assembly to find out.

## Underrust: How does u128 work on a 64-bit processor?

DevFeed: [Underrust: How does u128 work on a 64-bit processor?](<https://devfeed.tech/articles/underrust-how-does-u128-work-on-a-64-bit-processor-35481.md>)

Original publisher: [Read original article](<https://darkcoding.net/software/underrust-u128/>)

Author: Graham King

Published: 2025-04-05T20:45:00Z

Content type: tutorial

Language: en

Sources: [Graham King](<https://devfeed.tech/sources/graham-king.md>)

Topics: [cpu](<https://devfeed.tech/topics/cpu.md>), [x86](<https://devfeed.tech/topics/x86.md>), [Rust](<https://devfeed.tech/topics/rust.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [code](<https://devfeed.tech/tags/code.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [processors](<https://devfeed.tech/tags/processors.md>), [rust](<https://devfeed.tech/tags/rust.md>), [simd](<https://devfeed.tech/tags/simd.md>), [software](<https://devfeed.tech/tags/software.md>), [sse](<https://devfeed.tech/tags/sse.md>), [underrust](<https://devfeed.tech/tags/underrust.md>), [x86](<https://devfeed.tech/tags/x86.md>)

### AI overview

The article explains how Rust u128 values work on x86-64 processors whose general-purpose registers are limited to 64 bits. It describes splitting values across two registers and distinguishes this from the use of 128-bit SSE registers for SIMD operations.

### Source excerpt

Wherein our hero learns the arcane secrets of the u128 sword in the depths of the Underrust.

## Avoiding Compiler Elimination in Code Microbenchmarks

DevFeed: [Avoiding Compiler Elimination in Code Microbenchmarks](<https://devfeed.tech/articles/you-are-going-to-need-it-25608.md>)

Original publisher: [Read original article](<https://www.romainguy.dev/posts/2024/you-are-going-to-need-it/>)

Author: Romain Guy

Published: 2024-12-13T00:00:00Z

Content type: tutorial

Language: en

Sources: [Posts on Romain Guy](<https://devfeed.tech/sources/posts-on-romain-guy.md>)

Topics: [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [Code](<https://devfeed.tech/topics/code.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [Benchmark](<https://devfeed.tech/topics/benchmark.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [assembly](<https://devfeed.tech/tags/assembly.md>), [benchmark](<https://devfeed.tech/tags/benchmark.md>), [benchmarking](<https://devfeed.tech/tags/benchmarking.md>), [benchmarks](<https://devfeed.tech/tags/benchmarks.md>), [code](<https://devfeed.tech/tags/code.md>), [compare](<https://devfeed.tech/tags/compare.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [developer](<https://devfeed.tech/tags/developer.md>), [graphics](<https://devfeed.tech/tags/graphics.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [measurement](<https://devfeed.tech/tags/measurement.md>), [performance](<https://devfeed.tech/tags/performance.md>)

### AI overview

This article explains how compiler and runtime optimizations can eliminate the computation being measured in a microbenchmark. Using a comparison between value.pow(2f) and value * value, it shows why inspecting generated code and introducing a carefully placed side effect are necessary for a valid measurement.

### Source excerpt

Optimizing code can be a difficult task because there are so many traps you need to avoid at every step of the way. Today I want to focus on one of the (numerous) benchmarking traps, which you may have run into, and that I myself encounter regularly. Let's imagine you are trying to optimize code, and you notice the use of a value.pow(2f). One obvious way to optimize this is to replace the function call with a multiplication (value * value), but is it worth it? Since you are a diligent engineer, you decide to write a microbenchmark to compare before and after:

## PIE Instruction Extensions on ESP32-P4 and ESP32-S3

DevFeed: [PIE Instruction Extensions on ESP32-P4 and ESP32-S3](<https://devfeed.tech/articles/explore-the-pie-capabilities-on-the-esp32-p4-13674.md>)

Original publisher: [Read original article](<https://developer.espressif.com/blog/2024/12/pie-introduction/>)

Author: John Lee

Published: 2024-12-05T00:00:00Z

Content type: tutorial

Language: en

Sources: [Blog on Developer Portal](<https://devfeed.tech/sources/blog-on-developer-portal.md>)

Topics: [ESP32-P4](<https://devfeed.tech/topics/esp32-p4.md>), [ESP32-S3](<https://devfeed.tech/topics/esp32-s3.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [Hardware](<https://devfeed.tech/topics/hardware.md>), [Inference](<https://devfeed.tech/topics/inference.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [real-time](<https://devfeed.tech/topics/real-time.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [algorithms](<https://devfeed.tech/tags/algorithms.md>), [assembly](<https://devfeed.tech/tags/assembly.md>), [blog](<https://devfeed.tech/tags/blog.md>), [dsp](<https://devfeed.tech/tags/dsp.md>), [esp32-p4](<https://devfeed.tech/tags/esp32-p4.md>), [esp32-s3](<https://devfeed.tech/tags/esp32-s3.md>), [hardware](<https://devfeed.tech/tags/hardware.md>), [inference](<https://devfeed.tech/tags/inference.md>), [pie](<https://devfeed.tech/tags/pie.md>), [real-time](<https://devfeed.tech/tags/real-time.md>)

### AI overview

This tutorial examines PIE processor instruction extensions on ESP32-S3 and ESP32-P4. It covers their instruction architecture, formats, applications, and differences in hardware-loop support and accumulator size.

### Source excerpt

The recent breakthroughs in artificial intelligence technology in such fields as image recognition, speech recognition, and natural language processing have opened up more possibilities for embedded system applications. When attempting to deploy AI model inference on embedded devices such as the ESP32-P4, we always strive to minimize inference time as much as possible to meet real-time requirements.

## Open Sourcing DOS 4

DevFeed: [Open Sourcing DOS 4](<https://devfeed.tech/articles/open-sourcing-dos-4-21856.md>)

Original publisher: [Read original article](<https://www.hanselman.com/blog/open-sourcing-dos-4>)

Author: Scott Hanselman

Published: 2024-04-25T16:46:13Z

Content type: release

Language: en

Sources: [Scott Hanselman](<https://devfeed.tech/sources/scott-hanselman.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [Microsoft](<https://devfeed.tech/topics/microsoft.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [Operating system](<https://devfeed.tech/topics/operating-system.md>), [ibm](<https://devfeed.tech/topics/ibm.md>), [Software](<https://devfeed.tech/topics/software.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [code](<https://devfeed.tech/tags/code.md>), [ibm](<https://devfeed.tech/tags/ibm.md>), [microsoft](<https://devfeed.tech/tags/microsoft.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [os](<https://devfeed.tech/tags/os.md>), [release](<https://devfeed.tech/tags/release.md>), [software](<https://devfeed.tech/tags/software.md>), [source](<https://devfeed.tech/tags/source.md>), [technical](<https://devfeed.tech/tags/technical.md>)

### AI overview

Microsoft and IBM are releasing the source code for MS-DOS 4.00 under the MIT license, alongside unreleased beta binaries, documentation PDFs, and disk images. The article describes the software's history and the archival work behind the release.

### Source excerpt

See the canonical version of this blog post at the Microsoft Open Source Blog! Ten years ago, Microsoft released the source for MS-DOS 1.25 and 2.0 to the Computer History Museum, and then later republished them for reference purposes. This code holds an important place in history and is a fascinating read of an operating system that was written entirely in 8086 assembly code nearly 45 years ago. Today, in partnership with IBM and in the spirit of open innovation, we're releasing the source code to MS-DOS 4.00 under the MIT license. There's a somewhat complex and fascinating history behind the 4.0 versions of DOS, as Microsoft partnered with IBM for portions of the code but also created a branch of DOS called Multitasking DOS that did not see a wide release. https://github.com/microsoft/MS-DOS A young English researcher named Connor "Starfrost" Hyde recently corresponded with former Microsoft Chief Technical Officer Ray Ozzie about some of the software in his collection. Amongst the floppies, Ray found unreleased beta binaries of DOS 4.0 that he was sent while he was at Lotus. Starfrost reached out to the Microsoft Open Source Programs Office (OSPO) to explore releasing DOS 4 source, as he is working on documenting the relationship between DOS 4, MT-DOS, and what would eventually become OS/2. Some later versions of these Multitasking DOS binaries can be found around the internet, but these new Ozzie beta binaries appear to be much earlier, unreleased, and also include the ibmbio.com source. Scott Hanselman, with the help of internet archivist and enthusiast Jeff Sponaugle, has imaged these original disks and carefully scanned the original printed documents from this "Ozzie Drop". Microsoft, along with our friends at IBM, think this is a fascinating piece of operating system history worth sharing. Jeff Wilcox and OSPO went to the Microsoft Archives, and while they were unable to find the full source code for MT-DOS, they did find MS DOS 4.00, which we're releasing to

## For Loops and More in Go

DevFeed: [For Loops and More in Go](<https://devfeed.tech/articles/for-loops-and-more-in-go-22233.md>)

Original publisher: [Read original article](<https://www.ardanlabs.com/blog/2024/03/for-loops-and-more-in-go.html>)

Published: 2024-03-12T00:00:00Z

Content type: tutorial

Language: en

Sources: [William Kennedy](<https://devfeed.tech/sources/william-kennedy.md>)

Topics: [Go Language](<https://devfeed.tech/topics/go-language.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>)

Tags: [ardan-labs](<https://devfeed.tech/tags/ardan-labs.md>), [assembly](<https://devfeed.tech/tags/assembly.md>), [blog](<https://devfeed.tech/tags/blog.md>), [bugs](<https://devfeed.tech/tags/bugs.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [go](<https://devfeed.tech/tags/go.md>), [go-programming](<https://devfeed.tech/tags/go-programming.md>), [golang](<https://devfeed.tech/tags/golang.md>), [loops](<https://devfeed.tech/tags/loops.md>), [programming](<https://devfeed.tech/tags/programming.md>), [syntax](<https://devfeed.tech/tags/syntax.md>)

### AI overview

A tutorial on writing for loops in Go, covering loop termination, the assembly generated for an empty loop, loops with multiple variables, and labeled breaks around switch statements. It explains how these forms work and how understanding them can help prevent bugs.

### Source excerpt

Introduction Looping seems like a basic topic: Write a for loop with a termination condition, and you're done. However there's a lot of ways you can write a for loop in Go. Knowing more about the different versions of for will help you choose the best option to accomplish your tasks and it will help you prevent some bugs. Some Assembly Required What kind of code is generated by the compiler for a for loop? To keep things simple, I will produce the assembly for an empty loop:

## Writing a Debugger From Scratch - DbgRs Part 7 - Disassembly

DevFeed: [Writing a Debugger From Scratch - DbgRs Part 7 - Disassembly](<https://devfeed.tech/articles/writing-a-debugger-from-scratch-dbgrs-part-7-disassembly-39739.md>)

Original publisher: [Read original article](<https://www.timdbg.com/posts/writing-a-debugger-from-scratch-part-7/>)

Author: Tim Misiak

Published: 2024-01-18T16:10:45Z

Content type: tutorial

Language: en

Sources: [TimDbg](<https://devfeed.tech/sources/timdbg.md>)

Topics: [debug](<https://devfeed.tech/topics/debug.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [x86](<https://devfeed.tech/topics/x86.md>), [Rust](<https://devfeed.tech/topics/rust.md>), [Iced](<https://devfeed.tech/topics/iced.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [code](<https://devfeed.tech/tags/code.md>), [debugger](<https://devfeed.tech/tags/debugger.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [encoding](<https://devfeed.tech/tags/encoding.md>), [memory](<https://devfeed.tech/tags/memory.md>), [rust](<https://devfeed.tech/tags/rust.md>), [windbg](<https://devfeed.tech/tags/windbg.md>), [x86](<https://devfeed.tech/tags/x86.md>)

### AI overview

This tutorial installment explains how the DbgRs low-level debugger adds disassembly for Windows x64 code. It introduces the challenges of decoding x86 instruction encodings and describes using a Rust disassembly crate with iced-x86 instead of implementing a complete disassembler from scratch.

### Source excerpt

(New to this series? Consider starting from part 1) At the end of the last post, DbgRs could display stacks, which is the single most powerful tool in the debugging arsenal. But once you have those frames to examine, you need to understand what that code was doing. Source code is one place to look at, but if you're using a low level debugger like WinDbg or KD there's a good chance you need to see the assembly code, which means we need a disassembler.

## Micro-optimizations in Kotlin -- 2

DevFeed: [Micro-optimizations in Kotlin -- 2](<https://devfeed.tech/articles/micro-optimizations-in-kotlin-2-25600.md>)

Original publisher: [Read original article](<https://www.romainguy.dev/posts/2024/micro-optimizations-in-kotlin-2/>)

Author: Romain Guy

Published: 2024-01-16T00:00:00Z

Content type: tutorial

Language: en

Sources: [Posts on Romain Guy](<https://devfeed.tech/sources/posts-on-romain-guy.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Code](<https://devfeed.tech/topics/code.md>), [inlining](<https://devfeed.tech/topics/inlining.md>), [Android](<https://devfeed.tech/topics/android.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [assembly](<https://devfeed.tech/tags/assembly.md>), [code](<https://devfeed.tech/tags/code.md>), [developer](<https://devfeed.tech/tags/developer.md>), [graphics](<https://devfeed.tech/tags/graphics.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [inlining](<https://devfeed.tech/tags/inlining.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [performance](<https://devfeed.tech/tags/performance.md>)

### AI overview

This article examines micro-optimizations for Kotlin's Float.sign and Double.sign APIs. It explains their handling of negative and positive values, signed zero, and NaN, then compares the Kotlin implementation with Android's generated AArch64 assembly. The article shows how inlining and intrinsics eliminate function calls and translate the implementation into bit manipulation.

### Source excerpt

In the previous post, we saw how we could micro-optimize Int.sign to save a few instructions. We are now going to turn to Float.sign (and by extension Double.sign). Float.sign returns the sign of single-precision float value as a single-precision float value. While similar to Int.sign, this API must handle a special cases: Not-a-Number (NaN). The exact behavior of the API is that it will return: -1.0f if the value is negative +/-0.0f if the value is zero (floats can encode both positive and negative zero) 1.0f if the value is positive NaN if the value is NaN An easy way to implement this API ourselves is to return the input when the input equals 0.0f or NaN, and to return the input's sign copied onto 1.0f otherwise. Translated to code, we can write:

## Weird things I learned while writing an x86 emulator

DevFeed: [Weird things I learned while writing an x86 emulator](<https://devfeed.tech/articles/weird-things-i-learned-while-writing-an-x86-emulator-39728.md>)

Original publisher: [Read original article](<https://www.timdbg.com/posts/useless-x86-trivia/>)

Author: Tim Misiak

Published: 2023-02-02T07:54:20Z

Content type: article

Language: en

Sources: [TimDbg](<https://devfeed.tech/sources/timdbg.md>)

Topics: [Emulator](<https://devfeed.tech/topics/emulator.md>), [x86](<https://devfeed.tech/topics/x86.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [cpu](<https://devfeed.tech/topics/cpu.md>), [Encoding](<https://devfeed.tech/topics/encoding.md>), [debugging](<https://devfeed.tech/topics/debugging.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [execution](<https://devfeed.tech/topics/execution.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [breakpoint](<https://devfeed.tech/tags/breakpoint.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [code](<https://devfeed.tech/tags/code.md>), [compilers](<https://devfeed.tech/tags/compilers.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [emulator](<https://devfeed.tech/tags/emulator.md>), [encoding](<https://devfeed.tech/tags/encoding.md>), [execution](<https://devfeed.tech/tags/execution.md>), [software](<https://devfeed.tech/tags/software.md>), [time-travel-debugging](<https://devfeed.tech/tags/time-travel-debugging.md>), [x86](<https://devfeed.tech/tags/x86.md>)

### AI overview

The author shares x86 and amd64 encoding trivia learned while writing a CPU emulator for Time Travel Debugging. The article explains why alternate instruction encodings matter for software breakpoints, code size, compiler behavior, and CPU understanding.

### Source excerpt

If you've read my first post about assembly language, you might expect that this is another post on how to understand assembly language. I will write more about that at some point, but this post is not that. Instead, this post is going to talk about some of the weird things and random trivia I learned while writing an x86 and amd64 emulator. The emulator I wrote was for Time Travel Debugging.

## The faker's guide to reading (x86) assembly language

DevFeed: [The faker's guide to reading (x86) assembly language](<https://devfeed.tech/articles/the-faker-s-guide-to-reading-x86-assembly-language-39723.md>)

Original publisher: [Read original article](<https://www.timdbg.com/posts/fakers-guide-to-assembly/>)

Author: Tim Misiak

Published: 2023-01-03T16:20:24Z

Content type: tutorial

Language: en

Sources: [TimDbg](<https://devfeed.tech/sources/timdbg.md>)

Topics: [Assembly](<https://devfeed.tech/topics/assembly.md>), [x86](<https://devfeed.tech/topics/x86.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Reverse Engineering](<https://devfeed.tech/topics/reverse-engineering.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Ghidra](<https://devfeed.tech/topics/ghidra.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [c](<https://devfeed.tech/tags/c.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [ghidra](<https://devfeed.tech/tags/ghidra.md>), [guide](<https://devfeed.tech/tags/guide.md>), [ida](<https://devfeed.tech/tags/ida.md>), [language](<https://devfeed.tech/tags/language.md>), [reading](<https://devfeed.tech/tags/reading.md>), [reverse-engineering](<https://devfeed.tech/tags/reverse-engineering.md>), [rust](<https://devfeed.tech/tags/rust.md>), [tools](<https://devfeed.tech/tags/tools.md>), [x86](<https://devfeed.tech/tags/x86.md>)

### AI overview

This tutorial explains why reading x86 assembly is generally easier than writing it and why it helps developers understand native-code programs. It presents assembly reading as useful for troubleshooting, understanding compiled behavior, and reverse engineering code when source is unavailable, while noting that it complements tools such as Ghidra and IDA.

### Source excerpt

Assembly code scares people. There's a good reason for that. For many people, writing code in assembly language seems equivalent to writing code in ancient dwarven runes, or calculating pi in roman numerals. The fact that RollerCoaster Tycoon was almost completely written in assembly language sounds almost too amazing to be true. Many programmers view assembly language as some combination of ancient, arcane, inscrutable, useless, and complex. Despite all that, I have a secret to share with you.

## Underrust: Multiple Return Values

DevFeed: [Underrust: Multiple Return Values](<https://devfeed.tech/articles/underrust-multiple-return-values-35460.md>)

Original publisher: [Read original article](<https://darkcoding.net/software/rust-multiple-return-types/>)

Author: Graham King

Published: 2022-10-18T07:00:00Z

Content type: tutorial

Language: en

Sources: [Graham King](<https://devfeed.tech/sources/graham-king.md>)

Topics: [Rust](<https://devfeed.tech/topics/rust.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [LLVM](<https://devfeed.tech/topics/llvm.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [avx](<https://devfeed.tech/tags/avx.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [rust](<https://devfeed.tech/tags/rust.md>), [simd](<https://devfeed.tech/tags/simd.md>), [software](<https://devfeed.tech/tags/software.md>), [underrust](<https://devfeed.tech/tags/underrust.md>)

### AI overview

This article examines how Rust returns values at the ABI and assembly levels. It covers integer and floating-point returns, multiple values, structs, function pointers, caller-stack returns, return-value optimization, and an LLVM SIMD optimization using AVX registers.

### Source excerpt

How does Rust return values, and does it make any difference to us programmers?

[Next page](<https://devfeed.tech/topics/assembly.md?cursor=WyIyMDIyLTEwLTE4VDA3OjAwOjAwKzAwOjAwIiwgIjcwYTM4OGU2LTg1OWEtNDA3My1hZDIzLTFlNzgyMDc2Y2JmOCJd>)