DEV Community: Benjamin

Learning Assembly; Data

Benjamin — Mon, 24 Aug 2026 12:11:48 +0000

In our previous episodes ;
My quest to learn Assembly programming
Code to CPU

Today, we are going to talk about data

On our journey toward assembly programming, we need to understand two key ways computers represent data: binary and hexadecimal.

At their core, computer processors only understand one fundamental thing: is the power on (1) or off (0)?

These two states are what we call binary. From this simple representation of 1s and 0s comes everything we use daily on our computers: software, GUIs, CLI, the web browser you are using right now, etc…

A single 1 or 0 is called a bit.

When we group these bits together by 4, we use the term nibble.
When we group these bits together by 8, we use the term byte.
We are going to deal with these terms all the time.

In high-level programming, we use types like char, int, or float, which each occupy a specific number of bytes in memory. For instance, a standard integer is typically 4 bytes (32 bits), allowing us to represent a specific range of numbers.

If you want to learn to count with binary, and I highly recommend to know how this works, you can see those videos ;
https://www.youtube.com/watch?v=puaaRoWL-Ec
https://www.youtube.com/watch?v=LpuPe81bc2w

Now you know the principle of binary. But it is extremely impractical to write or read. Imagine having to write or debug something like this in your code:
11010101000101111101001010100

Not practical at all!

In most programming languages, we write numbers in base 10 (decimal) because ), it’s just easier and natural to you. But there is another crucial base used in low-level programming: hexadecimal.

Hexadecimal is base 16, using sixteen distinct symbols: 0123456789ABCDEF.

If you are not familiar with this concept at all, go watch this incredible video ; https://www.youtube.com/watch?v=bt4zavZCrLg

In that video, you'll see examples like 0x3F8 (which equals 1016 in decimal). We put 0x in front of hexadecimal values so the compiler and developer know it’s in base 16.

But WHY ?

Why do we use hexadecimal values in assembly and low-level development? Why does it matter so much?

We use hexadecimal because it is binary in disguise.

A value like 0xFF translates to binary effortlessly because of one very important property: each character in a hexadecimal string corresponds to exactly one nibble (4 bits).
0xFF = 1111 1111
as F = 1111

This property becomes critical when we start looking at memory addresses. If you are interested in cybersecurity, reverse engineering, or CTFs, mastering this is non-negotiable.

Another example, if you have a 2-byte value like 0x3A1C and you need to modify the second byte (1C), you can instantly pinpoint where it is. But if you only had its decimal equivalent which is 14876, it would be impossible to know at a glance which digits control which bits in memory.
This perfect alignment between hexadecimal and binary exists simply because 16 is a power of 2 (2^4=16).

Conclusion

Now you have everything you need to understand how data is represented at a low level! In the upcoming articles, we will explore the internal structure of the CPU and see what tools we use to manipulate this data.
I hope you enjoyed this article! If you liked it, don’t hesitate to follow me so you don't miss the next post.

Learning Assembly; Code to CPU

Benjamin — Sun, 09 Aug 2026 11:01:58 +0000

In the previous episode my quest to learn assembly programming, we started mapping out our goals for learning Assembly programming.

Before even touching assembly, we need to cover some prerequisite knowledge that will make much more sense later.

Often in life, when tackling a big subject, the hardest part is figuring out what prerequisites we actually need to understand the topic. Today, we need to explore how we go from our source code to CPU instructions.

Most tutorials will talk about C programming and expect readers to already know the language. Obviously... I'm going to do pretty much the same thing but don't worry, not exactly.

Today, we will cover not only C compilation (the broader process of creating a binary from our code) but also how other programming languages handle this journey.

If you think about it, at some point, the code we write or that an AI writes for us—has to be transformed by another piece of software to become an executable.

C Programming

C is a compiled programming language, meaning we have to use a compiler (another software) to turn it into an executable program we can actually run.

Because C is considered a low-level language, a lot of assembly tutorials love to talk about it due to how this transformation happens. When you use GCC or Clang (two different compilers), your code goes through four distinct phases:
• Phase 1: Preprocessing
• Phase 2: Compilation
• Phase 3: Assembly
• Phase 4: Linking

Phase 1 is "easy" (well, nothing is ever truly easy). It removes comments and processes everything starting with a #, like #ifndef, #define, etc.

Phase 2 has a slightly confusing name. The compilation phase is where we actually generate Assembly! Yes, the very same Assembly we are trying to learn. This is the last step where everything is still human-readable. The compiler produces these instructions for the CPU to execute later. This is exactly where we will intervene in future articles: we won't write C code, we will write assembly directly. Pure instructions for our CPU.

Phase 3 is where we leave the human-readable world. Everything produced by Phase 2 is converted into object files. From here on out, it’s for our machine to use. Even the machine cannot understand raw assembly text; for our hardware, assembly is just a text file at the end of the day. Phase 3 turns it into raw binary.

Phase 4 is where the Linker appears to bridge the gap between your code and the libraries you used. If your program calls specific library functions, the linker makes sure the executable knows exactly where to find them.

