Forem: Annurdien Rasyid

What makes ARM... ARM?

Annurdien Rasyid — Tue, 18 Nov 2025 08:09:44 +0000

You're probably reading this on an ARM chip. No, really. If it's a phone, 100%. A new Mac? Yep. A Windows laptop? Uh oh, look out, Intel. Let's fall down the rabbit hole of what this 'ARM' thing actually is.

It's one of those things that’s everywhere, but no one ever really explains.

The First Rabbit Hole: What is ARM?
The Big Showdown: RISC vs. CISC
The Heart of the Matter: The Instruction Set
- The Load/Store Philosophy (aka "The No Touchy Rule")
- Conditional Love (and Execution)
- The Squeezy Boy: The Thumb Instruction Set
The M1-llion Dollar Question: Why Did Apple Switch?
Lessons from the Rabbit Hole
Next Steps

TL;DR

ARM isn't a chip: It's a recipe (an architecture) that companies like Apple, Samsung, and Qualcomm license to make their own chips.
It's built on a philosophy called RISC (Reduced Instruction Set Computer). This means it uses a small, simple set of instructions. Think of it as the Marie Kondo of CPUs. ✨
The alternative is CISC (Complex Instruction Set Computer), which is what your typical Intel or AMD (x86) processor is. It's the "throw everything in a drawer" approach. 🌀
The key difference is the "Load/Store" model. ARM instructions can't futz with memory directly. They have to LDR (Load) data into a register, do the math, and STR (Store) it back. This seems slow but is insanely fast in practice.
Apple switched for power, efficiency, and... control. They wanted to build the whole "System on a Chip" (SoC) their own way, and Intel's x86 recipe was holding them back.

The First Rabbit Hole: What is ARM?

This was the first thing that psyched me out. I thought ARM was a company that made chips, like Intel.

