# ASM Published articles for ASM. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Land ahoy: leaving the Sea of Nodes DevFeed: [Land ahoy: leaving the Sea of Nodes]() Original publisher: [Read original article]() Author: Darius Mercadier Published: 2025-03-25T00:00:00Z Content type: article Language: en Sources: [V8]() Topics: [Compiler](), [V8](), [JavaScript](), [WebAssembly](), [Graphs]() Tags: [architectures](), [asm](), [blog-post](), [compiler](), [internals](), [javascript](), [performance](), [technical](), [webassembly]() ### AI overview This V8 developer article explains the project's move away from the Sea of Nodes intermediate representation toward the more traditional Control-Flow Graph representation used by Turboshaft. It describes the migration status across the JavaScript and WebAssembly compiler pipelines and introduces the historical limitations and technical debt associated with Crankshaft. ### Source excerpt V8's end-tier optimizing compiler, Turbofan, is famously one of the few large-scale production compilers to use Sea of Nodes (SoN). However, since almost 3 years ago, we've started to get rid of Sea of Nodes and fall back to a more traditional Control-Flow Graph (CFG) Intermediate Representation (IR), which we named Turboshaft. By now, the whole JavaScript backend of Turbofan uses Turboshaft instead, and WebAssembly uses Turboshaft throughout its whole pipeline. Two parts of Turbofan still use some Sea of Nodes: the builtin pipeline, which we're slowly replacing by Turboshaft, and the frontend of the JavaScript pipeline, which we're replacing by Maglev, another CFG-based IR. This blog post explains the reasons that led us to move away from Sea of Nodes. The birth of Turbofan and Sea of Nodes # 12 years ago, in 2013, V8 had a single optimizing compiler: Crankshaft. It was using a Control-Flow Graph based Intermediate Representation. The initial version of Crankshaft provided significant performance improvements despite still being quite limited in what it supported. Over the next few years, the team kept improving it to generate even faster code in ever more situations. However, technical debt was starting to stack up and a number of issues were arising with Crankshaft: It contained too much hand-written assembly code. Every time a new operator was added to the IR, its translation to assembly had to be manually written for the four architectures officially supported by V8 (x64, ia32, arm, arm64). It struggled with optimizing asm.js, which was back then seen as an important step towards high-performance JavaScript. It didn't allow introducing control flow in lowerings. Put otherwise, control flow was created at graph building time, and was then final. This was a major limitation, given that a common thing to do when writing compilers is to start with high-level operations, and then lower them to low-level operations, often by introducing additional control flow. Consi ## Breaking Kryptonite's obfuscation: a static analysis approach relying on symbolic execution DevFeed: [Breaking Kryptonite's obfuscation: a static analysis approach relying on symbolic execution]() Original publisher: [Read original article]() Author: Axel "0vercl0k" Souchet Published: 2013-09-16T18:47:00Z Content type: tutorial Language: en Sources: [Diary of a reverse-engineer]() Topics: [obfuscation](), [execution](), [LLVM](), [clang](), [Assembly](), [x86](), [Code]() Tags: [analysis](), [asm](), [assembly](), [clang](), [code](), [llvm](), [obfuscation](), [reverse-engineering](), [static](), [symbolic-execution](), [x86]() ### AI overview This tutorial demonstrates how symbolic execution can break Kryptonite, a proof-of-concept obfuscator that applies semantics-preserving transformations at the LLVM intermediate representation level. It describes a small symbolic execution engine built with IDAPy and Z3Py, using an x86 binary generated from LLVM code for a 32-bit adder. ### Source excerpt Introduction Kryptonite was a proof-of-concept I built to obfuscate codes at the LLVM intermediate representation level. The idea was to use semantic-preserving transformations in order to not break the original program. One of the main idea was for example to build a home-made 32 bits adder to replace the add ... ## Printing Generated Assembly Code From The Hotspot JIT Compiler DevFeed: [Printing Generated Assembly Code From The Hotspot JIT Compiler]() Original publisher: [Read original article]() Author: Martin Thompson (noreply@blogger.com) Published: 2013-06-27T19:24:00Z Content type: tutorial Language: en Sources: [Mechanical Sympathy]() Topics: [Java](), [JIT](), [Compiler](), [Assembly](), [Command-line interface](), [Linux](), [Concurrency]() Tags: [asm](), [assembly](), [command-line](), [compiler](), [concurrent](), [debugging](), [hotspot](), [java](), [jit](), [latency](), [linux]() ### AI overview A tutorial on installing the Hotspot Disassembler Plugin and using Java command-line options to print generated assembly code for a targeted method. It uses a concurrent two-thread latency test involving volatile fields and explains how to inspect JIT-generated output. ### Source excerpt Sometimes when profiling a Java application it is necessary to understand the assembly code generated by the Hotspot JIT compiler. This can be useful in determining what optimisation decisions have been made and how our code changes can affect the generated assembly code. It is also useful at times knowing what instructions are emitted when debugging a concurrent algorithm to ensure visibility rules have been applied as expected. I have found quite a few bugs in various JVMs this way. This blog illustrates how to install a Disassembler Plugin and provides command line options for targeting a particular method. Installation Previously it was necessary to obtain a debug build for printing the assembly code generated by the Hotspot JIT for the Oracle/SUN JVM. Since Java 7, it has been possible to print the generated assembly code if a Disassembler Plugin is installed in a standard Oracle Hotspot JVM. To install the plugin for 64-bit Linux follow the steps below: Download the appropriate binary, or build from source, from https://kenai.com/projects/base-hsdis/downloads On Linux rename linux-hsdis-amd64.so to libhsdis-amd64.so Copy the shared library to $JAVA_HOME/jre/lib/amd64/server You now have the plugin installed! Test Program To test the plugin we need some code that is both interesting to a programmer and executes sufficiently hot to be optimised by the JIT. Some details of when the JIT will optimise can be found here. The code below can be used to measure the average latency between two threads by reading and writing volatile fields. These volatile fields are interesting because they require associated hardware fences to honour the Java Memory Model. import static java.lang.System.out; public class InterThreadLatency { private static final int REPETITIONS = 100 * 1000 * 1000; private static volatile int ping = -1; private static volatile int pong = -1; public static void main(final String[] args) throws Exception { for (int i = 0; i < 5; i++) { final long duratio ## How Software Development Has Become More Complex DevFeed: [How Software Development Has Become More Complex]() Original publisher: [Read original article]() Published: 2006-07-13T15:41:57Z Content type: opinion Language: en Sources: [Blog by Michael Dubakov]() Topics: [Development](), [Programming](), [C++](), [Assembly](), [C#](), [Java](), [C]() Tags: [asm](), [c](), [c-plus-plus](), [c-sharp](), [developer](), [java](), [languages](), [programming](), [software-development]() ### AI overview The author argues that software development has become progressively more complex as programmers moved from assembler and simple languages to libraries, object-oriented programming, templates, and modern web technologies. The article emphasizes the growing knowledge required to work effectively with languages such as C++, Java, and C#, as well as web technologies. ### Source excerpt With years the software development becomes more and more complicated. I remember 8bits CPU assembler for home computers. You only need to understand very few basic principles to write a program on it. Also there weren't many syntactic constructions in it. However, assembler allowed creating any program you want. Assembler is easy to learn. I doubt that experienced developer who hadn't know asm before will not learn it in one or two days to write programs. As for me, Assembler has only one problem: to write even simple program you need to type many lines of unobvious code, which is hard to read and understand. This brings us to a higher level: Pascal and C were really powerful languages. They were simple, almost like assembler. But a problem appeared on the scene. The name of the problem was 'libraries'. First libraries were simple, but to be effective you had to know these libraries. The next step was made with appearing of Object Oriented languages such as C++. OOP is great paradigm and improves development performance. However it needs additional knowledge beside the language. To learn OOP (from my point of view) one needs 2-3 years of development experience. With appearing of OOP many libraries were born. To be effective you had to know something monstrous such MFC. Time passed and new language extensions appeared. I mean templates in C++ and libraries written with them. From one side these libraries greatly improved developers' performance by covering common programming patterns such lists, arrays etc. From other side you need to learn new library. Understanding of templates and learning standard template library will takes more than a year. As shown above to be effective with C++ you need 5+ years of experience (3 year of OOP paradigm and 2 years for language itself and common libraries). Modern languages C# or Java require a year or two less. So, to be effective programmer in one of the modern language (such C++, Java or C#) you need 3-5 years of experience.