And that’s it! That’s why people love explaining C compilation: it lets you see very quickly how things work and exactly where we, as assembly programmers, fit into the picture.

What about other programming languages?

How do they work? Do you know how Python code is treated? Or Rust? What about Java (no one wants to use Java anyway, haha)?

While we won't look at every single language out there, let's look at a few main strategies:

Rust
Rust is easily the most hyped language of recent years, the one everyone is talking about, and maybe the future of programming.

It doesn't have C's exact Phase 1 (no preprocessor #define). Instead, the Rust compiler performs strict safety checks—which is where most of the love for this language comes from—before producing assembly code and handing it off to a linker.

Java
Java was created with a very specific philosophy. It uses a virtual machine (the JVM) to get the job done. This isn't the type of virtual machine you run via a hypervisor; we are talking about a "Process Virtual Machine" or "Application Virtual Machine". The Java compiler produces bytecode, which is then executed by the JVM using a JIT (Just-In-Time) compiler.

Bytecode is not assembly. In Java's standard compilation phase, assembly text is completely skipped.

Python
Python shares a similar philosophy with Java but approaches it differently. Your code is translated into bytecode, and that bytecode is executed by an interpreter.

Take CPython, for example (the standard Python tool). CPython itself is written in C, meaning it went through the 4 phases of C compilation we discussed earlier to become an executable on your machine. When you run a script, CPython reads your code, turns it into bytecode, and executes it on its own virtual engine.

Now you understand a bit better why C is so often used to explain how computers work compared to other languages. There are many compilation and execution strategies out there, and some don't rely on human-readable assembly files at all.

Epilogue

Of course, all of these explanations are simplified. For instance, tools in Java and Python can show you assembly code, not to run it directly, but to let developers inspect what’s happening under the hood.

However, this is more than enough to understand how our code goes from raw text to CPU instructions.

That’s all we need for today to keep moving forward in our next articles. I hope you enjoyed it! If you want to catch the next posts, don't hesitate to follow me.

My quest to learn Assembly programming ; Introduction

Benjamin — Sun, 02 Aug 2026 16:19:07 +0000

In 2026, in the AI era, why should anyone want to learn Assembly programming? Why would someone want to go that far into the low-level programming world? And why would you want to share a quest that takes so much time with other people, especially one that probably won't interest that many of them?

My background

Initially, I wasn't even a developer. I worked in sales within the financial markets. Some time ago, I decided to leave that world behind to pursue something I’ve always wanted to do: tech, programming, and cybersecurity.

I joined 42 school in Paris, where I live, to learn and practice programming. Before entering the school, we had a month-long selection process called the "Piscine" (the swimming pool). During this intensive month, you have to learn C, complete series of exercises, work on team projects during weekends, and pass four exams. At the end of it, you either get accepted or you don't.

Luckily enough, I was accepted. While we learn many different concepts here, we start with C. But why this obsession with C ?

The C programming language is considered a low-level language. This means it is closer to the machine; you have to do a lot of manual work to achieve even the basics of what Python, JavaScript, or Java do automatically. The school starts with this language to ensure you truly understand what happens "behind the scenes" of how other programming languages work.

At 42, I have programmed graphical projects, a shell, a library, and more all in C. This has helped me understand how the digital world actually operates.

But is C really that low-level?

While it is often considered so, there is a world where you can go even lower. A world where you write instructions directly to your CPU. Those instructions are Assembly.

At 42, this isn't something you normally encounter until near the end of the Common Core (the mandatory curriculum you must finish before starting a "specialization").
But exploring this has helped me shape the "whys" I opened this article with.

Why would you want to learn that?

To become a better computer scientist, and to deeply understand how a computer works and how my code is executed.

I am also interested in cybersecurity, and I have already tackled some challenges in reverse engineering and binary exploitation. Both are deeply connected to understanding the lowest levels of computers.
In this AI era, we need highly competent people more than ever. While AI can boost productivity, human analytical thinking remains crucial and perhaps even more so today than before. In a Darwinian system, those who adapt best will survive. There are no shortcuts to becoming one of the best; you have to put in the work, acquire deep knowledge, and dedicate yourself to efforts that most people will shy away from.

There is also a simpler, more candid answer and I truly mean this: I just want to know how it works, and I love learning about things that fascinate me. This journey will bring me as close to the machine as possible. I want to become a better computer scientist (even if I don't know if I'll ever officially be considered one). But honestly? The other part of it is just that it’s fun. I simply enjoy learning and working on this.

Why share this journey?

I already share a lot here through various articles (but my first here on dev.to). I also run a YouTube channel in French (my native language) and share content across different platforms. The "why" is always the same: I couldn't find the resources I liked, so I decided to create them myself, my way. My hope is that it will help others on their own quest or teach them something new. If I can successfully help just one person, I’ve done my job, and I'm happy to have brought something of value to the table.

How am I going to do this?

I will share my journey through a series of articles, detailing everything I learn, the resources I use, and the exercises I complete. Breaking it all down into short, digestible posts like this one.
I hope this introduction makes you want to stick around and learn with me. See you soon!