Nope!

    /\_____/\
   /  o   o  \
  ( ==  ^  == )
   )         (
  (           )
 ( (  )   (  ) )
(__(__)___(__)__)

(Baaa!)

ARM (the company) is more like an architectural firm. They design blueprints. The big one is the ARM Instruction Set Architecture (ISA). This is, quite literally, the language that the processor speaks.

They license these blueprints out.

Apple 🍎 takes the blueprint and wildly modifies it to create their M-series monsters.
Qualcomm licenses it to build their Snapdragon chips for your Android phone.
Samsung licenses it for their Exynos chips.
Raspberry Pi uses a chip from Broadcom, who... you guessed it... licensed the ARM design.

This is completely different from the x86 world. Intel and AMD own their x86 designs. They design 'em, they build 'em, they sell 'em. You can't license the "Core i9" blueprint and make your own. This licensing model is ARM's first superpower.

The Big Showdown: RISC vs. CISC

Okay, so ARM's blueprint is for a RISC chip. What the heck does that mean?

It stands for Reduced Instruction Set Computer. Its arch-nemesis is CISC, the Complex Instruction Set Computer.

This is the core, A Number 1, most important difference.

Your CISC (Intel x86) processor is a jack of all trades. 🌀 (O_o) It has tons of complex, specialized instructions. Want to add two numbers from memory and store the result back in memory all in one go? It’s got an instruction for that! ADD [memory_A], [memory_B] (I'm simplifying, but you get it).

The philosophy is: "Let's make the hardware (the chip) smart, so the software (your code) can be dumber."

          CISC (x86)
+------------------------------------+
|  ONE BIG, COMPLEX INSTRUCTION      |
|  (e.g., "Add mem A to mem B")      |
+------------------------------------+
| Takes multiple  clock cycles, but  |
| looks like one step to the coder.  |
+------------------------------------+

The RISC (ARM) processor is a minimalist. ✨ (^-^) It has a tiny, fixed set of very simple instructions. All instructions are the same length (e.g., 32 bits). All of them (basically) take one clock cycle to run.

Want to add two numbers from memory? Too bad. The RISC philosophy says, "Hey, only 'Load' and 'Store' instructions get to touch memory. That's it."

So you have to do this instead:

LDR R1, [memory_A] (Load the value from memory A into a temporary bucket called Register 1)
LDR R2, [memory_B] (Load the value from memory B into Register 2)
ADD R3, R1, R2 (Add the numbers in R1 and R2, put the result in R3)
STR R3, [memory_C] (Store the result from R3 into memory C)

                   RISC (ARM)
+--------+ +--------+ +--------+ +---------+
|  LDR   | |  LDR   | |  ADD   | |  STR    |
+--------+ +--------+ +--------+ +---------+
| Each step is tiny, simple, and takes     |
| one clock cycle. More steps, but faster  |
| and way more predictable.                |
+------------------------------------------+

This looks less efficient, right? Four instructions vs. one! But here's the magic: because every instruction is so simple and all the same size, the CPU can chew through them at a ludicrous speed. It can pipeline them, run them out of order, and predict what's coming next with spooky accuracy.

The CISC chip, with its janky, variable-length instructions, is like a Rube Goldberg machine. It's constantly trying to figure out "Wait, is this instruction 1 byte? Or 5 bytes? Or 15?"

David Patterson, one of the godfathers of RISC, pointed out that the x86 manual is over 3,600 pages long. The ARM manual is... also a beast (5,400 pages for ARMv8), but the core RISC philosophy is all about that simple, clean foundation.

The Heart of the Matter: The Instruction Set

Let's dive a little deeper into that RISC philosophy.

The Load or Store Philosophy (aka "The No Touchy Rule")

This is what we just talked about, but it's worth its own section. It's the defining feature.

On an ARM chip, math operations (like ADD, SUB, MUL) can only operate on registers. Registers are those tiny, super-fast "bucket" storage spaces right on the CPU. An x86 chip might have 16 of them. An ARM chip has 32 (or more).

[R1] [R2] [R3] ... [R32]
 (tiny, happy, super-fast buckets!)

This is a brilliant design. Why? Because accessing main RAM is slow. Glacially slow. The CPU is a Formula 1 car, and RAM is a horse drawn buggy. (CPU 🏎️) ... (RAM 🐴)

The CISC (x86) approach lets you build an F1 car that can also be pulled by a horse (ADD [memory]...).

The RISC (ARM) approach says: "That's dumb. Let's build a tiny stable (the registers) right next to the F1 car. We'll use two really fast couriers (LDR and STR) to move hay into the stable. But the F1 car only ever deals with the stable."

This separation makes it way easier to optimize and run things in parallel.

"The RISC philosophy concentrates on reducing the complexity of instructions performed by the hardware. The RISC philosophy provides greater flexibility and intelligence in software rather than hardware."

Source: ACS College of Engineering

Conditional Love (and Execution)

This is a classic ARM feature that's just so cool. (^_−)☆ On older ARM architectures (and it's still around in a different form), you could make almost any instruction conditional.

In normal code, you'd say:
IF (R1 == 5) THEN { ADD R2, R2, 1 }

This IF causes a "branch," a jump in the code that can mess up the CPU's perfect pipeline.

ARM let you do this:
ADD**EQ** R2, R2, 1

This one instruction means: "Add 1 to R2, but only if the 'equal' flag is set." The CPU just runs the instruction, checks the flag, and if it's not set, does... nothing. It just skips it in one cycle. No jump. No pipeline flush. It's... elegant.

The Squeezy Boy: The Thumb Instruction Set

Another classic ARM trick! Those 32-bit instructions were great for performance, but they were chunky. In the '90s, memory was precious. So, ARM introduced "Thumb"—a second instruction set, living right alongside the first, that used 16-bit instructions.

+---------------+   squeeeeeze!   +-------+
|  32-bit Instr |     (>_<)       | 16-bit|
+---------------+                 +-------+

It was a compressed version. The CPU could switch into "Thumb mode," run a bunch of code with double the density, and then switch back to 32-bit mode for the heavy lifting. This was a killer feature for early mobile phones and the Game Boy Advance.

The M1-llion Dollar Question: Why Did Apple Switch?

This is the story, right? Apple, who had been with Intel's x86 for over a decade, just... left. And their new M1 chips destroyed the Intel competition.

It wasn't just RISC vs. CISC. It was control.

Performance-per-Watt: The Intel story for years was "more power, more power, more power." This also meant "more heat, more heat, more heat." Their 12" MacBook was a disaster—it was so hot it had to throttle itself constantly. Intel: (🔥_🔥) (too hot!) Meanwhile, Apple's iPads (running ARM chips) were getting scarily fast... and had no fans. ARM: (•‿•) (so cool) The writing was on the wall. ARM's simple RISC design is just way more power-efficient.
The SoC (System on a Chip): Apple didn't just want to swap a CPU. They wanted to build a single, monolithic beast of a chip.
```
+------------------------------------------+
|           Apple 🍎 M1 (SoC)              |
|                                          |
| +-------+ +-------+ +----------+ +-----+ |
| |  CPU  | |  GPU  | | Neural   | | RAM | |
| | (ARM) | |       | | Engine   | |     | |
| +-------+ +-------+ +----------+ +-----+ |
|                                          |
+------------------------------------------+
```
They put the CPU, the GPU, the AI cores, and even the RAM on the same piece of silicon. This is called a "System on a Chip," and it makes data transfer insanely fast. Intel's model was to sell you a CPU. You'd get your RAM from one company, your GPU from another... Apple wanted to control the whole widget. The ARM license let them do that. Intel's x86 business model did not.
The Gory Details: That Hacker News comment was right. The M1's decoders are monstrous. Because ARM's instructions are all the same simple 32-bit length, Apple could just build a super-wide decoder that shovels 8 instructions per clock cycle into the chip. Intel's best chips were struggling to do 4, because they're constantly parsing that messy, variable-length x86 code.

Lessons from the Rabbit Hole

Simplicity is a Superpower: 💡 RISC's "dumb" instructions are its greatest strength. It moves complexity from the silicon to the software (the compiler), and it turns out, software is way easier to change than a factory.
The Model Matters: ARM's business model (licensing) is just as important as its architecture. It lets companies like Apple innovate in ways that the "buy it off the shelf" x86 world just can't.
Computers Are Still (Beautifully) Cursed: At the end of the day, it's still just a fetch-execute cycle. But how you fetch, and what you execute... well, that's where all the magic is.

Next Steps

This just scratches the surface. We didn't even really get into 64-bit (AArch64), privilege levels (EL0-EL3), or the new kid on the block, RISC-V (which is open source!).

 (\_/)
 (O.o)
(")_(")
(Down the *next* rabbit hole...)

But for now, I want to leave you with the official Arm developer documentation. It's... a lot. But now you know the philosophy. It's not a 3,600-page manual of "what if"s; it's a testament to the power of "Load, Store, and get out of the way."

What's your favorite "simple-is-actually-genius" tech? Let me know!

From Swift to Machine Code

Annurdien Rasyid — Tue, 18 Nov 2025 08:08:29 +0000

Introduction
What is a Compiler?
The Swift Compiler Architecture
Frontend: Source Code to SIL
- Parsing & Lexing
- Want to See the AST for Yourself?
- Example: An Abstract Syntax Tree (AST)
- Semantic Analysis
- Clang Importer
- SIL Generation
- Example: What SIL Actually Looks Like
Mid-End: SIL Optimizations
- SIL Guaranteed Transformations
- SIL Optimizations
- IR Generation
- Example: What LLVM IR Looks Like
Back-End: LLVM Code Generation
- Example: The Final Assembly Output
Linker: Creating the Final Executable
Code Examples from the Swift Compiler
Key Takeaways
Conclusion

Introduction

Here's a fun thought: every time you write some Swift code and slam that "Run" button in Xcode, you're kicking off one of the most ridiculously sophisticated magic tricks in modern software. You're triggering this massive, complex piece of engineering. The Swift compiler grabs your (hopefully) beautiful, human-readable code and transforms it into super-efficient, safe, optimized machine code that your phone or Mac just... runs.

(This was one of those psyching-myself-out moments for me—seriously, it feels like it should be way more complicated than it is! It's like giving a master chef a recipe for a 5-course meal written in crayon. The chef (our compiler) has to:

Figure out what you meant to write (Parsing).
Make sure it's a valid, safe recipe that won't burn the kitchen down (Semantic Analysis).
Make it way more efficient than your crayon scrawl (Optimization).
Finally, translate it into the actual physical movements of their hands and tools (Machine Code).)

Swift first popped into existence back in 2010, thanks to Chris Lattner and his crew at Apple. Their grand plan? To build a shiny new language to replace Objective-C. They wanted something that could do everything Objective-C did, but with way, way better safety, performance, and a developer experience that didn't make you want to tear your hair out. Because who doesn't love a good "out with the old, in with the new" story, right?

So how does this wild transformation actually work? What sorcery happens between you typing print("Hello, World!") and seeing those glorious words appear on your screen? I'm going to walk you through this whole pipeline, step by step. Let's follow the rabbit down the hole.

      (\_/)
      (o.o)
     (")(")o

What is a Compiler?

Before we dive into Swift's peculiarities, let's get on the same page about what this compiler beast even is. If you ask a computer science professor, they'll clear their throat and give you a dusty definition like this:

A compiler is software that translates computer code written in one programming language into another language.

That sounds... kinda simple. And boring. And it massively undersells the drama! A compiler isn't just a basic Google Translate for code.

    +-----------------+      +-----------------+
    | "Hello" (Swift) | ===> | "Hola" (Machine)|  <- This is WRONG
    +-----------------+      +-----------------+

It's not just translating 'Hello' to 'Hola.' It's more like translating, "I'd, y'know, maybe like to get some food... if that's cool, I guess?" into "GO TO RESTAURANT. ORDER TACOS. PAY. EAT." It takes your sometimes-vague intent and turns it into a set of brutally fast, efficient, and unambiguous instructions.

The Swift compiler shoves your code through four main phases, or zones: Frontend, Mid-End, Back-End, and Linker. Each phase grabs the code, does its one job, and passes it along to the next.

The Swift Compiler Architecture

The Swift compiler follows the traditional playbook, but it adds some of its own special sauce.

Why all the stages? You don't try to bake a cake, frost it, and eat it all in one motion. You parse the ingredients (Frontend), mix and bake (Mid-End), decorate (Back-End), and put it on a plate (Linker). Each step builds on the last.

waves hands ~~~ compiler magic ~~~

+-------------------+
|    Frontend       |
| (The Grammar Cop) |
+-------------------+
         |
         v
+---------------------+
|   Mid-End (SIL)     |
| (The Super-Trainer) |
+---------------------+
         |
         v
+---------------------+
|  Back-End (LLVM).   |
| (The Factory Floor) |
+---------------------+
         |
         v
+--------------------------+
|         Linker           |
| (The General Contractor) |
+--------------------------+

What makes Swift so special is its secret weapon: Swift Intermediate Language (SIL). Think of it as a high-level, private language the compiler uses to talk to itself. This SIL thingy allows Swift to perform all kinds of galaxy-brain optimizations that other compilers just, like, can't achieve. (Seriously, what are those other compilers even doing? Twiddling their thumbs?)

Frontend: Source Code to SIL

The frontend is the bouncer and grammar cop at the club. Its job is to take your messy, all-too-human .swift files, make sure they're following the rules, and prepare them for the optimization party. It transforms that text into the fancy SIL we just talked about.

       .--.
      |o_o |
      |:_/ |
     //   \ \
    (|     | )
    /'\_   _/`\
    \___)=(___/

Parsing & Lexing

First, the compiler just... reads your code. A "lexer" scans your file and breaks it into "tokens" (like func, myFunctionName, (, ), {, }). Then a "parser" takes that stream of tokens and tries to build a giant tree structure called an Abstract Syntax Tree (AST).

This is literally a grammar check. Like your 8th-grade English teacher. It sees the func keyword and thinks, "OK, my rulebook says that after func comes an identifier (the name), then (, then some arguments, then ), then maybe -> and a return type, and definitely { and }." If you miss a curly brace, the parser throws up its hands and gives you that error message.

Want to See the AST for Yourself?

This AST thing isn't some mythical, abstract concept. It's real data. And you can actually go look at it!

A fantastic tool called the Swift AST Explorer lets you do just this. You paste your Swift code on the left, and on the right, it instantly shows you the exact, glorious, complicated Abstract Syntax Tree that the compiler builds from it. It's the perfect way to see this first step of the compiler in action. Go paste in a struct or a func and watch the tree get built. It's so cool!

Example: An Abstract Syntax Tree (AST)

Let's say you write this super simple line of Swift:

var x = 1 + 2

The parser chews on this and spits out a data structure (the AST) that, if we drew it as text (like you'd see in the explorer tool!), would look something like this:

(top_level_code
  (variable_declaration 'x'
    (binary_expression '+'
      (integer_literal 1)
      (integer_literal 2)
    )
  )
)

See? It's a tree! top_level_code is the root. It has one branch, a variable_declaration. That declaration has a name (x) and an initial value. The value is a binary_expression (the + operation). And that expression has two branches of its own: the integer_literal 1 and the integer_literal 2.

The compiler now understands your code's structure and intent, not just as a pile of letters.

Semantic Analysis

This is the logic check. Your grammar might be perfect, but you wrote, "The green idea slept furiously." Your teacher is now very confused.

This is the compiler stage that says, "Whoa, hoss. You're trying to add a String to an Int ("hello" + 5). That's semantic nonsense! What does that even mean? I can't find a + function that takes a String and an Int. ERROR!" This is where type checking lives, making sure all your types line up and your code actually makes sense.

Clang Importer

This part is the universal translator on your Star Trek team. It's the bridge that connects Swift to all that "legacy" (read: ancient but necessary) C and Objective-C code out there. It peeks into C/Obj-C "header files" and magically makes them available in Swift as if they were native Swift APIs. It handles all the weird cultural (syntactical) differences, like mapping NSString to String.

SIL Generation

And poof! The grand finale for the frontend. This stage takes that big, beautiful, type-checked AST (which is now guaranteed to be grammatically and logically correct) and converts it into raw Swift Intermediate Language (SIL). This is our first real look at the compiler's internal secret language. It's the super-detailed, high-level set of instructions for the next department (the Mid-End).

Swift Source (.swift) → AST → Type-checked AST → Raw SIL

Example: What SIL Actually Looks Like

Let's use our var x = 1 + 2 example again. The Raw SIL (before any optimization) is super verbose, but it looks something like this. Don't panic, I'll explain it.

// This is our main function
sil @main : $@convention(c) (Int32, UnsafeMutablePointer<Optional<UnsafeMutablePointer<Int8>>>) -> Int32 {
bb0(%0 : $Int32, %1 : $UnsafeMutablePointer<Optional<UnsafeMutablePointer<Int8>>>):

  // 1. Make some space on the stack for our variable 'x'
  %2 = alloc_stack $Int, var, name "x"

  // 2. Load the *type* Int
  %3 = metatype $@thin Int.Type

  // 3. Load the *literal value* 1
  %4 = integer_literal $Builtin.Int64, 1
  %5 = struct $Int (%4 : $Builtin.Int64)

  // 4. Load the *literal value* 2
  %6 = integer_literal $Builtin.Int64, 2
  %7 = struct $Int (%6 : $Builtin.Int64)

  // 5. Find the '+' function for Ints
  %8 = function_ref @$sSi1poiyS2i_SitFZ : $@convention(method) (Int, Int, @thin Int.Type) -> Int

  // 6. CALL the '+' function with 1 and 2
  %9 = apply %8(%5, %7, %3) : $@convention(method) (Int, Int, @thin Int.Type) -> Int

  // 7. STORE the result (which is in %9) into our variable 'x' (which is at %2)
  store %9 to %2 : $*Int

  // ... (lots of cleanup code)...
}

See? It's not magic, it's just a lot of very specific, tiny steps! It has to "allocate" memory for x, load the numbers 1 and 2, find the + function, call the + function, and finally store the result. This verbosity is good—it gives the optimizer tons of tiny pieces to move around and improve.

Mid-End: SIL Optimizations

Okay, we have Raw SIL. Now the Mid-End steps in. This is the personal trainer. Its job is to take that "raw" SIL and make it better, faster, stronger.

This is where Swift gets its superpowers. Because SIL still "understands" high-level Swift concepts (like Array or String, not just raw memory addresses), it can make smarter changes.

       .---.
      /  .-.  \
     |  |   |  |
      \  `-'  /
       `-----'
       /     \
      |       |
      |       |
       \     /
        `---'

SIL Guaranteed Transformations

First, some mandatory checkups. This is the "eat your vegetables" phase. It's the compiler being your spotter at the gym. "Whoa there, you're about to use that myVariable before you put any value in it! That's a crash waiting to happen. Let me stop you right there." This is what guarantees Swift's memory safety and catches things like uninitialized variables. This produces "canonical" SIL.

SIL Optimizations

Now the real fun begins. After we have "canonical" SIL, the compiler runs a ton of optimization passes. These are high-level, Swift-specific transformations. Stuff like:

ARC Optimization: This is the compiler cleaning up after you. It sees where you create an object and figures out exactly where you're done with it, inserting the 'throw this in the trash' (release) code automatically. Then it optimizes that, like "Hmm, you're releasing it on line 10 and retaining it again on line 11? Let's just... not do either of those. Saved two instructions."
Generic Specialization: This is a custom-tailoring shop. It sees your generic, one-size-fits-all Array<T> is being used in one place as Array<Int> and another as Array<String>. So it builds two brand-new, custom-fit versions: one that only works on Ints and one that only works on Strings. These bespoke versions are way faster.
Devirtualization: Replaces a fancy, dynamic "hey, somebody needs to run this function" call (dynamic dispatch) with a simple, direct "call this specific function right here" (static dispatch). Much, much faster.
Dead Code Elimination: Finds code that never, ever gets run (maybe it's inside an if false) and just yeets it into the sun.
Inlining: The compiler sees your code is about to make a "phone call" (function call) to a tiny function that just does a + b. It says, "This is dumb. Why go through all the overhead of a call? I'll just paste the a + b code right here." It hangs up the phone and just does the work.

IR Generation

Once the SIL is as lean and mean as it can possibly be, it's time to translate it again. This step (lib/IRGen) lowers the "Optimized SIL" into LLVM Intermediate Representation (IR). We're now officially leaving the cozy, Swift-specific world and entering the big, scary, platform-agnostic land of LLVM.

Raw SIL → Canonical SIL → Optimized SIL → LLVM IR

Example: What LLVM IR Looks Like

So, our optimizer looked at that bloated SIL and said, "Are you kidding me? You're allocating a variable just to store the result of 1 + 2? I know what 1 + 2 is! It's 3! And you're not even using x! I'm throwing all this junk out."

In a real (but still simple) optimized scenario where you print(1 + 2), the LLVM IR would look totally different. The optimizer would pre-calculate 1 + 2 (a process called "constant folding"). The IR would be translated from SIL and look more like this generic, low-level assembly:

; Define a constant string for "3\n"
@.str = private unnamed_addr constant [3 x i8] c"3\n\00"

; The main function
define i32 @main(i32 %0, i8** %1) {
  ; 1. Get a pointer to our constant string "3\n"
  %3 = getelementptr inbounds [3 x i8], [3 x i8]* @.str, i64 0, i64 0

  ; 2. Call the 'puts' function (a C function to print a string)
  %4 = call i32 @puts(i8* %3)

  ; 3. Return 0
  ret i32 0
}

; Declaration for the external 'puts' function
declare i32 @puts(i8*)

Wait, what? Where did our + go? The optimizer killed it! It saw 1 + 2, did the math at compile time, and just replaced the whole operation with the result, 3. Then it just calls a basic puts function (or a Swift equivalent) to print the string "3".

That's optimization. All that complicated SIL vanished because it wasn't needed.

Back-End: LLVM Code Generation

The Back-End is the factory floor. This is where we forget all about "Swift". The code is now in LLVM IR, a generic compiler language. LLVM is a masterpiece of engineering used by many languages (like Rust, Clang, C++, etc.). Swift is now just one more customer of the giant LLVM factory.

It takes that generic LLVM IR and does the final translation into actual, real-deal machine code for your target architecture (e.g., the ARM chip in your iPhone or the M-series chip in your Mac).

        ._________.
        | .-[ ]-. |
        | |  '  | |
        | |_____| |
        |_________|
       /           \
      /             \
     |_______________|

Example: The Final Assembly Output

This is it! The moment of truth! The LLVM Back-End takes that generic LLVM IR (the puts("3\n") one) and translates it into the specific assembly language for your CPU. If you're compiling for an Apple Silicon Mac (ARM64 architecture), it will look something like this:

; This is ARM64 assembly (for an Apple M-series chip)
_main:
    stp     x29, x30, [sp, -16]! ; Set up the stack (prologue)
    mov     x29, sp

    ; 1. Get the address of our string "3\n"
    adrp    x0, _main.str@PAGE
    add     x0, x0, _main.str@PAGEOFF

    ; 2. Call the 'puts' function (address is in register x0)
    bl      _puts

    ; 3. Set the return value to 0
    mov     w0, #0

    ldp     x29, x30, [sp], 16 ; Clean up the stack (epilogue)
    ret                        ; Return

; The data section, where our string lives
_main.str:
    .asciz  "3\n"

This is the real deal! This is the human-readable version of the binary machine code. No more high-level concepts like 'string' or 'variable.' This is all just: 'load this memory address into CPU register x0,' 'jump to the _puts function,' and 'put a 0 in the return register.'

The CPU just chugs through these instructions one by one. And poof! '3' appears on your screen.

But wait, there's more! The LLVM back-end does another whole round of optimizations on the assembly itself:

Instruction Selection: Picks the best and most efficient machine instructions for the job.
Register Allocation: This is a huge one. Your CPU has a tiny number of super-fast storage buckets (like 32 registers). This stage is a master-level game of Sudoku, figuring out how to juggle all your hundreds of variables to use only those few registers for maximum speed.
Instruction Scheduling: Re-orders the machine instructions to make sure the CPU's internal pipelines are always full and chugging along efficiently.
Peephole Optimizations: Takes one last look and makes tiny, local improvements (e.g., "you're storing a value just to load it right back? I'll just keep it in the register.").

Finally, the code generator spits out object files (.o). This is it! This is machine code! ...Almost.

Linker: Creating the Final Executable

You thought we were done? Ha! Psych!

You've got your .o file (or maybe a bunch of them), but it's just one piece of the puzzle. It's like one part of an IKEA furniture set. Your code (.o file) is the BILLY bookcase. But the instructions say you need a 'hex key' (the print function) and 'screws' (system libraries). Your .o file just has a bunch of "IOUs" for code it needs.

The Linker is the final boss. It's the general contractor who assembles the final, runnable program.

      /----\     /----\
     /      \   /      \
    |        |-|        |
     \      /   \      /
      \----/     \----/

The linker does a few crucial things:

Symbol Resolution: It goes through all your .o files. It sees your code "calling" _puts (a symbol) and finds the actual code for _puts in the operating system's C library. It connects the "call" to the "destination."
Library Linking: It grabs all the system libraries (like libc, Foundation, SwiftCore) and user libraries you said you needed and pulls in just the pieces you actually use.
Relocation: It adjusts all the memory addresses in the code so it can be loaded and run properly by the operating system.
Dead Code Stripping: After pulling in those big libraries, it finds all the code you didn't end up using and tosses it out to make your final executable smaller.

    ╱|、
  (˚ˎ 。7  
   |、˜〵          
  じしˍ,)ノ

Take a short break here.....

Code Examples from the Swift Compiler

Don't just take my word for it. This stuff is all open source! Let's peek under the hood at the actual source code from the Swift compiler repository. This is the belly of the beast.

      .--.
     /    \
    |      | \
     \    /  /
      '--'  /
           /
          /

Parsing: Building the AST

This is the code that reads your text and builds the grammar tree.

// From lib/Parse/Parser.h in swiftlang/swift
class Parser {
public:
  ParserResult<Expr> parseExpr(Diag<> ID);
  ParserResult<Stmt> parseStmt();
  ParserResult<Decl> parseDecl(ParseDeclOptions Flags, bool IsAtStartOfLineOrPreviousHadSemi);

  // Parse a function declaration
  ParserResult<FuncDecl> parseFuncDecl();
};

What this really means:
Look at those function names! parseExpr is the code that gets called when the parser expects an expression (like 1 + 1 or foo()). parseStmt handles a statement (like var x = 5). parseDecl handles a declaration (like class MyClass {} or func myFunc()).

Real-life example: When you type func, the main parser loop says "Aha! The func keyword! I'll call parseFuncDecl()." That function then takes over, saying "OK, I just saw func. According to my rulebook, the next thing must be an identifier (the function name). Let me call my parseIdentifier helper..." If it finds a 5 instead, it throws a "parser error"—your familiar "Expected an identifier" message.

Type Checking: Semantic Analysis

This is the code that solves the puzzle of your types.

// From lib/Sema/TypeCheckConstraints.cpp in swiftlang/swift
class ConstraintSystem {
public:
  Solution applySolution(const Solution &solution);
  void solve();

  // Type checking for function calls
  bool solveForFunctionCall(ApplyExpr *apply);
};

What this really means:
This is so cool. When you write let x = "hello" + 5, the compiler creates a ConstraintSystem—a big logic puzzle. It says, "I have an ApplyExpr (a function call, because + is just a function!). The left side is String. The right side is Int. I need to solve() for a function + that takes (String, Int). It looks through all its 'constraint' rules, finds no such function, and solve() fails. solveForFunctionCall is the detective trying to find a suspect (+ function) that matches the evidence (String and Int).

SIL Generation: High-Level IR

This is the scribe that translates the AST (the idea) into SIL (the recipe).

// From lib/SILGen/SILGen.cpp in swiftlang/swift
class SILGenModule {
public:
  SILFunction *getOrCreateFunction(SILLocation loc, SILDeclRef constant,
                                   ForDefinition_t forDefinition);

  // Generate SIL for expressions
  void emitExprInto(RValue &&rv, SILLocation loc, SGFContext C);
};

What this really means:
This is the translator. SILGenModule is in charge of converting the entire AST into SIL. When it sees your myFunc in the AST, it calls getOrCreateFunction to build the new, empty SIL function. Then, it walks all the code inside your function. When it sees the expression 1 + 1, it calls emitExprInto to spit out the actual SIL instructions for loading 1, loading another 1, and calling the add function for integers.

SIL Optimizations: Mid-Level Transformations

This is the clean-up crew, the personal trainer, the efficiency expert.

// From lib/SILOptimizer/SILCombiner/SILCombiner.h in swiftlang/swift
class SILCombiner : public SILInstructionVisitor<SILCombiner> {
public:
  void visitApplyInst(ApplyInst *AI);
  void visitAllocStackInst(AllocStackInst *ASI);

  // Combine redundant instructions
  bool tryCombine(InstructionBase *I);
};

What this really means:
This is the clean-up crew. It's a Visitor that 'visits' every single instruction in the SIL. Look at visitApplyInst—this code runs for every function call (ApplyInst) in your program. Inside this function is a giant list of patterns. It might say, "Are you calling a function that just returns a value... and then immediately calling another function with that value? I can combine these into one operation!" tryCombine is its master function, full of tricks to make the code faster.

LLVM IR Generation: Lowering to LLVM

This is the final translation from the Swift world to the generic factory floor.

// From lib/IRGen/IRGen.cpp in swiftlang/swift
class IRGenerator {
public:
  llvm::Module *getModule() const { return Module; }

  // Generate LLVM IR for SIL functions
  void emitSILFunction(SILFunction &f);
};

What this really means:
IRGenerator is the final translator. Its big job is emitSILFunction. This function takes a whole function written in SIL (Swift-specific) and painstakingly converts it, instruction by instruction, into LLVM IR (generic). It's the bridge out of the Swift-specific world. getModule() is just a helper to get the 'file' (llvm::Module) that it's writing all this new LLVM IR into.

Linking: Final Assembly

This isn't the final OS linker, but a compiler linker that helps with optimization!

// From lib/SILOptimizer/UtilityPasses/Link.cpp in swiftlang/swift
class SILLinker : public SILModuleTransform {
public:
  void run() override {
    SILModule &M = *getModule();
    for (auto &Fn : M)
      if (M.linkFunction(&Fn, LinkMode))
        invalidateAnalysis(&Fn, SILAnalysis::InvalidationKind::Everything);
  }
};

What this really means:
This is a super-clever part of the optimization phase. A SILModule is your entire app's worth of SIL. This pass, SILLinker, runs through it and finds all the functions (Fn). M.linkFunction is the key: it's the code that says, "Oh, you're calling myOtherFunction? Let me go find myOtherFunction's SIL code (maybe from another file) and pull it in so the optimizer can see both functions at the same time." This is what allows Whole Module Optimization and lets the compiler do crazy-smart things like inlining functions across files.

Key Takeaways

     .--.
    /  () \
    \    /
     `--'
       |
       |
      / \
     |   |
     `---'

It's not a single magic box. It's an assembly line:

Multi-phase Pipeline: A grammar teacher (Frontend), a hyper-obsessed personal trainer (Mid-End/SIL), a generic factory floor (Back-End/LLVM), and a general contractor (Linker).
SIL is Unique: That Swift Intermediate Language (SIL) is the real secret weapon. It lets Swift do all kinds of high-level, safety-conscious optimizations (like for generics and ARC) that other languages just can't.
Open Source: This is all just... out there. You can go read the entire swiftlang/swift repository right now. Go on. Psych yourself out.
Optimization Focus: They are obsessed with optimization. Every single stage, from SIL to LLVM, is designed to clean, tweak, polish, and speed up your code.
Safety First: The compiler is your overprotective parent. It uses semantic analysis (TypeCheckConstraints) and guaranteed SIL transformations to enforce Swift's safety rules so you don't (metaphorically) run with scissors.

Conclusion

So, yeah. The Swift compiler is one hell of a piece of software. It takes your perfectly reasonable human-written code and chews it up, transforms it, optimizes it, and spits it out the other end as blazing-fast, executable machine code. It does all this through four key phases, each ensuring your final program is safe, correct, and as fast as it can be.

Get your head around this pipeline, and you'll not only write better Swift code, but you'll be a wizard at debugging when things go weird. The secret, as we've seen, is that SIL thing. It's the compiler's private notebook, letting it perform high-level optimizations other compilers can only dream of.

And it's all open source! You can go wade into the swiftlang/swift repository if you're feeling brave. For a slightly less terrifying deep dive, check the official Swift compiler documentation.

From your brain to a running binary, the compiler is the unsung hero doing all the heavy lifting. Next time you hit "Run" in Xcode and wait for your print statement to appear, just take a second to appreciate the journey your code is on. It's doing all this work while you just sit there. Computers are so cool!

( •_•)
( •_•)>⌐■-■
(⌐■_■)

Swift Actor, what is that?

Annurdien Rasyid — Tue, 18 Nov 2025 08:04:33 +0000

You've probably written a race condition. It's okay. We all have. We deploy it, and we just kinda... hope. We're all that dog in the "This is fine" meme, surrounded by the fire of multiple threads trying to write to var totalClicks = 0 at the same time.

For decades, our solution was... "don't do that." We used locks, mutexes, semaphores, or the grand-daddy of all, DispatchQueue.sync. These are all just fancy ways of putting a velvet rope in front of our data, and they are so easy to get wrong.

Then Swift 5.5 gave us Actors.

TLDR

An Actor is a special kind of class that protects its own data. It's an "island of isolation."
It prevents data races by forcing all access to its var properties from the outside to be asynchronous (using await).
It processes these await calls one at a time, in the order they arrive (mostly). It has a "mailbox," or a queue, for incoming jobs.
Crucially, an actor is NOT a thread. It's a lightweight task that runs on a cooperative thread pool managed by the Swift runtime.
The "magic" isn't in the CPU; it's in the compiler (which enforces the await) and the Swift Runtime (which manages the mailbox and thread pool).
Actors are re-entrant, which is a fancy way of saying they can pause their current job (at an await) to run a new job, then come back later. This is weird, but it prevents deadlocks.

The Wild West of Dispatch Queue

Before actors, if you wanted to protect a variable, you did this:

class ClickCounter {
    private var count = 0
    private let queue = DispatchQueue(label: "com.my-app.click-counter-queue")

    func increment() {
        queue.sync {
            // This block is "safe"
            self.count += 1
        }
    }

    func getCount() -> Int {
        return queue.sync {
            // This block is also "safe"
            return self.count
        }
    }
}

This... works. But it's cursed.

It's manual: You have to remember to wrap every access in queue.sync. If you forget just one, poof, data race.
It's blocking: queue.sync blocks the calling thread until the work is done. If you call this from the main thread, your UI freezes.
It's easy to deadlock: What if queue.sync calls another function that also tries to queue.sync on the same queue? You've just deadlocked. Your app is frozen forever. Congrats.

  Thread 1 (Main)                            Thread 2 (Background)
      |                                             |
      |--- accesses var C ---X--- accesses var C ---|
      |                                             | (kaboom)
      | (UI frozen)                                 | (Wrong value)
      v                                             v

We needed something better. We needed the compiler to protect us from ourselves.

What Even Is an Actor?

This is what an actor looks like:

actor ClickCounter {
    private var count = 0

    func increment() {
        // Look ma, no queue!
        self.count += 1
    }

    func getCount() -> Int {
        // Also no queue!
        return self.count
    }
}

This... this is just a class, right? It looks so simple. This was one of those "psyching myself out" moments. I expected more.

But the magic isn't in what you write. It's in what the compiler makes everyone else write.

If you have an instance of it: let counter = ClickCounter()

counter.increment() -> COMPILE ERROR. (Expression is 'async' but is not marked with 'await')
let current = counter.count -> COMPILE ERROR. (Actor-isolated property 'count' can only be accessed 'async')

To use it, you must await:

func doAThing() async {
    await counter.increment()
    let current = await counter.getCount()
    print(current)
}

The actor keyword told the compiler: "Hey. See this count variable? And increment()? They are isolated. Anyone who wants to touch them from the outside? Make them get in line. Make them await."

It's Just a Class (With a Bouncer)

This is the best analogy. An actor is a nightclub.

Its properties (var count) and methods (increment()) are inside the club.
The actor itself is the only thread (metaphorically) allowed inside at a time.
All those await calls from other tasks are people lining up outside.
The actor has a Mailbox (a queue) which is the line.
The Swift Runtime is the Bouncer (⌐■_■). It picks the next person from the line, lets them in, waits for them to finish, and kicks them out before letting the next person in.

          (The "Mailbox" Queue)
[Task 3] [Task 2] [Task 1] <--- Bouncer (Swift Runtime)
                             |
                             v
                       +--------------+
                       | Actor        |
                       | (Nightclub)  |
                       |              |
                       | var count = 0|  <-- "Safe" State
                       |              |
                       +--------------+

When Task 1 (await counter.increment()) runs, the bouncer lets it in. It has exclusive access. It messes with count, finishes, and leaves. Then the bouncer lets Task 2 in.

No two tasks are ever inside at the same time. No data races. Beautiful.

Memory & CPU: The Great Actor Misdirection

This is the next psych-out moment.
"Okay, so an actor is a thread, right? It's got its own serial queue." NOPE.

This is the big lie. An actor is not a thread. It does not have its own DispatchQueue.

Where does an actor live?
In memory, it's just a class. It's a reference type. It lives on the heap. It's a chunk of memory that holds its properties (like count) and some internal bookkeeping stuff (like a lock and its mailbox).

Where does an actor run?
This is the crazy part. It doesn't "run." Its jobs run.

Swift has a Cooperative Thread Pool. When your app launches, the Swift Runtime creates a handful of threads, maybe as many as you have CPU cores. Let's say 8.

Your app might have thousands of async tasks (including all your actor calls). The Swift Runtime (our Bouncer, also called the Executor) is the big cheese. It juggles all these thousands of tasks onto those 8 available threads.

     Your Tasks (1000s of them)
[T1] [T2] [T3] [T4] ... [T999]
   \   |   /    /
    \  |  /    /
 (Swift Runtime Executor)
     |  |  |  |
     v  v  v  v
  +--+--+--+--+--+--+--+--+
  | T1| T4|   |T99|   |T23| ... (CPU Cores / Thread Pool)
  +--+--+--+--+--+--+--+--+

When you await counter.increment(), you aren't "blocking a thread." You're just creating a little job, handing it to the actor's mailbox, and your current task suspends. It says to the Runtime, "Hey, wake me up when this is done," and gets off the thread.

The Runtime is now free to run a different task on that thread. Maybe it's UI work. Maybe it's another actor.

Eventually, the increment() job gets to the front of the line. The Runtime says, "Okay, you're up," and slaps that job onto any available thread from the pool. It runs, finishes, and the original task gets woken up.

This is so much more efficient than DispatchQueue.sync, which just sits there, holding a whole thread hostage, doing nothing.

Down to the Metal: What the Assembly Actually Says

So what does this look like in assembly? This is where it gets really cursed.

Let's look at three cases.

Case 1: nonisolated (The Simple One)

If you have nonisolated let id = "counter", it's immutable. It's safe. The compiler knows this. Accessing it is just a normal, direct memory read.

; Just reading a 'let' property.
; rdi holds 'self' (the actor instance)
mov rax, [rdi + 0x18] ; Move value at offset 0x18 (the 'id' property) into rax
; ... (no locks, no queues, no magic)

It's fast. It's just a regular class property read.

Case 2: Internal Function (Already Inside the Club)

What about when increment() (which is private) accesses self.count? It's already inside the club. It doesn't need to get in line. It's already been "de-queued" by the bouncer.

; Inside 'increment()', accessing 'self.count'
; rdi holds 'self'
mov rbx, [rdi + 0x10] ; Move 'count' (at offset 0x10) into rbx
add rbx, 1            ; Add 1 to it
mov [rdi + 0x10], rbx ; Move it back
; ... (still no magic, just raw, fast access)

This is the "psych out" again. Inside the actor, all access is synchronous and fast. It's just simple assembly.

Case 3: External await Call (Getting in Line)

This is the one. What does await counter.increment() actually compile to?

You might expect a JMP or CALL to the increment function. You would be wrong.

You don't call increment at all. The compiler rewrites your code. It breaks your function into pieces (a "continuation") and tells the Swift Runtime to enqueue the piece of code that calls increment.

The assembly for await counter.increment() looks less like CALL and more like this (conceptually):

; This is a WILD simplification
; rdi = the actor instance ('counter')
; rsi = the job to run (a function pointer to 'increment')
; ... (stuff to package up 'self')
CALL swift_actor_enqueue ; <-- THE MAGIC BOUNCER
; ...
CALL swift_task_suspend ; <-- "I'm going to sleep now, wake me later"
; ...
; (code resumes here, hours later, maybe on a different thread)

That's it. That's the whole trick.

It's not "assembly" in the way we think of it. It's the compiler generating calls into the pre-built, C++-based Swift Runtime. The swift_actor_enqueue function is the bouncer. It takes the job, adds it to the actor's internal mailbox (with a lock, of course), and returns. Then swift_task_suspend parks your current task.

The complexity isn't in your code's assembly. The complexity is hidden inside the runtime. It's an abstraction, and a damn good one.

Re-entrancy: The Part That Melts Your Brain

Here's the last rabbit hole. And it's a doozy.
What happens if an actor awaits another async function?

actor BankAccount {
    var balance = 100

    func withdraw(amount: Int) async -> Bool {
        if balance < amount { return false } // Check 1

        // Uh oh...
        let permission = await fraudCheckService.requestPermission(amount)

        // We're back! ...or are we?
        if !permission { return false }

        // Check 2
        if balance < amount {
            print("Wait, what? I already checked this!")
            return false
        }

        balance -= amount
        return true
    }
}

When the code hits await fraudCheckService..., it suspends.
But what does that mean?

It means the actor gives up its lock. The bouncer says "Okay, you're waiting for the network, get out." And the bouncer immediately goes back to the mailbox and says, "NEXT!"

(Inside withdraw())
  |
  v
await fraudCheck...
  |
  +-----> (Task suspends, leaves the actor)
  |
(Mailbox) [Task 2: another call to withdraw(75)]
  |
  v
(Bouncer lets Task 2 in, while Task 1 is suspended)
  |
  v
(Task 2 runs. balance is 100. amount is 75. Checks pass.
 balance becomes 25. Task 2 finishes.)
  |
  v
(Task 1's network call *finally* returns.
 It gets back in line at the mailbox.)
  |
  v
(Bouncer lets Task 1 back in. It resumes.)
  |
  v
if balance < amount... (balance is 25, amount is 100)
  |
  v
(Check 2 fails. Thank god.)

This is re-entrancy. The actor "re-enters" itself to run other jobs while one is paused. This is wildly different from a DispatchQueue.sync block, which would never let go.

This is why we had to check the balance twice. Between the await, our actor's state could have been completely changed by other tasks.

This is the "beautifully cursed" part. It prevents deadlocks (because no one ever "holds" the lock while waiting), but it forces you to be very careful about your state before and after every single await.

Lessons Learned

Actors are abstractions, not threads. The "magic" is 90% the Swift compiler and 10% the Swift Runtime.
The compiler is your friend. It's what inserts the async/await barrier, which is the real protection.
Access inside an actor is fast. It's just raw, synchronous property access. No locks, no queues.
Access outside an actor is a runtime call. It's swift_actor_enqueue and swift_task_suspend. It's a state machine, not a simple CALL.
await means "pause and let someone else cut in." This is re-entrancy. Always re-check your state after an await.

Next Steps

This is just the start. We didn't even talk about MainActor (a special, global actor that is tied to the main thread) or Sendable (a protocol that tells the compiler which types are safe to throw over the wall into an actor).

  (\_/)
  (O.o)
 (")_(")
(Down the next rabbit hole...)

But now, when you type actor, you know what you're really doing. You're not just making a class. You're building a tiny, isolated island, hiring a bouncer, and telling the compiler to manage the line-up. And that's pretty cool.

I Wrote HTTP with Rust (From Scratch)

Annurdien Rasyid — Tue, 18 Nov 2025 07:14:54 +0000

Introduction

The best way to understand something is tried to implement it by yourself! I saw a guy on YouTube implement HTTP in C from scratch (including the TCP), I'm curious, can I do it in Rust, well I just did, (with unsafe yet not optimized code)! Now, before we dive into this rabbit hole, first we need to understand what is HTTP, but to understand HTTP, we need to know what is TCP/IP model and how it works.

WARNING: this is just a crazy implementation, this is not safe code, this is actually not great implementation and most importantly don't think this code is ready for production. Also We're assuming in your system, there's already TCP implementation, so we don't write TCP here.

The TCP/IP Model

So the TCP/IP model, also known as the Internet Protocol Suite, is a conceptual framework for how data is transmitted over a network. It is divided into four layers, each with specific functions. These layers are:

Application Layer
Transport Layer
Internet Layer
Network Interface Layer

It's look like this:

+--------------------+
| Application Layer  |
|  - HTTP            |
|  - FTP             |
|  - SMTP            |
|  - DNS             |
+--------------------+
| Transport Layer    |
|  - TCP             |
|  - UDP             |
+--------------------+
| Internet Layer     |
|  - IP              |
|  - ICMP            |
|  - ARP             |
+--------------------+
| Network Interface  |
|  - Ethernet        |
|  - Wi-Fi           |
|  - ARP             |
+--------------------+
| Physical Layer     |
|  - Physical Media  |
+--------------------+

Layer Functions:

Application Layer: It provides network services to the applications of the user. This is where high-level protocols like HTTP, FTP, SMTP, and DNS resides.
Transport Layer: Ensures reliable data transfer between hosts. It is responsible for error detection and correction, data flow control, and segmentation.
Internet Layer: Determines the best path through the network for data to travel. It handles packet routing, addressing, and fragmentation.
Network Interface Layer: Manages the hardware connections and data transfer between adjacent network nodes. It's'used for framing, physical addressing, and error detection on the physical link.

What is TCP?

The Transmission Control Protocol (TCP) is a core protocol of the Internet Protocol Suite. It provides reliable, ordered, and error-checked delivery of data between applications running on hosts communicating via an IP network. TCP is connection-oriented, meaning a connection is established and maintained until the applications at each end have finished exchanging messages.

TCP Packet Structure

A TCP packet (or segment) structure is divided into several fields, each serving a specific purpose for establishing and maintaining a reliable connection. Below is a simplified diagram of a TCP packet:

You don't really need to understand what are those data are used for, but basically, it enables TCP to reliably send data trough network.

What is HTTP?

The Hypertext Transfer Protocol (HTTP) is an application layer protocol used for transmitting hypermedia documents, such as HTML. It's a long story, here are two articles explain how HTTP actually works!

Noob friendly article

Not so noob friendly article

HTTP Request Header Structure

An HTTP request header is the format in which the client sends data to the server. It consists of a request line, header fields, and an optional message body. Here is a simplified diagram:

+-----------------------------------------+
| Request Line                            |
| GET /index.html HTTP/1.1                |
+-----------------------------------------+
| Header Fields                           |
| Host: www.example.com                   |
| User-Agent: Mozilla/5.0                 |
| Accept: text/html                       |
| ...                                     |
+-----------------------------------------+
|                                         |
| Optional Message Body (for POST, etc.)  |
| ...                                     |
+-----------------------------------------+

Components:

Request Line: Contains the HTTP method, the resource path, and the HTTP version.
- Example: GET /index.html HTTP/1.1
Header Fields: Key-value pairs providing metadata about the request.
- Host: The domain name of the server.
- User-Agent: Information about the client software.
- Accept: Media types the client is willing to receive.
- Other headers may include Content-Type, Content-Length, Connection, etc.
Optional Message Body: Present in requests like POST, PUT, etc., and contains the data to be sent to the server.

In my implementation, I ignore most of the request header, because I don't need most of them in this implementation. Only GET request that are handled in this project for the sake of simplicity, the point is I understand how HTTP works (just an excuse because I'm lazy)

How TCP and HTTP Work Together

When you visit a website, your browser (the client) initiates a TCP connection to the server hosting the website. Once the connection is established, the browser sends an HTTP request over the TCP connection to retrieve the web page. The server processes the request and sends back an HTTP response with the requested resource. This process involves the following steps:

TCP Handshake: Establishes a connection between client and server.

Client                           Server
|-------[SYN]-------------------->|
|<------[SYN, ACK]----------------|
|-------[ACK]-------------------->|

Sending HTTP Request: Once the TCP connection is established, the client sends an HTTP request.

Client                           Server
|-------[GET /index.html HTTP/1.1\r\n]-->|
|-------[Host: www.example.com\r\n]------|
|-------[User-Agent: Mozilla/5.0\r\n]----|
|-------[\r\n]-------------------------->|

Server Response: The server processes the request and sends back an HTTP response.

Client                           Server
|<------[HTTP/1.1 200 OK\r\n]-------------|
|<------[Content-Type: text/html\r\n]-----|
|<------[Content-Length: 137\r\n]---------|
|<------[\r\n]----------------------------|
|<------[<html>...content...</html>]------|

TCP Termination: After the data transfer, the TCP connection is closed.

Client                           Server
|-------[FIN]-------------------->|
|<------[FIN, ACK]----------------|
|-------[ACK]-------------------->|

Building the HTTP

Here's the code for this super simple HTTP implementation that I wrote from scratch, I use tokio for the TCP. Because I don't want to write
TCP by myself (for now)!

The Code

use tokio::net::{TcpListener, TcpStream};
use tokio::io::{AsyncReadExt, AsyncWriteExt};
use std::path::Path;
use std::fs;
use mime_guess::from_path;
use tokio::sync::RwLock;
use std::sync::Arc;

const HEADER_PACKET_LENGTH: usize = 1024;

type AllowedFileTable = Arc<RwLock<Vec<String>>>;

#[tokio::main]
async fn main() {
    let allowed_file_table = Arc::new(RwLock::new(create_allowed_file_table()));

    // Bind a TCP listener to the specified address and port.
    let listener = TcpListener::bind("127.0.0.1:7878").await.unwrap();
    println!("Server listening on port 7878");

    loop {
        let (socket, _) = listener.accept().await.unwrap();
        let allowed_file_table = Arc::clone(&allowed_file_table);
        tokio::spawn(async move {
            handle_client(socket, allowed_file_table).await;
        });
    }
}

/// Handles the client connection.
///
/// Reads the request from the client, checks if the requested file is allowed,
/// and sends the appropriate response.
///
/// # Arguments
///
/// * `socket` - The TCP stream representing the client connection.
/// * `allowed_file_table` - The allowed file table to check for file access.
async fn handle_client(mut socket: TcpStream, allowed_file_table

: AllowedFileTable) {
    let mut buffer = [0; HEADER_PACKET_LENGTH];
    if let Ok(n) = socket.read(&mut buffer).await {
        if n == 0 {
            return;
        }

        let request = String::from_utf8_lossy(&buffer[..n]);
        let mut lines = request.lines();

        if let Some(first_line) = lines.next() {
            let parts: Vec<&str> = first_line.split_whitespace().collect();
            if parts.len() == 3 && parts[0] == "GET" {
                // Extract the requested path.
                let path = parts[1].trim_start_matches('/');
                // Check if the requested file is allowed.
                let allowed = {
                    let table = allowed_file_table.read().await;
                    table.iter().find(|entry| entry.ends_with(path)).cloned()
                };

                if let Some(full_path) = allowed {
                    // Send the content if the file is allowed.
                    send_content(&full_path, &mut socket).await;
                } else {
                    // Send a 403 Forbidden response if the file is not allowed.
                    send_forbidden_packet(&mut socket).await;
                }
            } else {
                // Send a 400 Bad Request response if the request is not a valid GET request.
                send_bad_request_packet(&mut socket).await;
            }
        }
    }
}

/// Sends a 403 Forbidden response to the client.
///
/// # Arguments
///
/// * `socket` - The TCP stream representing the client connection.
async fn send_forbidden_packet(socket: &mut TcpStream) {
    let data = "HTTP/1.1 403 Forbidden\r\nContent-Type: text/html\r\nContent-Length: 0\r\n\r\n";
    println!("Forbidden request received");
    socket.write_all(data.as_bytes()).await.unwrap();
}

/// Sends a 400 Bad Request response to the client.
///
/// # Arguments
///
/// * `socket` - The TCP stream representing the client connection.
async fn send_bad_request_packet(socket: &mut TcpStream) {
    let data = "HTTP/1.1 400 Bad Request\r\nContent-Type: text/html\r\nContent-Length: 0\r\n\r\n";
    println!("Bad request received");
    socket.write_all(data.as_bytes()).await.unwrap();
}

/// Sends the content of the requested file to the client.
///
/// Reads the file, determines its MIME type, and sends it along with the HTTP response headers.
///
/// # Arguments
///
/// * `path` - The path of the file to send.
/// * `socket` - The TCP stream representing the client connection.
async fn send_content(path: &str, socket: &mut TcpStream) {
    if let Ok(content) = fs::read(path) {
        // Determine the MIME type based on the file extension.
        let content_type = from_path(path).first_or_octet_stream();
        let response = format!(
            "HTTP/1.1 200 OK\r\nContent-Type: {}\r\nContent-Length: {}\r\nAccess-Control-Allow-Origin: *\r\n\r\n",
            content_type, content.len()
        );
        socket.write_all(response.as_bytes()).await.unwrap();
        socket.write_all(&content).await.unwrap();
    } else {
        // Send a 403 Forbidden response if the file could not be read.
        send_forbidden_packet(socket).await;
    }
}

/// Creates and initializes the allowed file table.
///
/// Scans the predefined list of file paths and adds existing files to the allowed file table.
///
/// # Returns
///
/// A vector of strings representing the allowed file paths.
fn create_allowed_file_table() -> Vec<String> {
    let paths = vec!["./public/index.html", "./public/style.css"];
    let mut table = Vec::new();
    for path in paths {
        if Path::new(path).exists() {
            table.push(path.to_string());
        }
    }
    table
}

How It Works

Initialization: The main function initializes the allowed file table and starts the TCP listener on port 7878.
Accepting Connections: The server listens for incoming connections in an infinite loop. For each new connection, it spawns a new task to handle the client.
Handling Requests: The handle_client function reads the request from the client. It checks if the request is a valid HTTP GET request and whether the requested file is allowed. If the file is allowed, it serves the content; otherwise, it sends a 403 Forbidden response.
Sending Responses: There are helper functions to send different types of responses (send_forbidden_packet, send_bad_request_packet, and send_content). The send_content function reads the requested file, determines its MIME type, and sends the file content along with appropriate HTTP headers.

Limitations

Concurrency and Performance: Simple implementations may struggle with handling a high number of concurrent connections and large data volumes efficiently.
Security: Basic servers do not provide robust security mechanisms like SSL/TLS, making data susceptible to interception and tampering.
Scalability: Without features like load balancing, session management, and advanced routing, scaling out to handle increased traffic can be challenging.
Functionality: Limited to basic GET requests and static file serving. More advanced HTTP methods and dynamic content generation are not supported.

Here's the result

What Next

If you read this, I think your interested in programming, if you don't understand what I said here, it's totally fine, I don't really understand it either, especially how the TCP stream works, but damn, being stupid is fun right, you can always learning new things everyday, it's like endless journey!. I'm having so much fun writing this article. For next I think I will try to write WebSocket from scratch.

BTW the here's the github link.

Original Post: https://rasyid.codes/blog/rust-http/

Enhance Debugging in Swift with #file, #line, and #function

Annurdien Rasyid — Wed, 04 Dec 2024 03:40:23 +0000

Swift provides three special literals: #file, #line, and #function. These are automatically set to the current file name, line number, and function name, respectively. They are especially handy when creating custom logging functions or test predicates.

import Foundation

func log(_ message: String, _ file: String = #file, _ line: Int = #line, _ function: String = #function) {
    print("[\(file):\(line)] \(function) - \(message)")
}

func foo() {
    log("Hello world!")
}

foo() // [TryDebug.playground:8] foo() - Hello world!

Directly store value using "if expression" - Swift

Annurdien Rasyid — Wed, 04 Dec 2024 03:22:02 +0000

When we want to set a variable for a specific condition, this what we normally do:

let temperatureInCelsius = 25
let weatherAdvice: String

if temperatureInCelsius <= 0 {
    weatherAdvice = "It's very cold. Consider wearing a scarf."
} else if temperatureInCelsius >= 30 {
    weatherAdvice = "It's really warm. Don't forget to wear sunscreen."
} else {
    weatherAdvice = "It's not that cold. Wear a T-shirt."
}

print(weatherAdvice)
// Prints "It's not that cold. Wear a T-shirt."

We can make it more cleaner using if expression:

let temperatureInCelsius = 25
let weatherAdvice = if temperatureInCelsius <= 0 {
    "It's very cold. Consider wearing a scarf."
} else if temperatureInCelsius >= 30 {
    "It's really warm. Don't forget to wear sunscreen."
} else {
    "It's not that cold. Wear a T-shirt."
}

print(weatherAdvice)
// Prints "It's not that cold. Wear a T-shirt."

Learn more:

https://docs.swift.org/swift-book/documentation/the-swift-programming-language/controlflow#Conditional-Statements

Developing CROML (Crochet Obvious Minimal Language)

Annurdien Rasyid — Thu, 19 Sep 2024 16:07:33 +0000

Back Story

During my time at Apple Academy, my colleagues and I developed an app about crocheting. The app is designed to help crocheters track their stitch and row. In the app, we have a feature that allows users to take pictures of an Amigurumi pattern and then break it down into individual stitches. The goal is to enable users to know what stitch they need to do at that exact moment.

Crochet

For you non-crocheters, let me give you a context. A pattern in crocheting is a "rule" that you need to follow to create a certain shape; it consists of what type of stitch, how many times the stitch should be done, and in which row it should be done. Amigurumi is a type of crochet. It's basically a doll.

Let me give you an example of an Amigurumi pattern:

Here's another one:

You see, the pattern can be very different from one another; it has multiple abbreviations, and sometimes it includes natural language.

Challange

As I mentioned before, one of the features in our app is allowing the user to take a picture or upload a screenshot of this pattern, and then from that picture, the app should break it down into individual stitches that the user can follow each stitch.

There are multiple problems I face while developing this feature:

How to extract the crochet pattern string from an image.
How to convert that extracted string, which is a semi-structured language and sometimes has natural language, to data that a computer can understand.

For the first problem, which is to extract the string from the image, it's pretty straightforward. I use Apple Vision Framework to detect text in an image; it's easy!. For the second problem though, it's a bit tricky. I try using Regex and Named Entity Recognition, and it's just not working because the nature of the patterns is very different from one to the other. Also, sometimes the Vision Framework can output incorrect data; sometimes it detects "S" as "5".

Based on that reason, the obvious solution that came to my head is using Large Language Model to analyze the pattern and convert it to more structured data.

Why not using JSON?

The first thing that I did was create a prompt that tells the LLM to convert the crochet pattern to a JSON format. It's pretty straightforward, right? No need to process any further, just straight JSON data. Well, maybe it's true, but there are some problems with that.

Here's the first 20 lines from 456 of the crochet pattern in JSON format, pretty long, right?

{
  "pattern": {
    "parts": [
      {
        "name": "Head",
        "layers": [
          {
            "id": 1,
            "sequences": [
              {
                "stiches": [
                  {
                    "name": "SC",
                    "times": 6
                  }
                ],
                "repeat": 1
              }
            ]
          }

The problems with generating JSON directly with LLM are:

JSON is error-prone if it's generated by LLM; it's possible, and I encounter that many times the JSON data that the LLM output is not valid, sometimes it mises the (}semicolon) at the end.
Returning pure JSON data is very token expensive because crochet patterns can have many rows and stitches, and it also takes a very long time to generate the output.

The other solution is not to use JSON. I've tried using minimal language like TOML or YAML; it just doesn't feel right; they have too much indentation and are just not that readable for the context of a crochet pattern.

CROML

Because of that reason, I decided to create my own data representation that I can easily parse locally. I came up with CROML (Crochet Obvious Markup Language). Why, you ask? Here's a quote from Kent Beck.

Make it work, make it right, and make it fast. – Kent Beck

Here's how CROML looks like:

Head:
 1:SCx6
 2:INCx6
 3:(SCx1,INCx1)[r=6]
 4:(SCx2,INCx1)[r=6]
 5:(SCx3,INCx1)[r=6]
 6-8:SCx30
 9:SCx6,INCx3,(SCx1,INCx1,SCx1)[r=4],INCx3,SCx6

Ears:
 1:SCx6
 2:(SCx1,INCx1)[r=3]
 3:SCx9
 4:(SCx1,INCx1,SCx1)[r=3]
 5-8:SCx12
 9:(SCx2,DECx1)[r=3]

CROML Rules

1. Parts and Sections

Each part (e.g., Body, Head, Paws, etc.) is introduced by its name (only a-zA-Z are allowed), followed by a colon (:).
Each part contains layers. These layers are numbered sequentially and correspond to the crochet steps.
If a series of layers have the same sequence, they can be represented as a range (e.g., 6-10 for five layers with identical stitches).

2. Stitch Notation

Each stitch type is represented by its abbreviation (e.g., SC for single crochet, INC for increase, DEC for decrease).
The number of times a stitch is repeated in a layer is denoted by the format StitchName x Count, where StitchName is the abbreviation, and Count is the number of times the stitch is performed (e.g., SCx6 for six single crochets).

3. Multiple Stitches in a Sequence

When multiple stitches occur in the same sequence, group them with parentheses ( ) to show they occur together, separated by commas.
Example: (SCx1, INCx1) means one single crochet followed by one increase.

4. Repeating Sequences

If a sequence (group of stitches) is repeated for a number of rounds, append [r=x], where x is the number of repetitions.
Example: (SCx1, INCx1) [r=6] means to repeat “single crochet 1 stitch, increase 1 stitch” six times in a row.

5. Single Repetitions

If the sequence is only done once, no [r=x] is necessary. By default, no repeat means it occurs only once.
Example: SCx6 assumes a default repeat of 1 unless otherwise specified.

6. Layer Ranges

If multiple layers have the same stitch pattern, use a hyphen (-) to represent the range.
Example: 6-10: SCx20 means layers 6 through 10 are all single crocheted 20 times.

7. Order of Stitch Types

Within parentheses, list stitches in the order they occur.
When no parentheses are used, the notation assumes a single stitch pattern for that layer.

How About The Parser?

It's pretty straightforward; CROML is agnostic to indentation; I just use simple regex and then convert it to JSON locally; it's much faster than having to wait for LLM to complete generating JSON data.

Conclusion

Telling LLM to generate CROML is significantly reducing token usage and also speeding up the generation time. While maybe still not error proof, it's better than having a parse error because of just 1 character missing if I use JSON.

Forem: Annurdien Rasyid

What makes ARM... ARM?

Table of Contents

TL;DR

The First Rabbit Hole: What is ARM?

The Big Showdown: RISC vs. CISC

The Heart of the Matter: The Instruction Set

The Load or Store Philosophy (aka "The No Touchy Rule")

Conditional Love (and Execution)

The Squeezy Boy: The Thumb Instruction Set

The M1-llion Dollar Question: Why Did Apple Switch?

Lessons from the Rabbit Hole

Next Steps

From Swift to Machine Code

Table of Contents

Introduction

What is a Compiler?

The Swift Compiler Architecture

Frontend: Source Code to SIL

Parsing & Lexing

Want to See the AST for Yourself?

Example: An Abstract Syntax Tree (AST)

Semantic Analysis

Clang Importer

SIL Generation

Example: What SIL Actually Looks Like

Mid-End: SIL Optimizations

SIL Guaranteed Transformations

SIL Optimizations

IR Generation

Example: What LLVM IR Looks Like

Back-End: LLVM Code Generation

Example: The Final Assembly Output

Linker: Creating the Final Executable

Code Examples from the Swift Compiler

Parsing: Building the AST

Type Checking: Semantic Analysis

SIL Generation: High-Level IR

SIL Optimizations: Mid-Level Transformations

LLVM IR Generation: Lowering to LLVM

Linking: Final Assembly

Key Takeaways

Conclusion

Swift Actor, what is that?

TLDR

The Wild West of Dispatch Queue

What Even Is an Actor?

It's Just a Class (With a Bouncer)

Memory & CPU: The Great Actor Misdirection

Down to the Metal: What the Assembly Actually Says

Re-entrancy: The Part That Melts Your Brain

Lessons Learned

Next Steps

I Wrote HTTP with Rust (From Scratch)

Introduction

The TCP/IP Model

Layer Functions:

What is TCP?

TCP Packet Structure

What is HTTP?

HTTP Request Header Structure

How TCP and HTTP Work Together

Building the HTTP

The Code

How It Works

Limitations

Here's the result

What Next

Enhance Debugging in Swift with #file, #line, and #function

Directly store value using "if expression" - Swift

Developing CROML (Crochet Obvious Minimal Language)

Back Story

Crochet

Challange

Why not using JSON?

CROML

CROML Rules

1. Parts and Sections

2. Stitch Notation

3. Multiple Stitches in a Sequence