There's a pattern that repeats across the entire history of computing: we take something fundamentally non-deterministic and engineer enough layers on top of it until it behaves deterministically. Logic gates did it. Artificial neural networks (ANNs) replicated it at some level. LLMs are the next frontier, and the hardest one yet.

In this article, we'll explore how engineering is crucial to facing non-determinism, and analyse the current state of the art for LLMs.

Agenda

• Part I - The lie inside a logic gate

  • Noise margins
  • The CPU clock

• Part II - Aspirina: teaching non-determinism to behave

  • Where the chaos lives
  • Composition does the rest
  • The cost compared

• Part III - LLMs and the "Unresolved Problem"

  • Tests as noise margins
  • The agentic loop as clock
  • The type system and compiler
  • What's missing: timing analysis
  • How to mitigate that?

• Conclusion

Part I - The lie inside a logic gate

A logic gate is taught in school as a simple binary machine. You give it 0s and 1s, you get 0s and 1s back.

AND, OR and XOR are example of logic gates. They are clean, mathematical, deterministic. And that's a useful fiction.

At the physical level, a gate is a transistor (or a few of them) through which electrons flow. Electrons don't care about your Boolean algebra. The voltage on a wire is a continuous, analog value that fluctuates due to thermal noise, manufacturing variance, electromagnetic interference, and even cosmic radiation flipping bits in memory.

Fun fact: in May 2003, in Belgium, an electronic voting machine gave a candidate exactly 4096 extra votes. More than she could possibly have received. After investigation, the error was attributed to the spontaneous creation of a 13th bit in the memory of the computer. The leading explanation: a cosmic ray flipped a single bit, turning a 0 into a 1 at position 2^12, adding exactly 4096 to the candidate count.

Ok, but how does the industry get determinism out of this mess?

Noise margins

Engineers define voltage thresholds: anything below 0.8V is a 0, anything above 2.0V is a 1. The zone between those values is declared "forbidden". The circuit is designed to never operate stably there. This isn't physics; it's an engineering contract. (More on noise margins)

The CPU clock

A CPU clock isn't just a metronome. It's also a sampling strategy. You let the signal propagate through the gate (which takes time, called propagation delay), and only read the value at a specific moment: the clock edge. By then, the signal has had time to cross the threshold and stabilise. Timing is calculated to guarantee this.

But when timing fails, things may get weird. If a signal is sampled while it's still in the forbidden zone, a flip-flop can enter metastability, which is an unstable equilibrium where the output isn't quite 0 or 1 and can oscillate for an indeterminate time. This may cause real crashes in real systems.

Think of metastability as what happens when two clocks on a wall are unsynchronized. Each showing a slightly different time. "What time is it right now?", one may ask. The answer depends on which clock you look at, but you can't decide which one is right.

Inside the CPU, when facing a forbidden zone, the flip-flop faces the same dilemma. It can't decide if it's a 0 or a 1, which can corrupt the system state. Engineers mitigate this with synchronizer chains, but never eliminate it entirely.

It's the non-determinism of physics leaking through the engineering abstraction!

The key insight: the determinism of digital computing is not a property of nature. It's an engineering achievement. It's paid with noise margins, timing analysis and careful design.

Yes, it's all about engineering.

Part II - Aspirina: teaching non-determinism to behave

Aspirina is my personal project that builds a complete CPU entirely from artificial neural networks (ANNs) trained to behave as logic gates, written in Rust.

Actually I created the very first version almost 10 years ago in Elixir, when I was learning about ANNs and Elixir. Recently I decided to write a Rust version while I was learning Rust.

The inversion from Part I brings the beauty: instead of physical electrons that need to be tamed into bits, here we have ANNs - systems whose weights are initialised randomly and whose outputs are continuous floating-point numbers - that need to be tamed into 0 and 1 too.

The non-determinism here is introduced deliberately, and then engineered away. Bear with me.

Where the chaos lives - unleash the madness

A neural network starts with random weights. Its output for any input is whatever the math happens to produce. Not 0, not 1, but something like 0.6312. In case you missed, I already have an article in my blog about neural networks.

Backpropagation is the engineering response. It's the algorithm that adjusts the weights iteratively, measuring how wrong the output is (the loss) and leading weights in the direction that reduces the error. Run this for 10,000 epochs - 10,000 passes over the training data - and the network converges to weights that produce 0.002 for inputs that should be 0, and 0.997 for inputs that should be 1.

The sigmoid function (a.k.a the logistic curve) does in Aspirina what noise margins do in hardware: it squashes any continuous value into the range 0..1. It doesn't give you exact binary outputs, but it pushes values toward the extremes.

And that's exactly what we need

Combined with a threshold decision - below 0.5 we could consider 0, above 0.5 we consider 1 -, we get in Aspirina the same effect: a circuit that behaves deterministically even though its internals are continuous and learned.

Composition does the rest

Once gates are trained, they're composed to:

XOR + AND => Half Adder => Full Adder => 4-bit ALU => Memory => Registers => CPU => Assembler => Interpreter

Each layer treats the layer below as if it were perfectly deterministic, which is exactly the abstraction hierarchy of real hardware.

The non-determinism was contained at the lowest level (training), and every layer above it benefits from the illusion of determinism.

Yes, determinism is an illusion. Deal with it.

The cost compared

Compute time during training. Just as chip fabrication invests energy upfront to create reliable silicon, Aspirina invests 10,000 epochs upfront to create reliable logic. After that, inference is cheap and stable.

Now, enter LLMs.

Part III - LLMs and the "Unresolved Problem"

A large language model (LLM) is non-deterministic in a deeper and more stubborn way than either of the above.

Its weights are the result of a stochastic training process over vast data. Its output is sampled probabilistically (even with temperature=0), and there's pseudo-randomness baked in. And crucially, unlike a neural network trained on a clean truth table, an LLM's "correct output" for most inputs is fundamentally ambiguous.

Yet we're building agentic systems (Claude Code, Codex, Cursor etc) that use LLMs to write, run and iterate on code autonomously. How do we tame this?

The pattern repeats, but the engineering is particularly messier on LLM's.

Tests as noise margins

A test suite could behave as a binary verdict on the LLM's output: green or red. It doesn't matter if the model generated three different valid implementations in three runs: if all tests pass, they're equivalent from the system's perspective. The non-determinism of the model is contained below the threshold of "passes tests". This works, but only as well as the tests themselves. And unlike voltage thresholds, test coverage is always incomplete.

The agentic loop as clock

An agentic system like Claude Code doesn't generate once and deliver. It reads state (files, compiler output, test results), acts, observes the new state, and repeats. This feedback loop is structurally similar to the fetch-decode-execute cycle of a CPU or the iterative of Aspirina. Each iteration constrains the space of valid next actions. Errors are observable, and the agent can correct.

The type system and compiler as low-level validators

In a Rust project like Aspirina, the borrow checker rejects invalid outputs before tests even run. The LLM can generate wrong code and hallucinate, the compiler then refuses it, the agent observes the error message, and iterates.

This is a lower-level noise margin: just a formal filter beneath the test layer and type system.

And that's why I think that languages with strict compilers like Rust will thrive in the agentic era. Let's see.

What's missing: the equivalent of timing analysis

In hardware, engineers can prove that a circuit will work at a given clock frequency. They run static timing analysis and guarantee that every signal stabilises before every clock edge. There's no equivalent for agentic LLM systems.

We don't know how many iterations an agent will need. We can't bound the convergence time. We can't guarantee termination. An agent can loop indefinitely, or enter what I'd call "agentic metastability": making and undoing the same change repeatedly, unable to reach a stable state.

Anyone who has used Claude Code or Codex for long enough has seen this - the model oscillates between two approaches, each creating a problem that motivates reverting to the other.

Despite we can retry, add guardrails, skills, and set token budgets, in the end, we can't prove termination the way a hardware engineer proves timing closure on metastability

How to mitigate that?

In hardware, the fix for metastability is design. In agentic systems, the analog fix is clearer context, more granular tests, explicit checkpoints and tighter feedback loops; which can be described with the following practical list of skills I created and have been using on a daily basis for every project in production:

• PO (product owner): agent receives a prompt and outputs a well-scoped task based on initial requirements and prior knowledge on the codebase. Clearer context.

• TDD (test-driven development): the developer agent outputs the code, guided by TDD - red, green, refactor. Granular tests as noise margins.

• Review: agent and human checks before merging. Explicit checkpoint.

• Small PRs: small PR's enable development and testing with reviewable increments. Tighter feedback loops.

Yes, that's software engineering practices all the way down (and they are not new). Yet we don't have the formal tools to prove these fixes work. It's totally empirical.

Conclusion

At least for me, what's interesting is that each level's "solved" status depends on bounded, well-defined tasks. Logic gates are deterministic for Boolean logic. Aspirina's networks converge reliably because truth tables are finite and exact. LLMs work well on narrow, testable tasks with earlier and good feedback.

The frontier is: what does it take to engineer reliable agentic behaviour on open-ended, ambiguous, long-horizon tasks? The answer probably looks like what came before: more layers of verification, better sampling strategies (the clock), formal specifications (the truth table), and tools that can analyse convergence before execution. We just don't have those yet.

Non-determinism doesn't go away. It never has. We just keep finding better ways to push it where it can't hurt us. From voltage thresholds to synchronizer chains to temperature tuning. Every generation of computing has faced the same enemy and responded with the same weapon: engineering. Besides hype, LLMs are no different. We're just earlier in the cycle.

References

https://en.wikipedia.org/wiki/Logic_gate https://en.wikipedia.org/wiki/Electronic_voting_in_Belgium https://en.wikipedia.org/wiki/Noise_margin https://en.wikipedia.org/wiki/Metastability_(electronics) https://en.wikipedia.org/wiki/Sigmoid_function https://en.wikipedia.org/wiki/Large_language_model https://en.wikipedia.org/wiki/Backpropagation https://en.wikipedia.org/wiki/Static_timing_analysis https://github.com/leandronsp/aspirina https://github.com/leandronsp/morphine https://leandronsp.com/articles/ai-ruby-an-introduction-to-neural-networks-23f3

• Recursion is an obscure topic or you want to understand it a bit better;

• Tail call and TCO are alien communication methods and;

• Trampoline is a medicine name

Then this article is for you.

Here, I'll explain what these terms are in a didactic way and the problems they solve, with examples in Ruby. But don't worry because the examples are quite simple to understand, especially since the concepts shown here are language-agnostic.

So, come with me on this endless journey.

✋ To continue, go back to the beginning

Note: This is an English translation of the original article in Portuguese: Entendendo fundamentos de recursão

Agenda

• What is recursion

• Meet Fibo

• Tail call

• Stack and stack overflow

• Tail call optimization

• Trampoline

• Conclusion

• References

What is recursion

In computer programs, we're used to breaking large problems into smaller problems through the use of functions or methods.

Recursion is, in an extremely simplified way, a technique in computing where these problems are broken down so that a certain function is executed recursively.

With this, the function "calls itself" to solve some computation and continue its execution.

Meet Fibo

A very classic example of recursion is discovering, given the Fibonacci sequence, or Fibo, which number is found at a certain position.

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55.........

With this in place, the fib function would return results like:

fib(0) = 0
fib(1) = 1
fib(2) = 1
...
fib(7) = 13
fib(10) = 55

We then have a possible recursive implementation in Ruby:

def fib(position)
  return position if position < 2

  fib(position - 1) + fib(position - 2)
end

This code, however, is not performant. When trying to find the number at position 10_000 (ten thousand) in the sequence, the program becomes very slow because it makes numerous redundant recursive calls.

                 fib(10)
             /                \
     fib(9)                 fib(8)
        /          \          /   \
fib(8)     fib(7)     fib(7)    fib(6)
  /      \       /       \       /   \
fib(7) fib(6) fib(6) fib(5) fib(6) fib(5)
   /    \     /     \     /     \     /    \
fib(6) fib(5) fib(5) fib(4) fib(5) fib(4) fib(5) fib(4)
  /   \   /   \   /   \   /   \   /   \   /   \   /   \
...

Consequently, the larger the function input, the execution time of this code tends to grow exponentially, which in Big-O notation would be O(2^n).

Is it possible to reduce this complexity?

What if we try to apply a technique where the last function call, instead of being the sum of two recursive calls, becomes just one recursive call, without performing additional computations?

This technique exists and is called tail call, or tail recursion.

Tail call

Tail call, or TC, consists of a recursive function where the last recursive call is the function itself without additional computation.

With this in place, we reduce the complexity from exponential to linear, as if it were a simple loop iterating over a list of inputs.

In Big-O notation this becomes O(n), meaning the complexity grows linearly following the growth of the input.

Example in Ruby:

def fib(position, _current = 0, _next = 1)
  return _current if position < 1

  fib(position - 1, _next, _current + _next)
end

Therefore, the number of recursive calls is drastically reduced to something like:

fib(10, 0, 1)
fib(9, 1, 1)
fib(8, 1, 2)
fib(7, 2, 3)
fib(6, 3, 5)
fib(5, 5, 8)
fib(4, 8, 13)
fib(3, 13, 21)
fib(2, 21, 34)
fib(1, 34, 55)
fib(0, 55, 89)

Notice how the number of recursive calls decreased, meaning the code is following a more linear path with this approach.

Thus, when running the fib with TC program, the execution time is exponentially less than running without TC, being tens of thousands of times faster.

✋ Clearly a program that takes exponential time is terribly poor performance-wise, right?

# Without TC
fib(30) # 0.75 seconds

# With TC
fib(30) # 0.000075 seconds

Going back to the example of fib(10000), when running with TC, we see that execution is much faster, however:

recursion/fib.rb:10:in `fib_tc': stack level too deep (SystemStackError)
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'

Uh oh, a stack overflow!

To understand what's happening, let's first understand what the heck is a stack and stack overflow.

Stack and stack overflow

When a program is executed, a data structure in the form of a stack, called Stack (duh), is allocated in memory and is used to store the data being used in a running function.

✋ There's also another structure in the program's memory called Heap, which is not a stack and has other traits that are beyond the scope of this article. To understand recursion, we focus only on the stack

When the program enters a function or method, each piece of data is pushed onto the stack. When the function finishes, the removal (pop) of each piece of data is done.

With each function call, a new stack frame is assigned. Since a recursive call never ends, the runtime doesn't know it needs to "pop" the data and finish the frame, so at every call, a new stack frame is created and more elements are added to the stack.

Guess what happens when we add too much data to the stack to the point of exceeding its limit in the computer's memory?

Yes, the infamous Stack overflow happens 💥🪲, and this explains that error in Ruby when running fib of 10000 with tail call.

✋ So does that mean calculating fib of 10000 is an impossible problem to solve with recursion?

Hold on, some languages employ an optimization technique that consists of using the tail call with just one stack frame, hence ensuring that each recursive call is treated as if it were an iteration in a primitive loop.

With this, the function's arguments and data are manipulated in a single stack frame, exactly as if we had written a primitive loop. And consequently, new tail recursive calls won't cause stack overflow.

We call this technique Tail call optimization, or TCO.

Tail call optimization

Due to its imperative nature, and like several other general-purpose languages, Ruby doesn't have native TCO support.

Usually this optimization is more commonly found in languages with a strong inclination toward the functional paradigm, rather than the imperative one.

But in Ruby it's possible to enable TCO mode with a simple configuration in the Ruby runtime instruction (YARV), and thus we can execute fib of 10000 without pain.

RubyVM::InstructionSequence.compile_option = {
  tailcall_optimization: true,
  trace_instruction: false
}

def fib(position, _current = 0, _next = 1)
  return _current if position < 1

  fib(position - 1, _next, _current + _next)
end

# TC with TCO
fib(10000) # 0.02 seconds

Superb! With TCO enabled, a fib 10000 with tail call is executed in 0.02 seconds!

It's worth remembering that TCO is a technique used not only in recursion but also in instruction generation optimization in compilers, but this is beyond the scope of this article.

✋ Okay, but what if it's not possible to enable TCO for tail recursion or I'm programming in a language that doesn't have TCO support?

Trampoline to the rescue.

Trampoline

To understand trampoline, let's think about the problem and a possible solution.

If we think smart, we can initially conclude that recursion should be avoided, and this is premise number one.

def fib(position, _current = 0, _next = 1)
  return _current if position < 1

  ###################################
  #### We must avoid this!!!!!! ####
  ###################################
  fib(position - 1, _next, _current + _next)
end

Premise two, instead of returning a recursive call directly, what if we return it encapsulated in an anonymous function structure that stores context to be executed in another context?

Yes, like a closure or lambda for the more attentive readers

In Ruby, we can use the concept of lambdas.

def fib(position, _current = 0, _next = 1)
  return _current if position < 1

  lambda do
    fib(position - 1, _next, _current + _next)
  end
end

If we call result = fib(0), because of the first line's short-circuit (position < 1), the method's return is 0.

But if we call result = fib(10), the return won't be a recursive call, but rather the return will be an anonymous function (lambda).

By doing this, the method is then finished and the stack is cleared, meaning the pop of data is done from within the method.

Since lambdas store context, if we call result.call, the lambda is executed with the previous context, which can return the final number (if it enters the short-circuit) or another lambda with the new context.

And so, we loop until we have the final value, while the current return continues to be a lambda. Did you understand what we can do?

Yes, a loop!

result = fib(10000)

while result.is_a?(Proc)
  result = result.call
end

puts result

Output (a really very large number):

33644764876431783266621612005107543310302148460680063906564769974680081442166662368155595513633734025582065332680836159373734790483865268263040892463056431887354544369559827491606602099884183933864652731300088830269235673613135117579297437854413752130520504347701602264758318906527890855154366159582987279682987510631200575428783453215515103870818298969791613127856265033195487140214287532698187962046936097879900350962302291026368131493195275630227837628441540360584402572114334961180023091208287046088923962328835461505776583271252546093591128203925285393434620904245248929403901706233888991085841065183173360437470737908552631764325733993712871937587746897479926305837065742830161637408969178426378624212835258112820516370298089332099905707920064367426202389783111470054074998459250360633560933883831923386783056136435351892133279732908133732642652633989763922723407882928177953580570993691049175470808931841056146322338217465637321248226383092103297701648054726243842374862411453093812206564914032751086643394517512161526545361333111314042436854805106765843493523836959653428071768775328348234345557366719731392746273629108210679280784718035329131176778924659089938635459327894523777674406192240337638674004021330343297496902028328145933418826817683893072003634795623117103101291953169794607632737589253530772552375943788434504067715555779056450443016640119462580972216729758615026968443146952034614932291105970676243268515992834709891284706740862008587135016260312071903172086094081298321581077282076353186624611278245537208532365305775956430072517744315051539600905168603220349163222640885248852433158051534849622434848299380905070483482449327453732624567755879089187190803662058009594743150052402532709746995318770724376825907419939632265984147498193609285223945039707165443156421328157688908058783183404917434556270520223564846495196112460268313970975069382648706613264507665074611512677522748621598642530711298441182622661057163515069260029861704945425047491378115154139941550671256271197133252763631939606902895650288268608362241082050562430701794976171121233066073310059947366875

🔑 Key point And with this, friends, we have the trampoline technique: a non-recursive primitive loop that keeps calling another function written recursively but that returns a lambda with context, until reaching the final value.

This code, without TCO, for fib of 10000, takes 0.04 seconds, a result very close to TCO and without causing stack overflow.

Incredible, right? Now there are no excuses for not writing a function recursively in languages that don't have TCO support 😛

Conclusion

In this article, the intent was to bring some concepts and fundamentals around the recursion topic. These concepts overlap with very academic topics that sometimes make it difficult for people who are starting in the field or who don't have a very academic background to understand.

I hope I've clarified the recursion subject in a didactic way. If you can, leave any corrections or relevant information in the comments.

References

https://en.wikipedia.org/wiki/Fibonacci_sequence https://en.wikipedia.org/wiki/Recursion https://www.geeksforgeeks.org/stack-data-structure/ https://en.wikipedia.org/wiki/Tail_call https://en.wikipedia.org/wiki/Trampoline_(computing) https://nithinbekal.com/posts/ruby-tco/ https://www.bigocheatsheet.com/ https://ruby-doc.org/core-3.1.0/RubyVM/InstructionSequence.html#method-c-compile_option

Recently I wrote a 6-article series about x86 Assembly (written in Portuguese, but I'm planning to translate the guide to English soon), covering fundamental concepts of computer architecture and low-level programming while building a minimalist multi-threaded web server.

During the process, I left some important concepts aside for later articles, because if I had tackled them during the series, it would have been even longer than it already was. However, these are concepts that can be addressed separately, like the queues implemented in the thread pool.

And when we talk about queues, it's inevitable to address arrays and how they're organized in computer memory.

In this article, we'll cover fundamental concepts like memory manipulation, registers, and heap memory while implementing arrays.

I'm assuming you're already familiar with x86 Assembly and the GDB tool. If not, I strongly recommend reading my series.

Agenda

• Arrays don't exist

• Strings don't exist either

• The simplest array in the universe

• Using an array with uninitialized data

  • Index to the rescue
  • Hitting the array limit

• Heap, heap, hooray!

  • Dynamic memory allocation with brk
  • Pointers, pointers everywhere
  • Resize with brk

• The final program

• Conclusion

• References

Arrays don't exist

Arrays don't exist. Simple as that.

As we saw in part IV of the series, memory is organized contiguously, where information is allocated one after another.

Suppose we want to declare the following sequence of information:

1, 2, 'H', 0

I know, I know, the types are mixed, but that doesn't matter right now. They all fit in 1 byte

In x86 assembly (let's call it asm for the rest of the article), we can declare this information in the data section like this:

section .data
stuff: db 0x1, 0x2, 0x48, 0x0

Remember that the character 'H' in the ASCII table represents 0x48 in hexadecimal

Using gdb for debugging, we can confirm that this hexadecimal sequence at the stuff label is stored as follows:

# Reading the first hexbyte in stuff
(gdb) x/1xb (void*) &stuff
0x402000 <stuff>:       0x01

# Reading the second hexbyte in stuff
(gdb) x/1xb (void*) &stuff+1
0x402001:       0x02

# Reading the third hexbyte in stuff
(gdb) x/1xb (void*) &stuff+2
0x402002:       0x48

We can also represent the hexadecimal 0x48 in string format using x/s:

(gdb) x/s (void*) &stuff+2
0x402002:       "H"

It's all hexadecimal!

With this, if we want to represent the string "Hello", according to the ASCII table, it could look like this:

section .data
msg: db 0x48, 0x65, 0x6C, 0x6C, 0x6F, 0x0

In gdb, let's check the string representation of the msg label:

(gdb) x/s &msg
0x402000 <msg>: "Hello"

In asm, it's possible to declare the string with direct ASCII table representation:

section .data
msg: db "Hello", 0x0

; same as
; msg: db 0x48, 0x65, 0x6C, 0x6C, 0x6F, 0x0

Strings don't exist either

In other words, it's all hexadecimal in memory. An array, like a string, is simply a contiguous sequence of data with the same size in memory.

The difference is that a string is a "special array" that has data representing ASCII table characters (note that both need to delimit a "final" byte to represent the end of the string or array):

The simplest array possible

Below we have the implementation of a very simple array in asm, which we'll explore step by step in subsequent sections:

global _start

%define SYS_exit 60
%define EXIT_SUCCESS 0

section .data
array: db 1, 2, 3, 0

section .text
_start:
	mov al, [array]        ; array[0]
	mov bl, [array + 1]    ; array[1]
	mov cl, [array + 2]    ; array[2]
	mov sil, [array + 3]   ; array[3]
.exit:
	mov rdi, EXIT_SUCCESS
	mov rax, SYS_exit
	syscall

In the initialized data section .data, we declare an array with 3 elements of 1 byte each (integers from 1 to 3), using the number 0 as the array terminator:

section .data
array: db 1, 2, 3, 0

Next, in the .text section, which is where the program's source code goes, we can access array elements using pointer arithmetic, storing the result in registers:

section .text
_start:
mov al, [array]        ; array[0]

In the code above, we're accessing the value contained at memory address 0x402000 and storing the result in a register (AL) that has a size of 1 byte, meaning only the first byte of the array will be stored in the register.

Let's check with gdb:

# The array is stored at address 0x402000
# and contains the hex value 0x00 0x03 0x02 0x01,
# remembering that this architecture uses little-endian format
(gdb) x &array
0x402000 <array>:       0x00030201

(gdb) b 13
(gdb) run
(gdb) next

# In register AL we have the first element of the array
(gdb) i r al
al             0x1                 1

# It's the same as accessing the first hexbyte contained at address
# 0x402000
(gdb) x/1xb 0x402000
0x402000 <array>:       0x01

Remember that the AL register represents the lower 8-bits within the spectrum of the RAX register which encompasses a total of 64-bits in the x86_64 architecture

To access the other array elements, just do pointer arithmetic and store in other 1-byte registers:

mov al, [array]        ; array[0] => 1
mov bl, [array + 1]    ; array[1] => 2
mov cl, [array + 2]    ; array[2] => 3
mov sil, [array + 3]   ; array[3] => 0 (array ends here)

Using an array with uninitialized data

So far, we're declaring the array in the .data section where data is initialized. But we can make the program more "dynamic" by declaring the array in the section of uninitialized data, which is .bss.

Keeping compatibility with the previous example, let's declare a 4-byte array using the resb directive which means "reserve byte", where the first 3 bytes are reserved to store array elements and the last byte representing 0x0 which is the array terminator.

section .bss
array: resb 4 ; 3 bytes + 1 terminator byte

In gdb, we can see that the array is initialized with all values at zero, indicating that the array is empty but has 4 bytes reserved:

(gdb) x &array
0x402004 <array>:       0x00000000

(gdb) x/4xb &array
0x402004 <array>:       0x00    0x00    0x00    0x00

To add elements to the array, we also need to use pointer arithmetic, just like we did in the previous example to access an array with pre-initialized data.

; Move value 1 to the first byte of the memory address at array
mov byte [array], 1  ; array[0] = 1

With gdb we confirm that at address 0x402000 where the array is, byte 1 was added:

(gdb) x &array
0x402000 <array>:       0x00000001

And if we want to add value 2 to the next byte of the array?

mov byte [array + 1], 2

(gdb) x &array
0x402000 <array>:       0x00000201

Notice that what changes is the array "index". At the initial position of the array, it's like the index is zero, and at the subsequent position, we use index 1, which can be incremented until the array terminator.

It would be very complicated to keep manipulating a hard-coded index. We need a pointer to represent this index.

Index to the rescue

Assuming the array pointer starts with zero, which is the memory address where the array is, we can declare it in the initialized data section .data:

section .bss
array: resb 4 ; 3 bytes + 1 terminator byte

section .data
pointer: db 0

So, we could add the first element like this, right?

mov byte [array + pointer], 1   ; array + 0

When running the program, we get this error:

src/live.asm:14: error: invalid effective address: multiple base segments

This error indicates that we're trying to do pointer manipulation from multiple memory segments, in this case array and pointer.

To solve this, we need to do pointer manipulation with immediate values (which was the previous case with hard-coded numbers) or with registers:

; append(1)
mov al, byte [pointer]
mov byte [array + rax], 1   ; array + 0

• the first instruction moves the first byte contained at the pointer address and stores it in register AL

• the second instruction moves immediate value 1 (array element) to the array's memory address. Since RAX (64-bit version of AL) has value 0x0 representing the pointer, we're inserting at the first byte of the array

And to store the second element in the array?

; append(2)
mov al, byte [pointer]
mov byte [array + rax], 2

In gdb, let's check what's happening:

(gdb) x &array
0x402004 <array>:       0x00000002

Uh, oh... This way we're overwriting the previous value. We actually want the pointer to "move", that is, it needs to be incremented by one byte so that append(2) results in 2 elements in the array.

With the INC instruction we can solve this problem:

mov al, byte [pointer]      ; pointer -> 0
mov byte [array + rax], 1   ; array + 0
inc byte [pointer]          ; pointer -> 1

mov al, byte [pointer]
mov byte [array + rax], 2   ; array + 1

(gdb) x &array
0x402004 <array>:       0x00000201

Yay! What a wonderful day!

Hitting the array limit

And if we keep incrementing the pointer until we hit the array limit?

mov al, byte [pointer]
mov byte [array + rax], 1   ; array + 0
inc byte [pointer]

mov al, byte [pointer]
mov byte [array + rax], 2   ; array + 1
inc byte [pointer]

mov al, byte [pointer]
mov byte [array + rax], 3   ; array + 2
inc byte [pointer]

# Reading the first 4 hexabytes of the array, we have the representation
# of the full array with all spaces occupied, remembering that
# the last byte is the array terminator
(gdb) x /4xb &array
0x402004 <array>:       0x01    0x02    0x03    0x00

# The pointer is at the end of the array
(gdb) x &pointer
0x402000 <pointer>:     0x03

Wonderful, and if we add one more element, should our program allow it?

mov al, byte [pointer]
mov byte [array + rax], 4   ; array + 3
inc byte [pointer]

# We shouldn't allow another element to be added,
# since our array was already full
(gdb) x /4xb &array
0x402004 <array>:       0x01    0x02    0x03    0x04

# The pointer is beyond the array capacity (not good...)
(gdb) x &pointer
0x402000 <pointer>:     0x04

Let's use a conditional jump (I explain more about this in the series) to not allow the element to be added. With this, before appending to the array, we should check if the pointer is already at the end of the array:

cmp byte [pointer], 3   ; check if array is full
je .exit                ; jump to .exit routine if flag is raised

Here's the complete program:

global _start

%define SYS_exit 60
%define EXIT_SUCCESS 0

section .bss
array: resb 4 ; 3 bytes + 1 terminator byte

section .data
pointer: db 0

section .text
_start:
	cmp byte [pointer], 3   ; check if array is full
	je .exit

	mov al, byte [pointer]
	mov byte [array + rax], 1   ; array + 0
	inc byte [pointer]

	cmp byte [pointer], 3   ; check if array is full
	je .exit

	mov al, byte [pointer]
	mov byte [array + rax], 2   ; array + 1
	inc byte [pointer]

	cmp byte [pointer], 3   ; check if array is full
	je .exit

	mov al, byte [pointer]
	mov byte [array + rax], 3   ; array + 2
	inc byte [pointer]

	cmp byte [pointer], 3   ; check if array is full
	je .exit

	; shouldn't allow adding the fourth element,
	; since the array supports up to 3 elements. this way,
	; we'd be writing to the memory address of other
	; program data
	mov al, byte [pointer]
	mov byte [array + rax], 4   ; array + 3
	inc byte [pointer]
.exit:
	mov rdi, EXIT_SUCCESS
	mov rax, SYS_exit
	syscall

(gdb) x &pointer
0x402000 <pointer>:     0x00000003
(gdb) x &array
0x402004 <array>:       0x00030201

Perfect, let's now do a small refactoring in the code separating the append logic into a subroutine:

global _start

%define SYS_exit 60
%define EXIT_SUCCESS 0
%define CAPACITY 3

section .bss
array: resb CAPACITY + 1

section .data
pointer: db 0

section .text
_start:
	mov rdi, 1
	call .append

	mov rdi, 2
	call .append

	mov rdi, 3
	call .append

	mov rdi, 4
	call .append
.exit:
	mov rdi, EXIT_SUCCESS
	mov rax, SYS_exit
	syscall
.append:
	cmp byte [pointer], CAPACITY ; check if array is full
	je .done

	mov al, byte [pointer]
	mov byte [array + rax], dil
	inc byte [pointer]
.done:
	ret

If you want to understand more about conditional jump, routines, call, ret and flags, I suggest reading my series which has been referenced several times in this article

Running with gdb and...

(gdb) x &array
0x402004 <array>:       0x00030201

(gdb) x &pointer
0x402000 <pointer>:     0x00000003

A big Yay!

However, there may be situations where we want our array to be resized to support more elements, that is, the array size would be dynamic.

How do we add more elements beyond the initial capacity without writing to other memory areas that don't belong to the array?

Heap, heap, hooray!

Before talking about the heap, let's remember how the memory layout of a computer program works:

• the layout is represented as an area in computer memory where we have the program's lowest memory addresses toward the highest addresses at the top

• at the lowest memory addresses, we have the .text section, where we've already seen that it refers to the program itself

• then we have the data section which encompasses initialized data .data and the following section representing uninitialized data .bss

• at the highest addresses, we have the program's stack, which stores metadata such as the program name, its arguments and any program information that has a fixed size fitting within the stack, as well as function calls and their respective arguments

• the stack has a stack format and "grows downward", that is, as we add elements to the stack, it grows toward lower addresses in memory

In the "middle" of the layout, between the data section and the stack, we have a large area in memory that many end up associating as heap. In the heap, we can allocate data dynamically, unlike the static way we do in the data section.

To accommodate a dynamic-sized array that supports resizing, we have to allocate memory in this area.

In this article, we'll call this region in the middle of memory between the data section and the stack heap

Dynamic memory allocation with brk

One way to manipulate this memory area is through the brk syscall, which changes the program break, which is where the data section ends.

With brk, we can modify this program break to higher addresses, that is, allowing manipulation of memory areas that go beyond the program and data section.

The first thing we need to do is map the syscall and make the call that brings the current break address:

%define SYS_brk 12
....

section .text
_start:
; syscall to access the program break (0x403000), which is where
; the data section ends and the heap begins
mov rdi, 0
mov rax, SYS_brk
syscall
....

With gdb, let's analyze the program state:

# Breakpoint at brk syscall line
(gdb) b 18
(gdb) run

# The program start is in the .text section and begins at
# 0x401000
(gdb) x _start
0x401000 <_start>:      0x000000bf

# The pointer is in the .data section a bit higher and starts at
# 0x402000
(gdb) x &pointer
0x402000 <pointer>:     0x00000000

# The array is in the .bss section a bit higher and starts at
# 0x402004
(gdb) x &array
0x402004 <array>:       0x00000000

# Execute the brk syscall
(gdb) n

# The brk syscall stores in RAX the program break memory address,
# in this case a bit higher at 0x403000
(gdb) i r rax
rax            0x403000            4206592

• 0x401000: .text section which is where the program begins

• 0x402000: .data section where initialized data is

• 0x402004: .bss section where uninitialized data is

• 0x403000: program break, which is where the data section ends and our "heap" begins

With this, from address 0x403000 onwards is where we'll put our array elements, so the array address can use just one byte, which points to the address where the first element begins in the heap.

In the syscall we made, if the argument in RDI is zero, it means brk will return the current program break, in this case 0x403000. But we can make more brk syscalls with a different RDI argument (incremented), signaling that we're changing the program break.

From now on, in the .bss data section, we no longer need to reserve 4 bytes for the array, so only 1 byte is needed which will represent the array's memory address in the heap:

global _start

%define SYS_brk 12
%define SYS_exit 60
%define EXIT_SUCCESS 0
%define CAPACITY 3

; initially starts with 0x000000, but will later contain
; address 0x403000
section .bss
array: resb 1

section .data
pointer: db 0

section .text
_start:
	mov rdi, 0
	mov rax, SYS_brk
	syscall

	mov rdi, rax
	add rdi, CAPACITY
	mov rax, SYS_brk
	syscall

...
...

Analyzing with gdb:

# Breakpoint at first syscall
(gdb) b 18

(gdb) run

# Execute the syscall line
(gdb) n

# In RAX the syscall stores the program break address, in this case
# 0x403000
(gdb) i r rax
rax            0x403000            4206592

(gdb) x 0x403000
0x403000:       Cannot access memory at address 0x403000

At this moment, this address is not yet accessible because we haven't reserved new bytes in the heap. Let's move forward with the next syscall:

(gdb) n
(gdb) n

# Before executing the syscall, we verify that argument RDI will
# contain the desired address for the new program break, in this case with
# 3 bytes added, 0x403003
(gdb) i r rdi
rdi            0x403003            4206595

# Execute the syscall...
(gdb) n
(gdb) n

# After executing the second syscall, we see that in RAX, the program break was changed to 0x403003
(gdb) i r rax
rax            0x403003            4206595

Now, we can access memory addresses between 0x403000 and 0x403003:

(gdb) x 0x403000
0x403000:       0x00000000
(gdb) x 0x403001
0x403001:       0x00000000
(gdb) x 0x403002
0x403002:       0x00000000
(gdb) x 0x403003
0x403003:       0x00000000

Wow! Now we have in the heap a reserved area especially for our dear array, how cool is that!

How are we going to manipulate the array in this memory region?

Pointers, pointers everywhere

After the first syscall, we should take the memory address 0x403000 which represents the first program break and store it in the array pointer that's in .bss:

...
mov rdi, 0
mov rax, SYS_brk
syscall
mov [array], rax      ; <---- breakpoint here

mov rdi, rax
add rdi, CAPACITY
mov rax, SYS_brk
syscall
...

Let's check with gdb the breakpoint at the line that changes the array pointer:

(gdb) b 19
(gdb) run

(gdb) x &array
0x402004 <array>:       0x00000000

# Execute the line that changes the pointer
(gdb) n

# Now the pointer points to address 0x403000,
# this is what we want
(gdb) x &array
0x402004 <array>:       0x00403000

Important to note that array is at address 0x402004, in the .bss section, so its value represents another memory address 0x403000 which is where the first array element should start in the heap.

Now, when we make the next syscall to allocate 3 bytes in the heap, the program break will be modified and we'll be able to manipulate the array since the pointer already points to the correct address.

After the second syscall, we can no longer manipulate array by its value, because now the array value is no longer an actual element, but rather an address to another place in memory.

Here's the program in its current version:

global _start

%define SYS_brk 12
%define SYS_exit 60
%define EXIT_SUCCESS 0
%define CAPACITY 3

section .bss
array: resb 1   ; 0x403000

section .data
pointer: db 0

section .text
_start:
	mov rdi, 0
	mov rax, SYS_brk
	syscall
	mov [array], rax

	mov rdi, rax
	add rdi, CAPACITY
	mov rax, SYS_brk
	syscall

	mov rbx, [array]

	mov r8, 1
	call .append

	mov r8, 2
	call .append

	mov r8, 3
	call .append

	mov r8, 4
	call .append
.exit:
	mov rdi, EXIT_SUCCESS
	mov rax, SYS_exit
	syscall
.append:
	cmp byte [pointer], CAPACITY ; check if array is full
	je .done

	mov sil, byte [pointer]
	mov byte [rbx + rsi], r8b
	inc byte [pointer]
.done:
	ret

Explaining each block:

mov rdi, 0
mov rax, SYS_brk
syscall
mov [array], rax

• fetches the current program break and stores the address in the array pointer

mov rdi, rax
add rdi, CAPACITY
mov rax, SYS_brk
syscall

• modifies the current program break, incrementing 3 bytes which is the initial array capacity in the heap

; assign to the register the memory address that the
; "array" pointer is pointing to
mov rbx, [array]

• stores the pointer's memory address in register RBX. This is necessary because we don't want to do arithmetic directly on the pointer in the .bss section, but rather through a register that allows it

mov r8, 1
call .append

• since now RDI was used as argument in the brk syscall, it's not convenient to use this register anymore to represent the element to be added to the array, so we switch to register R8

.append:
	cmp byte [pointer], CAPACITY ; check if array is full
	je .done

	mov sil, byte [pointer]
	mov byte [rbx + rsi], r8b    ; indirect-mode addressing
	inc byte [pointer]
.done:
	ret

Now the .append routine has been modified so that heap array manipulation is through register RBX. We also can't use register RAX anymore to represent the pointer because the brk syscall also used it as return for the program break; in this case we switch to RSI (which has SIL as its lower 8-bit representation).

Running with gdb, we can verify that elements are being added at address 0x403000 which is in the heap, through the pointer that was stored in register RBX:

# Array points to address 0x403000
(gdb) x &array
0x402004 <array>:       0x00403000

# At that address, we have the added elements. Yay!
(gdb) x 0x403000
0x403000:       0x00030201

# And the "index" pointer correctly representing the end of the array in the heap
(gdb) x &pointer
0x402000 <pointer>:     0x00000003

At this point, the program has the same behavior as the previous example with static array in .bss, not allowing adding more elements when the array reaches its limit.

Let's change this by resizing the array and allowing new elements to be added.

Resize with brk

Next, we start the steps so that array resizing is done when it reaches capacity limit. We start by changing the .append routine:

.append:
	cmp byte [pointer], CAPACITY ; check if array is full
	je .resize

	mov sil, byte [pointer]
	mov byte [rbx + rsi], r8b
	inc byte [pointer]
.done:
	ret
.resize:
	...

Instead of jumping to .done when the array is full, we jump to another subroutine called .resize, which should make the brk syscall again, thus modifying the program break in a new memory area, obeying the initial array capacity:

.append:
	cmp byte [pointer], CAPACITY ; check if array is full
	je .resize

	mov sil, byte [pointer]
	mov byte [rbx + rsi], r8b
	inc byte [pointer]
.done:
	ret
.resize:
	mov rdi, 0
	mov rax, SYS_brk
	syscall

	mov rdi, rax            ; RDI now represents the current break
	add rdi, CAPACITY       ; add 3 bytes, becoming 0x403006
	mov rax, SYS_brk
	syscall
	jmp .append

• the first resize syscall brings the current break, in this case we already know it's 0x403003, which was allocated at the beginning of the program for the array

• the second resize syscall modifies the current break, thus allocating 3 more bytes in the heap

• at the end of resize, instead of returning the function, we'll go back to the beginning of .append and execute the necessary logic to add the element to the array

This way, we can manipulate this new memory area to add more elements to the array, thus dynamically modifying its capacity.

If we run the program exactly like this, we'll face a problem, because:

• every time resize is done, it jumps to the beginning of the routine

• the array size (pointer) is checked against the initial capacity, which in this case is 3. Since the pointer reached value 3, it will enter resize again characterizing an infinite loop with infinite resize until memory runs out

To solve this, we need to compare the pointer with the current capacity (modified), and therefore we'll add a value in the .data section representing the current capacity:

%define CAPACITY 3

section .data
pointer: db 0
currentCapacity: db CAPACITY ; starts with 3

In the .append routine, we'll make the comparison with currentCapacity, which will be modified with each resize, instead of with CAPACITY, which will remain fixed with the initial value throughout the program.

.append:
	mov r9, [currentCapacity]
	cmp byte [pointer], r9b     ; check if array is full
	je .resize
...

And, after resizing before going back to .append, we'll increment the initial capacity to the current capacity:

.resize:
	mov rdi, 0
	mov rax, SYS_brk
	syscall

	mov rdi, rax
	add rdi, CAPACITY
	mov rax, SYS_brk
	syscall

	mov r10, currentCapacity
	add byte [r10], CAPACITY
	jmp .append

Running the program, we can see that element 4 was successfully added to the array after resizing:

(gdb) x 0x403000
0x403000:       0x04030201

And if we add more and more elements?

...
	mov r8, 4
	call .append

	mov r8, 5
	call .append

	mov r8, 6
	call .append

	mov r8, 7
	call .append
...

# We can see that currentCapacity is 9, meaning there were
# 2 resizes. Our array can now accommodate up to 9 elements,
# so when adding the tenth element, one more resize would be done.
(gdb) x &currentCapacity
0x402001 <currentCapacity>:     0x09

# Fetching the first 9 hexabytes at the array address in the heap
(gdb) x/9xb  0x403000
0x403000:       0x01    0x02    0x03    0x04    0x05    0x06    0x07    0x00
0x403008:       0x00

How cool is that?

The final program

Here's the final program, with an array of initial capacity of 3 elements in the heap that can be resized using the brk syscall, as more elements are added to the array:

global _start

%define SYS_brk 12
%define SYS_exit 60
%define EXIT_SUCCESS 0
%define CAPACITY 3

section .bss
array: resb 1

section .data
pointer: db 0
currentCapacity: db CAPACITY ; initial capacity is 3

section .text
_start:
	mov rdi, 0
	mov rax, SYS_brk
	syscall
	mov [array], rax

	mov rdi, rax
	add rdi, CAPACITY
	mov rax, SYS_brk
	syscall

	mov rbx, [array]

	mov r8, 1
	call .append

	mov r8, 2
	call .append

	mov r8, 3
	call .append

	mov r8, 4
	call .append

	mov r8, 5
	call .append

	mov r8, 6
	call .append

	mov r8, 7
	call .append
.exit:
	mov rdi, EXIT_SUCCESS
	mov rax, SYS_exit
	syscall
.append:
	mov r9, [currentCapacity]
	cmp byte [pointer], r9b ; check if array is full
	je .resize

	mov sil, byte [pointer]
	mov byte [rbx + rsi], r8b
	inc byte [pointer]
.done:
	ret
.resize:
	mov rdi, 0
	mov rax, SYS_brk
	syscall

	mov rdi, rax
	add rdi, CAPACITY
	mov rax, SYS_brk
	syscall

	mov r10, currentCapacity
	add byte [r10], CAPACITY
	jmp .append

Conclusion

In this article, we showed the implementation of an array in x86 Assembly, covering important concepts like memory layout, register manipulation, and dynamic memory allocation with brk.

This article is the foundation for future articles about data structures, where I intend to write about implementing queues and later other data structures.

References

• brk syscall

• x86 Assembly series

If you want to learn about UNIX signals, binary operations the easy way, how a message broker works under the hood, and a bit of Ruby, this post is for you.

And if you came here just because of the clickbait title, I apologize and invite you to keep reading. It'll be fun, I promise.

It's all about UNIX

A few days ago, I saw some discussion on the internet about how we could send messages between processes. Many people think of sockets, which are the most common way to send messages, even allowing communication across different machines and networks. Some don't even realize that pipes are another way to send messages between processes:

$ echo 'hello' | base64
aGVsbG8K

Here's what's happening:

• The process echo is started with the content "hello"

• echo is a program that prints the message to STDOUT

• Through the pipe, the content in STDOUT is sent directly to the STDIN of the base64 process

• The base64 process encodes its input to Base64 and then puts the result in STDOUT

Note the word "send". Yes, anonymous pipes are a form of IPC (Inter-process communication). Other forms of IPC in UNIX include:

• named pipes (mkfifo)

• sockets

• regular files

• or even a simple signal

UNIX signals

According to Wikipedia:

A UNIX signal is a standardized message sent to a program to trigger specific behaviour, such as quitting or error handling

There are many signals we can send to a process, including:

• SIGTERM - sends a notification to the process to terminate. It can be "trapped," which means the process can do some cleanup work before termination, like releasing OS resources and closing file descriptors

• SIGKILL - sends a termination signal that cannot be trapped or ignored, forcing immediate termination

• SIGINT - the interrupt signal, typically sent when you press Ctrl+C in the terminal. It can be trapped, allowing the process to perform cleanup before exiting gracefully

• SIGHUP - the hangup signal, originally sent when a terminal connection was lost. Modern applications often use it to reload configuration files without restarting the process

• SIGQUIT - similar to SIGINT but also generates a core dump for debugging

• SIGSTOP - pauses (suspends) a process. Cannot be trapped or ignored

• SIGCONT - resumes a process that was paused by SIGSTOP

• SIGCHLD - sent to a parent process when a child process terminates or stops

• SIGUSR1 and SIGUSR2 - user-defined signals that applications can use for custom purposes

Sending messages using signals

Okay, we know that signals are a primitive form of IPC. UNIX-like systems provide a syscall called kill that sends signals to processes. Historically, this syscall was created solely to terminate processes. But over time, they needed to accommodate other types of signals, so they reused the same syscall for different purposes.

For instance, let's create a simple Ruby script sleeper.rb which sleeps for 60 seconds, nothing more:

puts "Process ID: #{Process.pid}"
puts "Sleeping for 60 seconds..."
sleep 60

After running we see:

Process ID: 55402
Sleeping for 60 seconds...

In another window, we can send the SIGTERM signal to the process 55402 via syscall kill:

$ kill -SIGTERM 55402

And then, in the script session:

[1]    55402 terminated  ruby sleeper.rb

Signal traps

In Ruby, we can also trap a signal using the trap method in Ruby:

puts "Process ID: #{Process.pid}"
puts "Sleeping for 60 seconds..."

trap('SIGTERM') do 
  puts "Received SIGTERM, exiting gracefully..."
  exit
end

sleep 60

Which in turn, after sending the signal, will gracefully:

Process ID: 55536
Sleeping for 60 seconds...
Received SIGTERM, exiting gracefully...

After all, we cannot send messages using signals. They are a primitive way of sending standardized messages which will trigger specific behaviours. At most, we can trap some signals, but nothing more.

Okay Leandro, but what's the purpose of this article then?

Hold on. That's exactly why I'm here. To prove points by doing useless stuff, like when I simulated OOP in Bash a couple of years ago (it was fun though).

To understand how we can "hack" UNIX signals and send messages between processes, let's first talk a bit about binary operations. Yes, those "zeros" and "ones" you were scared of when you saw them for the first time. But they don't bite (🥁 LOL), I promise.

What is a message?

If we model a message as a sequence of characters, we could say that at a high-level, messages are simply strings. But in memory, they are stored as bytes.

We know that bytes are made of bits. In computer terms, what's a bit? It's simply an abstraction representing only two states:

• zero

• one

That's it. For instance, using ASCII, we know that the letter "h" has the following codes:

• 104 in decimal

• 0x68 in hexadecimal

• 01101000 in binary

Binary-wise, what if we represented each "0" with a specific signal and each "1" with another? We know that some signals such as SIGTERM, SIGINT, and SIGCONT can be trapped, but intercepting them would harm their original purpose.

But thankfully, UNIX provides two user-defined signals that are perfect for our hacking experiment.

Sending SIGUSR1 and SIGUSR2

First things first, let's trap those signals in the code:

puts "Process ID: #{Process.pid}"
puts "Sleeping forever. Send signals to this process to see how it responds."

trap('SIGUSR1') do 
  puts "Received SIGUSR1 signal"
end

trap('SIGUSR2') do
  puts "Received SIGUSR2 signal"
end

sleep

Process ID: 56172
Sleeping forever. Send signals to this process to see how it responds.

After sending some kill -SIGUSR1 56172 and kill -SIGUSR2 56172, we can see that the process prints the following content:

Process ID: 56172
Sleeping forever. Send signals to this process to see how it responds.
Received SIGUSR1 signal
Received SIGUSR2 signal
Received SIGUSR2 signal
Received SIGUSR1 signal
Received SIGUSR1 signal
Received SIGUSR2 signal

Signals don't carry data. But the example we have is perfect for changing to bits, uh?

Received SIGUSR1 signal # 0
Received SIGUSR2 signal # 1
Received SIGUSR2 signal # 1
Received SIGUSR1 signal # 0
Received SIGUSR2 signal # 1
Received SIGUSR1 signal # 0
Received SIGUSR1 signal # 0
Received SIGUSR1 signal # 0

That's exactly 01101000, the binary representation of the letter "h". We're simply encoding the letter as a binary representation and sending it via signals

Again, we're encoding it as a binary and sending it via signals.

How cool is that?

Decoding the binary data

On the other side, the receiver should be capable of decoding the message and converting it back to the letter "h":

• sender encodes the message

• receiver decodes the message

So, how do we decode 01101000 (the letter "h" in ASCII)? Let's break it down into a few steps:

1. First, we need to see the 8 bits as individual digits in their respective positions
2. The rightmost bit is at position 0, whereas the leftmost bit is at position 7. This is how we define the most significant bit (MSB, the leftmost) and the least significant bit (LSB, the rightmost)
3. For this example, we perform a left shift operation on each bit and then sum all the values, in this case from MSB to LSB (the order doesn't matter much for now): (0 << 7) + (1 << 6) + (1 << 5) + (0 << 4) + ... + (0 << 0): left shift on zeros will always produce a zero

• 0 << 7 = (2 ** 7) * 0 = 128 * 0 = 0

• 1 << 6 = (2 ** 6) * 1 = 64 * 1 = 64

Similarly to the remaining bits:

• 1 << 5 = 32

• 0 << 4 = 0

• 1 << 3 = 8

• 0 << 2 = 0

• 0 << 1 = 0

• 0 << 0 = 0

So, our sum becomes, from MSB to LSB:

MSB                          LSB
0   1    1    0   1   0   0   0
0 + 64 + 32 + 0 + 8 + 0 + 0 + 0 = 104

104 is exactly the decimal representation of the letter "h" in ASCII.

How wonderful is that?

Sending the letter "h"

Now let's convert these operations to Ruby code. We'll write a simple program receiver.rb that receives signals in order from LSB to MSB (positions 0 to 7) and then converts them back to ASCII characters, printing to STDOUT.

Basically, we'll accumulate bits and whenever we form a complete byte, we'll decode it to its ASCII representation. The very basic implementation of our accumulate_bit(bit) method would look like as follows:

@position = 0 # start with the LSB
@accumulator = 0

def accumulate_bit(bit)
  # The left shift operator (<<) is used to 
  # shift the bits of the number to the left.
  #
  # This is equivalent of: (2 ** @position) * bit
  @accumulator += (bit << @position)
  return @accumulator if @position == 7 # stop accumulating after 8 bits (byte)

  @position += 1 # move to the next bit position: 0 becomes 1, 1 becomes 2, etc.
end

# Letter "h" in binary is 01101000
# But we'll send from the LSB to the MSB
#
# 0110 1000 (MSB -> LSB) becomes 0001 0110 (LSB -> MSB)
# The order doesn't matter that much, it'll depend on 
# the receiver's implementation.
accumulate_bit(0)
accumulate_bit(0)
accumulate_bit(0)
accumulate_bit(1)
accumulate_bit(0)
accumulate_bit(1)
accumulate_bit(1)
accumulate_bit(0)

puts @accumulator # should print 104, which is the ASCII code for "h"

Pay attention to this code. It's very important and builds the foundation for the next steps. If you didn't get it, go back and read it again. Try it yourself in the terminal or using your preferred programming language.

Now, how to convert the decimal 104 to the ASCII character representation? Luckily, Ruby provides a method called chr which does the job:

irb> puts 104.chr
=> "h"

We could do the same job for the rest of the word "hello", for instance. According to the ASCII table, it should be the following:

• e in decimal is 101

• l in decimal is 108

• o in decimal is 111

Let's check if Ruby knows that:

104.chr    # "h"
101.chr    # "e"
108.chr    # "l"
111.chr    # "o"

We can even "decode" the word to the decimal representation in ASCII:

irb> "hello".bytes
=> [104, 101, 108, 108, 111]

Now, time to finish our receiver implementation to properly print the letter "h":

@position = 0 # start with the LSB
@accumulator = 0

trap('SIGUSR1') { decode_signal(0) }
trap('SIGUSR2') { decode_signal(1) }

def decode_signal(bit)
  accumulate_bit(bit)
  return unless @position == 8 # if not yet accumulated a byte, keep accumulating

  print "Received byte: #{@accumulator} (#{@accumulator.chr})\n"

  @accumulator = 0 # reset the accumulator
  @position = 0 # reset position for the next byte
end

def accumulate_bit(bit)
  # The left shift operator (<<) is used to 
  # shift the bits of the number to the left.
  #
  # This is equivalent of: (2 ** @position) * bit
  @accumulator += (bit << @position)
  @position += 1 # move to the next bit position: 0 becomes 1, 1 becomes 2, etc.
end

puts "Process ID: #{Process.pid}"
sleep

Read that code and its comments. It's very important. Do not continue reading until you really get what's happening here.

• Whenever we get SIGUSR1, we accumulate the bit 0

• When getting SIGUSR2, accumulate then the bit 1

• When accumulator reaches the position8, it means we have a byte. At this moment we should print the ASCII representation using the .chr we seen earlier. Then, reset bit position and accumulator

Let's see our receiver in action! Start the receiver in one terminal:

$ ruby receiver.rb
Process ID: 58219

Great! Now the receiver is listening for signals. In another terminal, let's manually send signals to form the letter "h" (which is 01101000 in binary, remember?):

  # Sending from LSB to MSB: 0, 0, 0, 1, 0, 1, 1, 0
  $ kill -SIGUSR1 58219  # 0
  $ kill -SIGUSR1 58219  # 0
  $ kill -SIGUSR1 58219  # 0
  $ kill -SIGUSR2 58219  # 1
  $ kill -SIGUSR1 58219  # 0
  $ kill -SIGUSR2 58219  # 1
  $ kill -SIGUSR2 58219  # 1
  $ kill -SIGUSR1 58219  # 0

And in the receiver terminal, we should see:

Received byte: 104 (h)

How amazing is that? We just sent the letter "h" using only two UNIX signals!

But wait. Manually sending 8 signals for each character? That's tedious and error-prone. What if we wanted to send the word "hello"? That's 5 characters × 8 bits = 40 signals to send manually. No way.

We need a sender.

Building the sender

The sender's job is the opposite of the receiver: it should encode a message (string) into bits and send them as signals to the receiver process.

Let's think about what we need:

1. Take a message as input (like "hello")
2. Convert each character to its byte representation
3. Extract the 8 bits from each byte
4. Send SIGUSR1 for bit 0, SIGUSR2 for bit 1
5. Repeat for all characters

The tricky part here is the step 3: how do we extract individual bits from a byte? To extract the bit at position i, we can use the following formula:

bit = (byte >> i) & 1

Let me break this down:

• byte >> i performs a right shift by i positions

• & 1 is a bitwise AND operation that extracts only the rightmost bit

For the letter "h" (01101000 in binary, 104 in decimal):

Position 0 (LSB):

• (104 >> 0) = 104 / (2 ** 0) = 104 / 1 = 104

• 01101000 >> 0 = 01101000

• 01101000 & 00000001 = 0 (one AND zero is zero)

Position 1:

• (104 >> 1) = 104 / (2 ** 1) = 104 / 2 = 52

• 01101000 >> 1 = 00110100

• 00110100 & 00000001 = 0

Position 2:

• (104 >> 2) = 104 / (2 ** 2) = 104 / 4 = 26

• 01101000 >> 2 = 00011010

• 00011010 & 00000001 = 0

Position 3:

• (104 >> 3) = 104 / (2 ** 3) = 104 / 8 = 13

• 01101000 >> 3 = 00001101

• 00001101 & 00000001 = 1 (one AND one equals one)

And so on for positions 4, 5, 6, and 7. This gives us: 0, 0, 0, 1, 0, 1, 1, 0 — exactly the bits we need from LSB to MSB!

• (104 >> 0) & 1 = 104 & 1 = 0

• (104 >> 1) & 1 = 52 & 1 = 0

• (104 >> 2) & 1 = 26 & 1 = 0

• (104 >> 3) & 1 = 13 & 1 = 1

• (104 >> 4) & 1 = 6 & 1 = 0

• (104 >> 5) & 1 = 3 & 1 = 1

• (104 >> 6) & 1 = 1 & 1 = 1

• (104 >> 7) & 1 = 0 & 1 = 0

Pay close attention to this technique. It's a fundamental operation in low-level programming.

So now time to build the sender.rb which is pretty simple:

receiver_pid = ARGV[0].to_i
message = ARGV[1..-1].join(' ')

def encode_byte(byte)
  8.times.map do |i|
    # Extract each bit from the byte, starting from the LSB
    (byte >> i) & 1
  end
end

message.bytes.each do |byte|
  encode_byte(byte).each do |bit|
    signal = bit == 0 ? 'SIGUSR1' : 'SIGUSR2'
    Process.kill(signal, receiver_pid)
    sleep 0.001 # Delay to allow the receiver to process the signal
  end
end

For each byte (8-bit structure) we extract the bit performing the right shift + AND oprerations. The result is the extracted bit.

In the receiver window:

$ ruby receiver.rb
Process ID: 68968

And in the sender window:

$ ruby sender.rb 68968 h

The receiver will print:

$ ruby receiver.rb
Process ID: 68968
Received byte: 104 (h)

Processes sending messages with only two signals! How wonderful is that?

Sending the "hello" message

Now, sending the hello message is super easy. The sender is already able to send not only a letter but any message using signals:

$ ruby sender.rb 68968 hello

# And the receiver:
Received byte: 104 (h)
Received byte: 101 (e)
Received byte: 108 (l)
Received byte: 108 (l)
Received byte: 111 (o)

Just change the receiver implementation a little bit:

def decode_signal(bit)
  accumulate_bit(bit)
  return unless @position == 8 # if not yet accumulated a byte, keep accumulating

  print @accumulator.chr # print the byte as a character

  @accumulator = 0 # reset the accumulator
  @position = 0 # reset position for the next byte
end

And then:

$ ruby sender.rb 96875 Hello

# In the receiver's terminal
Process ID: 96875
Hello

However, if we send the message again, the receiver will print everything in the same line:

$ ruby sender.rb 96875 Hello
$ ruby sender.rb 96875 Hello

# In the receiver's terminal
Process ID: 96875
HelloHello

It's obvious: the receiver doesn't know where the sender finished the message, so it's impossible to know where we should stop one message and print the next one on a new line with \n.

We should then determine how the sender indicates the end of the message. How about being it all zeroes (0000 0000)?

• We send the message: first 5 bytes representing the "hello" message

• Then we send a "NULL terminator", just one byte 0 (0000 0000)

0110 1000 # h
0110 0101 # e
0110 1000 # l
0110 1000 # l
0110 1111 # o
0000 0000 # NULL

Hence, when the receiver gets a NULL terminator, it will print a line feed \n. Let's change the sender.rb first:

receiver_pid = ARGV[0].to_i
message = ARGV[1..-1].join(' ')

def encode_byte(byte)
  8.times.map do |i|
    # Extract each bit from the byte, starting from the LSB
    (byte >> i) & 1
  end
end

message.bytes.each do |byte|
  encode_byte(byte).each do |bit|
    signal = bit == 0 ? 'SIGUSR1' : 'SIGUSR2'
    Process.kill(signal, receiver_pid)
    sleep 0.001 # Delay to allow the receiver to process the signal
  end
end

# Send NULL terminator (0000 0000)
8.times do
  Process.kill('SIGUSR1', receiver_pid)
  sleep 0.001 # Delay to allow the receiver to process the signal
end

puts "Message sent to receiver (PID: #{receiver_pid})"

Then, the receiver.rb:

@position = 0 # start with the LSB
@accumulator = 0

trap('SIGUSR1') { decode_signal(0) }
trap('SIGUSR2') { decode_signal(1) }

def decode_signal(bit)
  accumulate_bit(bit)
  return unless @position == 8 # if not yet accumulated a byte, keep accumulating

  if @accumulator.zero? # NULL terminator received
    print "\n"
  else
    print @accumulator.chr # print the byte as a character
  end

  @accumulator = 0 # reset the accumulator
  @position = 0 # reset position for the next byte
end

def accumulate_bit(bit)
  # The left shift operator (<<) is used to 
  # shift the bits of the number to the left.
  #
  # This is equivalent of: (2 ** @position) * bit
  @accumulator += (bit << @position)
  @position += 1 # move to the next bit position: 0 becomes 1, 1 becomes 2, etc.
end

puts "Process ID: #{Process.pid}"
sleep

Output:

$ ruby sender.rb 96875 Hello, World!
$ ruby sender.rb 96875 You're welcome
$ ruby sender.rb 96875 How are you?

# Receiver
Process ID: 97176
Hello, World!
You're welcome
How are you?

OMG Leandro! That's amazing!

Amazing, right? We just built an entire communication system between two processes using one of the most primitive methods available: UNIX signals.

The sky's the limit now! Why not build a full-fledged message broker using this crazy technique?

A modest message broker using UNIX signals

We'll break down the development into three components:

1. Broker: the intermediary that routes messages
2. Consumer: processes that receive messages
3. Producer: processes that send messages

1. Let's start with the Broker. It should register itself with the producer, then trap incoming signals, decode them, and enqueue the messages for delivery to consumers via outgoing signals:

#!/usr/bin/env ruby

require_relative 'signal_codec'
require_relative 'consumer'

class Broker 
  PID = 'broker.pid'.freeze

  def initialize
    @codec = SignalCodec.new
    @queue = Queue.new
    @consumer_index = 0
  end

  def start 
    register_broker

    trap('SIGUSR1') { process_bit(0) }
    trap('SIGUSR2') { process_bit(1) }
    
    puts "Broker PID: #{Process.pid}"
    puts "Waiting for messages..."

    distribute_messages

    sleep # Keep alive
  end 

  private

  def process_bit(bit)
    @codec.accumulate_bit(bit) do |message|
      @queue.push(message) unless message.empty?
    end
  end

  def register_broker 
    File.write(PID, Process.pid)
    at_exit { File.delete(PID) if File.exist?(PID) }
  end

  def distribute_messages
    Thread.new do
      loop do
        sleep 0.1

        next if @queue.empty?

        consumers = File.exist?(Consumer::FILE) ? File.readlines(Consumer::FILE).map(&:to_i) : []
        next if consumers.empty?

        message = @queue.pop(true) rescue next

        consumer_pid = consumers[@consumer_index % consumers.size]
        @consumer_index += 1

        puts "[SEND] #{message} → Consumer #{consumer_pid}"

        @codec.send_message(message, consumer_pid)
      end
    end
  end
end

if __FILE__ == $0 
  broker = Broker.new
  broker.start
end

• The broker registers itself

• Traps incoming signals USR1 (bit 0) and USR2 (bit 1)

• Enqueues the messages

• Send messages to consumers using outgoing signals (USR1 and USR2 too)

Note that we're using a module called SignalCodec which will be explained soon. Basically this module contains all core components to encode/decode signals and perform bitwise operations.

2. Now the Consumer implementation:

#!/usr/bin/env ruby

require_relative 'signal_codec'

class Consumer
  FILE = 'consumers.txt'.freeze

  def initialize
    @codec = SignalCodec.new
  end

  def start
    register_consumer

    trap('SIGUSR1') { process_bit(0) }
    trap('SIGUSR2') { process_bit(1) }

    puts "Consumer PID: #{Process.pid}"
    puts "Waiting for messages..."

    sleep # Keep alive
  end

  private

  def process_bit(bit)
    @codec.accumulate_bit(bit) do |message|
      puts "[RECEIVE] #{message}"
    end
  end

  def register_consumer
    File.open(FILE, 'a') { |f| f.puts Process.pid }
    at_exit { deregister_consumer }
  end

  def deregister_consumer
    if File.exist?(FILE)
      consumers = File.readlines(FILE).map(&:strip).reject { |pid| pid.to_i == Process.pid }
      File.write(FILE, consumers.join("\n"))
    end
  end
end

if __FILE__ == $0
  consumer = Consumer.new
  consumer.start
end

• The consumer starts and registers itself with the broker

• Consumer then traps incoming signals (bit 0 and bit 1)

• Decodes and prints messages

3. Last but not least, the Producer implementation, which is pretty straightforward:

#!/usr/bin/env ruby

require_relative 'signal_codec'
require_relative 'broker'

unless File.exist?(Broker::PID)
  abort "Error: Broker not running (#{Broker::PID} not found)"
end

broker_pid = File.read(Broker::PID).strip.to_i
message = ARGV.join(' ')

if message.empty?
  puts "Usage: ruby producer.rb <message>"
  exit 1
end

codec = SignalCodec.new

puts "Sending: #{message}"
codec.send_message(message, broker_pid)
puts "Message sent to broker (PID: #{broker_pid})"

• Producer receives a ASCII message from the STDIN

• Encode and sends the message to the broker via outgoing signals

So far, this architecture should look familiar. Many broker implementations follow these basic foundations.

Of course, production-ready implementations are far more robust than this one. Here, we're just poking around with hacking and experimentation

The coolest part is the SignalCodec though:

class SignalCodec 
  SIGNAL_DELAY = 0.001 # Delay between signals to allow processing

  def initialize
    @accumulator = 0
    @position = 0
    @buffer = []
  end

  def accumulate_bit(bit)
    @accumulator += (bit << @position)
    @position += 1

    if @position == 8 # Byte is complete
      if @accumulator.zero? # Message complete - NULL terminator
        decoded = @buffer.pack("C*").force_encoding('UTF-8')
        yield(decoded) if block_given?
        @buffer.clear
      else 
        @buffer << @accumulator
      end

      @position = 0
      @accumulator = 0
    end
  end

  def send_message(message, pid)
    message.each_byte do |byte|
      8.times do |i|
        bit = (byte >> i) & 1
        signal = bit == 0 ? 'SIGUSR1' : 'SIGUSR2'
        Process.kill(signal, pid)
        sleep SIGNAL_DELAY
      end
    end

    # Send NULL terminator (0000 0000)
    8.times do
      Process.kill('SIGUSR1', pid)
      sleep SIGNAL_DELAY
    end
  end
end

If you've been following along, this shouldn't be hard to understand, but I'll break down how this beautiful piece of code works:

• The codec is initialized with the bit position at zero, as well as the accumulator

• A buffer is also initialized to store accumulated bits until a complete byte is formed

• The accumulate_bit method should be familiar from our earlier implementation, but it now accepts a closure (block) that lets the caller decide what to do with each decoded byte

• send_message encodes a message into bits and sends them via UNIX signals

Everything in action:

How cool, amazing, wonderful, impressive, astonishing is that?

Conclusion

Yes, we built a message broker using nothing but UNIX signals and a bit of Ruby magic. Sure, it's not production-ready, and you definitely shouldn't use this in your next startup (please don't), but that was never the point.

The real takeaway here isn't the broker itself: it's understanding how the fundamentals work. We explored binary operations, UNIX signals, and IPC in a hands-on way that most people never bother with.

We took something "useless" and made it work, just for fun. So next time someone asks you about message brokers, you can casually mention that you once built (or saw) one using just two signals. And if they look at you weird, well, that's their problem. Now go build something equally useless and amazing. The world needs more hackers who experiment just for the fun of it.

Happy hacking!

Sentado no sofá e assistindo Frozen, tive a ideia de escrever sobre minha retrospectiva deste ano. Nunca fiz isso antes, então bora lá, porque acho que foi muita coisa.

Mas antes, um aftermath de 2023

2023 foi um ano bastante agitado pra mim. Passei por uma tireoidectomia (mas estou bem, obrigado) e também foi o ano em que resolvi fazer "learn in public" e deixar tudo gravado no meu canal do Youtube.

Iniciei cobrindo a rinha de compiladores, onde submeti uma versão em Ruby, e depois fui trazendo conteúdo para iniciantes em Rust. Teve também transmissão ao vivo criando uma Rede Neural Artificial em Ruby, então vi que eu realmente estava gostando de compartilhar minha jornada coding in public.

Na parte de artigos, escrevi muita coisa em 2023:

• Introdução ao Tekton CI/CD

• Kubernetes 101

• Um guia completo cobrindo os fundamentos de Git

• Criando redes neurais em Ruby

• Teve até artigo sobre ponto flutuante

• Fundamentos de recursão

• Resumo da rinha de compiladores e trampolim

• Mais Rust

E o famoso Guia Web 101 também.

Mentira, esse guia web foi em 2021, mas eu quis colocar ele aqui só pra fazer propaganda mesmo

As metas para 2024

No fim de 2023 estabeleci algumas metas pra 2024 nessa parte de criação de conteúdo. Mas não foram metas muito arrojadas pois eu queria dar uma desaquecida do que foi o agitado 2023.

Dentre as metas estava continuar explorando Rust; escrever um guia completo de concorrência; criar um interpretador em Ruby; fazer lives com Kubernetes; falar sobre tédio e; Awk.

Sim, Awk

Podemos confirmar isto em meio a tantos rascunhos que tenho nesta plataforma:

E chegou 2024

Comecei o ano de 2024 focado em me aprofundar em Rust, tanto que em Janeiro até cheguei a criar o crust (outro CRUD, mas desta vez em Rust) e o aspirina (outra rede neural, mas desta vez em Rust) durante algumas lives. Queria também iniciar meus estudos em Rust na parte de I/O assíncrono. Era esse o plano.

Era.

A Rinha de Backend, 2ª edição

Mas aí veio a rinha de backend do Zan pra tirar meu foco e resolvi fazer lives compartilhando minha solução submetida, que inicialmente seria em Ruby, com o agostinho.

Ledo engano. Acabei por submeter 5 diferentes soluções:

• 3 em Ruby: agostinho, que usa meus micro frameworks favoritos Adelnor e Chespirito; tortuga que não usa framework nem biblioteca alguma, o puro suco de uma linguagem criada no Japão; e tonico, uma versão sem frameworks que usa I/O assíncrono all the way down

• 1 em Rust: quokka, criado durante uma live

• e claro, a famosa versão em Bash, canabrava

Foram muitas horas em lives, inclusive esta onde eu mostrava como criar uma thread pool e connection pool em Rust.

Nossa Leandro, como você arranja tempo pra fazer lives? Eu não consigo ter tempo pra isso

Isso é problema seu, e não meu.

Um leve sopro do Gleam e o grande tutorial de Assembly

No início do ano notei um pequeno hype em cima do Gleam. Decidi explorar em live. Até que gostei da linguagem, e estava determinado a continuar estudando.

Mas aí minha amiga e meu amigo, algumas pessoas do trabalho começaram a me provocar. Ficavam colocando Assembly na minha frente. Foi quando numa 6a feira sem pretensão, no Discord, eu e mais alguns colegas fizemos um tutorial rápido de Assembly x86.

Foi quando pensei "ta aí, vou aprender esse negócio e criar um web server multi-threaded simples em Assembly, compartilhando a jornada tanto em artigos quanto em lives".

A saga do Assembly x86

Fiz várias lives pela manhã (que eu chamava de lives matinais, duh), mostrando o desenvolvimento do web server e minha saga de aprendizado. Foi incrível, pude ter contato com pessoas como o Blau Araújo que é referência em conteúdo pt-BR em Assembly e outras coisas de baixo nível.

Tem um vídeo no meu canal, que é a minha "sincera" reação quando o server finalmente funcionou devolvendo a primeira resposta HTTP, ao vivo em live.

Não obstante, resolvi também escrever artigos em live. Me diga, quem em sã consciência acompanha alguém escrevendo um artigo em live durante umas 4 ou 5 horas?

Não sei quem é mais maluco

Brincadeiras a parte, e ideia é mesmo compartilhar o processo. É sobre o modus operandi, a forma como eu quebro o raciocínio em partes na hora de escrever. E também o que me inspira.

No mundo dos artigos, eu comecei em Abril a saga "Escrevendo um Web server em Assembly x86". Foram um total de 6 artigos, onde no final conseguimos implementar um web server simples, porém multi-threaded em Assembly. Foram 3 meses escrevendo, fazendo lives e muitos conceitos abordados, muita coisa mesmo.

Aproveitei também para escrever sobre Arrays em Assembly x86.

Esta saga foi muito enriquecedora pra mim. Pude aprender e firmar muitos conceitos. Vale muito a pena aprender Assembly e coisas de baixo nível.

Enfim o "Guia de Concorrência 101"

Quando finalizei a saga de Assembly, resolvi voltar para uma das coisas que eu tinha como meta para 2024: escrever sobre concorrência. Este é um tema que estudo há mais de 5 anos quase que diariamente, experimentando e validando conceitos.

Foi então que bem agora, agorinha mesmo (risos) no final de Novembro que comecei a escrever o guia de concorrência (pt-BR). Por enquanto já abordei conceitos de concorrência no sistema operacional e como a linguagem C implementa as principais primitivas de concorrência. Mas o intuito é cobrir com mais linguagens de programação: Ruby, Python, PHP, NodeJS, Go, Rust, Elixir, Java, Kotlin e mais o que vier à cabeça.

Com uma brincadeira no bluesky, o Rodolfo de Nadai (meu primeiro investidor) deu uma ideia de eu lançar um "buy me a coffee" neste guia. Lancei e gostei da ideia, tanto que no momento são 23 apoiadores do projeto. Apesar de que faço de forma genuína sem interesse financeiro, pois defendo muito o conhecimento livre, este apoio da galera tem sido crucial para que eu continuasse, desde o apoio com Pix, revisão ou mesmo compartlihamento do conteúdo.

Gratidão a todos vocês que fazem isto acontecer ❤

Misc

Outras coisas que explorei ao longo deste ano, enquanto ia focando nas coisas de Assembly e concorrência:

• leandronsp/necelu, brincando com Lucene em Java (relembrando the good old days)

• open telemetry: OTel é um assunto bem interessante, onde quero me aprofundar em 2025

• leandronsp/yacs, Yet Another City Search, uma busca textual ultra-rápida em PostgreSQL em mais de 12 milhões de geonames/cidades

O que esperar pra 2025

Para 2025, espero mergulhar mais fundo em Rust, explorar OpenTelemetry e, quem sabe, encarar outra linguagem inusitada.

Afinal, aprender nunca é demais. 🚀

Feliz 2025 a todes <3

E também já faz bastante tempo que tenho o interesse em voltar a escrever mais como fazia antigamente, quando tudo o que tinha era algo na mente e simplesmente convertia em um punhado de texto solto no meu blog, como essa relíquia aqui.

Gosto de escrever artigos técnicos, mas por outro lado também gosto de simplesmente sentar e começar a escrever sem grandes pretensões. Só que me faltava algo. Eu só não sabia o que era.

Para entender o que me faltava, vamos dar uns passos atrás e entender o contexto de como eu vinha utilizando plataformas de blogging e o cenário de blogging moderno.

Blogpost

A primeira plataforma que utilizei foi o Blogger, antigo blogspot, onde comecei a escrever meus primeiros artigos quando eu ainda "mexia com TI". O ano era 2009.

Eu compartilhava estudo de programação quando tinha terminado a faculdade e também as gambiarras que eu fazia instalando e corrigindo problemas no Windows XP com Service Pack 3®.

Atualmente o editor é assim, mas na época era bastante limitado:

Não é ruim até, mas repara como que o espaço não é aproveitado. E uma coisa que eu sempre prezo ao escrever é, no caso, o conforto em escrever. Gosto de uma pegada fluída, com fonte agradável e que tenha um bom contraste. No caso desta plataforma em questão, eu tenho que clicar num botão de "Preview" e assim sou direcionado para outra página, saindo completamente do contexto.

Isso me entristece, muito.

Foram bons momentos como blogueirinho no Blogger, mas fiquei uns anos sem escrever por conta de vários motivos até que...

Medium

Circa 2014 decidi experimentar voltar a escrever, mas desta vez no Medium. Fiz apenas um punhado de artigos sem grandes pretensões, mas eu tinha gostado da fluidez (na época) de escrever na plataforma deles.

Entretanto a experiência de escrever ainda tava longe de ser a que eu queria. Mas eu nem sabia o que queria.

Cadê o botão de preview? Oh, gosh...

Fast-forward para 2021.

DEV.to e Hashnode

A plataforma dev.to me pareceu a princípio bastante intuitiva. Tem um lance de comunidade que é bacana, porque para além de ser uma plataforma de blogging é também uma comunidade em volta disso. Sem contar com o suporte a Markdown que nos dias de hoje é crucial para escrever artigos.

Decidi criar uma conta lá e desde então tenho publicado quase 100 artigos:

Ao mesmo tempo, a experiência de escrever era a melhor de todas que eu encontrei, mas ainda faltava uma coisa que eu já estava começando a perceber: preview em tempo real.

É muito chato você escrever bastante coisa e ter que clicar num botão lá em cima pra abrir outra página que, não raramente, demora pra carregar. É uma experiência que não sou fã 100%.

Na mesma época eu queria algo parecido mas que pudesse ter uma "landing page" no estilo dos blogs antigos com um menu customizado com os links que eu quisesse colocar. Para além do suporte a Markdown e um editor fluído. Foi quando conheci o Hashnode.

Com Hashnode, eu pude criar uma página "customizada" com menu e assim organizar melhor meus artigos. Mas me faltava ainda algo mais configurável.

Pra não mencionar que a experiência de escrita continuava a ser a mesma: ter que clicar num botão de preview que, com uma latência absurda, faz 412 coisas menos mostrar o preview que você verdadeiramente quer naquele momento.

Acabou que deixei o Hashnode flopar, mas ficou com meu domínio leandronsp.com e passei a escrever mais pelo DEV.to mesmo.

Era o que tinha pra janta.

Mas Leandro, existem ferramentas de visualização de Markdown, você consegue usar isso no Obsidian, na linha de comando, com plugin do Vim, com extensão do VSCode, etc etc

Calma, calabreso. Eu quero apenas escrever, ver em tempo real o que estou escrevendo sendo renderizado e a seguir publicar. That's it. Pra mim o web browser é ainda a ferramenta onde sinto mais conforto ao fazer esse tipo de tarefa.

Desculpa galera do terminal, mas como um heavy-terminal user e Vimer raiz, eu ainda prefiro blogar no browser

Foi assim até 2 dias atrás.

A vontade de escrever sobre UNIX signals

Como aqueles momentos em que do nada me vem a cabeça experimentar algo inútil que ninguém pediu e que provavelmente não vai pedir, decidi criar um broker de mensageria utilizando apenas sinais UNIX.

Em breve publico isto, foi divertido

Então, como de praxe, resolvi sentar pra escrever sobre. No DEV.to como habitual. Mas quer saber?

Cansei.

Resolvi criar meu próprio motor de blog que iria me atender em todos os aspectos que sinto falta nos motores atuais: aproveitar espaço, trazer preview em tempo real, navegação fluída, simples e sem muito ruído, tudo com suporte a Markdown.

Eu queria algo mais ou menos assim:

Com isto em mente, resolvi criar o curupira.

Curupira

Pra quem já me conhece sabe que sou péssimo com nomes, mas resolvi dar esse nome em homenagem ao nosso folclore brasileiro e ao protetor das nossas matas. Só porque sim.

No intuito de ter uma navegação fluída como a que eu sonhava, decidi utilizar Phoenix LiveView. Em resumo, é uma tecnologia que escala absurdamente por conta da VM que roda por baixo, a BEAM. Meu objetivo de ter de um lado o editor para escrever e do outro um preview em tempo real poderia ser finalmente atingido de forma simples.

É muito, mas muito simples criar apps real-time com Phoenix LiveView. A seguir uma demonstração de como pode ficar a página inicial do curupira:

Basicamente você tem de um lado uma bio que resume teu blog, e do outro a lista de artigos. É isto. Não precisa ser complicado, temos que aproveitar o máximo de espaço possível na tela.

Dá também pra alternar entre tema claro e escuro:

Além de tudo isso, é possível também gerar o site estático a partir de um comando make.

Isto vai ser melhorado em breve, quero também deixar o processo de geração do site estático mais fluído e UX-friendly em um futuro próximo

leandronsp.com

Após gerar o site estático, mudei o apontamento do meu domínio principal para o Cloudflare Pages, mas poderia ser qualquer outro como Github Pages, Vercel, etc (esta parte ainda está manual no momento, vem mais coisa em breve).

Meu novo site ficou então assim:

Preferi fazer com que a página do artigo tivesse espaço suficiente para o conteúdo, e não para ruídos.

Conclusão

É isto, pra quem tiver curiosidade em ver o repositório leandronsp/curupira, publiquei hoje mas ainda está WIP.

Este artigo já foi escrito com o curupira, e em breve será publicado neste blog.

Durante o processo, acabei deixando de lado alguns conceitos importantes para artigos posteriores, pois se fosse abordar durante a saga, iria ficar maior do que já foi. Entretanto são conceitos que podem ser tratados à parte, como no caso das filas implementadas na thread pool.

E quando falamos de filas, fica inevitável abordar arrays e como estes são organizados na memória do computador.

Neste artigo, vamos abordar conceitos fundamentais como manipulação de memória, registradores e memória heap ao longo da implementação de arrays.

Vou assumir que você já tem familiaridade com Assembly x86 e a ferramenta GDB. Caso não tenha, recomendo fortemente a leitura da minha saga.

Agenda

• Arrays não existem

• Strings também não existem

• O array mais simples do universo

• Utilizando um array com dados não inicializados

  • Índice para o resgate
  • Atingindo o limite do array

• Heap, heap, hooray!

  • Alocação dinâmica de memória com brk
  • Ponteiros, ponteiros everywhere
  • Resize com brk

• O programa final

• Conclusão

• Referências

Arrays não existem

Arrays não existem. Simples assim.

Como vimos na parte IV da saga, a memória é organizada de forma contígua, onde as informações são alocadas uma após a outra.

Supondo que queremos declarar a seguinte sequência de informações:

1, 2, 'H', 0

Eu sei, eu sei, os tipos estão misturados, mas isto não importa para este momento. Todos eles cabem em 1 byte

Em assembly x86 (vamos chamar de asm no restante do artigo), podemos declarar estas informações da seguinte forma na seção de dados:

section .data
stuff: db 0x1, 0x2, 0x48, 0x0

Lembrando que o caracter 'H' na tabela ASCII representa 0x48 em hexadecimal

Ao utilizarmos o gdb para fazer debugging, podemos confirmar que esta sequência de hexadecimal no rótulo stuff está armazenada da seguinte forma:

# Leitura do primeiro hexabyte em stuff
(gdb) x/1xb (void*) &stuff
0x402000 <stuff>:       0x01

# Leitura do segundo hexabyte em stuff
(gdb) x/1xb (void*) &stuff+1
0x402001:       0x02

# Leitura do terceiro hexabyte em stuff
(gdb) x/1xb (void*) &stuff+2
0x402002:       0x48

Podemos também representar o hexadecimal 0x48 em formato de string utilizando x/s

(gdb) x/s (void*) &stuff+2
0x402002:       "H"

É tudo hexadecimal!

Com isto, caso queiramos representar a string "Hello", de acordo com a tabela ASCII, poderia ficar assim:

section .data
msg: db 0x48, 0x65, 0x6C, 0x6C, 0x6F, 0x0

No gdb vamos verificar a representação string do rótulo msg:

(gdb) x/s &msg
0x402000 <msg>: "Hello"

Em asm, é possível declarar a string já com a representação direta da tabela ASCII:

section .data
msg: db "Hello", 0x0

; é o mesmo que
; msg: db 0x48, 0x65, 0x6C, 0x6C, 0x6F, 0x0

Strings também não existem

Ou seja, é tudo hexadecimal na memória. Um array, assim como uma string, é simplesmente uma sequência contígua de dados com mesmo tamanho na memória.

A diferença é que a string é um "array especial" que tem dados que representam caracteres da tabela ASCII (note que ambos precisam delimitar um byte "final" para representar o término da string ou array):

O array mais simples possível

A seguir temos a implementação de um array bastante simples em asm, pelo que iremos explorar cada passo nas seções subsequentes:

global _start

%define SYS_exit 60
%define EXIT_SUCCESS 0

section .data
array: db 1, 2, 3, 0

section .text
_start:
	mov al, [array]        ; array[0]
	mov bl, [array + 1]    ; array[1]
	mov cl, [array + 2]    ; array[2]
	mov sil, [array + 3]   ; array[3]
.exit:
	mov rdi, EXIT_SUCCESS
	mov rax, SYS_exit
	syscall

Na seção de dados inicializados .data, declaramos um array com 3 elementos de 1 byte cada (inteiros de 1 a 3), utilizando o número 0 como término do array:

section .data
array: db 1, 2, 3, 0

A seguir, na seção .text, que é onde vai o código fonte do programa, podemos acessar os elementos do array utilizando aritmética de ponteiros, armazenando o resultado em registradores:

section .text
_start:
mov al, [array]        ; array[0]

No código acima, estamos acessando o valor contido no endereço de memória 0x402000 e armazenando o resultado em um registrador (AL) que tem o tamanho de 1 byte, ou seja, vai ser armazenado no registrador apenas o primeiro byte do array.

Vamos conferir com gdb:

# O array está armazenado no endereço 0x402000
# e contém o valor em hexa 0x00 0x03 0x02 0x01,
# lembrando que esta arquitetura utiliza o formato little-endian
(gdb) x &array
0x402000 <array>:       0x00030201

(gdb) b 13
(gdb) run
(gdb) next

# No registrador AL temos o primeiro elemento do array
(gdb) i r al
al             0x1                 1

# É o mesmo que acessar o primeiro hexabyte contido no endereço
# 0x402000
(gdb) x/1xb 0x402000
0x402000 <array>:       0x01

Lembrando que o registrador AL representa os 8-bits menores dentro do espectro do registrador RAX que contempla um total de 64-bits na arquitetura x86_64

Para acessar os demais elementos do array, basta fazer aritmética de ponteiros e ir armazenando em outros registradores de 1 byte:

mov al, [array]        ; array[0] => 1
mov bl, [array + 1]    ; array[1] => 2
mov cl, [array + 2]    ; array[2] => 3
mov sil, [array + 3]   ; array[3] => 0 (aqui termina o array)

Utilizando um array com dados não inicializados

Até agora, estamos declarando o array na seção .data onde os dados são inicializados. Mas podemos deixar o programa mais "dinâmico", declarando o array na seção de dados não inicializados, que é a .bss.

Mantendo a compatibilidade com o exemplo anterior, vamos declarar um array de 4 bytes utilizando a diretiva resb que significa "reserve byte", onde os 3 primeiros bytes são reservados para armazenar elementos do array e o último byte representando 0x0 que é o término do array.

section .bss
array: resb 4 ; 3 bytes + 1 byte de término

No gdb, podemos ver que o array está inicializado com os valores tudo a zero, o que indica que o array está vazio mas com 4 bytes reservados:

(gdb) x &array
0x402004 <array>:       0x00000000

(gdb) x/4xb &array
0x402004 <array>:       0x00    0x00    0x00    0x00

Para adicionar elementos no array, precisamos também utilizar aritmética de ponteiros, tal como fizemos no exemplo anterior para acessar um array com dados pré-inicializados.

; Move o valor 1 para o primeiro byte do endereço de memória em array
mov byte [array], 1  ; array[0] = 1

Com gdb confirmamos que no endereço 0x402000 que é onde está o array, foi adicionado o byte 1:

(gdb) x &array
0x402000 <array>:       0x00000001

E se quisermos adicionar o valor 2 no próximo byte do array?

mov byte [array + 1], 2

(gdb) x &array
0x402000 <array>:       0x00000201

Repare que o que modifica é o "índice" do array. Na posição inicial do array, é como se o índice fosse zero, e na posição subsequente, utilizamos o índice 1, podendo incrementar até o término array.

Seria muito complicado ficar manipulando índice hard-coded. Precisamos de um ponteiro para representar este índice.

Índice para o resgate

Assumindo que o ponteiro do array começa com zero, que é o endereço de memória onde está o array, podemos declará-lo na seção de dados inicializados .data:

section .bss
array: resb 4 ; 3 bytes + 1 byte de término

section .data
pointer: db 0

Logo, poderíamos adicionar o primeiro elemento da seguinte forma, certo?

mov byte [array + pointer], 1   ; array + 0

Ao rodar o programa, temos o seguinte erro:

src/live.asm:14: error: invalid effective address: multiple base segments

Este erro indica que estamos tentando fazer manipulação de ponteiros a partir de múltiplos segmentos na memória, no caso o array e pointer.

Para resolver isto, precisamos fazer manipulação de ponteiros com valores imediatos (que foi o caso anterior com número hard-coded) ou com registradores:

; append(1)
mov al, byte [pointer]
mov byte [array + rax], 1   ; array + 0

• a primeira instrução move o primeiro byte contido no endereço de pointer e armazena no registrador AL

• a segunda instrução move o valor imediato 1 (elemento do array) para o endereço de memória do array. Como em RAX (versão 64-bits de AL) temos o valor 0x0 que representa o ponteiro, então estamos fazendo a inserção no primeiro byte do array

E para armazenar o segundo elemento no array?

; append(2)
mov al, byte [pointer]
mov byte [array + rax], 2

No gdb, vamos verificar o que está acontecendo:

(gdb) x &array
0x402004 <array>:       0x00000002

Uh, oh... Desta forma estamos sobrescrevendo o valor anterior. Queremos na verdade que o ponteiro "ande", ou seja, precisa ser incrementado em um byte para que o append(2) resulte com os 2 elementos no array.

Com a instrução INC podemos resolver este problema:

mov al, byte [pointer]      ; pointer -> 0
mov byte [array + rax], 1   ; array + 0
inc byte [pointer]          ; pointer -> 1

mov al, byte [pointer]
mov byte [array + rax], 2   ; array + 1

(gdb) x &array
0x402004 <array>:       0x00000201

Yay! Que dia maravilhoso!

Atingindo o limite do array

E se continuarmos incrementando o ponteiro até atingir o limite do array?

mov al, byte [pointer]
mov byte [array + rax], 1   ; array + 0
inc byte [pointer]

mov al, byte [pointer]
mov byte [array + rax], 2   ; array + 1
inc byte [pointer]

mov al, byte [pointer]
mov byte [array + rax], 3   ; array + 2
inc byte [pointer]

# Lendo os primeiros 4 hexabytes do array, temos a representação
# do array cheio com todos os espaços ocupados, lembrando que
# o último byte é o término do array
(gdb) x /4xb &array
0x402004 <array>:       0x01    0x02    0x03    0x00

# O ponteiro está no fim do array
(gdb) x &pointer
0x402000 <pointer>:     0x03

Maravilha, e se adicionar mais um elemento, nosso programa deveria permitir?

mov al, byte [pointer]
mov byte [array + rax], 4   ; array + 3
inc byte [pointer]

# Não deveríamos permitir que mais um elemento fosse adicionado,
# pois nosso array já estava cheio
(gdb) x /4xb &array
0x402004 <array>:       0x01    0x02    0x03    0x04

# O ponteiro está para além da capacidade array (not good...)
(gdb) x &pointer
0x402000 <pointer>:     0x04

Vamos utilizar um jump condicional (explico mais sobre isto na saga) para não permitir que o elemento seja adicionado. Com isto, antes de fazer o append no array, devemos verificar se o ponteiro já não está no fim do array:

cmp byte [pointer], 3   ; verifica se o array está cheio
je .exit                ; salta para a rotina .exit caso a flag seja levantada

Assim fica o programa completo:

global _start

%define SYS_exit 60
%define EXIT_SUCCESS 0

section .bss
array: resb 4 ; 3 bytes + 1 byte de término

section .data
pointer: db 0

section .text
_start:
	cmp byte [pointer], 3   ; verifica se o array está cheio
	je .exit
	
	mov al, byte [pointer]
	mov byte [array + rax], 1   ; array + 0
	inc byte [pointer]
	
	cmp byte [pointer], 3   ; verifica se o array está cheio
	je .exit

	mov al, byte [pointer]
	mov byte [array + rax], 2   ; array + 1
	inc byte [pointer]

	cmp byte [pointer], 3   ; verifica se o array está cheio
	je .exit

	mov al, byte [pointer]
	mov byte [array + rax], 3   ; array + 2
	inc byte [pointer]

	cmp byte [pointer], 3   ; verifica se o array está cheio
	je .exit

	; não deveria permitir adicionar o quarto elemento,
	; pois o array suporta até 3 elementos. desta forma,
	; estaríamos escrevendo no endereço de memória de outros
	; dados do programa
	mov al, byte [pointer]
	mov byte [array + rax], 4   ; array + 3
	inc byte [pointer]
.exit:
	mov rdi, EXIT_SUCCESS
	mov rax, SYS_exit
	syscall

(gdb) x &pointer
0x402000 <pointer>:     0x00000003
(gdb) x &array
0x402004 <array>:       0x00030201

Perfeito, vamos agora fazer um pequeno refactoring no código separando a lógica de append para uma subrotina:

global _start

%define SYS_exit 60
%define EXIT_SUCCESS 0
%define CAPACITY 3

section .bss
array: resb CAPACITY + 1

section .data
pointer: db 0

section .text
_start:
	mov rdi, 1
	call .append

	mov rdi, 2
	call .append

	mov rdi, 3
	call .append

	mov rdi, 4
	call .append
.exit:
	mov rdi, EXIT_SUCCESS
	mov rax, SYS_exit
	syscall
.append:
	cmp byte [pointer], CAPACITY ; verifica se o array está cheio
	je .done

	mov al, byte [pointer]
	mov byte [array + rax], dil
	inc byte [pointer]
.done:
	ret

Se você quer entender mais sobre conditional jump, rotinas, call, ret e flags, sugiro a leitura da minha saga que foi referenciada diversas vezes neste artigo

Executando com gdb e...

(gdb) x &array
0x402004 <array>:       0x00030201

(gdb) x &pointer
0x402000 <pointer>:     0x00000003

Um grande Yay!

Entretanto, podem haver situações onde queremos que nosso array seja redimensionado para suportar mais elementos, ou seja, o tamanho do array seria dinâmico.

Como adicionar mais elementos além da capacidade inicial de forma que não podemos escrever em outras áreas da memória que pertencem ao array?

Heap, heap, hooray!

Antes de falar sobre o heap, vamos relembrar como funciona o layout de memória de um programa de computador:

• o layout é representado como uma área na memória do computador onde temos os endereços de memória mais baixos do programa em direção aos endereços mais altos que ficam no topo

• nos endereços de memória mais baixos, temos a seção .text, onde já vimos que é referente ao programa em si

• depois temos a seção de dados que contempla os dados inicializados .data e a seção a seguir que representa os dados não-inicializados .bss

• nos endereços mais altos, temos a stack do programa, que armazena metadados tais como o nome do programa, seus argumentos e qualquer informação do programa que tenha um tamanho fixo cabendo dentro da stack, bem como chamadas de funções e seus respectivos argumentos

• a stack tem um formato de pilha e "cresce pra baixo", ou seja, conforme adicionamos elementos na stack, esta cresce em direção aos endereços mais baixos na memória

No "meio" do layout, entre a seção de dados e a stack, temos uma grande área na memória que muitos acabam associando como heap. No heap, podemos alocar dados de forma dinâmica, diferente da forma estática que fazemos na seção de dados.

Para acomodar um array de tamanho dinâmico que suporte redimensionamento (resize), temos de alocar memória nesta área.

Neste artigo, vamos chamar esta região no meio da memória que fica entre a seção de dados e a stack de heap

Alocação dinâmica de memória com brk

Uma das formas de manipular esta área da memória é através da syscall brk, que muda o program break, que é onde termina a seção de dados.

Com brk, podemos modificar esse program break para endereços mais altos, ou seja, permitindo a manipulação de áreas na memória que vão além da seção de programa e dados.

A primeira coisa que precisamos fazer é mapear a syscall e fazer a chamada que traz o endereço do break atual:

%define SYS_brk 12
....

section .text
_start:
; syscall para acessar o program break (0x403000), que é onde termina 
; a seção de dados e começa o heap
mov rdi, 0
mov rax, SYS_brk
syscall
....

Com gdb, vamos analisar o estado do programa:

# Breakpoint na linha da syscall brk
(gdb) b 18
(gdb) run

# O início do programa fica na seção .text e começa com 
# 0x401000
(gdb) x _start
0x401000 <_start>:      0x000000bf

# O pointer está na seção .data um pouco mais acima e começa com
# 0x402000
(gdb) x &pointer
0x402000 <pointer>:     0x00000000

# O array está na seção .bss um pouco mais acima e começa com 
# 0x402004
(gdb) x &array
0x402004 <array>:       0x00000000

# Executa a syscall brk
(gdb) n

# A syscall brk armazena em RAX o endereço de memória do program break, 
# no caso um pouco mais acima em 0x403000
(gdb) i r rax
rax            0x403000            4206592

• 0x401000: seção .text que é onde começa o programa

• 0x402000: seção .data onde ficam os dados inicializados

• 0x402004: seção .bss onde ficam os dados não-inicializados

• 0x403000: program break, que é onde termina a seção de dados e começa o nosso "heap"

Com isto, a partir do endereço 0x403000 é onde vamos colocar os elementos do nosso array, pelo que o endereço do array pode utilizar apenas um byte, que aponta para o endereço onde começa o primeiro elemento no heap.

Na syscall que fizemos, se o argumento em RDI tiver zero, significa que brk vai retornar o program break atual, no caso 0x403000. Mas podemos fazer mais syscalls brk com o argumento RDI diferente (incrementado), sinalizando que estamos mudando o program break.

A partir de agora, na seção de dados .bss, não precisamos mais reservar 4 bytes para o array, pelo que é necessário apenas 1 byte que irá representar o endereço de memória do array no heap:

global _start

%define SYS_brk 12
%define SYS_exit 60
%define EXIT_SUCCESS 0
%define CAPACITY 3

; inicialmente começa com 0x000000, mas depois irá conter 
; o endereço 0x403000
section .bss
array: resb 1  

section .data
pointer: db 0

section .text
_start:
	mov rdi, 0
	mov rax, SYS_brk
	syscall

	mov rdi, rax
	add rdi, CAPACITY
	mov rax, SYS_brk
	syscall

...
...

Ao analisarmos com gdb:

# Breakpoint na primeira syscall
(gdb) b 18

(gdb) run

# Executa a linha da syscall
(gdb) n

# Em RAX a syscall armazena o endereço do program break, no caso
# 0x403000
(gdb) i r rax
rax            0x403000            4206592

(gdb) x 0x403000
0x403000:       Cannot access memory at address 0x403000

Neste momento, este endereço ainda não é acessível pois não reservamos novos bytes no heap. Vamos andar com a próxima syscall:

(gdb) n
(gdb) n

# Antes de executar a syscall, verificamos que o argumento RDI vai 
# conter o endereço desejado para o novo program break, no caso com
# 3 bytes adicionados, 0x403003
(gdb) i r rdi
rdi            0x403003            4206595

# Executa a syscall...
(gdb) n
(gdb) n

# Após a execução da segunda syscall, vemos que em RAX, o program break foi alterado para 0x403003
(gdb) i r rax
rax            0x403003            4206595

Agora, podemos acessar os endereços de memória entre 0x403000 e 0x403003:

(gdb) x 0x403000
0x403000:       0x00000000
(gdb) x 0x403001
0x403001:       0x00000000
(gdb) x 0x403002
0x403002:       0x00000000
(gdb) x 0x403003
0x403003:       0x00000000

Uau! Agora temos no heap uma área reservada especialmente para o nosso querido array, olha que coisa!

Como vamos manipular o array nesta região da memória?

Ponteiros, ponteiros everywhere

Após a primeira syscall, devemos pegar o endereço de memória 0x403000 que representa o primeiro program break e armazenar no ponteiro do array que está em .bss:

...
mov rdi, 0
mov rax, SYS_brk
syscall
mov [array], rax      ; <---- breakpoint aqui

mov rdi, rax
add rdi, CAPACITY
mov rax, SYS_brk
syscall
...

Vamos verificar com gdb o breakpoint na linha que muda o ponteiro do array:

(gdb) b 19
(gdb) run

(gdb) x &array
0x402004 <array>:       0x00000000

# Executa a linha que muda o ponteiro
(gdb) n

# Agora o ponteiro aponta para o endereço 0x403000, 
# é isto o que queremos
(gdb) x &array
0x402004 <array>:       0x00403000

Importante notar que array está no endereço 0x402004, na seção .bss, pelo que seu valor representa outro endereço de memória 0x403000 que é onde deve começar o primeiro elemento do array no heap.

Agora, quando fizermos a próxima syscall para alocar 3 bytes no heap, o program break será modificado e iremos conseguir manipular o array pois o ponteiro já aponta para o endereço correto.

Após a segunda syscall, já não podemos mais manipular o array pelo seu valor, pois agora o valor do array já não é mais um elemento de fato, mas sim um endereço para outro lugar na memória.

Vamos ao programa na versão atual:

global _start

%define SYS_brk 12
%define SYS_exit 60
%define EXIT_SUCCESS 0
%define CAPACITY 3

section .bss
array: resb 1   ; 0x403000

section .data
pointer: db 0

section .text
_start:
	mov rdi, 0
	mov rax, SYS_brk
	syscall
	mov [array], rax

	mov rdi, rax
	add rdi, CAPACITY
	mov rax, SYS_brk
	syscall

	mov rbx, [array]

	mov r8, 1
	call .append

	mov r8, 2
	call .append

	mov r8, 3
	call .append

	mov r8, 4
	call .append
.exit:
	mov rdi, EXIT_SUCCESS
	mov rax, SYS_exit
	syscall
.append:
	cmp byte [pointer], CAPACITY ; verifica se o array está cheio
	je .done

	mov sil, byte [pointer]
	mov byte [rbx + rsi], r8b
	inc byte [pointer]
.done:
	ret

Explicando cada bloco:

mov rdi, 0
mov rax, SYS_brk
syscall
mov [array], rax

• busca o program break atual e armazena o endereço no ponteiro array

mov rdi, rax
add rdi, CAPACITY
mov rax, SYS_brk
syscall

• modifica o program break atual, incrementando 3 bytes que é a capacidade inicial do array no heap

; atribuir ao registrador o endereço de memória ao qual o
; ponteiro "array" está apontando
mov rbx, [array] 

• armazena o endereço de memória do ponteiro no registrador RBX. Isto é necessário pois não queremos fazer aritmética diretamente no ponteiro da seção .bss, mas sim através de um registrador que permite

mov r8, 1
call .append

• como agora o RDI foi usado como argumento na syscall brk, não convém mais utilizarmos este registrador para representar o elemento a ser adicionado no array, pelo que trocamos pelo registrador R8

.append:
	cmp byte [pointer], CAPACITY ; verifica se o array está cheio
	je .done

	mov sil, byte [pointer]
	mov byte [rbx + rsi], r8b    ; indirect-mode addressing
	inc byte [pointer]
.done:
	ret

Agora a rotina .append foi modificado para que a manipulação do array no heap seja através do registrador RBX. Também não podemos mais usar o registrador RAX para representar o ponteiro pois a syscall brk também utilizou como retorno do program break; neste caso trocamos para o RSI (que tem o SIL como sua representação de 8-bits menores).

Ao executar com gdb, podemos verificar que os elementos estão sendo adicionados no endereço 0x403000 que fica no heap, através do ponteiro que foi armazenado no registrador RBX:

# Array aponta para o endereço 0x403000
(gdb) x &array
0x402004 <array>:       0x00403000

# No endereço, temos os elementos adicionados. Yay!
(gdb) x 0x403000
0x403000:       0x00030201

# E o ponteiro de "índice" corretamente representando o fim do array no heap
(gdb) x &pointer
0x402000 <pointer>:     0x00000003

Neste momento, o programa está com o mesmo comportamento do exemplo anterior com array estático em .bss, não permitindo adicionar mais elementos quando o array atinge seu limite.

Vamos mudar isto, redimensionando o array e permitir que novos elementos sejam adicionados.

Resize com brk

A seguir, iniciamos os passos para que o redimensionamento do array seja feito quando este atingir o limite da capacidade. Começamos por alterar a rotina .append:

.append:
	cmp byte [pointer], CAPACITY ; verifica se o array está cheio
	je .resize

	mov sil, byte [pointer]
	mov byte [rbx + rsi], r8b
	inc byte [pointer]
.done:
	ret
.resize:
	...

Ao invés de fazer jump para .done quando o array estiver cheio, fazemos jump para outra sub-rotina chamada .resize, que deverá fazer a syscall brk novamente, modificando assim o program break em uma nova área na memória, obedecendo a capacidade inicial do array:

.append:
	cmp byte [pointer], CAPACITY ; verifica se o array está cheio
	je .resize

	mov sil, byte [pointer]
	mov byte [rbx + rsi], r8b
	inc byte [pointer]
.done:
	ret
.resize:
	mov rdi, 0
	mov rax, SYS_brk
	syscall

	mov rdi, rax            ; RDI passa a representar o break atual
	add rdi, CAPACITY       ; adiciona 3 bytes, ficando 0x403006
	mov rax, SYS_brk
	syscall
	jmp .append

• a primeira syscall de resize traz o break atual, no caso já sabemos que é 0x403003, que foi alocado no início do programa para o array

• a segunda syscall de resize modifica o break atual, alocando assim mais 3 bytes no heap

• ao fim do resize, ao invés de retornar a função, vamos voltar para o início do .append e executar a lógica necessária para adicionar o elemento no array

Desta forma, podemos manipular esta nova área na memória para adicionar mais elementos no array, modificando assim sua capacidade dinamicamente.

Se executarmos o programa exatamente assim, vamos enfrentar um problema, pois:

• a cada vez que é feito o resize, salta para o início da rotina

• é verificado o tamanho do array (pointeiro) com a capacidade inicial, que no caso é 3. Como o ponteiro atingiu o valor 3, então vai entrar novamente no resize caracterizando assim um loop infinito com resize infinito até acabar a memória

Para resolver isto, precisamos comparar o pointer com a capacidade atual (modificada), e portanto vamos adicionar um valor na seção .data que representa a capacidade atual:

%define CAPACITY 3

section .data
pointer: db 0
currentCapacity: db CAPACITY ; começa com 3

Na rotina .append, vamos fazer a comparação com o currentCapacity, que vai ser modificado a cada resize, ao invés de ser com CAPACITY, que vai permanecer fixo com o valor inicial enquanto durar o programa.

.append:
	mov r9, [currentCapacity]
	cmp byte [pointer], r9b     ; verifica se o array está cheio
	je .resize
...

E, após o redimensionamento antes de voltar pro .append, vamos incrementar o valor da capacidade inicial à capacidade atual:

.resize:
	mov rdi, 0
	mov rax, SYS_brk
	syscall

	mov rdi, rax
	add rdi, CAPACITY
	mov rax, SYS_brk
	syscall

	mov r10, currentCapacity
	add byte [r10], CAPACITY
	jmp .append

Ao executar o programa, podemos ver que o elemento 4 foi adicionado com sucesso no array após o redimensionamento:

(gdb) x 0x403000
0x403000:       0x04030201

E se adicionarmos mais e mais elementos?

...
	mov r8, 4
	call .append

	mov r8, 5
	call .append

	mov r8, 6
	call .append

	mov r8, 7
	call .append
...

# Podemos ver que o currentCapacity é 9, ou seja, foram feitos 
# 2 redimensionamentos. Nosso array consegue agora acomodar até 9 elementos, 
# pelo que ao adicionar o décimo elemento, mais um resize seria feito.
(gdb) x &currentCapacity
0x402001 <currentCapacity>:     0x09

# Buscando os 9 primeiros hexabytes no endereço do array no heap
(gdb) x/9xb  0x403000
0x403000:       0x01    0x02    0x03    0x04    0x05    0x06    0x07    0x00
0x403008:       0x00

How cool is that?

O programa final

A seguir o programa final, com um array de capacidade inicial de 3 elementos no heap que pode ser redimensionado utilizando a syscall brk, conforme mais elementos vão sendo adicionados no array:

global _start

%define SYS_brk 12
%define SYS_exit 60
%define EXIT_SUCCESS 0
%define CAPACITY 3

section .bss
array: resb 1

section .data
pointer: db 0
currentCapacity: db CAPACITY ; capacidade inicial é 3

section .text
_start:
	mov rdi, 0
	mov rax, SYS_brk
	syscall
	mov [array], rax

	mov rdi, rax
	add rdi, CAPACITY
	mov rax, SYS_brk
	syscall

	mov rbx, [array]

	mov r8, 1
	call .append

	mov r8, 2
	call .append

	mov r8, 3
	call .append

	mov r8, 4
	call .append

	mov r8, 5
	call .append

	mov r8, 6
	call .append

	mov r8, 7
	call .append
.exit:
	mov rdi, EXIT_SUCCESS
	mov rax, SYS_exit
	syscall
.append:
	mov r9, [currentCapacity]
	cmp byte [pointer], r9b ; verifica se o array está cheio
	je .resize

	mov sil, byte [pointer]
	mov byte [rbx + rsi], r8b
	inc byte [pointer]
.done:
	ret
.resize:
	mov rdi, 0
	mov rax, SYS_brk
	syscall

	mov rdi, rax
	add rdi, CAPACITY
	mov rax, SYS_brk
	syscall

	mov r10, currentCapacity
	add byte [r10], CAPACITY
	jmp .append

Conclusão

Neste artigo, mostramos a implementação de um array em Assembly x86, passando por conceitos importantes como layout de memória, manipulação de registradores e alocação dinâmica de memória com brk.

Este artigo é base para artigos futuros sobre estruturas de dados, onde pretendo escrever sobre a implementação de filas e posteriormente listas ligadas.

Stay tuned!

Referências

Neste artigo, vamos mergulhar nas entranhas da implementação de uma pool de threads com sincronização através de locks, e para atingir tal feito em assembly abordaremos filas, alocação dinâmica de memória e controle de locks com futex.

Ao fim deste artigo, que é o último da saga, teremos uma visão mais holística sobre como funciona um web server e como uma pool de threads poderia ser implementada em linguagens de baixo nível.

Respira e vem comigo, esta última parte será uma avalanche de conceitos.

Agenda

• Simulando a latência com nanosleep

• Simulando requests em escala com xargs

• Concorrência com forking de processos

• Concorrência com clone de processo

• Concorrência com threads

  • Entendendo a criação de uma thread
  • Thread flags
  • Alocação de memória com brk
  • Modificando o server para suportar multi-threading

• Concorrência com thread pool

  • Uma thread em loop
  • 5 threads em loop
  • Sincronização com futex

• Alocação de memória com mmap

• Conclusão

• Referências

Simulando a latência com nanosleep

Quando uma requisição é feita a um web server, o tempo de resposta total é um somatório de toda a latência envolvida na comunicação, desde o momento em que o pedido sai da origem (client), passando pela rede de computadores (internet), chegando no destino (server), sendo processado, para então a resposta fazer o caminho inverso até voltar ao client.

Quanto maior a latência em qualquer parte do processo, maior o tempo de resposta, e portanto menor a capacidade de entregar respostas de diferentes requisições em um determinado intervalo de tempo.

A esta capacidade de processar requisições em um intervalo de tempo chamamos de throughput. O que queremos no fim das contas é aumentar o throughput sem comprometer a latência. Esta é uma das premissas para sistemas escaláveis, mas o foco deste artigo não será em escalabilidade necessariamente.

No artigo anterior, finalizamos o web server que apenas responde no socket uma mensagem HTML contendo "Hello, world". A seguir o código inicial do server, que será a base para o restante do artigo:

global _start

%define SYS_socket 41
%define SYS_bind 49
%define SYS_listen 50
%define SYS_accept4 288
%define SYS_write 1
%define SYS_close 3

%define AF_INET 2
%define SOCK_STREAM 1
%define SOCK_PROTOCOL 0
%define BACKLOG 2
%define CR 0xD
%define LF 0xA

section .data
sockaddr:
	sa_family: dw AF_INET   ; 2 bytes
	port: dw 0xB80B         ; 2 bytes
	ip_addr: dd 0           ; 4 bytes
	sin_zero: dq 0          ; 8 bytes
response: 
	headline: db "HTTP/1.1 200 OK", CR, LF
	content_type: db "Content-Type: text/html", CR, LF
	content_length: db "Content-Length: 22", CR, LF
	crlf: db CR, LF
	body: db "<h1>Hello, World!</h1>"
responseLen: equ $ - response

section .bss
sockfd: resb 1

section .text
_start:
.socket:
	; int socket(int domain, int type, int protocol)
	mov rdi, AF_INET
	mov rsi, SOCK_STREAM
	mov rdx, SOCK_PROTOCOL
	mov rax, SYS_socket
	syscall
.bind:
	mov [sockfd], rax
	; int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
	mov rdi, [sockfd]
	mov rsi, sockaddr
	mov rdx, 16
	mov rax, SYS_bind
	syscall
.listen:
	; int listen(int sockfd, int backlog)
	mov rdi, [sockfd]
	mov rsi, BACKLOG
	mov rax, SYS_listen
	syscall
.accept:
	; int accept(int sockfd, struct *addr, int addrlen, int flags)
	mov rdi, [sockfd]
	mov rsi, 0
	mov rdx, 0
	mov r10, 0
	mov rax, SYS_accept4
	syscall
	mov r8, rax
	call handle
	jmp .accept
handle:
	; int write(fd)
	mov rdi, r8
	mov rsi, response
	mov rdx, responseLen
	mov rax, SYS_write
	syscall

	; int close(fd)
	mov rdi, r8
	mov rax, SYS_close
	syscall
	ret

Até aqui tudo normal. A rotina accept fica em loop chamando a rotina handle que escreve "Hello, world" na resposta de cada requisição que chega no socket.

Com strace, podemos ver as chamadas que foram feitas após uma requisição com curl:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0
accept4(3, NULL, NULL, 0)               = 4
write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
close(4)                                = 0
accept4(3, NULL, NULL, 0

socket, bind, listen, para então iniciar o accept, que ao receber uma requisição HTTP, passa para write, close e então voltar ao accept novamente em loop.

Para simular um pouco de latência, vamos fazer com que a resposta demore cerca de 1 segundo, e para tanto precisamos utilizar uma syscall no Linux chamada nanosleep, que suspende a execução da thread atual até atingir um tempo decorrido especificado com base no relógio monotônico do sistema:

Primeiro definimos a syscall, que tem o código 35:

%define SYS_nanosleep 35

Na rotina handle, antes de escrever a resposta no socket, fazemos a chamada de sistema para nanosleep passando como argumento uma struct que representa um timespec, que contempla o tempo decorrido em segundos e nano-segundos:

handle:
	; int nanosleep(timespec duration)
	lea rdi, [timespec]
	mov rax, SYS_nanosleep
	syscall

	; int write(fd)
	...

	; int close(fd)
	...

E na seção de dados, definimos o tempo decorrido em segundos, que são os primeiros 8 bytes da struct, deixando a zero os 8 bytes restantes que representam o tempo em nano-segundos

section .data
timespec:
	tv_sec: dq 1
	tv_nsec: dq 0

Neste exemplo queremos que o sleep seja de 1 segundo

Com strace, podemos ver que a syscall nanosleep foi executada após o accept e antes do write:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0

accept4(3, NULL, NULL, 0)               = 4
nanosleep({tv_sec=1, tv_nsec=0}, NULL)  = 0
write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86

close(4)                                = 0
accept4(3, NULL, NULL, 0

Calculando o tempo decorrido com o utilitário time:

$ time curl localhost:3000

<h1>Hello, World!</h1>
real    0m1.040s
user    0m0.005s
sys     0m0.009s

Podemos também encurtar a resposta do time trazendo apenas o tempo real, exportando a variável na sessão shell atual ou adicionando no bashrc:

export TIMEFORMAT=%R

$ time curl localhost:3000
<h1>Hello, World!</h1>1.036

Yay! Já conseguimos simular uma latência de 1 segundo em Assembly. Agora vamos ver se nosso web server tem a capacidade de atender a requests em escala.

Simulando requests em escala com xargs

Para começar, vamos simular 10 requests sequenciais com curl. Poderíamos ficar digitando curl localhost:3000 10 vezes, ou então ser pragmáticos, automatizar sem reinventar a roda e nem instalar nada adicional no sistema.

Como?

xargs.

xargs é um utilitário presente na maioria dos sistemas operacionais UNIX-like, que lê strings a partir de arquivos ou standard input e utiliza estas strings como argumentos para comandos arbitrários.

Vamos ter como exemplo uma sequência de 1 a 10 em bash:

$ echo ${1..10}
1 2 3 4 5 6 7 8 9 10

Podemos utilizar cada valor do echo como argumento para o xargs:

$ echo {1..10} | xargs -n1
1
2
3
4
5
6
7
8
9
10

A opção -n1 significa a quantidade de argumentos que serão usados para o comando que vem a seguir ao xargs, que no caso queremos apenas 1 argumento, o que neste caso tanto faz pois não queremos fazer nada com o argumento: queremos apenas executar o comando curl 10 vezes.

Podemos então agora executar o curl com o time para saber o tempo decorrido de cada request:

$ time echo {1..10} | xargs -n1 bash -c "time curl localhost:3000"

<h1>Hello, World!</h1>1.037
<h1>Hello, World!</h1>1.033
<h1>Hello, World!</h1>1.025
<h1>Hello, World!</h1>1.037
<h1>Hello, World!</h1>1.032
<h1>Hello, World!</h1>1.026
<h1>Hello, World!</h1>1.019
<h1>Hello, World!</h1>1.046
<h1>Hello, World!</h1>1.053
<h1>Hello, World!</h1>1.041
10.426

Claramente, vemos que cada request demorou cerca de 1 segundo, o que no total o tempo decorrido foi de 10,4 segundos. Esta é a latência total para o caso de fazermos requisições sequenciais.

E se fizermos requisições simultâneas? Num cenário mais próximo do real, vamos supor que nossa aplicação web recebe 10 requisições no mesmo segundo em horários de pico.

Para isto, conseguimos também utilizar o xargs para simular, através da opção -P, que representa a quantidade de processos simultâneos que o xargs irá utilizar para realizar os comandos.

Incrível! Com isto nosso web server atende 10 requisições simultâneas, fazendo com que o throughput total dos 10 requests fique em torno de 1 segundo, certo?

Calma, calabreso, vamos testar.

$ time echo {1..10} | xargs -n1 -P10 bash -c "time curl localhost:3000"

<h1>Hello, World!</h1>1.053
<h1>Hello, World!</h1>2.071
<h1>Hello, World!</h1>3.076
<h1>Hello, World!</h1>4.087
<h1>Hello, World!</h1>5.088
<h1>Hello, World!</h1>6.106
<h1>Hello, World!</h1>7.140
<h1>Hello, World!</h1>8.154
<h1>Hello, World!</h1>9.168
<h1>Hello, World!</h1>10.183
10.214

Não melhorou nada! Ter 10 requests simultâneos não quer dizer que nosso server consiga atender os 10 requests ao mesmo tempo. Muito pelo contrário, pode até piorar e prejudicar a latência total, pois há diversos requests na fila esperando para serem atendidos.

• o primeiro request demora 1 segundo

• o segundo request chega ao mesmo tempo mas demora 2 segundos

• o terceiro request chega ao mesmo tempo mas demora 3 segundos

• e assim sucessivamente...

Nosso server é síncrono, e com isto podemos criar gargalos. Precisamos então que o server consiga lidar com concorrência.

Concorrência com forking de processos

Uma das formas primitivas de concorrência e escalar um web server para atender mais de um request em simultâneo é com o uso de processos. Como cada processo no sistema operacional tem sua memória isolada dos demais, podemos fazer com que cada request seja atendido em um processo diferente.

Para entender esta técnica, precisamos compreender que todo programa de computador roda em um processo no sistema operacional, e isto vimos bastante nos artigos anteriores. Dentro deste processo, o programa ainda roda em uma unidade de execução no SO chamada thread.

Todo processo tem uma thread chamada thread principal, que é onde está sendo executado o programa

No exemplo anterior, quando chamamos o sleep, a thread que está sendo suspensa por um tempo determinado é justamente a thread principal do programa.

A thread compartilha a memória do processo o qual ela faz parte, mas como precisamos criar outro processo, temos de fazer um forking, que basicamente cria um processo filho copiando tudo o que o programa principal tem.

Repare que cada processo filho tem uma cópia do processo principal. O loop é basicamente o accept do nosso web server, que fica em loop. Desta forma cada request pode ser atendido por um processo diferente, de forma concorrente.

Podemos fazer forking de processo com o uso da syscall fork:

%define SYS_fork 57

A rotina handle mantém igual, com o sleep antes de escrever a resposta no socket:

handle:
	lea rdi, [timespec]
	mov rax, SYS_nanosleep
	syscall

	; int write(fd)
	mov rdi, r8
	mov rsi, response
	mov rdx, responseLen
	mov rax, SYS_write
	syscall

	; int close(fd)
	mov rdi, r8
	mov rax, SYS_close
	syscall
	ret

E na rotina accept, adicionamos a chamada do fork logo após o request chegar no socket:

.accept:
	; int accept(int sockfd, struct *addr, int addrlen, int flags)
	mov rdi, [sockfd]
	mov rsi, 0
	mov rdx, 0
	mov r10, 0
	mov rax, SYS_accept4
	syscall
	mov r8, rax

	; fork de processo
	mov rax, SYS_fork
	syscall

	; se o retorno do fork for ZERO, significa que está sendo executado
	; a partir do processo filho. Então a rotina "handle" é executada
	test rax, rax
	jz handle

	; quando o retorno não é ZERO, significa que a execução do programa 
	; principal continuou. Então o processo principal volta para o loop
	jmp .accept

• depois de uma chamada ao fork, a syscall retorna ZERO quando se está dentro do processo filho. Neste caso, a execução do processo filho continua com a rotina handle e depois termina

• após a chamada do fork, se o retorno NÃO for ZERO, significa que a execução é do programa principal, então neste caso volta-se ao loop para esperar um novo request no socket

Ao executar com strace, podemos ver várias chamadas à syscall fork:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0
accept4(3, NULL, NULL, 0)               = 4
fork(strace: Process 12787 attached
)                                  = 12787
[pid 12786] accept4(3, NULL, NULL, 0 <unfinished ...>
[pid 12787] nanosleep({tv_sec=1, tv_nsec=0},  <unfinished ...>
[pid 12786] <... accept4 resumed>)      = 5
[pid 12786] fork(strace: Process 12788 attached
)                      = 12788
[pid 12788] nanosleep({tv_sec=1, tv_nsec=0},  <unfinished ...>
[pid 12786] accept4(3, NULL, NULL, 0)   = 6
[pid 12786] fork(strace: Process 12789 attached
)                      = 12789
[pid 12786] accept4(3, NULL, NULL, 0)   = 7
[pid 12786] fork( <unfinished ...>
[pid 12789] nanosleep({tv_sec=1, tv_nsec=0}, strace: Process 12790 attached
 <unfinished ...>
[pid 12786] <... fork resumed>)         = 12790
[pid 12790] nanosleep({tv_sec=1, tv_nsec=0},  <unfinished ...>
[pid 12786] accept4(3, NULL, NULL, 0)   = 8
[pid 12786] fork(strace: Process 12791 attached

E os tempos de resposta para 10 requests simultâneos:

$ time echo {1..10} | xargs -n1 -P10 bash -c "time curl localhost:3000"

<h1>Hello, World!</h1>1.049
<h1>Hello, World!</h1><h1>Hello, World!</h1><h1>Hello, World!</h1><h1>Hello, World!</h1>1.051
1.053
1.052
1.055
<h1>Hello, World!</h1>1.051
<h1>Hello, World!</h1>1.052
<h1>Hello, World!</h1>1.056
<h1>Hello, World!</h1>2.106
<h1>Hello, World!</h1>2.116
2.138

Yay! Podemos ver que os requests são atendidos de forma concorrente, e que o tempo total ficou em 2,1 segundos para 10 requests simultâneos!

Lembrando que, quando estamos lidando com concorrência, não temos controle da ordem de execução dos processos, que são escalonados pelo sistema operacional. Esta preempção de processos pode fazer com que um request que chegou depois seja atendido primeiro. É uma das características de race condition e é por isso que vemos os requests chegando fora de ordem.

Mas no nosso caso não importa. Cada request é único e não depende do anterior.

Concorrência com clone de processo

Outra forma muito similar à chamada fork é através da syscall clone, que basicamente clona um processo, tal como fizemos no exemplo anterior, garantindo isolamento e concorrência.

%define SYS_clone 56

E a diferença é que chamamos a syscall de clone, ao invés da syscall fork:

.accept:
	; int accept(int sockfd, struct *addr, int addrlen, int flags)
	mov rdi, [sockfd]
	mov rsi, 0
	mov rdx, 0
	mov r10, 0
	mov rax, SYS_accept4
	syscall
	mov r8, rax

	; chamada à syscall clone
	; com argumentos a ZERO, significa que será feito um clone do processo
	mov rdi, 0
	mov rsi, 0
	mov rax, SYS_clone
	syscall

	; se o retorno for zero, execução é a partir do processo filho
	test rax, rax
	jz handle

	; continuação da execução do processo principal
	jmp .accept

• depois de uma chamada ao clone, a syscall retorna ZERO quando se está dentro do processo filho. Neste caso, a execução do processo filho continua com a rotina handle e depois termina

• após a chamada do clone, se o retorno NÃO for ZERO, significa que a execução é do programa principal, então neste caso volta-se ao loop para esperar um novo request no socket

Executamos com strace e:

<h1>Hello, World!</h1><h1>Hello, World!</h1>1.062
1.064
<h1>Hello, World!</h1><h1>Hello, World!</h1>1.063
1.061
<h1>Hello, World!</h1><h1>Hello, World!</h1>1.071
1.061
<h1>Hello, World!</h1>1.059
<h1>Hello, World!</h1>1.069
<h1>Hello, World!</h1><h1>Hello, World!</h1>2.135
2.128
2.148

Ainda servindo 10 requests simultâneos perto dos 2 segundos! Not bad.

Entretanto, forking ou clone de processos leva a um gasto excessivo de memória, pois cada processo filho é exatamente uma cópia do processo principal. Se o principal tem 200MB de memória, com 4 forks teríamos um gasto total de 800MB de memória.

Chegou o momento de falarmos das threads.

Concorrência com threads

Vamos relembrar o que falamos no início do artigo:

Todo processo tem uma thread chamada thread principal, que é onde está sendo executado o programa

Apesar de todo programa rodar dentro de uma thread, podemos também criar mais threads que compartilham a memória do mesmo processo, e para isto podemos fazer uso da mesma syscall clone, mas passando argumentos diferentes que tornam este clone uma thread dentro do mesmo processo, e não uma cópia inteira do processo.

Desta forma, ficamos sempre com UM processo mas atendendo requests em threads diferentes, gastando assim menos memória se comparado com forking de processos.

Entendendo a criação de uma thread

Antes de adaptarmos o código do server para utilizar threads, vamos dar um passo atrás e entender como se cria uma thread em Assembly.

Para criar uma thread, fazemos uso da syscall clone. De acordo com a documentação, a syscall clone cria um processo "filho", similar ao que fizemos no fork. Mas a diferença é que a syscall clone permite um maior controle sobre o que será compartilhado entre o processo principal e o processo filho.

%define SYS_clone 56

Coisas que podem ser compartilhadas (ou não):

• espaço de endereço de memória virtual

• tabela de descritores de arquivos

• tabela de handlers de sinais

• entre outros recursos...

No exemplo anterior utilizamos a syscall clone passando argumentos a ZERO, o que significa que não queríamos compartilhar nada entre os processos, portanto uma cópia seria feita como no forking de processos

Para a execução da syscall, precisamos enviar 2 argumentos:

• rdi: representa as flags, que modificam o comportamento do que será compartilhado com o processo filho (thread)

• rsi: ponteiro para a função que a thread irá executar, que precisa ser definido dentro de uma área reservada na memória, ou seja, precisamos alocar um novo bloco de memória para a thread poder colocar a função e seus argumentos

Portanto, para criar uma thread, precisamos de thread flags e alocação de memória.

Thread flags

Em RDI, vamos passar as seguintes flags:

• CLONE_VM: processo principal e processo filho compartilham o mesmo espaço de memória virtual

• CLONE_FS: processos compartilham o mesmo sistema de arquivos

• CLONE_FILES: processos compartilham a mesma tabela de descritor de arquivos (file descriptor table)

• CLONE_SIGHAND: processos compartilham a mesma tabela de handlers de sinais (signal handlers)

• CLONE_PARENT: processos compartilham o mesmo parent, ou seja, o processo "filho" na verdade é filho do processo parent do processo original (mesmo porque estamos falando de uma thread que compartilha o mesmo processo)

• CLONE_THREAD: o processo filho é colocado no mesmo grupo de threads do processo original

• CLONE_IO: processos compartilham o mesmo contexto de I/O

No fim das contas, estamos criando um processo "filho" mas que compartilha recursos com o processo principal. Este é o princípio da thread.

mov rdi, CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IO

Alocação de memória com brk

Em RSI, precisamos indicar o ponteiro para a função na memória, neste caso o ponteiro da rotina handle, que tem a lógica de imprimir a mensagem e etc. Mas aqui não basta indicar o ponteiro, mas sim em que região da memória do processo a thread irá armazenar a função, seus argumentos e variáveis locais.

Cada thread precisa ter sua própria região na memória para armazenar a função e argumentos. É como se a thread tivesse uma área de "stack" só dela

Para alocar memória, vamos relembrar como funciona o layout de um programa na memória:

Nos endereços de memória mais baixos, temos o programa, e a seguir temos os dados estáticos (data). No topo, que é onde ficam os endereços mais altos, temos a stack.

E no meio, o que temos a seguir a seção de dados é uma área enorme disponível na memória. A syscall brk permite mudar o ponto onde termina a seção de dados, também chamado de program break.

Podemos ficar mudando este break em direção aos endereços mais altos. Por exemplo, se chamarmos a syscall brk passando argumento ZERO, ela devolve o endereço de memória do program break, que é onde termina a seção de dados:

%define SYS_brk 12

...

mov rdi, 0
mov rax, SYS_brk
syscall

O que temos em RAX é 0x403000, que é exatamente o endereço de memória onde termina a seção de dados. Vamos modificar o break andando UM byte pra frente:

mov rdi, rax
add rdi, 1
mov rax, SYS_brk
syscall

Agora, RAX traz o endereço do novo program break, que é 0x403001. Ou seja, agora podemos manipular este endereço de memória no nosso programa.

E o quê isto tem a ver com a thread?

Podemos alocar uma quantidade arbitrária de bytes para a thread utilizar nesta área na memória. Como o break é sempre modificado, a próxima thread irá utilizar outra área de memória, e assim sucessivamente!

Um "Hello, world" com threads em Assembly

Vamos escrever um exemplo simples antes de ir para o web server. Primeiro, definimos as constantes, dentre elas as syscalls e as flags pra criação de threads:

global _start

%define SYS_brk 12
%define SYS_clone 56
%define SYS_write 1        
%define SYS_exit 60

%define STDOUT 1
%define CHILD_STACK_SIZE 4096

%define CLONE_VM 0x00000100
%define CLONE_FS 0x00000200
%define CLONE_FILES 0x00000400
%define CLONE_PARENT 0x00008000
%define CLONE_THREAD 0x00010000
%define CLONE_IO 0x80000000
%define CLONE_SIGHAND 0x00000800

A seguir, na seção de dados, temos a mensagem "Hello, world" que a thread irá imprimir:

section .data
msg: db "Hello"
msgLen: equ $ - msg

Na seção text, o entrypoint do programa faz uma chamada à rotina da thread e a seguir termina:

section .text
_start:
	call thread

	mov rdi, 0
	mov rax, SYS_exit
	syscall

Agora, a definição da rotina handle que a thread irá executar:

handle:
	mov rdi, STDOUT
	mov rsi, msg
	mov rdx, msgLen
	mov rax, SYS_write
	syscall

	mov rdi, 0
	mov rax, SYS_exit
	syscall

A thread imprime a mensagem no STDOUT e termina. Sim, a thread precisa terminar, caso contrário o sistema emite um segmentation fault

E por fim, vamos detalhar o processo da rotina da thread (explicação nos comentários do exemplo a seguir):

thread:
	; Busca o break atual e guarda em RDX. Na primeira vez, o valor
	; é 0x403000
	mov rdi, 0
	mov rax, SYS_brk
	syscall
	mov rdx, rax

	; Modifica o break atual andando 4096 bytes à frente.
	; Após esta chamada, o break passa a ser 0x404000
	mov rdi, rax
	add rdi, CHILD_STACK_SIZE
	mov rax, SYS_brk
	syscall

	; (1) Thread flags: como deve ser feito o compartilhamento de recursos
	; entre o processo principal e o processo filho
	mov rdi, CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IO
	
	; (2a) Endereço de memória em RSI: é o break atual + 4096 bytes.
	; Retiramos também 8 bytes para caber o ponteiro da função
	lea rsi, [rdx + CHILD_STACK_SIZE - 8]

	; (2b) No endereço em RSI colocamos o ponteiro da função "handle".
	; Como endereçamento em x86_64 é de 8 bytes, é por isto
	; que no passo anterior fizemos [rdx + 4096 - 8]
	mov qword [rsi], handle
	mov rax, SYS_clone
	syscall
	ret

E pronto, ao executar o programa, temos a mensagem "Hello" na saída do programa que foi feita pela thread.

Caso o programa principal faça call thread 2 vezes, a próxima thread irá ter em RSI o break modificado, iniciando em 0x404000.

Modificando o server para suportar multi-threading

Agora vamos trazer o código necessário para modificar o server:

%define SYS_clone 56
%define SYS_brk 12

Thread flags:

%define CHILD_STACK_SIZE 4096
%define CLONE_VM 0x00000100
%define CLONE_FS 0x00000200
%define CLONE_FILES 0x00000400
%define CLONE_PARENT 0x00008000
%define CLONE_THREAD 0x00010000
%define CLONE_IO 0x80000000
%define CLONE_SIGHAND 0x00000800

Rotina accept:

.accept:
	; int accept(int sockfd, struct *addr, int addrlen, int flags)
	mov rdi, [sockfd]
	mov rsi, 0
	mov rdx, 0
	mov r10, 0
	mov rax, SYS_accept4
	syscall
	mov r8, rax

	; Chamada da thread. Irá ser executada assincronamente tal como no
	; forking de processos, mas compartilhando a memória do
	; processo principal
	call thread

	; Processo principal volta para o loop
	jmp .accept

Definição da thread:

thread:
	mov rdi, 0
	mov rax, SYS_brk
	syscall
	mov rdx, rax

	mov rdi, rax
	add rdi, CHILD_STACK_SIZE
	mov rax, SYS_brk
	syscall

	mov rdi, CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IO
	lea rsi, [rdx + CHILD_STACK_SIZE - 8]
	mov qword [rsi], handle
	mov rax, SYS_clone
	syscall
	ret

Aqui seguimos o mesmo padrão do exemplo anterior: aloca memória com brk e a seguir executa a syscall clone com as flags de compartilhamento de recursos

E a lógica da rotina handle que será executada pela thread, que faz o sleep, a seguir escreve no socket a mensagem, fecha o socket da requisição e por fim termina sua execução:

handle:
	lea rdi, [timespec]
	mov rax, SYS_nanosleep
	syscall

	; int write(fd)
	mov rdi, r8
	mov rsi, response
	mov rdx, responseLen
	mov rax, SYS_write
	syscall

	; int close(fd)
	mov rdi, r8
	mov rax, SYS_close
	syscall

	mov rdi, 0
	mov rax, SYS_exit
	syscall

Com 1 chamada isolada, temos o seguinte output com strace:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0
accept4(3, NULL, NULL, 0)               = 4
brk(NULL)                               = 0x9da000
brk(0x9db000)                           = 0x9db000
clone(child_stack=0x9daff8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IOstrace: Process 13078 attached
) = 13078
[pid 13078] nanosleep({tv_sec=1, tv_nsec=0},  <unfinished ...>
[pid 13077] accept4(3, NULL, NULL, 0 <unfinished ...>
[pid 13078] <... nanosleep resumed>0x9daff8) = 0
[pid 13078] write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
[pid 13078] close(4)                    = 0
[pid 13078] exit(0)                     = ?
[pid 13078] +++ exited with 0 +++
<... accept4 resumed>)                  = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
accept4(3, NULL, NULL, 0

Vamos reparar na sequência de chamadas:

• depois do accept, foi feita uma chamada a brk modificando o program break (alocando memória)

• a seguir, vemos a chamada clone, que acoplou o processo filho 13078

• a thread (13078) é suspensa com nanosleep por 1 segundo

• o processo principal (13077) volta para o accept e fica a espera de mais requests

• a thread escreve no socket

• a thread fecha o socket

• a thread é encerrada com exit

Agora, simulando os 10 requests simultâneos:

<h1>Hello, World!</h1>1.060
<h1>Hello, World!</h1>1.064
<h1>Hello, World!</h1>1.064
<h1>Hello, World!</h1>1.062
<h1>Hello, World!</h1>1.068
<h1>Hello, World!</h1>1.073
<h1>Hello, World!</h1><h1>Hello, World!</h1><h1>Hello, World!</h1><h1>Hello, World!</h1>2.098
2.094
2.097
2.091
2.113

Superb! Temos o mesmo tempo total de 2,1 segundos mas gastando muito menos memória!

Entretanto, temos um pequeno problema. Imagina que num momento de grande número de acessos, a nossa aplicação recebe 1000 requests concorrentes. E se receber 5000? Ou então dezenas de milhares de requests simultâneos?

Uma chamada de sistema tem custo. O sistema operacional oferece um limite de threads que podem ser criadas ao mesmo tempo por processo. Se deixarmos assim, nossa aplicação corre um grande risco de ultrapassar esse limite, além de que chamadas a brk + clone têm seus custos de criação.

E se pudéssemos reciclar um número limitado de threads? Sim, estamos falando de pool de threads.

Concorrência com thread pool

A forma mais comum de trabalhar com thread é com thread pool. Basicamente, definimos um número arbitrário de threads que nunca terminam, mas ficam em loop consumindo mensagens de alguma estrutura de dados. Esta estrutura pode ser uma fila.

Uma thread em loop

Vamos inicialmente definir que teremos apenas UMA thread em loop lendo mensagens da fila. O processo deverá ser o seguinte:

• processo principal inicia uma thread

• a thread fica em loop lendo mensagens (socket) da fila. Quando tiver vazia, repete o loop. Quando houver algum socket na fila, a thread executa a lógica que é fazer o nanosleep, escrever no socket, fechar o socket, e voltar para o loop de leitura da fila

• processo principal continua execução após criação da thread, onde fica em loop lendo requisições que chegam no socket (accept). Quando uma requisição chega, adiciona o socket na fila e volta para o loop do accept.

Vamos passo a passo, começando pelas constantes:

global _start

%define SYS_socket 41
%define SYS_bind 49
%define SYS_listen 50
%define SYS_accept4 288
%define SYS_write 1
%define SYS_close 3

%define SYS_nanosleep 35
%define SYS_clone 56
%define SYS_brk 12
%define SYS_exit 60

%define AF_INET 2
%define SOCK_STREAM 1
%define SOCK_PROTOCOL 0
%define BACKLOG 2
%define CR 0xD
%define LF 0xA

%define CHILD_STACK_SIZE 4096
%define CLONE_VM 0x00000100
%define CLONE_FS 0x00000200
%define CLONE_FILES 0x00000400
%define CLONE_PARENT 0x00008000
%define CLONE_THREAD 0x00010000
%define CLONE_IO 0x80000000
%define CLONE_SIGHAND 0x00000800

A seguir, a seção de dados:

section .data
sockaddr:
	sa_family: dw AF_INET   ; 2 bytes
	port: dw 0xB80B         ; 2 bytes
	ip_addr: dd 0           ; 4 bytes
	sin_zero: dq 0          ; 8 bytes
response: 
	headline: db "HTTP/1.1 200 OK", CR, LF
	content_type: db "Content-Type: text/html", CR, LF
	content_length: db "Content-Length: 22", CR, LF
	crlf: db CR, LF
	body: db "<h1>Hello, World!</h1>"
responseLen: equ $ - response
timespec:
	tv_sec: dq 1
	tv_nsec: dq 0
queuePtr: db 0

section .bss
sockfd: resb 8
queue: resb 8

Repare que a fila representa 8 bytes fixos (para nosso exemplo é o suficiente), utilizando também um ponteiro para manipular a fila.

Seguindo com o código, o programa inicia logo disparando a thread:

section .text
_start:
	call thread        

A seguir vêm as rotinas habituais (vou omitir pra poupar caracteres neste artigo): socket, bind e listen.

O accept fica da seguinte forma:

.accept:
	; int accept(int sockfd, struct *addr, int addrlen, int flags)
	mov rdi, [sockfd]
	mov rsi, 0
	mov rdx, 0
	mov r10, 0
	mov rax, SYS_accept4
	syscall

	mov r8, rax
	call enqueue

	jmp .accept

Okay, agora, ao invés de chamar uma thread, o programa principal enfileira o socket da requisição. Lógica do enqueue:

enqueue:
	xor rdx, rdx
	mov dl, [queuePtr]	
	mov [queue + rdx], r8	
	inc byte [queuePtr]
	ret

Aqui, estamos manipulando o ponteiro em queue utilizando queuePtr, incrementando um byte quando algo é adicionado na fila.

Agora vamos à implementação da rotina da thread:

thread:
	mov rdi, 0
	mov rax, SYS_brk
	syscall
	mov rdx, rax

	mov rdi, rax
	add rdi, CHILD_STACK_SIZE
	mov rax, SYS_brk
	syscall

	mov rdi, CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IO
	lea rsi, [rdx + CHILD_STACK_SIZE - 8]
	mov qword [rsi], handle
	mov rax, SYS_clone
	syscall
	ret

Nada de novo por enquanto. O que modifica é a rotina handle (explicação detalhada nos comentários):

handle:
	; Verifica se a fila está vazia. Se estiver, fica em loop infinito.
	; Repare que este código não está otimizado. Loop infinito 
	; acarreta alto consumo de CPU. Nas próximas seções vamos resolver isto.
	; Por ora, vamos aceitar este consumo de CPU.
	cmp byte [queuePtr], 0
	je handle

	; Remove (faz pop) da fila de socket, e guarda em R8.
	call dequeue
	mov r8, rax

	; Processo normal, faz o nanosleep de 1 segundo simulando latência
	lea rdi, [timespec]
	mov rax, SYS_nanosleep
	syscall

	; Escreve no socket que está em R8
	; int write(fd)
	mov rdi, r8
	mov rsi, response
	mov rdx, responseLen
	mov rax, SYS_write
	syscall

	; Fecha o socket
	; int close(fd)
	mov rdi, r8
	mov rax, SYS_close
	syscall

	; Volta para o início (loop)
	jmp handle

E por último, a lógica da rotina dequeue:

dequeue:
	xor rax, rax
	xor rsi, rsi

	mov al, [queue]
	mov rcx, 0
.loop_dequeue:
	cmp byte [queuePtr], 0
	je .return_dequeue

	cmp cl, [queuePtr]
	je .done_dequeue

	; shift
	xor r10, r10
	mov r10b, [queue + rcx + 1]
	mov byte [queue + rcx], r10b

	inc rcx
	jmp .loop_dequeue
.done_dequeue:
	dec byte [queuePtr]
.return_dequeue:
	ret

Por enquanto não vou entrar em detalhes em como trabalhar com filas em Assembly. Vou deixar estes detalhes para outro artigo, que irá tratar especificamente de arrays, filas e listas ligadas. Em breve!

Pronto, já podemos executar o server e...

<h1>Hello, World!</h1>1.042
<h1>Hello, World!</h1>2.059
<h1>Hello, World!</h1>3.071
<h1>Hello, World!</h1>4.083
<h1>Hello, World!</h1>5.090
<h1>Hello, World!</h1>6.094
<h1>Hello, World!</h1>7.112
<h1>Hello, World!</h1>8.121
<h1>Hello, World!</h1>9.140
<h1>Hello, World!</h1>10.150
10.166

Ouch! Voltamos aos 10 segundos. Mas isto se deve ao fato de termos apenas uma thread em loop. Vamos aumentar o número de threads na pool.

5 threads em loop

A seguir modificamos o programa para inicializar 5 threads, para que desta forma nosso server tenha mais capacidade em atender requests simultâneos:

section .text
_start:
.initialize_pool:
	mov r8, 0
.pool:
	call thread        
	inc r8
	cmp r8, 5
	je .socket
	jmp .pool
....
....

Com este loop fazemos call thread 5 vezes, pelo que cada thread, e ainda utilizando o exemplo anterior, irá ficar em loop buscando mensagens na fila.

Executamos o código com 1 request e temos sucesso:

$ time curl localhost:3000

<h1>Hello, World!</h1>1.022

Mas no output do strace, após a resposta, vemos uma sequência de erros das threads:

<h1>Hello, World!</h1>[pid 13483] write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86 <unfinished ...>
[pid 13482] write(0, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86 <unfinished ...>
[pid 13480] write(0, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86 <unfinished ...>
[pid 13484] <... write resumed>)        = 86
[pid 13481] write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 22

<h1>Hello, World!</h1> <unfinished ...>
[pid 13480] <... write resumed>)        = 86
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 22

<h1>Hello, World!</h1>[pid 13484] close(0 <unfinished ...>
[pid 13483] <... write resumed>)        = 86
[pid 13482] <... write resumed>)        = 86
[pid 13480] close(0 <unfinished ...>
[pid 13484] <... close resumed>)        = 0
[pid 13481] <... write resumed>)        = 86
[pid 13484] nanosleep({tv_sec=1, tv_nsec=0},  <unfinished ...>
[pid 13483] close(4 <unfinished ...>
[pid 13482] close(0 <unfinished ...>
[pid 13481] close(4 <unfinished ...>
[pid 13480] <... close resumed>)        = -1 EBADF (Bad file descriptor)
[pid 13483] <... close resumed>)        = 0
[pid 13482] <... close resumed>)        = -1 EBADF (Bad file descriptor)
[pid 13481] <... close resumed>)        = -1 EBADF (Bad file descriptor)

A thread tentou fechar o socket descriptor da requisição mas outra thread tentou ler o socket de forma concorrente (Bad file descriptor).

Quando envolve mais de uma thread consumindo o mesmo recurso (neste caso a fila), precisamos de um mecanismo de sincronização, que no caso são locks.

Sincronização com futex

Com locks, conseguimos controlar o acesso a um recurso compartilhado entre diferentes threads.

Através da syscall futex, podemos suspender uma thread baseando-se em uma "variável condicional". De forma oposta, podemos tornar uma thread de volta à execução baseando-se também na variável condicional.

Esta técnica de variável condicional (condvar) é um primitivo de sincronização bastante utilizado. No nosso caso para controle da fila, queremos o seguinte cenário:

• a thread verifica se há algo na fila. Caso a fila esteja vazia, a thread é suspensa com futex wait através de uma variável condicional

• quando algo for adicionado na fila, outra thread/processo "emite um sinal" chamando a syscall futex wake na mesma variável condicional.

• quando o sinal é emitido, neste momento a thread que tem o acesso ao lock (variável condicional) é trazida de volta ao contexto, então lê a mensagem da fila e executa a ação necessária. Após, se a fila estiver vazia, repete o processo com futex wait e fica novamente suspensa

Desta forma, garantimos que as threads não ficam consumindo a CPU em loop indefinidamente

Modificando o código, começamos por definir a syscall:

%define SYS_futex 202

A seguir, na seção de dados .bss declaramos a variável condicional ocupando 8 bytes, que será utilizada como sincronização do futex:

section .bss
...
condvar: resb 8

Na rotina enqueue, emitimos o sinal após o socket ser adicionado na fila:

enqueue:
	xor rdx, rdx
	mov dl, [queuePtr]	
	mov [queue + rdx], r8	
	inc byte [queuePtr]

	call emit_signal
	ret

A lógica o emit_signal (explicação nos comentários):

emit_signal:
   ; Endereço de memória para a variável condicional (8 bytes)
   mov rdi, condvar
   
   ; Flags do Futex (WAKE), que irá trazer a thread
   ; de volta ao contexto
   mov rsi, FUTEX_WAKE | FUTEX_PRIVATE_FLAG 

   ; Argumentos adicionais, que neste caso vamos deixar a ZERO
   xor rdx, rdx
   xor r10, r10
   xor r8, r8

   ; Chamada da syscall
   mov rax, SYS_futex
   syscall
   ret

Agora, modificamos a rotina handle:

handle:	
	; Caso a fila esteja vazia, fazemos jump para "wait"
	cmp byte [queuePtr], 0         
	je .wait           

	; Faz pop do socket da fila e segue o fluxo normal
	call dequeue      
	mov r10, rax

	lea rdi, [timespec]
	mov rax, SYS_nanosleep
	syscall

	; int write(fd)
	mov rdi, r10
	mov rsi, response
	mov rdx, responseLen
	mov rax, SYS_write
	syscall

	; int close(fd)
	mov rdi, r10
	mov rax, SYS_close
	syscall

	; Volta para o início
	jmp handle       
.wait:
	; Chamada para wait_condvar, que vai suspender a thread atual com FUTEX
	call wait_condvar 
	jmp handle       

E, por último e não menos importante, a lógica da rotina wait_condvar, que suspende a thread de execução:

wait_condvar:
   ; Endereço de memória para a variável condicional (8 bytes)
   mov rdi, condvar   

   ; Flags do Futex (WAIT), que irá suspender a thread
   mov rsi, FUTEX_WAIT | FUTEX_PRIVATE_FLAG 
   xor rdx, rdx
   xor r10, r10              
   xor r8, r8               
   mov rax, SYS_futex
   syscall
   test rax, rax
   jz .done_condvar
.done_condvar:
   ret

Assim que iniciamos o server com strace, podemos ver as syscalls em ação:

brk(NULL)                               = 0x155c000
brk(0x155d000)                          = 0x155d000
clone(child_stack=0x155cff8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IOstrace: Process 13539 attached
) = 13539
[pid 13539] futex(0x402088, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 13538] brk(NULL)                   = 0x155d000
[pid 13538] brk(0x155e000)              = 0x155e000
[pid 13538] clone(child_stack=0x155dff8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IOstrace: Process 13540 attached
) = 13540
[pid 13540] futex(0x402088, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 13538] brk(NULL)                   = 0x155e000
[pid 13538] brk(0x155f000)              = 0x155f000
[pid 13538] clone(child_stack=0x155eff8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IOstrace: Process 13541 attached
) = 13541
[pid 13541] futex(0x402088, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 13538] brk(NULL)                   = 0x155f000
[pid 13538] brk(0x1560000)              = 0x1560000
[pid 13538] clone(child_stack=0x155fff8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IOstrace: Process 13542 attached
) = 13542
[pid 13542] futex(0x402088, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 13538] brk(NULL)                   = 0x1560000
[pid 13538] brk(0x1561000)              = 0x1561000
[pid 13538] clone(child_stack=0x1560ff8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IOstrace: Process 13543 attached
) = 13543
[pid 13538] socket(AF_INET, SOCK_STREAM, IPPROTO_IP <unfinished ...>
[pid 13543] futex(0x402088, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 13538] <... socket resumed>)       = 3
[pid 13538] bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
[pid 13538] listen(3, 2)                = 0
[pid 13538] accept4(3, NULL, NULL, 0)   = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
[pid 13538] --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
[pid 13538] accept4(3, NULL, NULL, 0

Repare que cada thread faz a chamada a futex com FUTEX WAIT, e isto vemos acontecer 5 vezes no trace. Ou seja, as 5 threads estão suspensas sem consumir CPU.

Ao fazer o primeiro request, temos o seguinte resultado:

)   = 4
[pid 13538] futex(0x402088, FUTEX_WAKE_PRIVATE, 0) = 1
[pid 13539] <... futex resumed>)        = 0
[pid 13538] accept4(3, NULL, NULL, 0 <unfinished ...>
[pid 13539] nanosleep({tv_sec=1, tv_nsec=0}, NULL) = 0
[pid 13539] write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
[pid 13539] close(4)                    = 0
[pid 13539] futex(0x402088, FUTEX_WAIT_PRIVATE, 0, NULL

• o processo principal recebeu a mensagem no socket, enfileirou e executou futex com FUTEX_WAKE

• uma das threads foi trazida de volta ao contexto e fez a sua devida execução (nanosleep + write + close)

• o processo principal voltou para o accept a espera de mais requests no socket

• a thread terminou seu trabalho, viu que não tinha mais nada na fila e executou futex com FUTEX_WAIT, ficando novamente suspensa

Finalmente, podemos executar 10 requests simultâneos e...

<h1>Hello, World!</h1><h1>Hello, World!</h1><h1>Hello, World!</h1>1.079
1.082
1.083
<h1>Hello, World!</h1><h1>Hello, World!</h1>1.062
1.083
<h1>Hello, World!</h1><h1>Hello, World!</h1>2.087
2.088
<h1>Hello, World!</h1>2.100
<h1>Hello, World!</h1>2.101
<h1>Hello, World!</h1>2.110
2.127

Nice! Com uma pool de 5 threads, conseguimos atingir 2,1 segundos para 10 requests concorrentes. Agora temos concorrência consumindo muito menos recursos:

• menos memória, pois não é forking de processos

• menos CPU, pois as threads não ficam em loop infinito

• menos latência, pois com uma limitação de 5 threads, novos requests não criam novas threads

Alocação de memória com mmap

Um problema comum ao utilizar brk é que a memória pode ficar fragmentada. Uma vez que o program break foi modificado, aquela memória pode ser utilizada, mas torna muito difícil ser reciclada.

Uma forma de lidar com este problema de fragmentação é utilizar uma syscall que trata de reservar uma área na memória que pode ser reciclada futuramente. Estamos falando da syscall mmap.

thread:
	mov rdi, 0x0
	mov rsi, CHILD_STACK_SIZE
	mov rdx, PROT_WRITE | PROT_READ
	mov r10, MAP_ANONYMOUS | MAP_PRIVATE | MAP_GROWSDOWN
	mov rax, SYS_mmap
	syscall

	mov rdi, CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IO
	lea rsi, [rax + CHILD_STACK_SIZE - 8]
	mov qword [rsi], handle
	mov rax, SYS_clone
	syscall
	ret

Ao invés de chamar brk, podemos chamar mmap, especificando:

• rdi: endereço de memória onde deve ser mapeado. Se tiver ZERO, o sistema operacional se encarrega de trazer um endereço de memória disponível

• rsi: tamanho do espaço reservado na memória. No nosso caso, queremos 4096 bytes para a thread

• rdx: proteção de memória, neste caso queremos que a memória possa ser tanto escrita (PROT_WRITE) quanto lida (PROT_READ) pela thread

• r10: flags de mapeamento

  • MAP_ANONYMOUS: o mapeamento não é associado a nenhum arquivo ou descritor de arquivo (modo anônimo)
  • MAP_PRIVATE: mapeamento privado com copy-on-write, ou seja, os dados serão copiados à medida em que são escritos
  • MAP_GROWSDOWN: o mapeamento é usado no formato "stack", ou seja, o mapeamento é dos endereços maiores em direção aos menores

Com mmap, podemos fazer uso da sua contrapartida, a syscall unmmap, que permite reciclar uma determinada área na memória que não é mais utilizada, evitando fragmentação.

Esta técnica é muito utilizada pela libc através da função malloc. Com mmap podemos definir uma memória heap para nosso programa

É isto, na prática não terá nenhum efeito com relação ao exemplo anterior. Mas esta seção foi apenas para trazer uma forma diferente de alocar memória para a thread.

Conclusão

Ufa! Finalmente chegamos ao final da saga. Passamos por uma introdução, onde a seguir fizemos uma abordagem pela história e arquitetura de computadores, para então analisar código de máquina, que foi a base para entrar em assembly x86 de fato, para finalmente concluir o desenvolvimento do web server.

Este último artigo foi uma abordagem para multi-threading em Assembly, passando por conceitos de concorrência como forking de processos, clone, threading, pool de threads e sincronização com locks.

Declaro aqui então o fim da saga desenvolvendo um web server em Assembly x86.

Até a próxima saga!

Referências

Agora, vamos de fato construir um web server muito simples que devolve um HTML com a frase "Hello, World". A meta é chegarmos nisto:

O processo para chegarmos a este objetivo consiste em cobrir fundamentos de Web, passando por sockets, TCP e HTTP, enquanto vamos explorando conceitos práticos em Assembly x86.

Agenda

• Arquitetura Web

  • Cliente-servidor
  • Modelo OSI
  • Sockets e TCP
  • HTTP

• Como funciona um servidor web

  • 4 syscalls para o resgate

• Um server modesto em Assembly

  • Criando o socket
  • Fazendo bind no socket
  • Preparando para receber conexões
  • Chegou o momento de aceitar clientes
  • Resposta do servidor e fechamento da conexão
  • Mas o servidor deve ficar em loop, não?

• Conclusão

• Referências

Arquitetura Web

Para criar um servidor web, precisamos manipular mensagens HTTP, que são transportadas via camada de transporte TCP/IP através de uma rede.

Estas mensagens são enviadas entre diferentes dispositivos conectados a uma rede, que pode ser privada (local) ou pública. Regularmente, comunicação HTTP é feita entre 2 dispositivos, sendo um deles o cliente e outro o servidor.

Vamos brevemente falar de cada um destes conceitos.

Cliente-servidor

Numa arquitetura cliente-servidor, temos 2 dispositivos conectados a uma rede de computadores:

Para um servidor web, é necessário que o cliente realize uma conexão com o servidor, em seguida faça uma requisição, pelo que o servidor deve devolver uma resposta e, por último, fechar a conexão.

Mas como esta mensagem deve ser enviada? Quem garante a entrega? E caso ocorra falha de sinal na camada física (cabeamento de rede), como assegurar que cada "pacote" da mensagem seja entregue em ordem?

É pra isto que foi criado o modelo de comunicação OSI.

Modelo OSI

OSI é um modelo de referência para comunicação entre diferentes dispositivos através de diferentes redes, que estabelece um conjunto de camadas que vai desde a camada física até a camada de formato de mensagens.

• Camada física: responsável pelo tráfego de informações através de meios físicos, tais como bluetooth, frequência de rádio, cabos etc

• Camada de enlace de rede: responsável pela decodificação e codificação de mensagens em frames, do meio físico para o meio digital e vice-versa

• Camada de rede: é aqui que definimos protocolos de rede, tais como o protocolo de internet, também conhecido como IP (Internet Protocol)

Na web, os dados trafegam geralmente através de uma rede de computadores pública, global e descentralizada, neste caso a Internet

• Camada de transporte: camada responsável por características de entrega, tais como definir critérios de confiabilidade e ordem dos pacotes de mensagens. Por exemplo, nesta camada temos o protocolo de controle de transmissão, ou TCP

• Camada de sessão e apresentação: aqui vão critérios de informações que podem ser vinculadas a uma determinada conexão entre diferentes dispositivos, bem como o formato de apresentação das informações na rede

• Camada de aplicação: nesta camada, temos a definição do formato de mensagens em um nível mais "aplicacional", como por exemplo protocolo HTTP (Hypertext Transfer Protocol), FTP, SSH entre outros

Entretanto fica aqui uma questão: como que todo esse modelo de comunicação em rede se converte em algo prático num programa dentro de um sistema operacional?

Chegou o momento de falar sobre sockets e TCP.

Sockets e TCP

Num computador, todos os programas são encapsulados dentro de uma estrutura chamada processo, como vimos em artigos anteriores.

Quando falamos em cliente na aquitetura cliente-servidor, estamos falando de um processo rodando dentro de um computador, e o mesmo vale para o servidor, onde cada processo tem seu próprio identificador, ou PID:

Sabendo que processos são isolados, foram definidas diferentes formas de comunicação entre processos (também conhecido como IPC, ou inter process communication), tais como pipes, arquivos do filesystem, descritores de arquivos e UNIX sockets.

Estamos baseando a saga em sistema "UNIX-like", mais especificamente GNU/Linux

Ou seja, temos ciência que é possível fazer 2 processos dentro de um mesmo computador se comunicarem através de UNIX sockets. Mas como fazer dois processos em computadores distintos se comunicarem?

Entramos então em Berkeley Sockets, que define uma API comum de comunicação utilizando sockets, onde diferentes sockets podem estar no mesmo computador, ou em uma mesma rede local, ou até mesmo em redes diferentes dentro da Internet.

É aqui que temos a introdução ao TCP, que é um protocolo de comunicação via sockets. Portanto, para fazer um cliente se comunicar com um servidor, é preciso estabelecer endpoints de comunicação, que são basicamente sockets, e neste caso para a web, vamos utilizar sockets TCP.

Estes sockets são abertos tanto do lado do cliente, quanto no servidor. No servidor, estes sockets são mapeados em descritores de arquivos, que representam um número especial e reservado, também chamado de porta de comunicação:

Ok Leandro, consegui entender o conceito de sockets e TCP. Mas qual deveria ser o formato da mensagem na web?

Com vocês, o HTTP.

HTTP

HTTP é um protocolo de formato de mensagem que faz parte da camada de aplicação.

Com HTTP, a mensagem é definida seguindo padrões de hipertexto, que são basicamente documentos que podem ter ligações com outros documentos em sites diferentes.

Na web, o padrão segue um formato de headline, que contém o tipo de pedido, seguido de quebra de linhas com cabeçalhos de metadados e por fim, opcionalmente e dependendo do tipo de pedido, um corpo com a mensagem principal contendo majoritariamente HTML, CSS e Javascript.

Até agora, passamos por conceitos que formam a web. Como nosso exemplo de web server é bastante simples, estes fundamentos já são o suficiente para entrarmos na próxima seção, que é de fato escrever o web server em Assembly x86.

Como funciona um servidor web

Conforme vimos na seção anterior, arquitetura web passa por manipulação de sockets TCP.

Tal manipulação é feita via chamadas de sistema (syscalls) no sistema operacional, portanto, para darmos início ao servidor, vamos entender como devem ser criados os sockets a nível do OS.

4 syscalls para o resgate

Resumidamente temos que fazer 4 syscalls para termos um server operante, que são:

socket A syscall socket é responsável por criar um endpoint de comunicação de rede e retornar um descritor de arquivo (fd) relativo ao endpoint criado.

Na libc, socket é referenciada pelo número 41 e tem a seguinte assinatura:

int socket(int domain, int type, int protocol)

Lembrando que estamos utilizando arquitetura x86_64, ou x64

bind bind atribui nome e porta ao socket previamente criado. Esta syscall na libc responde pelo número 49 e tem a assinatura a seguir:

int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)

listen A syscall listen marca o socket criado (precisa ser do tipo stream, no caso TCP) para aceitar conexões. É conhecida pelo número 50 e tem a seguinte assinatura em C:

int listen(int sockfd, int backlog)

accept A syscall accept admite uma conexão de um cliente no socket e cria um novo socket de conexão específico para aquele cliente. Esta syscall, a princípio, bloqueia o programa e só continua a execução quando uma nova conexão com novo cliente é estabelecida.

É referenciada pelo número 288 e tem a seguinte assintaura:

int accept(int sockfd, struct *addr, int addrlen, int flags)

Em resumo, tudo o que precisamos para criar um web server, independente do programa, linguagem de programação ou tecnologia, é de chamar estas 4 syscalls.

Não se engane, o teu servidor Express, Rails, Django ou NGINX, faz estas chamadas de sistema por baixo dos panos: socket, bind, listen e accept

Sem mais delongas, vamos ver como tudo isto se aplica naquilo que importa para esta saga: assembly.

Um server modesto em Assembly

Montar as syscalls para o web server em Assembly não é tão difícil quanto parece. Para começar, vamos fazer a primeira syscall, que é a socket.

Criando o socket

Como de costume, vamos montar as instruções de acordo com o manual e tabela de syscalls.

Já vimos na seção anterior quais são os números das syscalls e suas respectivas assinaturas na libc

Iniciamos definindo as constantes, apenas as necessárias para a syscall socket:

global _start

; syscalls constants
%define SYS_socket 41

; other constants
%define AF_INET 2
%define SOCK_STREAM 1
%define SOCK_PROTOCOL 0

Após isto, vamos reservar 1 byte com a diretiva resb 1 que significa "reservar 1 byte". Este byte será utilizado para armazenar o número do descritor de arquivo que referencia o socket que vai ser criado.

Como não queremos inicializar o valor deste byte, não vamos colocar na seção .data como temos utilizado até o momento na saga, mas sim na seção .bss.

• Na seção .data, ficam apenas dados inicializados

• Na seção .bss, ficam os dados não-inicializados

section .bss
sockfd: resb 1

Vamos relembrar o layout de memória:

Como vemos na imagem, a seção .bss vem a seguir a seção .data, ou seja, fica em endereços de memória mais altos que a seção .data.

Agora, vamos montar os registradores seguindo a convenção de chamada e a ordem dos parâmetros da função socket na libc:

section .text
_start:
.socket:
	; int socket(int domain, int type, int protocol)
	mov rdi, AF_INET
	mov rsi, SOCK_STREAM
	mov rdx, SOCK_PROTOCOL
	mov rax, SYS_socket
	syscall
	mov [sockfd], rax 
.exit:
	mov rdi, 0
	mov rax, 60
	syscall

• domain: representa o domínio de comunicação. No caso queremos usar AF_INET, que significa IPv4, e tem o valor 2 conforme especificado no glibc

• type: representa o tipo de comunicação, que no caso vamos usar SOCK_STREAM que é sequencial, confiável, duplex e baseado em conexão. O valor conforme glibc é 1

• protocol: esta opção é usada no caso da utilização de um protocolo em específico. Neste caso, vamos deixar o valor como 0 que é o default para AF_INET e SOCK_STREAM, indicando que se trata de um socket TCP

Lembrando que existem sockets da família UNIX que não funcionam na camada de rede IP. É possível combinar socket UNIX com SOCK_STREAM, mas neste caso estamos combinando a família AF_INET (IPv4) com o tipo SOCK_STREAM (segmento de bytes, duplex), e esta combinação faz este socket ser TCP. Para mais detalhes sobre sockets, sugiro a leitura de um artigo que escrevi sobre UNIX Sockets

Vamos confirmar com GDB?

# Breakpoint na linha <syscall>
(gdb) break 22

(gdb) run

# Confirmando que os registradores estão com os valores corretos
# antes da execução da syscall...
(gdb) i r rdi rsi rdx rax
rdi            0x2                 2
rsi            0x1                 1
rdx            0x0                 0
rax            0x29                41

# Confirmando que `sockfd` continua com o valor zerado
(gdb) x &sockfd
0x402000 <sockfd>:      0x00000000

(gdb) next

Após a execução da syscall, podemos ver que o retorno da função, que representa o descritor de arquivo conforme documentação, está armazenado no registrador RAX (de acordo com a convenção de chamada):

(gdb) i r rax
rax            0x3                 3

(gdb) next

(gdb) x &sockfd
0x402000 <sockfd>:      0x00000003

Ou seja, após a syscall, temos em sockfd o número do socket que acabou de ser criado.

Executando com strace:

$ strace ./live

execve("./live", ["./live"], 0x7ffca20187e0 /* 24 vars */) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
exit(0)                                 = ?
+++ exited with 0 +++

Sem erros, yay!

Vamos para a próxima syscall.

Fazendo bind no socket

Agora, é o momento de atribuir um endereço e uma porta como endpoint de comunicação para este socket. É para isto que serve a syscall bind.

Analisando a função:

; int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)

Podemos ver que um dos argumentos é um ponteiro para uma struct na memória. Vamos entender melhor cada argumento.

sockfd Em sockfd vai o inteiro que representa o descritor do socket criado

*sockaddr addr Representa o ponteiro para o endereço de memória que contém uma estrutura de dados que, de acordo com este guia, contempla: family, port, ip_address, sin_zero, onde sin_zero é apenas padding de preenchimento de bytes.

Para arquitetura x64, esta estrutura deve conter 16 bytes no total, onde:

• 2 bytes são para a família de protocolo

• 2 bytes para a porta

• 4 bytes para o endereço de IP

• 8 bytes de padding para o sin_zero, ou seja, preencher os 8 bytes restantes com ZERO

addrlen: tamanho do sockaddr, e já sabemos que são 16 bytes

Uma vez entendidos os parâmetros da função, vamos montar a chamada.

%define SYS_bind 49

; Data types in asm
; (db) byte => 1 byte
; (dw) word => 2 bytes
; (dd) doubleword => 4 bytes
; (dq) quadword => 8 bytes

section .data
sockaddr: 
	family: dw AF_INET   ; 2 bytes
	port: dw 0x0BB8      ; 2 bytes (representa a porta 3000)
	ip_address: dd 0     ; 4 bytes
	sin_zero: dq 0       ; 8 bytes

.bind:
	; int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
	mov rdi, [sockfd]
	mov rsi, sockaddr
	mov rdx, 16
	mov rax, SYS_bind
	syscall

Ao validar com GDB, podemos ver que o sockaddr está armazenando a estrutura necessária para ser enviada no parâmetro sockaddr *addr da syscall:

# Breakpoint na syscall de bind
(gdb) break 38

(gdb) run

(gdb) x &sockaddr
0x402000 <family>:      0xb80b0002

Se buscarmos os 2 primeiros bytes, confirmamos que é o valor 2 (repare que está invertido pois é o padrão little-endian da aquitetura x86_64:

(gdb) x /2xb &sockaddr
0x402000 <family>:      0x02    0x00

Quanto à porta, queremos que o server responda no número 3000. Portanto, verificamos que os próximos 2 bytes representam a porta:

# Em hexadecimal, 3000 equivale a 0x0BB8, mas por causa do formato
# little-endian da arquitetura x86_64, estamos visualizando 0xB80B
(gdb) x /2xb (void*) &sockaddr+2
0x402002 <port>:        0xb8    0x0b

Queremos também que o servidor responda no endereço de IP 0.0.0.0, então os próximos 4 bytes estarão todos a zero:

(gdb) x /4xb (void*) &sockaddr+4
0x402004 <ip_address>:  0x00    0x00    0x00    0x00

E, por fim, os 8 bytes restantes representando sin_zero, todos preenchidos com zero:

(gdb) x /8xb (void*) &sockaddr+8
0x402008 <sin_zero>:    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00

Vamos executar com strace:

$ strace ./live

execve("./live", ["./live"], 0x7ffd51ed4650 /* 24 vars */) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(47115), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
exit(0)                                 = ?
+++ exited with 0 +++

Ouch! Apesar da função bind ter retornado 0 indicando que não houve erros, temos um pequeno problema. Repare que a porta não está sendo mapeada para o número 3000, e sim para 47115, conforme vemos em htons(47115).

Entendendo a implicação de endianess na syscall bind htons é uma função de rede utilizada para converter a ordem dos bytes do programa antes de serem utilizados na rede. Como a internet utiliza big-endian, esta função converte a ordem utilizada na arquitetura (no caso da x86_64, little-endian) para o formato big-endian da rede.

Entretanto htons(47115) não é o valor que queremos. O que precisamos é que o mapeamendo seja htons(3000). Por quê isto está acontecendo?

O valor que colocamos em hexadecimal representando 3000 é 0x0BB8, mas se prestarmos atenção no GBD, o valor de fato armazenado está com os bytes invertidos para little-endian, que é 0xB80B. Ocorre que 0xB80B em decimal é 47115!!!!!! Aí que está o problema!

Precisamos então inverter os bytes no programa, e assim sendo o valor que será passado para a função htons fica corrigido.

....
section .data
sockaddr: 
	family: dw AF_INET   ; 2 bytes
	port: dw 0xB80B      ; 2 bytes (aqui invertemos os bytes)
	ip_address: dd 0     ; 4 bytes
	sin_zero: dq 0       ; 8 bytes
....

E analisando novamente com GDB:

# Agora sim, apesar de estar invertido, é exatamente este valor que
# queremos que seja passado para htons: 0x0BB8 em decimal é 3000
(gdb) x /2xb (void*) &sockaddr+2
0x402002 <port>:        0x0b    0xb8

Executando novamente com strace:

$ strace ./live

execve("./live", ["./live"], 0x7ffd51ed4650 /* 24 vars */) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
exit(0)                                 = ?
+++ exited with 0 +++

Superb! Podemos ver que a syscall bind foi executada com os parâmetros corretamente, inclusive o htons(3000), então retornando 0, que indica que não houve qualquer erro.

Preparando para receber conexões

Próximo passo consiste em preparar o socket para receber conexões, que basicamente é chamar a função listen:

%define SYS_listen 50
%define BACKLOG 2

.listen:
	; int listen(int sockfd, int backlog)
	mov rdi, [sockfd]
	mov rsi, BACKLOG
	mov rax, SYS_listen
	syscall

Onde BACKLOG significa a quantidade de conexões "pendentes" no socket. Executamos com strace e:

$ strace ./live

execve("./live", ["./live"], 0x7ffe6b4eea30 /* 24 vars */) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0
exit(0)                                 = ?
+++ exited with 0 +++

Que noite maravilhosa! Listen funcionou lindamente, afinal, é uma função muito simples. Agora, hora de aceitar conexões de clientes no socket.

Chegou o momento de aceitar clientes

O grande momento chegou. Vamos montar as instruções da syscall accept, que de acordo com a função em libc, recebe um socket como primeiro argumento e os demais são opcionais.

%define SYS_accept 288

.accept:
	; int accept(int sockfd, struct *addr, int addrlen, int flags)
	mov rdi, [sockfd]
	mov rsi, 0              ; não precisa estabelecer um addr
	mov rdx, 0              ; não precisa do tamanho uma vez que não há addr
	mov r10, 0
	mov rax, SYS_accept
	syscall

Se executarmos com GDB, podemos ver que o resultado da syscall fica bloqueado até que uma conexão seja feita:

# Breakpoint na syscall de socket
(gdb) break 55

(gdb) run
(gdb) next

O programa está parado na syscall de socket, aguardando resposta do kernel. Para que o kernel responda e o programa continue a execução, é preciso realizar um pedido usando um HTTP client, e neste caso vamos usar o curl:

$ curl localhost:3000

Repare que o programa continuou a execução. Vamos ver a resposta que está em RAX:

(gdb) i r rax
rax            0x4                 4

# Um número diferente do sockfd, que é o socket criado pelo server
(gdb) x &sockfd
0x402010 <sockfd>:      0x00000003

Podemos ver que é um número diferente (RAX contém 4 e sockfd contém 3). De acordo com a documentação, este é o número do descritor que representa um novo socket criado para comunicação entre um cliente específico e o servidor.

Vamos mover o valor de RAX para R8, apenas para preservar o socket, uma vez que RAX será usado novamente por outras syscalls de accept:

mov r8, rax             ; client socket

Resposta do servidor e fechamento da conexão

Uma outra coisa importante a se fazer é fechar a conexão com este socket do cliente depois de ter processado e respondido a requisição.

Vamos implementar a subrotina .write, que escreve a resposta na conexão (socket) do cliente:

%define SYS_write 1

%define CR 0xD
%define LF 0xA

section .data
response: 
	headline: db "HTTP/1.1 200 OK", CR, LF
	content_type: db "Content-Type: text/html", CR, LF
	content_length: db "Content-Length: 22", CR, LF
	crlf: db CR, LF
	body: db "<h1>Hello, World!</h1>"
responseLen: equ $ - response

section .text
...
.write:
	; int write(int fd, buffer *bf, int bfLen)
	mov rdi, r8
	mov rsi, response
	mov rdx, responseLen
	mov rax, SYS_write
	syscall
	ret

No exemplo acima, assumimos que a string de resposta HTTP aponta para uma estrutura na memória, definida em .data.

Atenção para CR (carriage return), LF (line feed) que são constantes que representam \r\n que são separadores de linhas definidos pelo protocolo HTTP

Agora, definir a subrotina .close, que fecha a conexão com o cliente:

%define SYS_close 3

section .text
...
.close:
	; int close(int fd)
	mov rdi, r8
	mov rax, SYS_close
	syscall
	ret

Ligando tudo no accept:

section .text
....
.accept:
	; int accept(int sockfd, struct *addr, int addrlen, int flags)
	mov rdi, [sockfd]
	mov rsi, 0              ; não precisa estabelecer um addr
	mov rdx, 0              ; não precisa do tamanho uma vez que não há addr
	mov r10, 0
	mov rax, SYS_accept
	syscall
	mov r8, rax             ; client socket
	call .write             ; escreve no socket
	call .close             ; fecha o socket
	jmp .exit               ; termina o programa

E agora, vamos executar o programa com strace:

$ strace ./live

execve("./live", ["./live"], 0x7ffd811567c0 /* 24 vars */) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0
accept4(3, NULL, NULL, 0

• primeiro foi feita a syscall socket

• a seguir foi feito o bind

• depois o listen

• e por fim, o accept ficou bloqueado a espera de uma requisição

Em outra janela, vamos fazer a requisição:

$ curl localhost:3000
<h1>Hello, World!</h1>

E no servidor, a saída do strace no final ficou assim:

write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
close(4)                                = 0
exit(0)                                 = ?
+++ exited with 0 +++

Escreveu a resposta com write, fechou a conexão com close, e depois terminou o programa com exit.

Como não ficar feliz?

Mas o servidor deve ficar em loop, não?

Sim, o servidor deve ficar em loop, portanto ao invés de fazer o jmp .exit, fazemos jmp .accept na última linha da procedure:

...
.accept:
	; int accept(int sockfd, struct *addr, int addrlen, int flags)
	mov rdi, [sockfd]
	mov rsi, 0              ; não precisa estabelecer um addr
	mov rdx, 0              ; não precisa do tamanho uma vez que não há addr
	mov r10, 0
	mov rax, SYS_accept
	syscall
	mov r8, rax             ; client socket
	call .write
	call .close
	jmp .accept             ; <-- MUDANÇA AQUI, mantém o server em loop infinito

Assim, o server nunca termina, e quando uma conexão com um cliente é fechada, voltamos no início do loop e ficamos a espera de nova conexão na syscall accept.

Código final do server:

global _start

%define SYS_socket 41
%define SYS_bind 49
%define SYS_listen 50
%define SYS_accept 288
%define SYS_write 1
%define SYS_close 3

%define AF_INET 2
%define SOCK_STREAM 1
%define SOCK_PROTOCOL 0
%define BACKLOG 2
%define CR 0xD
%define LF 0xA

; Data types in asm
; byte => 1 byte
; word => 2 bytes
; doubleword => 4 bytes
; quadword => 8 bytes

section .data
sockaddr: 
	family: dw AF_INET   ; 2 bytes
	port: dw 0xB80B      ; 2 bytes (47115 big endian becomes 3000 little endian)
	ip_address: dd 0     ; 4 bytes
	sin_zero: dq 0       ; 8 bytes
sockaddrLen: equ $ - sockaddr
response: 
	headline: db "HTTP/1.1 200 OK", CR, LF
	content_type: db "Content-Type: text/html", CR, LF
	content_length: db "Content-Length: 22", CR, LF
	crlf: db CR, LF
	body: db "<h1>Hello, World!</h1>"
responseLen: equ $ - response

section .bss
sockfd: resb 1

section .text
_start:
.socket:
	; int socket(int domain, int type, int protocol)
	mov rdi, AF_INET
	mov rsi, SOCK_STREAM
	mov rdx, SOCK_PROTOCOL
	mov rax, SYS_socket
	syscall
	mov [sockfd], rax 
.bind:
	; int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
	mov rdi, [sockfd]
	mov rsi, sockaddr
	mov rdx, sockaddrLen
	mov rax, SYS_bind
	syscall
.listen:
	; int listen(int sockfd, int backlog)
	mov rdi, [sockfd]
	mov rsi, BACKLOG
	mov rax, SYS_listen
	syscall
.accept:
	; int accept(int sockfd, struct *addr, int addrlen, int flags)
	mov rdi, [sockfd]
	mov rsi, 0              ; não precisa estabelecer um addr
	mov rdx, 0              ; não precisa do tamanho uma vez que não há addr
	mov r10, 0
	mov rax, SYS_accept
	syscall
	mov r8, rax             ; client socket
	call .write
	call .close
	jmp .accept
.write:
	; int write(int fd, buffer *bf, int bfLen)
	mov rdi, r8
	mov rsi, response
	mov rdx, responseLen
	mov rax, SYS_write
	syscall
	ret
.close:
	; int close(int fd)
	mov rdi, r8
	mov rax, SYS_close
	syscall
	ret

Executando tudo com strace e temos:

$ strace ./live

execve("./live", ["./live"], 0x7fff9fde7840 /* 24 vars */) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0
accept4(3, NULL, NULL, 0)               = 4
write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
close(4)                                = 0
accept4(3, NULL, NULL, 0)               = 4
write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
close(4)                                = 0
accept4(3, NULL, NULL, 0)               = 4
write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
close(4)                                = 0
accept4(3, NULL, NULL, 0

No lado do cliente:

$ curl localhost:3000
<h1>Hello, World!</h1>

$ curl localhost:3000
<h1>Hello, World!</h1>

$ curl localhost:3000
<h1>Hello, World!</h1>

Com vocês, o web browser

Esta saga não teria nenhuma graça se não fosse pra ser executada em um web browser, afinal estamos falando de um web server, não?

Conclusão

Incrivelmente chegamos no final da construção de um modesto web server. Aqui aprendemos conceitos sobre sockets, TCP e HTTP, com uma pitada leve de HTML.

Fala aí, quem não já conhecia a tag H1 do HTML? kk

Para além de termos visto sobre as syscalls de rede socket, bind, listen e accept em Assembly.

Ainda não chegamos ao fim da saga, pelo que no próximo artigo iremos abordar a criação de threads e aprender sobre alocação dinâmica de memória para as threads.

Stay tuned!

Agradecimentos a Rodrigo Gonçalves de Branco por ter revisado este artigo com o devido rigor

Referências

Vamos iniciar transportando o "Hello, World" feito em código de máquina para assembly x86 e, posteriormente, abordar um exemplo de programa que recebe argumento da linha de comando.

Ao longo deste artigo vamos aprender a base de conceitos como rótulos, segmentos de memória, muito gdb, layout de memória, muita stack, procedures (subrotinas, ou funções), loops, condicionais, flags, tipos de registradores e etc

Aperte os cintos, pois este será um artigo bem extenso. Sugiro ao leitor, - que tem interesse em aprender na prática com esta saga -, que tenha o ambiente preparado e que execute cada exemplo seguindo os passos aqui descritos.

Sem mais delongas, vamos ao que importa.

Agenda

• Humanizar é preciso

  • Mnemonics

• Assemblers

• Nosso primeiro programa

  • A chamada de sistema exit
  • Arquivos Objeto
  • Linker

• Depurando o programa

  • O utilitário size
  • Debugging com gdb
  • Rastreando execução com strace

• Evoluindo nosso primeiro programa

  • Alocando bytes para "Hello, World"
  • Adicionando a chamada de sistema write
  • Layout de memória
  • Definindo constantes

• Um programa mais sofisticado

  • Definindo labels
  • Desvio de fluxo com jump
  • Desvio de fluxo com call
  • Brincando com pilhas
  • Calculando tamanho dinamicamente com loop
  • RFLAGS
  • Botando mais pilha no negócio
  • Depurando o programa final com strace

• Falando um pouco de registradores

  • Propósito dos registradores
  • Registradores de propósito geral
  • Registradores especiais
  • Precisamos sempre utilizar todos os 64 bits?

• Uma side note sobre stack frames

• Conclusão

• Referências

Antes de iniciar, quero novamente deixar uma menção especial ao excelente curso gratuito de Assembly x86 do Blau Araújo. É importante reforçar o quanto este material dele é necessário e foi crucial para que eu pudesse fundamentar diversos conceitos explorados ao longo desta saga

Humanizar é preciso

Como vimos no artigo anterior, CPU só entende código de máquina:

48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 0A  ; Hello, World

BF 01 00 00 00     ; RDI ⬅️ 1
48 BE 00 10 40     ; RSI ⬅️ 0x401000
BA 0D 00 00 00     ; RDX ⬅️ 13
B8 01 00 00 00     ; RAX ⬅️ 1
0F 05              ; SYSCALL
BF 00 00 00 00     ; RDI ⬅️ 0
B8 3C 00 00 00     ; RAX ⬅️ 60
0F 05              ; SYSCALL

Entretanto, para uma pessoa desenvolvedora manter um programa em código de máquina, é preciso ter muita paciência e atenção ao detalhe, pelo que também manter programas assim é muito propenso a bugs.

Precisamos de alguma forma, representar cada instrução em código de máquina em uma linguagem mais "human-friendly".

Mnemonics

É aí que entram os mnemonics, que são uma forma textual de representar informações visando facilitar a memorização para o cérebro humano.

Ao invés de trabalharmos com BF 01 00 00 00, podemos trocar por MOV RDI, 1, que significa:

estou movendo o valor imediato 1 para o registrador RDI

E assim vamos montando instrução por instrução, tal e qual faríamos com código de máquina, mas utilizando uma linguagem de fácil memorização.

Mas a CPU não entende essa "linguagem". Temos de construir um programa que faz a tradução de mnemonics para código de máquina, ou seja, de MOV RSI, 1 para BF 01 00 00 00.

Estamos falando de montadores, ou simplesmente assemblers.

Assemblers

Ao longo do tempo, foram desenvolvidos diversos assemblers para diferentes arquiteturas.

Para arquitetura x86, há diversos assemblers já construídos, GNU Assembler (as), NASM, FASM, pra mencionar alguns.

Assemblers para esta arquitetura em específico podem seguir 2 tipos de sintaxe que são predominantes:

• AT&T, desenvolvida pela AT&T corporation

• Intel, desenvolvida pela Intel

Nesta saga, vamos focar no Assembler NASM para arquitetura X86 64-bits (x64), com sintaxe Intel e rodando em sistema GNU/Linux, como já mencionamos algumas vezes em artigos anteriores.

• Arquitetura x86_64 (x64)

• Sistema Operacional GNU/Linux (Ubuntu)

• Assembler NASM 2.16.01

• GNU ld 2.38 (ligador, ou linker)

• Debugger GNU gdb 12.1

• strace 5.16 (tracing de syscalls)

Uma vez que definimos as ferramentas utilizadas, vamos seguir traduzindo o "Hello, World" para asm x86 enquanto entendemos o uso de cada uma delas.

A partir de agora, quando me referir a Assembly ou simplesmente "asm", leia-se Assembly x86_64

Nosso primeiro programa

Em Assembly, todo programa deve ter um ponto de entrada, também chamado de entry point:

global _start

_start:
	; código do programa vai aqui

E a primeira coisa que nosso programa vai fazer é sair:

kkkkkkkkkk

A chamada de sistema exit

Brincadeiras à parte, a chamada de sistema que precisamos executar é a exit, definida da seguinte forma no glibc:

void _exit(int status);

Com isto, temos de seguir a lógica para montar as instruções tal como fizemos com os opcodes, que seguindo a mesma tabela de syscalls, é:

• nome da syscall vai em RAX

• primeiro argumento (o status de erro) vai em RDI

global _start

_start:
	mov rdi, 0   ; error status
	mov rax, 60  ; nome da syscall: SYS_exit
	syscall       

Este programa simplesmente faz aquilo que mencionamos no artigo anterior: que todo programa deve terminar.

• mov rdi, 0 move o valor imediato 1 para o registrador RDI; vai representar o error code da syscall exit: 0 para término sem erros

• mov rax, 60 move o valor imediato 60 para o registrador RAX; vai representar o nome da syscall em si, exit

• syscall faz a chamada de sistema da syscall exit, definida em RAX

Para que o programa seja compilado, precisamos primeiro fazer a "montagem" das instruções com NASM:

$ nasm -f elf64 hello.asm -o hello.o

• -f elf64: arquitetura de destino, x64

• hello.asm input, ou seja, o arquivo que contém o código fonte

• -o hello.o: define saída para o arquivo hello.o

Mas o quê é este arquivo hello.o?

Arquivos objeto

Arquivo objeto (Object File) é um arquivo que contém código de máquina gerado por um assembler ou compilador.

Porém este arquivo ainda não é um executável final, porque podemos querer combinar com outros arquivos objeto e bibliotecas nativas do SO.

A partir deste arquivo, que geralmente tem a extensão .o, podemos utilizar outro programa para "ligar" com outros arquivos, se necessário, no intuito de gerar um arquivo com código de máquina final e executável.

Este programa se chama linker, pelo que utilizaremos a versão padrão do ld que vem com o GNU no nosso sistema operacional GNU/Linux.

Linker

Linker é o programa responsável por, a partir de um ou mais arquivos objeto, gerar um arquivo final executável com o código de máquina.

Como já geramos anteriormente o arquivo objeto hello.o utilizando o assembler NASM, podemos concluir o processo de compilação do nosso programa fonte asm x86 com ld

$ ld hello.o -o hello

E agora, vamos rodar o binário final executável hello:

$ ./hello
echo $?
0

Hurray! Nosso primeiro programa em Assembly concluído com sucesso!

Contudo, vamos lembrar de um ponto importante que vimos na parte II da saga: que o programa e seus dados ficam na memória. Queremos entender o que está acontecendo na memória com este simples programa.

Depurando o programa

Uma das etapas mais importantes, senão a mais importante, em desenvolvimento de software, é a depuração (ou debugging, em inglês).

Depurar é o ato de conseguir interceptar a execução do programa, analisar o estado, alterar o estado, adicionar pontos de parada (breakpoints) entre outras técnicas.

O processo de depuração também consiste em analisar a saída do programa como um todo, seu tamanho e trace de chamadas no sistema operacional.

O utilitário size

Vamos iniciar o processo de depuração do nosso programa analisando o tamanho, com o utilitário GNU size:

$ size hello

   text    data     bss     dec     hex filename
     12       0       0      12       c hello

Mas o quê significa "text, data, bss, etc"?

Cada programa no sistema operacional é dividido em seções, que representam alguma característica para o sistema operacional.

text Esta seção contém todo o código fonte do programa, e assim o SO sabe que precisa buscar esta seção na memória principal

data Seção de dados inicializados na memória

bss Seção de dados não-inicializados na memória

O comando size traz justamente o tamanho (em bytes) de cada seção.

dec e hex não são seções, são apenas a representação do valor total (em bytes) tanto em decimal quanto hexadecimal

• text: esta seção contém todo o código fonte do nosso programa, também chamado de "texto"

• data: seção de dados inicializados, logo a seguir neste artigos entramos em detalhe

• bss: seção de dados não-inicializados, logo a seguir também falaremos deste

• dec: o tamanho total em decimal

• hex: o tamanho total em hexadecimal

Nosso programa por enquanto só tem a seção text, que é exatamente todo o código a partir do rótulo _start.

Nossa, Leandro, nosso programa tem apenas 12 bytes?

Aparentemente sim. Vamos confirmar:

$ ls -lh hello

...... 4.6K ... hello

Como assim o arquivo tem 4,6Kb? O programa não ocupa 12 bytes apenas?

Bom, isto ocorre por causa dos headers que são adicionados pelo linker, que contém informação relevante para que o sistema operacional possa admitir a execução do arquivo.

Vamos novamente utilizar o comando size mas desta vez:

$ size --format sysv --radix 16 hello

hello  :
section   size       addr
.text    0xc   0x401000
Total    0xc

A opção --format indica o formato sysv que traz também os símbolos. E a opção --radix 16 permite visualizar o tamanho de cada seção em hexadecimal.

Na seção size, 0xc representa o número 12 em decimal. Nada de novo aqui. Mas se repararmos na coluna addr, temos um valor hexadecimal para a seção text (0x401000).

Já vimos isto no artigo anterior, que 0x401000 se referia ao endereço em hexadecimal de memória virtual que indica o início do programa, lembra?

Hora de confirmar isto com uma análise mais profunda na depuração, chegou o momento de utilizarmos GNU gdb.

Debugging com GDB

GDB é um depurador (debugger em inglês) que permite ver o que está acontecendo dentro de um programa em execução.

Com um depurador, podemos analisar as informações estáticas contidas no binário do programa, estabelecer breakpoints (pontos de parada) em qualquer parte do código, executar e analisar mudanças de estado do programa durante sua execução.

Para habilitar o programa com gdb, precisamos montar o programa com a opção -g, que exporta símbolos necessários para depuração:

$ nasm -g -f elf64 hello.asm -o hello.o
$ ld hello.o -o hello

Podemos verificar os símbolos exportados no binário com o comando size novamente:

$ size --format sysv --radix 16 hello

hello  :
section           size       addr
.text              0xc   0x401000
.debug_aranges    0x30        0x0
.debug_info       0x75        0x0
.debug_abbrev     0x1d        0x0
.debug_line       0x3d        0x0
Total            0x10b

##############

$ ls -lh hello
...... 5.1K ... hello

Como demonstrado acima, o binário agora contém seções adicionais de "debug" que serão utilizadas pelo gdb, e consequentemente o tamanho do programa teve um acréscimo de 500MB 512 bytes!

Sem mais delongas, vamos entrar no gdb:

$ gdb --quiet

(gdb)

E agora, dentro do shell gdb, podemos utilizar diversos comandos de depuração. O comando help traz a lista de classes de comandos disponíveis:

help

...
aliases -- User-defined aliases of other commands.
breakpoints -- Making program stop at certain points.
data -- Examining data.
files -- Specifying and examining files.
internals -- Maintenance commands.
obscure -- Obscure features.
running -- Running the program.
stack -- Examining the stack.
status -- Status inquiries.
support -- Support facilities.
text-user-interface -- TUI is the GDB text based interface.
tracepoints -- Tracing of program execution without stopping the program.
user-defined -- User-defined commands.
...

Para o escopo deste artigo vamos utilizar apenas alguns comandos para depuração, mas a lista de comandos disponíveis é gigante. Deixo o desafio ao leitor para se aventurar com o help do gdb e brincar de depurar qualquer binário executável

Como queremos depurar o binário hello, podemos carregar os símbolos utilizando o comando file:

(gdb) file hello
Reading symbols from hello...
(gdb)

O comando info files traz alguns insights:

(gdb) info files
Symbols from "/code/asm-x64/hello".
Local exec file:
        `/code/asm-x64/hello', file type elf64-x86-64.
        Entry point: 0x401000
        0x0000000000401000 - 0x000000000040100c is .text
(gdb)

Que interessante! O entry point do programa começa justamente em 0x401000, que é o que está definido na seção .text.

Para visualizar o código fonte do programa, utilizamos o comando list:

(gdb) list
1       global _start
2
3       _start:
4               mov rdi, 0   ; error code
5               mov rax, 60  ; SYS_exit
6               syscall
(gdb)

Lembrando que o programa ainda não está em execução, estamos apenas analisando o binário executável com o gdb

Com o comando x, de examine, podemos examinar o rótulo _start que é o ponto de entrada do programa:

(gdb) x _start
0x401000 <_start>:      0x000000bf
(gdb)

Se quisermos executar o programa, podemos fazê-lo com o comando run:

(gdb) run
Starting program: /code/asm-x64/hello
[Inferior 1 (process 7991) exited normally]
(gdb)

Entretanto, podemos definir breakpoints antes de executar, assim temos controle do estado do programa em execução:

# Aqui, definimos um ponto de parada no rótulo _start_
(gdb) break _start
Breakpoint 1 at 0x401000: file hello.asm, line 4.

# Info sobre breakpoints
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000000000401000 hello.asm:4
(gdb)

Agora sim, vamos executar:

(gdb) run
Starting program: /code/asm-x64/hello

Breakpoint 1, _start () at hello.asm:4
4               mov rdi, 0   ; error code
(gdb)

O programa está parado na linha 4 como solicitado. Esta linha no código não foi avaliada, pelo que podemos analisar e alterar o estado do programa:

# Neste momento o valor no registrador RDI está 0 (default)
(gdb) info register rdi
rdi            0x0                 0

# Mudamos o valor do registrador para 42
(gdb) set $rdi = 42

# Agora verificamos que foi modificado diretamente do GDB
(gdb) info register rdi
rdi            0x2a                42
(gdb)

Para avaliar a linha atual, utilizamos o comando next:

(gdb) next
5               mov rax, 60  ; SYS_exit

# E podemos agora verificar que o valor de RDI foi modificado para 0, 
# conforme descrito no programa
(gdb) info register rdi
rdi            0x0                 0
(gdb)

Poderíamos continuar indo linha a linha com next, ou então continuar a execução do programa com continue que pára no próximo ponto de parada ou executa todas as instruções que faltam até terminar o programa.

# Inicia execução e pára no primeiro breakpoint definido
(gdb) run
Starting program: /Users/leandronsp/Documents/code/asm-x64/hello

Breakpoint 1, _start () at hello.asm:4
4               mov rdi, 0   ; error code

# Continua execução. Neste caso termina o programa pois
# não há mais breakpoints a partir deste ponto
(gdb) continue
Continuing.
[Inferior 1 (process 8000) exited normally]
(gdb)

Pronto, terminamos a demonstração do primeiro programa com gdb. Para sair, utilizamos o comando exit.

Rastreando execução com strace

O utilitário strace permite rastrear todas as chamadas de sistema e sinais que um programa faz. É bastante útil quando queremos saber o que pode ter acontecido com determinada syscall, quais parâmetros foram enviados e o que a syscall retornou.

$ strace ./hello

execve("./hello", ["./hello"], 0x7ffc504b5710 /* 24 vars */) = 0
exit(0)                                 = ?
+++ exited with 0 +++

Vamos entender a saída do strace por partes.

execve("./hello", ["./hello"], 0x7ffc504b5710 / 24 vars /) = 0:

• execve é uma chamada do Linux que executa um determinado programa

• ./hello é o caminho para o programa que será executado

• ["./hello"] é a lista de argumentos passados para o programa. Como só há o nome do programa (que entra na lista ARGV), indica que este programa não recebe argumentos extras na linha de comando

• 0x7ffc504b5710 é o endereço de memória onde as variáveis de ambiente do processo em execução estão armazenadas

• /* 24 vars */ indica que há 24 variáveis de ambiente definidas no shell atual

• =0 é o resultado da chamada execve, o que significa que foi bem-sucedido e executado com sucesso

exit(0) = ?:

• exit é a chamada de sistema (syscall) feita no sistema operacional, e geralmente é definida no libc, sendo no caso de sistema GNU, glibc. Foi o valor 60 passado para o registrador RAX, lembra?

• (0) é o parâmetro passado para a função, que neste caso foi o que determinamos no registrador RDI, indicando que nosso programa em execução vai terminar sem erros

• = ? indica que o resultado da chamada de sistema não é conhecido, ou seja não houve um retorno explícito de valor da chamada de sistema

+++ exited with 0 +++:

• +++ sinaliza o início de uma mensagem de saída do strace

• exited with 0 indica que o programa terminou sem erros

• +++ sinaliza o fim da mensagem de saída

Uma vez que entendemos como depurar nosso programa, podemos evolui-lo para imprimir a mensagem "Hello, World" na saída do terminal.

Evoluindo nosso primeiro programa

Vamos agora evoluir o programa anterior para que possamos imprimir a mensagem "Hello, World" na saída padrão STDOUT.

Para isto, conforme vimos na parte III da saga, "Código de Máquina", vamos por partes.

Alocando bytes para "Hello, World"

Precisamos primeiro definir os bytes de cada caracter da string em hexadecimal de acordo com a tabela ASCII, que resulta em 48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 0A.

0x48 para "H", 0x65 para "e", 0x6C para "l" e assim por diante...

Portanto, se quisermos evoluir o primeiro programa que contém apenas a syscall exit, podemos começar por definir a string utilizando a diretiva db que significa define byte, utilizando o endereço do primeiro byte em um rótulo que iremos chamar de msg:

global _start

msg: db 0x48, 0x65, 0x6C, 0x6C, 0x6F, \
		0x2C, 0x20, 0x57, 0x6F, 0x72, \
		0x6C, 0x64, 0xA

_start:
	mov rdi, 0   ; error code
	mov rax, 60  ; SYS_exit
	syscall       

Antes de sair adicionando mais código, vamos utilizar o gdb para analisar o que esta mudança provoca na memória:

# Examinar o que há no rótulo msg
(gdb) x msg
0x401000 <msg>: 0x6c6c6548

# Examinar o que há no rótulo _start
(gdb) x _start
0x40100d <_start>:      0x000000bf
(gdb)

Ora ora, o que temos aqui?

• msg aponta para o endereço 0x401000 que era o endereço usado pelo _start no nosso programa anterior

• e agora _start aponta para outro endereço, 0x40100d que está 13 bytes ("d" em hexa) acima de msg, exatamente os 13 bytes da string "Hello, World" adicionado com quebra de linha!!!!!1

Superb! Mas o que significa o valor 0x6c6c6548?

Se analisarmos com calma, dá pra perceber que se trata dos caracteres da string em ASCII segundo o que foi definido no programa. Mas eles estão invertidos, lembra de endianness que foi explicado no artigo anterior?

Então, esta arquitetura segue o padrão little-endian, onde os bytes são armazenados na ordem inversa, do menos relevante (expoentes menores da base 2) para o mais relevante (expoentes maiores).

Voltando ao gdb, podemos confirmar que todos os bytes da string estão alocados trabalhando com ponteiros de 4 em 4 bytes:

(gdb) x msg
0x401000 <msg>: 0x6c6c6548 ; Hell

(gdb) x msg+4
0x401004:       0x57202c6f ; o, W

(gdb) x msg+8
0x401008:       0x646c726f ; orld

Ou então, o comando x permite passar uma quantidade junto com o formato de apresentação, por exemplo queremos que traga os primeiros 13 hexabytes a partir do ponteiro msg:

(gdb) x/13xb msg
0x401000 <msg>: 0x48    0x65    0x6c    0x6c    0x6f    0x2c    0x20    0x57
0x401008:       0x6f    0x72    0x6c    0x64    0x0a

Exatamente os hexadecimais da string "Hello, World" com quebra de linha!

Mas em Assembly, não precisamos definir os bytes de uma string em hexadecimal. Podemos utilizar os quotes literais, assim o programa fica menos verboso e o assembler faz o processo de traduzir o caracter para o hexadecimal da tabela ASCII:

msg: db "Hello, World", 0xA

Não conseguimos representar a quebra de linha dentro de quotes literais, então vamos manter esta com 0xA

Adicionando a chamada de sistema write

Como já sabemos, o programa precisa utilizar a syscall write para escrever na saída, que está definida da seguinte forma no glibc:

ssize_t write(int fd, const void buf[.count], size_t count);

• nome da syscall vai em RAX

• primeiro argumento (file descriptor, no caso o STDOUT) vai em RDI

• segundo argumento (ponteiro para o início do buffer) vai em RSI

• terceiro argumento (quantidade de bytes a serem escritos) vai em RDX

global _start

msg: db "Hello, World", 0xA
_start:
	;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
	; Chamada de sistema
	; glibc -> ssize_t write(int fd, 
							 const void buf[.count], 
							 size_t count)
	;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
	mov rdi, 1   ; STDOUT
	mov rsi, msg ; ponteiro para o início da string
	mov rdx, 13  ; quantidade de bytes a serem escritos
	mov rax, 1   ; nome da syscall: SYS_write
	syscall      ; chamada de sistema

	;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
	; Chamada de sistema
	; glibc -> void _exit(int status)
	;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
	mov rdi, 0   ; erro de saída
	mov rax, 60  ; nome da syscall: SYS_exit
	syscall           

Ao compilar o programa com nasm + ld, seguindo a mesma lógica do primeiro programa, temos de fato a saída tão desejada:

$ ./hello
Hello, World

Yay! que dia maravilhoso!

Vamos ver como fica o trace disso tudo agora?

$ strace ./hello

execve("./hello", ["./hello"], 0x7fff139437f0 /* 24 vars */) = 0
write(1, "Hello, World\n", 13Hello, World
)          = 13
exit(0)                                 = ?
+++ exited with 0 +++

Wow, podemos ver que, agora, o programa executa primeiro a syscall write, que retorna o valor 13, que é quantidade de bytes escritos com sucesso; e a seguir executa a syscall exit, também com sucesso, indicando que nosso programa imprime a string na saída e termina sem erros.

Como ficou o tamanho do programa agora?

$ size hello

   text    data     bss     dec     hex filename
     52       0       0      52      34 hello

Hmm, parece que a seção text aumentou de tamanho, que é a adição da string "Hello, World" e das instruções para a syscall write. Mas por enquanto é a única seção existente:

$ size --format sysv --radix 16 hello

hello  :
section           size       addr
.text             0x34   0x401000
(omitindo seções de debug)
Total            0x139

Podemos ver que a string definida no rótulo msg, que começa no endereço 0x401000 está contida na seção .text.

Isto é um problema?

Mais ou menos:

1. O rótulo msg , que é um "dado", contendo a string, está definido num endereço de memória anterior, ou seja, em endereço de memória mais baixo em direção a 0
2. O rótulo _start, que é o início do programa, está definido num endereço posterior, ou seja, em endereço de memória mais alto com relação à string

No sistema operacional, todo programa é encapsulado em um processo tal como vimos no artigo anterior. E sendo um processo, é submetido a um "layout" que deve seguir algumas regras.

Layout de memória

Fazendo paralelo com a saída do comando size, a memória do programa segue um layout, que basicamente contém as seguintes seções, ou segmentos de memória:

• text

• data

• bss

Já falamos disto anteriormente neste artigo, mas basicamente na seção text fica todo o código, instruções do programa.

Na seção data, ficam dados inicializados (aqui deveria estar a nossa string). E na seção bss vão os dados não-inicializados, mas já com uma área pré-alocada na memória.

Em termos de espaço virtual de memória do programa, a seção text deve ficar nos endereços de memória mais baixos, próximos ao entry point 0x401000.

Com isto, o programa deve crescer a partir da seção text em direção a data e bss, dos menores endereços de memória para os maiores (da esquerda pra direita):

text -> data -> bss

Ou então, analisando numa imagem em vertical, de baixo pra cima:

Existem mais seções no layout mas vamos adicioná-las à medida que avançamos no artigo. Por agora, como nosso programa está tratando dados (msg) como text, devemos colocar na seção correta, que é data:

global _start

; segmento de dados (endereços mais altos)
section .data
msg: db "Hello, World", 0xA

; segmento de texto (endereços mais baixos)
section .text
_start:
	mov rdi, 1   ; STDOUT
	mov rsi, msg ; ponteiro para o início da string
	mov rdx, 13  ; quantidade de bytes a serem escritos
	mov rax, 1   ; nome da syscall: SYS_write
	syscall      ; chamada de sistema

	mov rdi, 0   ; erro de saída
	mov rax, 60  ; nome da syscall: SYS_exit
	syscall  

Com gdb, podemos conferir que agora estamos obedecendo o layout de memória estabelecido para o programa:

(gdb) x _start
0x401000 <_start>:      0x000000bf

(gdb) x &msg
0x402000 <msg>: 0x6c6c6548
(gdb)

Note que para acessar msg no segmento de dados, precisamos examinar através da referência, com o operador &

Definindo constantes

Em Assembly podemos definir constantes que podem ser reutilizadas em diversas partes do programa, evitando assim alguma redundância com repetição de código e valores.

A diretiva %define permite definir valores constantes tanto para string quanto números:

global _start

%define SYS_write 1
%define SYS_exit 60
%define EXIT_STATUS 1
%define STDOUT 1
%define NEWLINE 0xA

section .data
msg: db "Hello, World", NEWLINE

section .text
_start:
	mov rdi, STDOUT
	mov rsi, msg 
	mov rdx, 13
	mov rax, SYS_write
	syscall      

	mov rdi, EXIT_STATUS
	mov rax, SYS_exit
	syscall  

Podemos também definir uma constante baseada em uma expressão aritmética. Por exemplo, ao invés de deixarmos o tamanho em bytes com valor fixo 13, podemos fazer que isto seja calculado com base em aritmética de ponteiros na memória com a diretiva equ:

...
section .data
msg: db "Hello, World", NEWLINE
msgLen: equ $ - msg
...

O operador $ tem o ponteiro de memória para o último byte no programa, no caso o NEWLINE definido na linha anterior. Ao subtrair do ponteiro msg com a expressão $ - msg, temos o tamanho em bytes calculado e desta forma não precisa ser um valor fixo em RDX:

global _start

%define SYS_write 1
%define SYS_exit 60
%define EXIT_STATUS 1
%define STDOUT 1
%define NEWLINE 0xA

section .data
msg: db "Hello, World", NEWLINE
msgLen: equ $ - msg

section .text
_start:
	mov rdi, STDOUT
	mov rsi, msg 
	mov rdx, msgLen
	mov rax, SYS_write
	syscall      

	mov rdi, EXIT_STATUS
	mov rax, SYS_exit
	syscall  

Wonderful! Nosso programa agora tá muito mais elegante!

Ufa, parece que terminamos o nosso primeiro programa e este por si só já foi uma jornada longa. Mas tenha um pouco mais de paciência, vem comigo, pois chegou o momento de escrevermos um programa um pouco mais sofisticado.

Hora de explorar mais funcionalidades no Assembly e entrar no mundo da stack.

Um programa mais sofisticado

Vamos começar por um programa simples e evoluindo conforme depuramos e entendemos a memória. Ao fim, o programa deve ser capaz de receber um nome através dos argumentos da linha de comando e imprimir "Hi, <nome>".

Desejado:

$ ./greeting Leandro
Hi, Leandro

Definindo labels

Já sabemos que o programa precisa imprimir "Hi, " alguma coisa. Então as instruções pra syscall write são necessárias, e já fazendo uso de constantes:

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi", 0xA

section .text
_start:
	mov rdi, STDOUT
	mov rsi, greet
	mov rdx, 3
	mov rax, SYS_write
	syscall
	
	mov rdi, 0
	mov rax, SYS_exit
	syscall

Este programa imprime "Hi" apenas. Mas podemos melhorar a organização separando em blocos com algum valor semântico:

• separar o bloco de exit

• separar o bloco de write

Assembly emprega o conceito de labels, que são rótulos, mas que podem ser definidas em qualquer parte do código. Utilizando o caracter ponto (.), o programa fica bem mais expressivo:

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi", 0xA

section .text
_start:
.print:
	mov rdi, STDOUT
	mov rsi, greet
	mov rdx, 3
	mov rax, SYS_write
	syscall
.exit:
	mov rdi, 0
	mov rax, SYS_exit
	syscall

Assim como qualquer rótulo, o programa vai executando top-down. O que fizemos aqui foi apenas colocar rótulos em determinadas partes do programa, mas sem alterar seu fluxo de execução.

Desvio de fluxo com jump

Se quisermos alterar o fluxo de execução, podemos utilizar a instrução JMP que altera o fluxo do programa para outro ponto, continuando a partir desde novo ponto.

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi", 0xA

section .text
_start:
	; Faz o jump para a label .print, sem passar por .exit
	jmp .print
.exit:
	mov rdi, 0
	mov rax, SYS_exit
	syscall
.print:
	mov rdi, STDOUT
	mov rsi, greet
	mov rdx, 3
	mov rax, SYS_write
	syscall
	
	; Faz o jump para a label .exit, caso contrário o programa não terminaria
	; da forma adequada (todo programa deve terminar)
	jmp .exit

Este foi um exemplo bastante simples com jump e desvio de fluxo. Mas é possível também desviar o fluxo, executar a lógica do novo fluxo, e retornar ao ponto anterior.

Entretanto, para que isto funcione, vamos imaginar uma possível solução:

• definir algum registrador "especial" que guarda sempre o ponteiro da próxima instrução

• antes de desviar o fluxo, guardar o endereço de memória da próxima instrução do programa em alguma estrutura de dados para que possa ser resgatado quando a lógica do desvio terminar

Sim, estamos falando do desvio com call, ret, registradores e pilha.

Desvio de fluxo com call

Tendo o exemplo anterior, ao invés de fazer jmp, vamos utilizar a instrução call que faz o desvio para outra rotina:

call .print  ; <------ chamada da rotina

Além disso, a última linha da rotina .print deve "retornar" o fluxo desviado para o ponto anterior.

.print:
	mov rdi, STDOUT
	mov rsi, greet
	mov rdx, 3
	mov rax, SYS_write
	syscall
	ret  ; <------ retorno da rotina

Antes de analisarmos com gdb passo a passo, precisamos entender um aspecto importante dos programas no sistema operacional.

Quando um programa é executado, ele é definido em uma estrutura chamada processo (já falamos disto no artigo anterior). Todo processo carrega o layout de memória definido no binário do programa, conforme vimos anteriormente:

text -> data -> bss

Nos endereços mais altos da memória virtual do processo (programa em execução), o sistema operacional também define uma outra estrutura de dados, chamada stack, que tem um formato de pilha (LIFO, Last In, First Out).

text -> data -> bss ---------> <-------- stack

A stack fica nos endereços mais altos e carrega informações como argumentos do programa, lista de variáveis de ambiente definidas no shell, argumentos para funções entre qualquer informação pertinente para o programa. Stack sempre cresce para baixo em direção aos endereços menores.

rsp Em um programa Assembly x86, é preciso armazenar o ponteiro atual do topo da stack, e esta informação fica no registrador RSP, ou stack pointer.

rip Já o ponteiro da instrução atual fica no registrador RIP, ou instruction pointer.

Com estes dois registradores conseguimos demonstrar o uso de call e ret para desvio de fluxo. Voltando ao programa:

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi", 0xA

section .text
_start:
	call .print     ; <--------- desvio do fluxo
	
	; aqui neste ponto, já continua a execução normal em direção ao exit
	; para terminar o programa
.exit:
	mov rdi, 0
	mov rax, SYS_exit
	syscall
.print:
	mov rdi, STDOUT
	mov rsi, greet
	mov rdx, 3
	mov rax, SYS_write
	syscall
	ret            ; <---------- retorno ao ponto anterior

E agora demonstrando com gdb:

$ gdb greeting

# Breakpoint em _start, início do programa
(gdb) break _start_
(gdb) run

# RIP apontando para 0x401000 (_start), o entry point do programa
(gdb) info register $rip
rip            0x401000            0x401000 <_start>

# RSP apontando para um endereço de memória
# Se formos examinar com x $rsp, temos
# 0x7fffffffe450: 0x00000001, que é a quantidade de argumentos
# passados, no caso 1 representa apenas o nome do programa, ou seja
# não há argumentos na linha de comando
(gdb) i r $rsp
rsp            0x7fffffffe450      0x7fffffffe450

Até aqui okay, agora vamos andar um step para que o desvio de call seja avaliado e analisar o RIP:

(gdb) step
18              mov rdi, STDOUT

# O RIP andou conforme esperado
(gdb) i r $rip
rip            0x401011            0x401011 <_start.print>

# RIP apontando para 0x000001bf, que é BF 01 00 00 
# Lembra? é o opcode pra MOV RDI, 1
# Exatamente onde paramos
(gdb) x $rip
0x401011 <_start.print>:        0x000001bf

E a stack (RSP) como ficou?

# A pilha andou alguns bytes (no caso foi feito um "push", o que a fez crescer para endereços de memórias menores)
# Lembra? Pilha "cresce pra baixo" na memória
(gdb) i r rsp
rsp            0x7fffffffe448      0x7fffffffe448

# Opaaa, o que temos aqui? 0x00401005
# É alguma pista...
(gdb) x $rsp
0x7fffffffe448: 0x00401005

# Examinando o ponteiro do início do programa...
(gdb) x _start
0x401000 <_start>:      0x00000ce8

# Se andarmos alguns bytes, 
# temos exatamente o endereço da label .exit, 0x401005
(gdb) x _start + 5
0x401005 <_start.exit>: 0x000000bf

Se você prestou atenção nos comentários do snippet acima...

É muito importante prestar atenção em todos os comentários, se não estiver fazendo isso, volte o artigo do início e tente acompanhar no terminal, é extremamente importante para entender os conceitos

...se prestarmos a devida atenção, este é o endereço que tá no topo da pilha agora, que foi adicionado pela instrução call.

Ok Leandro, mas como fazemos então para voltar ao ponto anterior?

Calma, jovem. Estamos parados no início da rotina .print. Vamos continuar a depuração com gdb até parar em ret:

(gdb) next
19              mov rsi, greet
(gdb) next
20              mov rdx, 3
(gdb) next
21              mov rax, SYS_write
(gdb) next
22              syscall
(gdb) next
Hi
_start.print () at greeting.asm:23
23              ret
(gdb)

Nice, antes de avaliar a instrução ret, podemos ver que RIP andou mas RSP continua na mesma, com o endereço da próxima instrução antes do desvio:

# RIP aponta para a instrução da linha "ret"
(gdb) x $rip
0x40102c <_start.print+27>:     0x000000c3

# RSP aponta para o endereço de memória que está a instrução .exit, que
# vem a seguir ao desvio feito com "call" lá em cima
(gdb) x $rsp
0x7fffffffe448: 0x00401005

Vamos andar com ret e....

# RIP agora aponta para 0x401005, que é a instrução .exit
(gdb) x $rip
0x401005 <_start.exit>: 0x000000bf

# Foi feito "pop" em RSP e agora este aponta para o topo da pilha
# com o valor exato quando estava no início do programa
(gdb) x $rsp
0x7fffffffe450: 0x00000001
(gdb)

OMG!! Acabamos de demonstrar manipulação de registradores e pilhas.

Brincando com pilhas

Pilhas é divertido.

Mas prefiro filas, gosto de tratar as coisas de modo ordenado. Quem chega primeiro precisa ser atendido primeiro kkkkkkkk

Mas com pilhas não é assim. Quem entra por último sai primeiro.

Com base nisto, como podemos manipular a stack do programa? Vamos alterar um pouco o código adicionando o ponteiro de greet na stack:

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi", 0xA

section .text
_start:
	push greet    ; <----- adiciona o ponteiro de greet na stack
	call .print
.exit:
	mov rdi, 0
	mov rax, SYS_exit
	syscall
.print:
	mov rdi, STDOUT
	mov rsi, greet
	mov rdx, 3
	mov rax, SYS_write
	syscall
	ret

No gdb, vamos colocar um breakpoint na linha da chamada call:

# Breakpoint na linha 13
(gdb) b 13
Breakpoint 1 at 0x401005: file greeting.asm, line 13.

# Run
(gdb) r

# Examinando o topo da pilha
(gdb) x $rsp
0x7fffffffe448: 0x00402000

# Examinando o endereço de memória que tá no topo da pilha
(gdb) x 0x00402000
0x402000 <greet>:       0x2c0a6948

Cool, temos 0x48 0x69 0x0A (little-endian), exatamente a string "Hi" seguida de uma quebra de linha. Com esta rica informação, ao invés da rotina .print passar pro registrador RSI o ponteiro de greet, porque não passar o ponteiro do topo da pilha?

Algo nessa linha:

; ao invés disso (atual)
mov rsi, greet

; que tal mover o ponteiro que tá em rsp (topo da pilha) para rsi
mov rsi, rsp

Por enquanto, seguramos esta ideia no bolso. Ainda no gdb, vamos continuar analisando a pilha depois de entrar na rotina:

(gdb) step
_start.print () at greeting.asm:19

# Agora o topo da pilha foi modificado, "call" colocou o endereço de 
# memória da próxima instrução quando voltar do "ret"
(gdb) x $rsp
0x7fffffffe440: 0x0040100a

# O endereço de memória aponta justamente pra próxima instrução quando voltar do "ret", no caso a instrução que tá na label .exit do programa
(gdb) x 0x0040100a
0x40100a <_start.exit>: 0x000000bf

Mas agora o topo da pilha estraga nossa ideia de fazer mov rsi, rsp, mas podemos fazer aritmética com ponteiros e mover o conteúdo resultante, e é muito fácil:

# Topo da pilha apontando pra instrução guardada pelo "call"
(gdb) x $rsp
0x7fffffffe440: 0x0040100a

# Topo da pilha + 8 bytes apontando pro endereço onde tá a string "Hi"
(gdb) x $rsp+8
0x7fffffffe448: 0x00402000

Nesta arquitetura, a pilha, assim como os registradores, armazenam por padrão até 8 bytes por cada informação

Então teoricamente, tudo o que precisamos é mov rsi, [rsp + 8]

Note que é preciso usar [rsp + 8], com square brackets é uma forma de fazermos aritmética de ponteiros e acessar o valor resultante da operação na memória, no caso o endereço apontando para a string "Hi"

Para finalizar este primeiro exemplo, é muito importante fazermos "pop" da pilha. Todo push deve ter um pop, caso contrário podemos gastar a pilha desnecessariamente e talvez chegar a um stack overflow se exagerarmos bastante.

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi", 0xA

section .text
_start:
	push greet             ; <----- push na pilha
	call .print
	pop rbp                ; <----- pop da pilha, jogando o valor em rbp
	                       ; note que rbp é outro registrador de propósito geral,
	                       ; mas que é utilizado para manter a base da pilha
.exit:
	mov rdi, 0
	mov rax, SYS_exit
	syscall
.print:
	mov rdi, STDOUT
	mov rsi, [rsp + 8]     ; <----- 8 bytes depois do topo da pilha está o
	                       ; endereço de memória da string
	mov rdx, 3
	mov rax, SYS_write
	syscall
	ret

Podemos reparar 2 coisas:

• A rotina .print está ficando bastante genérica, ou seja ela não sabe o que está na pilha, simplesmente move para o registrador RSI e faz a syscall write

• A rotina .print ainda usa o tamanho em bytes como valor fixo, no caso 3 bytes. Deveria ser dinâmico também se quisermos fazer com que esta rotina seja bem genérica

Colocamos o tamanho também na pilha? Nah, seria mais interessante ainda se calculássemos dinamicamente o que vem da pilha. Para fazer este cálculo, teríamos que "iterar", em forma de loop, por cada byte que queremos imprimir, incrementar em um registrador e utilizar isto na syscall.

Vamos entrar no mundo dos loops e condicionais.

Calculando tamanho dinamicamente com loop

Combinando labels e jumps, podemos criar um loop em assembly, como neste pequeno exemplo a seguir:

; Um loop infinito sem condição de parada
; Não façam isso

global _start

_start:
.loop
	jmp .loop

Entretanto para adicionarmos uma condição de parada do loop, é necessário utilizar uma instrução de comparação e outra que muda algum estado.

No nosso exemplo, vamos introduzir um loop que calcula o tamanho da string antes de fazer a syscall. Entendendo a necessidade:

; Pseudo-code

.print:
	mov rdi, STDOUT
	mov rsi, [rsp + 8]   ; string em RSI     
	                       
	mov rdx, ?           ; <--- aqui devemos introduzir um loop que vai
	                     ; modificando o valor de RDX, lendo byte a byte
	                     ; o conteúdo da string
	mov rax, SYS_write
	syscall
	ret

Para resolver isto, podemos criar uma label chamada .calculate_size que contém um jmp para ela mesma:

.print:
	mov rsi, [rsp + 8]       ; string em RSI 
	mov rdx, 0               ; RDX começa em 0
.calculate_size:             ; label
	jmp .calculate_size      ; jmp "recursivo"
.done:
	mov rdi, STDOUT
	mov rax, SYS_write
	syscall
	ret

Ao rodarmos o programa, obviamente caímos em loop infinito. Precisamos definir uma condição de parada, que consiste em:

• mudar o estado de alguma variável condicional

• desviar o fluxo para outra label quando a condição for verdadeira

Em Assembly, podemos fazer a mudança de estado utilizando a instrução inc:

.print:
	mov rsi, [rsp + 8]     
	mov rdx, 0             ; RDX (contador) começa em 0
.calculate_size:
	inc rdx                ; incrementa o valor que está em RDX (linha 23)
	jmp .calculate_size
.done:
	mov rdi, STDOUT
	mov rax, SYS_write
	syscall
	ret

Com gdb, verificamos que o valor de RDX está sempre sendo incrementado:

# Adicionar breakpoint na linha 23 (<<inc rdx>>)
(gdb) break 23
Breakpoint 1 at 0x401021: file live.asm, line 23.

# Executar o programa, que vai no primeiro breakpoint
(gdb) run
Breakpoint 1, _start.calculate_size () at live.asm:23
23              inc rdx

# Continuar execução até o próximo breakpoint ou fim do programa.
# Mas como estamos em loop, o programa vai parar de novo nesta linha
(gdb) continue

# Atalho para "info register rdx"
(gdb) i r rdx
rdx            0x1                 1

# Próxima iteração...
(gdb) continue
(gdb) i r rdx
rdx            0x2                 2

# E assim infinitamente pois não temos ainda a segunda premissa da condição de parada, que é a condicional
(gdb) continue
(gdb) i r rdx
rdx            0x19                25

Como podemos elaborar esta condicional, uma vez que o valor em RDX pode ser infinito, logo ter todas as possibilidades?

Uma ideia é irmos consumindo byte a byte da string até chegar a zero. Para isto, podemos definir o fim da string com 0x0 e fazer aritmética binária na própria string, consumindo os bytes até chegar a 0x0!

Eis o exemplo com um pseudo-código:

; "Hi", 0 
; que em hexabyte fica 0x49, 0x69, 0x00

INCREMENT
0x69 0x00   ; consumiu o byte mais à esquerda 0x49

INCREMENT   ; consumiu o byte mais à esquerda 0x69
0x00 0x...

Nossa Leandro, que fantástico! Podemos então fazer inc em um registrador que contém a string, nesse caso o próprio RSI?

Isso mesmo!

.....
section .data
greet: db "Hi", 0xA, 0      ; <--- adicionamos o "zero" para identificar o 
                            ; fim da string

.....

.print:
	mov rsi, [rsp + 8]     
	mov rdx, 0
.calculate_size:
	inc rdx                 ; incrementa o valor inteiro em RDX (contador)
	inc rsi                 ; <--- além de incrementar o RDX, incrementamos
	                        ; também o RSI, que contém o endereço de
	                        ; memória para a string. Aritmética em hexabytes
	                        ; vai fazer o efeito de "consumir os bytes até zero
	jmp .calculate_size
.done:
	mov rdi, STDOUT
	mov rax, SYS_write
	syscall
	ret

Agora, com gdb, vamos verificar o que está acontecendo com nosso programa:

# Breakpoint na linha <jmp .calculate_size>
(gdb) break 25
Breakpoint 1 at 0x401027: file live.asm, line 25.

(gdb) run

# Cool, o contador RDX foi incrementado
(gdb) i r rdx
rdx            0x1                 1

# Em RSI, temos outro endereço de memória.
# Anteriormente era o início da string, 0x402000, mas agora está
# apontando para 0x402001
(gdb) i r rsi
rsi            0x402001            4202497

# Wow! Temos os bytes da string "i", seguido de "\n", e depois o 0x00
# Parece que o inc RSI funcionou como esperávamos?
(gdb)x /4xb 0x402001
0x402001:       0x69    0x0a    0x00    0x2c

# A vida continua...
(gdb) continue

# Caminho mais curto
# E parece que RSI andou mais ainda, agora apontando para o byte "\n"
(gdb) x $rsi
0x402002:       0x0a

# A vida continua...
(gdb) continue

# O nosso grande momento! Agora RSI aponta para 0x00
(gdb) x $rsi
0x402003:       0x00

Tudo o que precisamos fazer, neste momento, é comparar o valor que está em RSI com zero. Se chegou a zero, significa que podemos parar o loop. Vamos verificar o que está no contador RDX (esperamos que seja 3):

(gdb) i r rdx
rdx            0x3                 3

Yay! Que grande momento!

Mas como verificar em Assembly se chegou ou não no valor? Existe "IF" e "ELSE" em Assembly?

Hell no!

Não. Não tem "IF" e "ELSE" em Assembly.

Uma possível solução seria:

• utilizar uma instrução que compare o valor de um registrador ou em algum endereço de memória com qualquer outro valor

• esta instrução iria guardar o resultado da comparação em outro registrador "especial"

• utilizar outra instrução para fazer desvio do fluxo de acordo com o valor que estive neste registrador especial

Sim, é aí que entramos no tal do registrador RFLAGS.

RFLAGS

O registrador de flags é um registrador de status que mantém sempre o estado atual da CPU, neste caso estamos referindo a uma CPU x86_64, pelo que chamamos este registrador de RFLAGS.

Este registrador guarda opcodes condicionais, que são resultado de diversas operações lógicas e aritméticas que afetam o estado da CPU.

Voltando ao nosso exemplo, podemos comparar o registrador RSI com o valor 0, e então verificar o que está acontecendo com o registrador eflags:

.print:
	mov rsi, [rsp + 8]     
	mov rdx, 0
.calculate_size:
	inc rdx
	inc rsi
	cmp byte [rsi], 0x00   ; <-- aqui comparamos (em byte) o valor que está
	                       ; em RSI com o byte 0x00
	jmp .calculate_size
.done:
	mov rdi, STDOUT
	mov rax, SYS_write
	syscall
	ret

E com isto podemos conferir com gdb:

# Breakpoint na linha <cmp byte [rsi], 0x00>
(gdb) break 25

(gdb) run

# O que temos no primeiro byte de RSI? "i", pois o "H" já foi
# consumido no <inc rsi>
(gdb) x /1xb $rsi
0x402002:       0x69

# E no eflags?
# Nossa, temos o IF que estávamos precisando!!!!!11
(gdb) i r eflags
eflags         0x202               [ IF ]

Calma jovem, IF não é o que você está pensando!

IF é uma flag chamada interrupt flag, que está sempre presente no programa em execução. Ela determina se o programa pode ou não sofrer interrupções de hardware. No nosso caso, está sempre habilitada por padrão, e é por este motivo que podemos fazer chamadas de sistema (syscalls).

Continuando no gdb...

(gdb) continue

# O que temos em RSI? "\n"
(gdb) x /1xb $rsi
0x402002:       0x0a

# Executar a instrução <cmp byte [rsi], 0x00>
(gdb) next

# Ok, segunda iteração continua na mesma, sem flags adicionais
(gdb) i r eflags
eflags         0x202               [ IF ]

######## Próxima iteração ##########

(gdb) continue

# O que temos em RSI? 0x00, cool.
(gdb) x /1xb $rsi
0x402003:       0x00

# Executar a instrução <cmp byte [rsi], 0x00>
(gdb) next

# Outras flags foram adicionadas ao estado: PF e ZF
(gdb) i r eflags
eflags         0x246               [ PF ZF IF ]

PF é a parity flag, que é adicionada quando uma operação aritmética em qualquer registrador resulta em paridade ímpar.

Não é do escopo deste artigo entrar em detalhes sobre PF, sugiro a leitura sobre o assunto

Já a ZF é chamada zero flag, adicionada quando uma operação aritmética resulta em zero, que é exatamente o que estamos buscando aqui.

Agora o que precisamos é desviar o fluxo (lembra do jmp) quando a flag zero está presente. Para isto, temos a disposição diversas instruções de jump baseadas em flags:

• jz (jump if zero)

• jnz(jump if not zero)

• je (jump if equal)

• jne (jump if not equal)

Isto pra mencionar apenas algumas, existem muitas outras que podem ser consultadas aqui

Com isto, a instrução que precisamos é a jz, que verifica se a flag ZF está presente:

.print:
	mov rsi, [rsp + 8]     
	mov rdx, 0
.calculate_size:
	inc rdx
	inc rsi
	cmp byte [rsi], 0x00     ; <--- compara RSI com 0x00. Adiciona a flag ZF                                  ; quando chegar a zero
	jz .done                 ; <--- desvia fluxo para a label ".done" caso a
	                         ; flag ZF esteja presente
	jmp .calculate_size
.done:
	mov rdi, STDOUT
	mov rax, SYS_write
	syscall
	ret

Com gdb, colocamos o breakpoint na linha mov rdi, STDOUT que é depois do loop. Caso o programa fique parado nesta linha, significa que o loop foi concluído com sucesso e os bytes da string devidamente calculados:

# Breakpoint na linha <mov rdi, STDOUT>
(gdb) break 29

(gdb) run

# Olha o que temos aqui
(gdb) i r rdx rsi
rdx            0x3                 3
rsi            0x402003            4202499

# E se formos examinar a string (com x/s) em RSI, temos isto:
(gdb) x/s $rsi
0x402003:       ""

• Em RDX, temos o contador, que está em 3, que é a quantidade de bytes que será passada como terceiro argumento da syscall write. Okay, aqui ficou tudo certo.

• Em RSI, temos 0x402003, e o valor está vazio, ou 0x00. Isto é um problema

O problema reside no fato de que RSI precisa ter o ponteiro para a string em si, e as operações de inc rsi modificaram o registrador, pelo que não queremos que isto aconteça.

Podemos então inicialmente mover o valor que está em RSI para outro registrador temporário, que pode ser um daqueles registradores de rascunho, chamados de draft registers:

.print:
	mov rsi, [rsp + 8]     
	mov r9, rsi          ; aqui preservamos RSI, movendo o valor para R9
	mov rdx, 0
.calculate_size:
	inc rdx
	inc r9               ; incrementar o valor em R9, preservando assim RSI
	cmp byte [r9], 0x00  ; comparar 0x00 com R9, e não mais RSI
	jz .done
	jmp .calculate_size
.done:
	mov rdi, STDOUT       
	mov rax, SYS_write
	syscall              ; no momento da syscall, RSI está intacto, contendo
	                     ; o ponteiro para o endereço de memória onde está
	                     ; localizada a nossa queridíssima string "Hi"
	ret

Após estas alterações, vamos executar o programa completo:

./greeting
Hi

Que dia maravilhoso! Nosso programa imprime a string "Hi" calculando dinamicamente o tamanho dos bytes da string!

Entretanto, queremos implementar a proposta inicial, não é, Leandro? O programa não tem que ler o nome da linha de comando e imprimir "Hi, Leandro"?

Botando mais pilha no negócio

Nosso objetivo é chamar ./greeting com argumento e assim o programa deve imprimir Hi, com o argumento enviado:

# Objetivo, isto ainda não funciona
./greeting Leandro
Hi, Leandro

Se pensarmos um pouco, podemos inferir que qualquer argumento pode ser armazenado na stack do processo, que é quando o programa está em execução.

Com gdb, podemos confirmar isto:

# Breakpoint na primeira linha do programa, depois do _start
(gdb) break 12

# Executa o programa com o argumento "Leandro"
(gdb) run Leandro

# Onde estará Leandro? Na pilha? (rsp)
#      -> x de examine
#      -> /8xb os primeiros 8 hexa bytes
(gdb) x /8xb $rsp
0x7fffffffe450: 0x02    0x00    0x00    0x00    0x00    0x00    0x00    0x00

Mas o quê significa esse número 2? Vamos examinar a stack e a ordem das informações contidas nela.

Voltando ao gdb, e se lermos os próximos 8 bytes na stack?

(gdb) x /8xb $rsp + 8
0x7fffffffe458: 0xb1    0xe6    0xff    0xff    0xff    0x7f    0x00    0x00

Lembrando que os bytes são escritos na stack em formato little-endian, ou seja estão invertidos

Com isto, temos um hexadecimal 0x7fffffffe6b1. Parece um endereço de memória, não?

# Examinando o endereço de memória no formato de string (/s)
(gdb) x /s 0x7fffffffe6b1
0x7fffffffe6b1: "/Users/..../code/asm-x64/live"

Wow, temos o primeiro argumento, também chamado de ARG0 que é o nome do programa com o caminho absoluto no sistema operacional.

Andando mais 8 bytes...

# Endereço de memória...
(gdb) x /8xb $rsp + 16
0x7fffffffe460: 0xdf    0xe6    0xff    0xff    0xff    0x7f    0x00    0x00

# Examinando o valor que está no endereço
(gdb) x /s 0x7fffffffe6df
0x7fffffffe6df: "Leandro"

Yay! Temos o nosso argumento, armazenado na stack. É o primeiro argumento, também chamado de ARG1.

Se continuarmos andando na stack de 8 em 8 bytes, vamos passar por todos os argumentos (no nosso caso não há mais), e a seguir vamos chegar no vetor ambiente, que contém todas as variáveis de ambiente contidas no shell que está executando o nosso programa

Com isto, sabemos que o primeiro argumento está localizado em rsp + 16:

• rsp: quantidade de argumentos

• rsp + 8: ARG0, nome do programa

• rsp + 16: ARG1, primeiro argumento (se existir)

• rsp + 24: ARG2, segundo argumento (se existir)

• e assim sucessivamente...até chegar no vetor de variáveis de ambiente (vetor ambiente)

Sabendo que nossa sub-rotina .print já recebe uma string da stack e calcula dinamicamente o tamanho da string que foi passada, podemos passar pro topo da stack o nosso argumento (que por acaso também está na stack), e em seguida chamada a rotina .print novamente:

section .data
greet: db "Hi, ", 0

_start:
	push greet      
	call .print     
	pop rbp     

	; aqui fazemos push pro topo da stack o valor que está em RSP + 16 (ARG1)
	; utilizamos o tipo "qword" que significa "quadword"
	push qword [rsp + 16]
	call .print
	pop rbp
...

O quê significa quadword? Em assembly podemos definir tipos de bytes, que basicamente são grupos de bytes, podendo ou não caber em um registrador ou stack dependendo da arquitetura da CPU.

• byte: especifica 1 byte (8-bit)

• word: 2 bytes (16-bit)

• dword: 4 bytes (32-bit)

• qword: 8 bytes (64-bit)

• tbyte: 10 bytes

Na arquitetura x86_64, precisamos especificar que o tipo de byte adicionado na stack, quando não vier de um registrador mas sim de um lugar arbitrário na memória ou stack, tem um determinado tamanho em bytes.

Neste caso, estamos utilizando qword que é justamente 8 bytes (ou 64-bit) que representa a arquitetura em questão.

Precisamos adicionar mais um caracter, que é o newline, ou \n, no fim da mensagem. Para isto, podemos definir um dado inicializado e chamar a rotina .print , que já está bem "crescidinha", não?

Programa completo, com comentários:

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi, ", 0
newline: db 0xA, 0

section .text
_start:
	push greet             ; adiciona "Hi, " na stack para print
	call .print     
	pop rbp         

	push qword [rsp + 16]  ; adiciona ARG1 na stack para print
	call .print
	pop rbp

	push newline           ; adiciona newline na stack para print
	call .print
	pop rbp
.exit:                     ; label de término do programa
	mov rdi, 0
	mov rax, SYS_exit
	syscall
.print:                    ; rotina de print no STDOUT
	mov rsi, [rsp + 8]     
	mov r9, rsi
	mov rdx, 0
.calculate_size:           ; loop para calcular tamanho da string
	inc rdx
	inc r9
	cmp byte [r9], 0x00
	jz .done
	jmp .calculate_size
.done:                     ; label para finalizar a rotina print e retornar
	mov rdi, STDOUT
	mov rax, SYS_write
	syscall
	ret

Rodamos o programa e:

./greeting Leandro
Hi, Leandro

OMG! Eu não estou acreditando no que estou vendo!!!!!11

Depurando o programa final com strace

Com strace, podemos fazer o trace de syscalls do programa final. Olha que maravilha isto:

$ strace ./greeting Leandro

execve("./greeting", ["./greeting", "Leandro"], 0x7ffc30f75368 /* 24 vars */) = 0
write(1, "Hi, ", 4Hi, )                     = 4
write(1, "Leandro", 7Leandro)                  = 7
write(1, "\n", 1
)                       = 1
exit(0)                                 = ?
+++ exited with 0 +++

Foram feitas 4 chamadas de sistema, sendo:

• 1 write, "Hi, "

• 1 write "Leandro"

• 1 write "\n"

• 1 exit

Falando um pouco de registradores

Até o momento, vimos durante este artigo a utilização de alguns registradores que foram muito úteis para o desenvolvimento do programa, dentre eles RSI, RAX, RDX, RSP, RIP, RFLAGS e assim por diante.

Mas qual o propósito de cada registrador? Posso usar qualquer registrador para qualquer operação, de forma aleatória?

De forma prática, sim. Mas nem sempre convém.

Nada impede que o teu programa coloque qualquer valor em um registrador arbitrário. Por exemplo, com gdb vamos alterar alguns registradores e ver como o programa se comporta:

# Breakpoint & run
(gdb) break 13
(gdb) run Leandro

# Vamos alterar alguns registradores arbitrários
(gdb) set $rax = 42
(gdb) set $rdx = 33

# Confirmando que foram modificados
(gdb) i r rax rdx
rax            0x2a                42
rdx            0x21                33

# Continuando...
(gdb) continue
Continuing.
Hi, Leandro
[Inferior 1 (process 19231) exited normally]

Okay, podemos ver que ter mudado estes registradores para qualquer valor não impactou o programa. No meio do programa, provavelmente eles são sobrescritos novamente e utilizados de acordo com determinada lógica.

Mas e se alterarmos, por exemplo, um registrador como o rip, que é o ponteiro da próxima instrução?

# Breakpoint & run
(gdb) break 13
(gdb) run Leandro

# Antes de alterar o RIP, podemos ver qual o valor ele carrega,
# que é o ponteiro da próxima instrução
(gdb) i r rip
rip            0x401000            0x401000 <_start>

# Vamos alterar o registrador RIP
(gdb) set $rip = 42

# Confirmando que foi alterando
(gdb) i r rip
rip            0x2a                0x2a

# Continuando...
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x000000000000002a in ?? ()

Ouch! Agora o programa não pôde ser finalizado com sucesso. Confirmamos então que nem sempre convém mudar os registradores sem haver algum critério.

Propósito dos registradores

Os registradores, e falando especificamente da arquitetura x86, seguem um propósito original para o qual foram designados. Mas também podem ser utilizados em convenções de chamadas de sistema tal como vimos na montagem das syscalls write e exit, e neste caso a utilização correta importa bastante.

E além disso, alguns registradores contém dados importantes para a execução do programa, tais como o rip e eflags.

• Propósito original

• Convenções de chamadas

• Funcionamento crítico do programa

Apesar destas características importantes de uso dos registradores, podem haver situações em que utilizar um registrador de propósito geral é o que faz mais sentido para o programa. Vamos a seguir destacar alguns registradores e seus propósitos originais.

Registradores de propósito geral

Podemos categorizar os registradores de uso geral em 2 partes: manipulação de dados diretos ou endereços de memória.

Dados Registradores podem manipular dados, que chamamos de valor imediato, e nesta categoria podemos utilizar RAX, RBX, RCX, RDX e os registradores de rascunho que vão de R8 a R15.

• RAX: operações aritméticas e armazenamento de resultados; também usado para o nome de chamadas de sistema em convenções de chamada (syscalls)

• RBX: ponteiro de base, utilizado para o endereço de algumas informações na memória

• RCX: geralmente usado como contador, para armazenar a quantidade de vezes que uma instrução deve ser executada

• RDX: usado para algumas operações de multiplicação e divisão, muito utilizado para armazenar o resto de operações

• R8 a R15: registradores de rascunho utilizados para propósito geral

Endereços de memória Registradores também permitem manipular endereços de memória. Nesta categoria temos RSI, RDI, RBP e RSP.

• RSI: utilizado como um ponteiro de origem em operações de transferências de dados, frequentemente usado em loops para iterar sobre arrays ou buffers de dados

• RDI: utilizado como ponteiro de destino em operações de transferências de dados, frequentemente usado junto com RSI

• RBP: frequentemente usado como ponteiro base em operações de memória, para referenciar variáveis locais e parâmetros de função na stack

• RSP: ponteiro para o topo da pilha (stack) do programa em execução

Registradores especiais

Vamos destacar apenas 2 dos registradores considerados "especiais":

• RFLAGS: utilizado para armazenar o estado da CPU, frequentemente modificado por instruções aritméticas e controle de paridade binária

• RIP: ponteiro de instrução, que sempre contém o endereço da próxima instrução a ser executada. Por exemplo, a instrução ret busca o endereço do topo da pilha e modifica o rip para que o programa continue a partir daquele ponto

Precisamos sempre utilizar todos os 64 bits?

Sabemos que registradores nesta arquitetura ocupam 64 bits de memória. Mas e quando o dado que estamos manipulando não precisa dos 64 bits? Conseguimos otimizar o uso de memória?

A ideia seria algo do tipo "por favor me dê uma fatia dos 64 bits, não preciso de tudo"

Historicamente, como vimos na parte II desta saga, as CPU's x86 não começaram com 64 bits. Evoluíram de 8 bits, para 16, então 32 até chegar em 64 bits.

Para manter compatibilidade, os registradores "legados" podem ser utilizados na arquitetura x64, e assim quando não houver necessidade de utilizar todos os bits do registrador, podemos utilizar uma fatia menor.

Por exemplo, o registrador RAX de 64-bits tem o seu equivalente de 32-bits que é o EAX, que ocupa os 32 bits mais baixos.

O registrador EAX, por sua vez, tem o equivalente AX de 8-bits. Dentro deste AX, podemos utilizar ainda a parte maior que se chama AH ou a parte menor que se chama AL.

O "H" em AH vem de "high", e consequentemente "L" de AL significa "low". Óbvio, não? :P

Sendo assim, há situações em que ao invés de:

mov rax, 7  ; 1 byte mas ocupa 8 bytes (64 bits)

E sabendo que 42 não ocupa 64 bits, podemos mudar para:

mov eax, 7  ; 1 byte mas ocupa 4 bytes (16 bits)

Ou então:

mov ax, 7   ; 1 byte ocupando exatamente 1 byte (8 bits)

Assim o programa final passa a ocupar menos memória em sua totalidade.

Seguindo esta lógica, podemos aplicar para todos os registradores, trazendo alguns como exemplo:

• RAX: EAX -> AX -> AH -> AL

• RBX: EBX -> BX -> BH -> BL

• RDX: RDX -> DX -> DH -> DL

• R8: R8W -> R8B

E assim por diante.

Uma side note sobre stack frames

Depois de publicar o artigo, o Rodrigo Gonçalves de Branco decidiu dar um feedback ultra detalhado executando todos os exemplos aqui demonstrados, e um dos insights foi sobre a utilização de stack frames.

Foi um trabalho fenomenal, meus agradecimentos ao Rodrigo

Voltando ao exemplo dos argumentos na pilha, dentro da rotina _start, temos a pilha do programa com o seguinte layout:

Quando fazemos a chamada:

...
	push greet    ; adiciona "Hi, " na stack para print
	call .print     
...

Estamos basicamente manipulando a pilha original do programa. O push vai colocar no topo da pilha (RSP) o endereço de greet, como demonstrado a seguir no GDB:

# Breakpoint no <push greet>
(gdb) break 13   

(gdb) run
(gdb) next

(gdb) x $rsp
0x7fffffffe448: 0x00402000

Agora a pilha ficou assim:

Se fizermos step no GDB, podemos ver que o RSP foi modificado novamente, desta vez adicionando o endereço da próxima instrução por conta da chamada call:

(gdb) step

(gdb) x $rsp
0x7fffffffe440: 0x0040100a

Isso é o que acontece com a pilha em uma simples chamada de rotina com argumentos!

Bom, sabendo disso, vemos que o argumento que precisamos está em rsp + 8, exatamente como no nosso programa original. So far, so good.

O problema é que podemos reparar que o RSP é modificado durante as chamadas de funções no programa. Não temos controle sobre isso.

E podem acontecer comportamentos inesperados (bugs?) quando isso ocorre, pelo simples fato de estarmos apontando dados na pilha e eles já estarem em posições que não esperávamos.

Para mitigar este potencial problema, podemos preservar a base da pilha em algum registrador sempre no início de cada função, desta forma cada rotina/função pode ter sua própria "versão" da pilha sem correr riscos de apontar para o dado errado.

Esta técnica é chamada de stack frame.

E é pra isso que usamos o registrador RBP! No prólogo de cada rotina, adicionamos o rbp na pilha e em seguida colocamos o ponteiro de rsp dentro do registrador rbp, igualando assim ambos registradores:

_start:
    push rbp
    mov rbp, rsp
....

Repare que esta técnica consiste em igualar RSP com RBP, assim pode-se de forma segura manipular o ponteiro em RBP, pois mesmo RSP sendo modificado pelo programa, RBP continua intacto.

Continuando com o programa:

push rbp
mov rbp, rsp
....
push greet
call .print
....

Constatamos no GDB que a stack foi alterada, portanto RSP foi modificado para apontar para o endereço da próxima instrução, ao passo que RBP continua apontando pro valor anterior:

# RBP 
(gdb) x $rbp
0x7fffffffe448: 0x00000000

# RSP aponta para o endereço da próxima instrução 
# antes da chamada da rotina
(gdb) x $rsp
0x7fffffffe438: 0x0040100e

# RSP + 8 aponta para o primeiro argumento da rotina
(gdb) x $rsp + 8
0x7fffffffe440: 0x00402000

# RSP + 16 aponta para o mesmo valor de RBP (base da pilha),
# ou seja, `RBP = RSP + 16` neste caso porque houve um PUSH
# explícito do argumento e também outro push feito pelo CALL
(gdb) x $rsp + 16
0x7fffffffe448: 0x00000000

E modificando a rotina .print para também ter seu próprio stack frame, como fica a pilha depois de executar:

.print:
    push rbp
    mov rbp, rsp
....

Analisando com GDB:

(gdb) x $rbp
0x7fffffffe430: 0xffffe448

(gdb) x $rsp
0x7fffffffe430: 0xffffe448

RSP e RBP ficaram igualados novamente, dando uma característica de stack frame, preservando a pilha como podemos ver na imagem a seguir:

Portanto, o argumento da rotina, ao invés de ser rsp + 8, passa a ser rbp + 16 por conta da stack frame, ficando da seguinte forma:

.print:                  
	push rbp
	mov rbp, rsp

	mov rsi, [rbp + 16]     
	mov r9, rsi
	mov rdx, 0

Uma coisa importante: ao final de cada rotina, antes do retorno, devemos fazer pop do topo da pilha para voltar ao estado original antes do push rbp feito no início da rotina:

push rbp
mov rbp, rsp
....
pop rbp
ret

Desta forma, ao fazer o pop rbp, o que está em RSP é justamente o endereço de retorno antes da chamada da função:

Ao continuar com o programa, a instrução ret (já falamos sobre ela anteriormente) faz pop do topo da pilha (RSP) e continua a execução do programa na próxima instrução:

_start:
	push rbp
	mov rbp, rsp     ; <--- iguala RSP e RBP

	push greet       ; <--- adiciona <greet> na pilha
	call .print      ; <--- adiciona ponteiro da próxima 
                         ; instrução na pilha
	pop rax          ; <--- faz pop de <greet> da pilha      

............
.print:                 
	push rbp         
	mov rbp, rsp     ; <--- iguala RSP e RBP

	mov rsi, [rbp + 16]     
        .............
	syscall
	pop rbp          ; <--- remove frame RBP da pilha
	ret              ; <--- faz pop do pointeiro da 
                         ; próxima instrução e atualiza RIP

Quando o fluxo volta para quem chamou a rotina, a próxima instrução deve ser sempre o pop dos argumentos que entraram na pilha.

Neste caso no exemplo anterior estamos fazendo pop do argumento e descartando o valor em RAX com pop rax, deixando assim a pilha em seu estado anterior à chamada da rotina:

Ao fim do programa (rotina _start), devemos também fazer pop rbp, assim a pilha volta ao estado original de quando foi iniciado o programa.

Código completo:

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi, ", 0
newline: db 0xA, 0

section .text
_start:
	push rbp               ; <-- cria um stack frame
	mov rbp, rsp           ; para preservar a pilha

	push greet             ; adiciona "Hi, " na pilha
	call .print            ; chama sub-rotina
	pop rax                ; remove "Hi, " da pilha

	push qword [rbp + 24]  ; adiciona argumento na pilha
	call .print            ; chama sub-rotina
	pop rax                ; remove argumento da pilhha

	push newline           ; adiciona newline na pilha
	call .print            ; chama-subrotina
	pop rax                ; remove newline da pilha

	pop rbp                ; remove RBP da pilha, 
                               ; retornando ao estado original
.exit:               
	mov rdi, 0
	mov rax, SYS_exit
	syscall                ; termina o programa
.print:                   
	push rbp               ; <-- cria um stack frame
	mov rbp, rsp           ; para preservar a pilha

	mov rsi, [rbp + 16]     
	mov r9, rsi
	mov rdx, 0
.calculate_size:               ; loop para calcular tamanho
	inc rdx
	inc r9
	cmp byte [r9], 0x00
	jz .done
	jmp .calculate_size
.done:                     
	mov rdi, STDOUT
	mov rax, SYS_write
	syscall

	pop rbp                ; <--- remove RBP da pilha, 
                               ; retornando ao estado anterior

	ret                    ; <--- retorna fluxo para o
                               ; estado anterior

É isto. Esta seção foi apenas uma demonstração de como utilizar boas práticas de manipulação da pilha quando utilizamos argumentos em funções, através da técnica de criar um frame como base da pilha com o registrador RBP.

Conclusão

É isto, pessoal. Esta parte da saga foi bastante densa. Passamos pela criação de um programa simples em Assembly, ao passo em que íamos depurando o programa com ferramentas como strace, size e muito gdb.

Também aprendemos sobre labels, tipos de registradores, desvio de fluxo com jmp, call, ret, muita stack, depurando tudo e mais um pouco, loops, FLAGS e aritmética de ponteiro.

Apesar de ter sido muito denso, os tópicos aqui abordados servirão de base para entendermos o próximo artigo que já começa pesado com syscalls de rede, para iniciarmos o nosso tão esperado web server.

Nos vemos no próximo artigo!

Referências

Mas o que é um programa de computador?

Teremos a resposta para esta pergunta ao longo deste artigo. Vamos abordar muitos conceitos, desde código de máquina (o mais importante na minha opinião), a sistemas de numeração binário, decimal e hexadecimal.

Iremos também compreender opcodes, chamadas de sistema, modo kernel, libc, ASCII, standard streams; e alterar arquivos binários em hexadecimal.

Ao final deste artigo vamos estar em um patamar de entendimento mais holístico de como um programa é interpretado na CPU.

Ainda não entraremos em Assembly. Foi escolhido desta forma pois o intuito com esta saga é detalhar ao máximo como as peças de encaixam, e acredito que trazer Assembly sem explicar outros conceitos primordiais pode confundir bastante.

Também não é esperado que você escreva os códigos de máquina deste artigo, pois aqui neste link providencio o binário já pronto para que você possa acompanhar com as ferramentas que irei utilizar. Basta apenas baixar o arquivo binário no link fornecido e atribuir permissão de execução com chmod +x, se necessário.

Lembrando que é importante que esteja em um ambiente Linux, caso contrário não irá funcionar. Se estiver em outro ambiente e não puder virtualizar, poderá acompanhar esta saga apenas lendo, pois a ideia é também trazer muitos conceitos fundamentais de baixo-nível

Ainda não será o código do web server, o programa proposto neste post é bastante simples, mas estamos quase lá. Vamos focar em conceitos fundamentais para que futuros artigos, que cobrem o desenvolvimento do web server, possam ser melhor compreendidos.

Sem mais delongas, prepare-se para a partir de agora entrar numa espiral de código de máquina e manipulação de memória.

Agenda

• O que é um programa de computador

  • Sistemas Operacionais e Processos
  • Um programa deve sempre terminar

• Nosso primeiro programa

  • A linguagem das CPU's, o sistema binário
  • O famoso sistema decimal
  • Hexadecimal, o queridinho dos computadores
  • Opcodes
  • Endianness

• Nosso segundo programa

  • Alocando dados na memória do programa
  • ASCII
  • Syscalls
  • Montando a syscall write
  • Montando a syscall exit

• Manipulando o nosso programa

• A vida de quem programa é assim?

• Conclusão

• Referências

O que é um programa de computador

Como já vimos na parte II, a função primordial de uma CPU é ler uma instrução da memória, decodificar, executar e armazenar o resultado de volta na memória.

Então a grosso modo, um programa de computador é um conjunto de instruções pra a CPU processar. Em um cenário típico, teríamos diversos programas diferentes lendo e escrevendo da mesma memória do computador:

Mas um potencial problema, é que neste cenário poderíamos ter dois diferentes programas acessando ou modificando o mesmo endereço de memória:

Pra resolver isto, precisamos agrupar as instruções de um programa de modo a "isolar" de outros programas que também estão rodando no computador.

É aí que entra um dos papéis do sistema operacional com o conceito de processos.

Lembrando que nesta saga, vamos focar apenas em sistemas UNIX-like, mais precisamente distruibuições GNU/Linux

🔵 Sistemas Operacionais e Processos

Cada programa executado no SO é encapsulado em uma estrutura chamada processo, que vai ter uma área virtual na memória principal.

Na prática, cada programa vai ter seu próprio "0x10000", isolado dos demais.

🔵 Um programa deve sempre terminar

Como o SO aloca recursos de memória (dentre outros) para o processo, nosso programa precisa indicar quando termina.

Desta forma aquele espaço reservado de memória fica livre para ser utilizado por outro processo. Isto evita problemas como vazamento de memória entre outros.

Caso isto não seja feito, o SO vai lançar uma exceção e o programa não pode ser admitido como processo.

Nosso primeiro programa

Vamos trabalhar inicialmente com um exemplo bastante simples. Um programa que não faz nada.

Nossa Leandro, como assim um programa que não faz nada?

Sim, parece estranho para linguagens de mais alto nível. Mas pensando em CPU isto já é alguma coisa, pelo que precisamos de ao menos algumas instruções para um programa que "não faz nada": o programa precisa terminar, lembra?.

🔵 A linguagem das CPU's, o sistema binário

Pensando na CPU como um dispositivo eletrônico, esta só entende pulso elétrico. Mas conseguimos abstrair tais pulsos como 0 ou 1.

Consequentemente, quando falamos em código de máquina para uma CPU estamos falando em instruções que utilizam sistema binário, composto de 0 ou 1.

Nosso programa que não faz nada além de "terminar" pode ser representado então pelo seguinte conjunto de instruções:

Não se preocupe em escrever o programa. Por enquanto são só exemplos de código de máquina para que possamos entender bem os conceitos

10111111 00000001 00000000 00000000 00000000   
10111000 00111100 00000000 00000000 00000000  
00001111 00000101                            

No sistema binário, cada símbolo é chamado de bit. Este simples programa tem 12 conjuntos de 8 bits cada. Conte você mesmo para confirmar!

O sistema binário tem esse nome porque só fornece dois tipos de símbolos para representar números. Vamos contar:

0
1

Acabou. Com 1 dígito podemos ter 2 combinações apenas. Mas e se quisermos representar mais números? Aí nos resta ficar combinando com mais dígitos.

Para 2 dígitos, conseguimos aumentar para 4 combinações:

00
01
10
11

Se quisermos continuar, temos que entrar com 3 dígitos, sempre começando com o mais à esquerda possível, o que nos dá 8 combinações:

000 
001 
010 
100
100 
101 
110 
111

Com isto, temos um padrão:

• 1 dígito: 2 combinações

• 2 dígitos: 4 combinações

• 3 dígitos: 8 combinações

Repare no padrão de exponenciação. Estamos pegando o número 2 como base e aplicando o número do dígito como expoente:

numero de símbolos ^ número de dígitos

• 2^1 = 2

• 2^2 = 4

• 2^3 = 8

Extrapolando para 4 ou mais dígitos, podemos chegar na seguinte conclusão:

• 2^4 = 16 combinações

• 2^5 = 32 combinações

• 2^6 = 64 combinações

• 2^7 = 128 combinações

• 2^8 = 256 combinações

E assim por diante...

Você tá brincando com minha cara, né Leandro? Vim aqui pra ficar escovando bit?

Não exatamente. No programa, cada conjunto ali de 8 bits (chamado de byte) tem um significado para a CPU, o que faz nosso programa ter 12 bytes.

E como não somos uma CPU, estamos nada preocupados em representar instruções em bits, vamos então converter para o sistema decimal para conseguirmos representar nosso mesmo programa de forma mais simples e intuitiva.

🔵 O famoso sistema decimal

Já estamos habituados com o sistema decimal. Muitos números no nosso dia-dia são representados através do sistema decimal.

Falamos de números como "dez", "cento e quinze", "quarenta e dois" sem qualquer problema, pois foi o que aprendemos desde a primeira infância. Nosso cérebro já fixou o aprendizado tão intrinsicamente, que sequer pensamos que se trata de um sistema de numeração como qualquer outro.

Vamos por um momento esquecer que sabemos sistema decimal e aplicar as mesmas regras que aplicamos para o sistema binário.

Repetindo mais uma vez, no sistema binário temos à disposição apenas dois símbolos: 0 e 1.

E no decimal?

Temos dez símbolos à disposição, que são:

0 1 2 3 4 5 6 7 8 9

Tal como no sistema binário, com 1 dígito apenas temos essas 10 possibilidades acima.

Já chegou no nove? Acabaram as combinações? Não tem problema, vamos subir pra dois dígitos sempre começando pelo dígito mais à equerda possível:

00 01 02 03 04 05 06 07 08 09
10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29
...
...........................99

Olha só, com apenas dois dígitos no sistema decimal, podemos combinar 100 números diferentes!

O padrão é o mesmo no sistema binário, podemos logo aplicar exponenciação da base, sendo:

numero de símbolos ^ número de dígitos

Portanto:

• 10^2 = 100 combinações

• 10^3 = 1000 combinações

• 10^4 = 10000 combinações

• etc etc etc

Convertendo binário em decimal

Uma vez que entendendo sistemas de numeração binário e decimal, podemos "compactar" nosso programa inicial de binário para decimal de modo a termos uma leitura mais intuitiva, não?

Aplicando a regra de exponenciação, não fica difícil fazer a conversão:

• 0 é sempre 0, pois este símbolo está presente em ambos sistemas de numeração

• Mesmo vale para 1, pois está presente em ambos

Se quisermos então converter 10 (que é o próximo número depois de 1 em binário) de binário pra decimal, vamos aplicar a seguinte regra:

dígito x 2^posição do dígito

...somando o resultado de cada operação em dígito, onde a posição mais à direita possível começa com zero, pois de acordo com a senhora matemática, qualquer número elevado a zero é UM*.

Com isto:

• 10 = (1 x 2^1) + (0 x 2^0) = 2 + 0 = 2

Vamos extrapolar um pouquinho?

• 11 = (1 x 2^1) + (1 x 2^0) = 2 + 1 = 3

• 100 = (1 x 2^2) + (0 x 2^1) + (0 x 2^0) = 2 + 0 + 0 = 4

Yay! Nice, uh?

Agora vamos converter byte a byte do nosso programa:

10111111 00000001 00000000 00000000 00000000   
10111000 00111100 00000000 00000000 00000000  
00001111 00000101                            

• 10111111 = (1 x 2^7) + (0 x 2^6) ... = 191

• 00000001 = (0 x 2^7) + (0 x 2^6) ... + (1 + 2^0) = 1

• etc etc etc até chegar ao 12º byte

Temos então um programa convertido para decimal da seguinte forma:

191 1 0 0 0
184 60 0 0 0
15 5

Entretanto, não é comum representar sistema decimal para instruções de CPU, pois cada byte (8 bits) não seria dividido em partes iguais no sistema decimal, o que poderia causar um desalinhamento, criando buracos desnecessários na memória.

Uma forma de ver este problema é que o sistema decimal composto de 10 símbolos não é divisível por 8 (resto 2), que é a quantidade de bits em um byte

E se tivéssemos um sistema de numeração com uma quantidade de dígitos que fosse divisível por 8?

Sabendo que 16 é divisível por 8 (resto 0) e não causaria desalinhamento entre bits pra representar um programa, será que existe um sistema de numeração de 16 símbolos para podermos compactar ainda mais a representação textual do nosso programa?

Sim, estamos falando do sistema hexadecimal.

🔵 Hexadecimal, o queridinho dos computadores

Certamente você já ouviu falar, viu ou até praticou hexadecimal. Similar ao que fizemos com sistema decimal, vamos esquecer tudo o que sabemos sobre hexadecimal e aplicar algumas regras.

Quantos símbolos temos à disposição? 16.

Daí o nome: hexa, representando 6, e decimal representando 10. DEZ + SEIS!!!!!111

Os primeiros 10 símbolos são exatamente como no decimal:

0 1 2 3 4 5 6 7 8 9

E quanto aos 6 símbolos restantes? Poderíamos representar emojis, gifs animados ou derivados de batata, mas seria muito mais simples representarmos as primeiras 6 letras do alfabeto, não?

0 1 2 3 4 5 6 7 8 9 A B C D E F

As regras pra combinar são as mesmas, sempre do mais à esquerda possível:

0 1 2 3 4 5 6 7 8 9 A B C D E F
10 11 12 13 14 15 16 17 18 19 ?

Qual seria o próximo? 20?

Não, jovem, vamos combinar com as letras restantes

...
19
1A
1B
1C
1D
1E
1F

Agora sim, as combinações com o dígito 2:

20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 
30 31 32 33 34 ............................. 3F 
...........................99................9F
100

Com apenas 2 dígitos no sistema hexadecimal, podemos ter 256 combinações de números diferentes!

• em binário, 2 dígitos = 4 combinações

• em decimal, 2 dígitos = 100 combinações

• em hexa, 2 dígitos = 256 combinações

Por exemplo, para termos 256 combinações com 2 símbolos FF, precisaríamos de 8 símbolos 1111 1111 no sistema binário, obviamente ocupando mais espaço pra representar e visualizar programas.

O céu é o limite 🚀

Aplicando regra de exponenciação para convertermos pra decimal, vamos ter o seguinte:

• do 0 ao 9 é tudo igual

• A = 10, B = 11, C = 12, D = 13, E = 14, F = 15

Onde:

dígito do sistema * 16^posição do dígito

Com isto, convertendo 1A e FF para decimal, ficaria:

• 1A = (1 * 16^1) + (10 * 16^0) = 16 + 10 = 26

• FF = (15 * 16^1) + (15 * 16^0) = 240 + 15 = 255

Ok, mas precisamos converter de binário para hexa

Com razão, como podemos converter o byte 11111111 para hexadecimal? Dá pra fazer por dedução da conversão decimal, por exemplo:

• sabendo que o byte 11111111 representa 255 em decimal, e sabendo que FF em decimal é 255, portanto concluímos que 11111111 = FF

• se dividirmos o byte em 2 partes, podemos calcular que 1111 = F, portanto chegamos no mesmo resultado

Geralmente empregamos a técnica de dividir o byte em 2 partes de 4 bits cada. Assim fica mais fácil visualizar.

O simples programa original escrito em binário, fica então convertido em hexadecimal da seguinte forma:

BF 01 00 00 00 
B8 3C 00 00 00 
0F 05          

Opa! Já conseguimos ter uma leitura mais intuitiva, certo? Mas que raios significa BF 01, B8 3C ou 0F 05 na CPU?

🔵 Opcodes

Cada CPU possui uma arquitetura específica. Falando de x64 (ou x86_64), esta traz um conjunto de opcodes no manual que representam as instruções disponíveis, registradores entre outras operações de CPU.

De acordo com o manual:

• o opcode BF move um valor imediato para o registrador RDI

• 01 00 00 00: valor imediato hexa que representa 1 em decimal, mas na ordem inversa no formato little-endian (vamos falar de endianness mais a seguir)

• o opcode B8 move um valor imediato para o registrador RAX

• 3C 00 00 00: valor imediato hexa que representa 60 em decimal, mas na ordem inversa no formato little-endian

• o opcode 0F 05 entra no modo "kernel" do SO e aguarda a resposta de uma chamada de sistema (syscall)

Mas por quê os bytes são representados na ordem inversa nesta arquitetura de CPU?

🔵 Endianness

O conceito de endianness está relacionado com a forma que CPU's lêem e processam bytes na memória.

Vamos trazer o exemplo de um byte em binário, 10000001, que sabemos que é 129 em decimal. Prestando atenção nos expoentes:

2^7 + 2^6 + 2^5 + 2^4 + 2^3 + 2^2 + 2^1 + 2^0

• o bit mais à esquerda, 1 x 2^7 = 128

• somado com o bit mais à direita, 1 x 2^0 = 1

• o restante dos bits está tudo a zero, não precisam entrar pra soma

Podemos inferir que os bits mais à direita não têm tanto peso no valor final, por isso são chamados bits menos significativos.

O bit da direita incorporou apenas o valor 1 pro resultado final

Da mesma forma, os bits mais à esquerda têm mais peso no valor final, por isso são chamados de bits mais significativos.

O bit da esquerda incorporou 128 pro resultado final, trazendo mais significância

Esta propriedade de definir significância de bits é chamada de endianness. Diferentes arquiteturas de CPU podem decidir ler do mais significativo ao menos significativo (padrão intuitivo de leitura, big-endian) ou do menos significativo ao mais significativo (little-endian).

A decisão passa por fatores históricos ou por facilitar manipulação de ponteiros. Diferentes sistemas podem decidir por inverter a leitura/escrita ou não dos bytes.

Na CPU x86_64, o formato é little-endian, portanto em hexa o valor de 4 bytes 00 0D 00 3C passa a ser 3C 00 0D 00 no formato little-endian.

Concluindo, vamos adicionar comentários ao nosso pseudo-programa:

BF 01 00 00 00  ; MOVE 1 PARA RDI
B8 3C 00 00 00  ; MOVE 60 PARA RAX
0F 05           ; CHAMADA DE SISTEMA (SYSCALL)

Como a CPU sabe qual syscall deve executar? Por padrão, o número da syscall fica no registrador RAX. E como saber qual o número da syscall?

Neste link, temos uma lista completa de todas as syscalls da arquitetura x64, e ali podemos conferir que a syscall exit do kernel representa o número 60 decimal, ou 3C hexa. É exatamente o que a instrução B8 3C está fazendo!

Mais a seguir neste artigo vamos aprofundar no mundo das syscalls e chamadas do kernel.

Nosso segundo programa

Até agora vimos apenas o código de máquina de um programa que não faz nada (apenas termina), mas foi bastante útil para entendermos sistema binário, hexadecimal e outros conceitos.

Continuaremos ainda explorando código de máquina. Não precisa escrever nada, mas pode acompanhar com o código que disponibilizei no início do artigo e rodar os comandos em Linux

Vamos agora elaborar um hipotético programa que imprime "Hello, World" na saída (STDOUT). Para isto, devemos:

• alocar memória para a string "Hello, World"

Sim, dados ficam na memória junto com o programa, lembra?

• escrever a string na saída STDOUT, que é a saída padrão do programa (em outras palavras, a "tela")

Se quiser mais detalhes do que é STDOUT, standard streams e redirecionamento de streams, sugiro ler outros artigos que escrevi sobre UNIX pipes

• terminar o programa

Alocar, imprimir, terminar. Escrever no STDOUT é uma chamada de sistema, e terminar o programa é outra chamada de sistema. Portanto, temos:

• uma alocação de dados na memória do programa

• 2 chamadas de sistema

🔵 Alocando dados na memória do programa

Em linguagem de máquina, fazemos alocação byte a byte, e sabendo que queremos alocar "Hello, World" literalmente, como representar cada letra, o caracter vírgula e o caracter espaço na memória?

Precisamos de uma tradução dos caracteres para representação decimal ou hexadecimal. É isso mesmo que você está lendo, vamos entrar em ASCII.

🔵 ASCII

ASCII (American Standard Code for Information Interchange), é um padrão para codificação de caracteres em comunicação eletrônica, criado nos anos 60.

O padrão ASCII estabeleceu inicialmente 7 bits para cada caracter e foi concebido para suportar caracteres presentes somente na língua inglesa. Por conta desta limitação, tem suporte para um máximo de 128 caracteres (2^7) que abordam os dígitos decimais, caracteres especais e letras do alfabeto, maiúsculas e minúsculas.

Mais tarde veio uma extensão da tabela com um bit a mais portanto suportando mais caracteres como acentuações, porém ainda com limitações para suportar outros idiomas e caracteres especiais.

Tempos depois surgiu o padrão Unicode, que adiciona a capacidade de codificação de tamanho variável, permitindo assim uma multitude de caracteres e alfabetos de diversos idiomas.

Unicode também contempla a mesma tabela ASCII nos primeiros 128 caracteres por questões de retrocompatibilidade em sistemas. Portanto, apesar de sistemas modernos utilizarem esquemas de codificação Unicode tais como UTF-8, neste artigo focaremos na terminologia ASCII por ser suficiente nos nossos exemplos

Podemos verificar na tabela ASCII que os códigos hexa de cada caractere da nossa string são:

H: 0x48     
e: 0x65     
l: 0x6C     
l: 0x6C     
o: 0x6F
,: 0x2C
[space]: 0x20
W: 0x57
o: 0x6F
r: 0x72
l: 0x6C
d: 0x64
[newLine]: 0xA

0x é uma notação, um prefixo para determinar que o número depois de x é um hexadecimal

Com isto podemos então escrever os primeiros bytes hexa do nosso programa:

48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 0A

Nice, agora vamos "montar" as instruções para a syscall que escreve no STDOUT. Como o kernel faz isso?

🔵 Syscalls

Syscalls são chamadas de sistema onde o programa sai do modo "user" e entra no modo "kernel". Basicamente, o programa fica à espera que o kernel do sistema operacional execute a função que foi solicitada.

Apesar de neste link estar tudo compilado, temos que entender um fator muito importante sobre o kernel que estamos trabalhando, e se trata do kernel Linux.

O kernel Linux foi escrito em C na virada da década de 80 para 90, e por ser escrito em C, todas as chamadas de sistema são declaradas em C.

Por exemplo, no manual de system calls do kernel podemos pesquisar sobre qualquer chamada de sistema ou comando utilitário.

A chamada que queremos utilizar pra escrever no STDOUT se chama write, e é definida pela função:

ssize_t write(int fd, const void buf[.count], size_t count);

...que está presente na biblioteca padrão C (libc), que o kernel incorpora.

Para distribuições GNU, que é o meu caso utilizando Ubuntu, há um repositório mirror do glibc que é a biblioteca padrão em C para sistemas GNU/Linux.

Repara que a função write espera 3 argumentos:

• fd, ou file descriptor, que no nosso caso é o STDOUT, representado pelo valor 1

💡 STDIN representa 0 e STDERR representa 2. Tá lá no nosso outro artigo sobre Bash e UNIX pipes, corre dar uma olhada

• buf, ou buffer, que é o ponteiro para o início do buffer de dados. No caso de escrever "Hello, World" com quebra de linha, o buf apontaria para o início da string "Hello, World\n" na memória.

• count, que é o tamanho do buffer de dados a ser escrito. Para a string "Hello, World\n", o count seria 13, pois isso inclui os 12 caracteres da string mais 1 byte para a quebra de linha.

🔵 Montando a syscall write

Para montar uma chamada de sistema, é necessário seguir uma interface que determina como um programa deve comunicar com o sistema operacional.

Quem determina isto é a ABI (Application Binary Interface), que define como estruturas de dados ou funções computacionais conversam entre si.

Como precisamos chamar uma função do kernel Linux, vamos utilizar as convenções determinadas por este sistema operacional e a arquitetura da CPU em questão.

Com isto, podemos montar as instruções utilizando registradores para a syscall write. Novamente seguindo esta tabela (que ajuda muito), vamos fazer instrução por instrução:

👉 ARG0 O primeiro argumento da função vai no registrador RDI, e aqui vamos colocar o valor 1 que representa o file descriptor STDOUT. Em hexa, o manual x86 diz que o opcode hexa é BF, seguido do hexa 00 00 00 01 em formato little-endian:

BF 01 00 00 00

👉 ARG1 O segundo argumento é o ponteiro para o buffer onde começa a string na memória, movido para o registrador RSI.

Como a string fica no começo do programa, geralmente este endereço fica em 0x401000. Portanto, o opcode para o move no registrador é 48 BE e o valor do endereço de memoria no formato little-endian em hexa, 00 10 40

48 BE 00 10 40 

👉 ARG2 Já o terceiro argumento da função vai para o registrador RDX, que representa o tamanho do buffer em bytes a ser escrito no file descriptor definido no registrador RDI (ARG0).

O opcode é o BA e o valor é 13 em hexa, que é 00 00 00 0D só que no formato little-endian:

BA 0D 00 00 00

Agora, vamos colocar no registrador RAX o número da syscall write, que de acordo com esta tabela (sempre esta tabela, habitue-se a ela), é o número 1, mas em hexa e little-endian:

B8 01 00 00 00

Falei bastante desta tabela, de syscalls e little-endian aqui, nos próximos artigos vou falar cada vez menos. A ideia é focar em outras coisas e estes detalhes estarem já bem fundamentados

Por último, vamos montar a instrução da syscall em si, que é o opcode:

0F 05

Trecho final da syscall write:

48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 0A ; "Hello, World"

BF 01 00 00 00                 ; MOV 1 para RDI
48 BE 00 10 40                 ; MOV 0x401000 para RSI
BA 0D 00 00 00                 ; MOV 13 para RDX
B8 01 00 00 00                 ; MOV 1 para RAX (write)
0F 05                          ; SYSCALL

A syscall write já tá montada, agora falta terminar o programa.

🔵 Montando a syscall exit

A API da chamada de sistema exit pode ser consultada no manual, e tem a seguinte assinatura no glibc:

void _exit(int status);

👉 ARG0 O primeiro argumento é o status de término, que de acordo com a especificação POSIX, pode ser qualquer inteiro de 0 a 255 mas sendo o 0 indicando que o progama terminou sem erros.

BF 00 00 00 00

Agora, vamos ao trecho final da syscall exit:

BF 00 00 00 00          ; MOV 0 para RDI
B8 3C 00 00 00          ; MOV 60 para RAX (exit)
0F 05                   ; SYSCALL

Programa completo:

48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 0A
BF 01 00 00 00 
48 BE 00 10 40
BA 0D 00 00 00 
B8 01 00 00 00 
0F 05          
BF 00 00 00 00 
B8 3C 00 00 00 
0F 05          

Tomando como exemplo o binário que disponibilizei, ele tem mais bytes por conta de headers necessários para o próprio sistema operacional admitir o programa.

Vamos executar o binário:

$ ./example

Hello, world

Yay! Que dia, hein?

Manipulando o nosso programa

Com o arquivo binário em mãos, e sugiro baixar do repositório, vamos utilizar o utilitário xxd que faz um dump de hexa de qualquer binário, e com ele podemos reparar que o binário vai ter, a partir do byte 4096, a mesma quantidade de bytes que escrevemos aqui neste artigo:

xxd -s 4096 -g1 -c8 -l52 example

00001000: 48 65 6c 6c 6f 2c 20 57  Hello, W
00001008: 6f 72 6c 64 0a bf 01 00  orld....
00001010: 00 00 48 be 00 10 40 00  ..H...@.
00001018: 00 00 00 00 ba 0d 00 00  ........
00001020: 00 b8 01 00 00 00 0f 05  ........
00001028: bf 00 00 00 00 b8 3c 00  ......<.
00001030: 00 00 0f 05              ....

Maravilhoso, não?

E por fim, antes de concluir este artigo que por si só dá quase uma saga, vamos alterar o binário direto em código de máquina utilizando o utilitário hexedit.

Esta dica peguei em vídeos do Blau Araújo. Ele é realmente fantástico e traz conteúdo de primeira. Pra mim é a melhor referência para conteúdo de baixo nível em pt-BR

Para mudar o binário, rodamos o comando:

hexedit --color example

Que vai abrir um editor bastante específico. Com /, podemos buscar por um hexa, por exemplo "48", que vai levar para o início da string.

Vamos trocar o "W" maiúsculo por "w" minúsculo, diretamente em código de máquina, que significa trocar o byte 57 da tabela ASCII por 77:

Então:

48 65 6C 6C  6F 2C 20 57  6F 72 6C 64  0A 

Passa a ser:

48 65 6C 6C  6F 2C 20 77  6F 72 6C 64  0A 

Gravar o arquivo com ctrl+s e depois ctrl+c para sair. Executar novamente e:

$ ./example

Hello, world

MEO DEOS, impressionante!!!!111

A vida de quem programa é assim?

Leitores mais atentos devem estar se perguntando:

É sempre assim a vida de quem programa? Ficar escovando bits e mudar diretamente código de máquina em hexadecimal?

Para a maioria esmagadora dos casos, não.

E se a gente criasse um programa tradutor que nos permitisse montar as instruções em uma linguagem mais human-friendly e traduzisse para o código de máquina tal o que vimos aqui neste artigo?

Estamos falando de assemblers, que são montadores que permitem escrever em uma linguagem de montagem específica de uma arquitetura (um assembly) e converter para os opcodes, as instruções de CPU.

Reforçando, nesta saga vamos focar no montador NASM para a linguagem Assembly x86 de 64-bits em sistemas GNU/Linux.

Conclusão

Jornada longa essa, hein? Este artigo cobriu diversos conceitos fundamentais, tais como sistema binário, hexadecimal, opcodes, syscalls, libc, ASCII...

Estes conceitos fundamentam o entendimento para escrever código Assembly, que será o tema principal dos próximos artigos.

No próximo artigo, vamos abordar conceitos básicos de Assembly, buscando converter o simples programa que fizemos neste artigo em um asm (atalho pra dizer "assembly") bem organizadinho.

Em seguida, iremos entrar nas syscalls de socket, bind e accept justamente para montarmos o código do nosso web server. Vamos também manipular buffer de arquivos, alocar dados dinamicamente na memória, trabalhar com threads, locks, criar fila na mão, enfim, ainda há muita coisa por vir. Isto aqui é apenas a ponta do iceberg.

Não será um tutorial, mas vamos falar de mnemonics, endereçamento de memória, segmentos de memória, layout de memória de um programa, debugging com gdb entre outras coisas.

Fiquem ligades!

Referências

Agora, chegou o momento de começarmos a de fato falar sobre coisas técnicas.

Como de costume, não gosto de esgormitar termos complexos sem a devida explicação. Portanto, vamos iniciar a saga trazendo um pouco de contexto histórico, motivações e porque estamos aqui quando o assunto é computadores.

Okay, agora fui filósofo demais. Mas o que mais importa é que o verdadeiro Assembly são os amigos que fazemos no caminho

Sem mais delongas, vamos ao que interessa.

Agenda

• Um pouco de história

• Computar informações

  • Máquina de Turing
  • Arquitetura de von Neumann
  • O gargalo de von Neumann

• Hierarquia de memória

  • Como a CPU executa instruções
  • Registradores de CPU

• ISA

  • CISC
  • RISC

• Por quê x86?

• Conclusão

• Referências

Um pouco de história

Ainda muitos milhares de anos a.C, o ser humano precisava realizar cálculos. Um dos instrumentos mais primitivos para esta tarefa era o Ábaco, e certamente você já deve ter visto um:

Não vou entrar em detalhes em como um Ábaco funciona, sugiro que compre um e experimente. É divertido. Eu usei quando estava no ensino primário (cria dos anos 90, cof cof).

Computadores mecânicos

Ainda nesta "pré-história" dos computadores e já avançando para uma Europa iluminista (circa século XVII), podemos ver a seguir invenções mecânicas e projetos como a máquina de calcular de Blaise Pascal, depois a máquina analítica de Charles Babbage e então a máquina de tabulação de Herman Hollerith.

💡 É da máquina de tabulação de Herman Hollerith que vem o nome do seu comprovante de pagamento "holerite"

Estas máquinas eram mecânicas e tinham muitas limitações como não ter uma memória própria para as "instruções", mas foram muito importantes para a evolução, possibilitando mais tarde que Ada Lovelace pudesse escrever o primeiro possível algoritmo para o projeto da máquina de Babbage.

Pra quem quiser uma explicação excelente e mais completa sobre a história dos computadores e como estes funcionam, sugiro o vídeo como reinventar um computador do zero do canal Infinitamente.

Computar informações

Na era moderna dos computadores, que se dá início no século XX, é quando acontece a revolução eletrônica através das válvulas e dos transistores.

Mas não apenas na área da eletrônica. Foi no século XX que vimos a revolução computacional através de um modelo abstrato que abriu portas para muito do que conhecemos hoje em termos de computadores.

Estamos falando da máquina de Turing.

Máquina de Turing

Nos anos 30, o matemático Alan Turing desenvolveu o conceito abstrato de uma máquina que possuía uma fita infinita, dividida em células, e um cabeçote de leitura/escrita que movia para frente e para trás na fita, possiblitando modificar o estado atual na máquina.

Basicamente, este modelo de máquina permitiria que certas classes de problemas pudessem ser resolvidas com operações simples.

Extrapolando, nesta fita, que pode representar um tipo de "memória", é possível armazenar o estado mas também outra máquina, ou seja, temos aqui o conceito de uma máquina de Turing universal, que é capaz de simular outra máquina de Turing.

De forma resumida, podemos colocar na fita tanto o estado (dados) quanto as próprias instruções do programa, mitigando assim o problema de limitação que os computadores primitivos tinham, que era resolver problemas complexos de forma mais simples.

Entretanto, a máquina de Turing era apenas uma abstração. Este conceito de instruções e estado na mesma memória precisava ser concretizado.

É aí que entra von Neumann.

Arquitetura de von Neumann

Von Neumman foi um polímata que propôs um modelo computacional que é utilizado por muitos computadores modernos e dispositivos que usamos hoje em dia.

Neste modelo, temos uma unidade de processamento central, ou CPU, que é responsável por realizar cálculos aritméticos e executar instruções.

Conectada a esta CPU, temos o conceito de memória compartilhada, que vai ser usada para armazenar todas as instruções e estado de um programa de computador.

Esta arquitetura possibilitou que computadores como ENIAC e EDVAC pudessem ser desenvolvidos. O EDVAC, por sua vez, foi um dos precursores na implementação do modelo de von Neumann, com uma CPU que era conectada a uma memória compartilhada e sequencial.

À medida que os componentes computacionais foram ficando mais modernos, os computadores foram ficando menores, mais potentes, versáteis e com utilização de propósito mais geral.

Então, a arquitetura de von Neumann pode ainda contar com dispositivos de entrada e saída de dados (impressora, teclado, mouse, placa de rede, monitor, etc), também conhecidos como dispositivos I/O:

Podemos assumir, então, que quando escrevemos um programa de computador, estamos basicamente manipulando uma memória finita (que tem fim) e dispositivos de entrada e saída de dados, através de instruções que são executadas pela CPU.

Tudo graças ao modelo concreto de von Neumann.

Vale destacar que há arquiteturas computacionais que não seguem este modelo, mas aqui neste guia estamos focando em computadores de propósito geral

O gargalo de von Neumann

Esta arquitetura entretanto traz uma limitação. Como o barramento (caminho) entre a CPU e memória é único, tanto instruções quanto dados trafegam pelo mesmo local, levando a um cenário onde a CPU pode ficar limitada em processamento até que todos os dados sejam lidos do barramento.

Uma forma de mitigar este problema é definir diferentes "níveis" de memória, para que a CPU possa ter uma taxa de processamento maior.

Você acertou, vamos falar agora sobre a hierarquia de memória.

Hierarquia de memória

Nosso programa manipula memória.

Com que frequência?

Todo tempo.

Para mitigar o problema do gargalo de von Neumann, podemos definir uma hierarquia de memória, assim não só a memória principal (RAM) é "enxergada pela CPU" como memória, mas também outros dispositivos de armazenamento no sistema computacional.

Adicionado a isso, com a modernização de computadores no século XX, foi criada a necessidade de orquestrar e controlar todas as interfaces com o hardware. Temos então a concepção de sistemas operacionais para esta tarefa, que começam a surgir em meados dos anos 60/70, dentre eles o UNIX.

Ao tratarmos tudo como memória, podemos introduzir tal hierarquia. Portanto, num sistema computacional tratamos tudo (ou quase tudo) como memória e assim o sistema operacional (SO) pode abstrair de um determinado programa onde aquilo na hierarquia se encontra de fato sendo utilizado, deixando então nosso programa "livre" deste detalhe de implementação física.

Quanto mais pro topo da hierarquia, menor a capacidade de armazenamento e mais caro. Por exemplo, registradores de CPU são memórias voláteis que estão no topo.

Vamos falar sobre registradores mais a seguir na saga

E quanto mais pra base da hierarquia, maior a capacidade e consequentemente mais barato. Exemplo na base são as unidades de armazenamento durável não-voláteis (HD, SSD etc).

No meio temos a memória principal e volátil, tendo como principal exemplo a memória RAM.

A hierarquia de memória desempenha, então, um papel crucial na forma como a CPU gerencia e acessa memória.

Como a CPU executa instruções

Para que uma CPU execute determinada instrução, é necessário ao menos um ciclo de clock, também chamado popularmente como "giro de CPU", ou ciclo de CPU.

Vamos imaginar uma coisa que fica "girando" indefinidamente igual um relógio. De forma simples, é assim que podemos imaginar o clock de uma CPU, como um giro de relógio.

Alguns tipos de instruções podem gastar mais de um ciclo, e determinar quais instruções vão gastar mais ou menos ciclos é algo que é projetado diretamente na construção da CPU.

E onde as instruções ficam armazenadas?

Isso mesmo, na memória.

Portanto, a CPU precisa buscar a instrução na memória, decodificar, executar e armazenar o resultado de volta na memória.

Tudo isto faz gastar imensos ciclos de CPU. Ao gastarmos ciclos, a CPU pode bater num limite e não conseguir atender a tantas operações no mesmo segundo. Pra não mencionar a latência que a CPU gasta pra utilizar o barramento físico e "viajar" até a memória principal.

Tomando como premissa a hierarquia de memória, e se ao invés de armazenar o resultado na memória principal, a CPU resolver armazenar dentro da própria CPU?

Conheça os registradores de CPU.

Registradores de CPU

Você já pode estar pensando em cache de CPU, né? Mas calma lá jovem, cache de CPU é outra seara que não pretendo entrar, não por agora.

Mas que também tem seu lugar na hierarquia de memória

Lembrando (mais uma vez), da hierarquia de memória, de forma muito simplificada:

• topo: registradores

• depois: cache de CPU

• ainda depois: memória principal (RAM)

• beeem depois: memória secundária (HD, SSD)

Quanto mais perto do topo, mais rápido a CPU consegue processar, mas em contrapartida é volátil e também tem menor capacidade de armazenamento.

Então, registradores são apenas memórias de hierarquia mais alta que são preferencialmente usadas para computação porque possuem a menor latência do conjunto de memórias disponíveis.

São nos registradores onde a CPU vai armazenar instruções e dados do programa em execução, de modo a manipular sem precisar ficar dando tantos "saltos" na memória principal, economizando assim latência e ciclos de CPU.

Vamos pensar nos registradores como "caixinhas" de tamanho fixo que ficam dentro da CPU.

E como podemos manipular os registradores da CPU? Devemos estabelecer um padrão, que define como controlar o conjunto de instruções da CPU.

Precisamos de uma arquitetura de conjunto de instruções, ou ISA (Instruction Set Architecture).

ISA

ISA serve para definir o conjunto instruções e registradores em uma determinada CPU. O fabricante define a ISA, que pode ser classificada de formas diferentes, determinando quantas operações podem ser feitas por instrução, entre outros aspectos.

Neste artigo vamos destacar 2 abordagens de conjunto de instruções: CISC e RISC.

CISC

CISC, ou Complex Instruction Set Computing, é uma arquitetura onde as instruções podem ser agrupadas em conjuntos mais complexos de instruções, permitindo que uma única instrução execute várias operações complexas.

Aqui, determinadas tarefas podem resultar em apenas um ciclo de CPU, o que aumenta eficiência, mas por outro lado, esta complexidade de instruções pode tornar o tempo de execução menos previsível.

Exemplos de arquiteturas CISC incluem System/360, PDP-11 e Intel 8086.

RISC

Para resolver o problema de instruções muito complexas em CISC, a arquiteura RISC, ou Reduced Instruction Set Computing, determina uma execução mais simples com menos instruções, diminuindo assim o número de circuitos e consequentemente ciclos de CPU. O tamanho das instruções geralmente é fixo, resultando em um desempenho mais rápido e previsível.

Exemplos de arquiteturas RISC são MIPS e ARM, sendo ARM atualmente utilizada nos processadores de MacBook M1 em diante.

Este é um dos motivos de um MacBook ARM consumir menos bateria e fazer menos barulho, por exemplo.

E já que o tema é x86...

Como a saga se trata de x86, especificamente 64-bit (logo mais vamos entender o motivo disso), inicialmente esta arquitetura foi desenvolvida seguindo o padrão CISC, que é o conjunto complexo de instruções.

Entretanto a ISA do x86 foi adaptada para suportar internamente operações simplificadas como encontramos em RISC, portanto pode-se sizer que x86 é um "fake-CISC", que segue um modelo "RISC-ish".

Por quê x86?

Alguns leitores mais atentos devem estar se perguntando: por quê raios x86? O que isto significa?

Bom, pra entender o que é isto, vamos mergulhar um pouco na história dos microprocessadores da Intel.

Anos 70

Os anos 70 foram primordiais. Além da explosão cambriana de sistemas operacionais, vemos também a consolidação da era dos transistores e assim a evolução das CPU's.

Do lado Intel, temos o 8080 de 8-bit lançado em 1974, que além de ser utilizado em sistemas industriais, também foi amplamente encontrado nos primeiros computadores pessoais.

Intel 8086

Esta versão traz consigo conjuntos de instruções de 16-bits e foi um marco na era dos computadores pessoais. É aqui que passa a ser cunhado o termo de família "x86", pois o "x" caracteriza qualquer número que venha antes de "86".

Intuitivo, não?

Anos 80, a década do Intel x86

A partir de então, nesta década vimos a chegada do 80286 (286) que suporta também 16-bit + 8-bit de endereçamento de memória; depois, o famoso 80386 (i386), que trouxe uma grande mudança suportando instruções de 32-bit e os famosos registradores exx (eax, ebx, eip, etc); para então chegarmos ao 80486 (486), que foi uma melhoria do 386 com suporte a instruções mais avançadas.

Pra quem tiver curiosidade em saber a especificação da arquitetura x86, está tudo bem documentado num simples manual de 5000 páginas

Anos 90, Pentium e além

O que vem a seguir é a evolução seguindo com os Pentium 586, 686 e depois, uma simplificação dos termos para x86_32 (32-bit) ou x86_64 (64-bit).

Destaca-se os Pentium II, III e os Core "i AlgumaCoisa" que perduram até hoje.

E os AMD?

Enquanto a Intel dominava o mercado de CPU's, a AMD (Advanced Micro Devices) mexeu os palitinhos e também lançou versões compatíveis com x86, portanto pode-se dizer que, ao desenvolver para arquitetura x86, é possível executar as mesmas instruções em uma CPU fabricada pela AMD.

Conclusão

É isto. Este foi um artigo bastante denso, que cobriu uma breve história dos computadores, passando por modelos computacionais até chegar nas arquiteturas de CPU's e entendermos o que significa aquele "x86" no título do artigo.

No próximo artigo, pretendo trazer brevemente sistema binário e hexadecimal para então começar a apresentar aquilo que estamos todos interessados: linguagem de montagem, ou simplesmente Assembly.

Artigo revisado com carinho por Jeff Quesado, o "Coelho da Bolha", e também por Cadu, o músico frustrado (same thing).

Referências

Para alguns, um monstrinho. Pra outros, algo antiquado. Mas pra quem tem curiosidade em entender como as coisas funcionam, oportunidade.

Nesta saga que será uma série de artigos, vamos explorar Assembly com NASM para arquitetura x86-64 em GNU/Linux enquanto desenvolvemos um web server multi-thread bastante simples.

O intuito não está nas capacidades do web server em si, pois este irá apenas responder uma mensagem "Hello, world" em formato HTML, mas sim nos conceitos utilizados para construi-lo.

Para quem não tem muita familiaridade com conceitos de mais baixo-nível em computação e concorrência, não se preocupe, pois queremos com este guia fazer com que temas que são vistos como "complexos" possam ser absorvidos com mais facilidade a quem tem curiosidade, podendo então causar aquela boa impressão no churrasco de domingo ou no jantar de Natal.

To brincando gente, tá proibido falar de Assembly nestas ocasiões, por favor não façam isso eu imploro

Conteúdo proposto

Ao longo dos artigos vamos passar por diversos conceitos de computação, sendo alguns de forma superficial e outros com um pouco mais de profundidade, podendo mencionar alguns:

• Arquitetura de computadores

• Tipos de arquiteturas

• Padrões, sistema binário e hexadecimal

• Básicos de Assembly x86-64

• Debugging com GDB

• Filesystem, Sockets

• Threads, pool e alocação de memória

• Arrays, filas, ponteiros

• Concorrência e primitivos de sincronização como spinlocks e futex

• Tag h1 do HTML (LOL)

Poderá haver mais conceitos a serem abordados, mas que serão mapeados e detalhados conforme necessidade.

É um tutorial de Assembly?

Definitivamente, não.

A ideia aqui é desenvolver de forma prática um servidor web enquanto passamos por conceitos de Assembly e não só, mas também outros temas importantes sobre concorrência.

Se quer fazer um tutorial rápido para se familiarizar com Assembly x86, há este do tutorials point, mas atenção que ele é para 32-bits, sendo que nosso guia será feito em 64-bits (uma vez entendido os conceitos, fica fácil transportar).

É um curso de Assembly?

Hell no.

Obviamente, vamos aprender diversos conceitos à medida que avançamos na saga, mas se você tem algum interesse em aprender fundamentos de Assembly de forma bastante didática, sugiro acompanhar a playlist de Fundamentos de Assembly x86-64 do Blau Araújo. Ele é referência no assunto em conteúdo pt-BR e já cortou muito mato neste assunto.

Requisitos de ambiente

É esperado que o código seja executado em um sistema UNIX-based, preferencialmente GNU/Linux x86_64 que é onde testamos o código proposto.

• Sistema Operacional Ubuntu 22.04.4 LTS (GNU/Linux 6.5.0-17-generic x86_64)

• NASM 2.16.01

• GNU ld 2.38 (binutils)

E para debugging (claro, nesta casa fazemos debugging, não somos brincalhões):

• GNU gdb 12.1

• strace 5.16

Para outros ambientes, pode-se optar por rodar o código dentro de um container Docker, seguindo as versões acima apresentadas.

Exemplo de Dockerfile (validar isto plmdds):

FROM ubuntu
RUN apt-get update && apt-get -y install make binutils gdb build-essential wget strace
WORKDIR /app
RUN wget https://www.nasm.us/pub/nasm/releasebuilds/2.16.01/nasm-2.16.01.tar.gz -O nasm.tar.gz && tar -xzvf nasm.tar.gz && cd nasm-2.16.01 && ./configure && make && make install

Será que consigo acompanhar?

Você pode apenas ler e tentar entender os conceitos, ou então ser mais hands-on e escrever código à medida que avança nos artigos.

Recomendo fortemente que experimente o código e rode em seu próprio computador seguindo os requisitos de ambiente, seja em host, virtualizado ou containerizado.

O repositório com o código completo pode ser encontrado em leandronsp/magali.

Este artigo é o primeiro de uma série que vamos explorar sobre Assembly x86-64 enquanto desenvolvemos um web server do zero, sem enrolação e com muita mão na massa.

No próximo artigo já iremos começar com introdução a arquiteturas de computadores e o básico necessário com as terminologias e um pouco de história dos computadores, padrões e linguagens Assembly.

Stay tuned!

Vou voltar a escrever coisas técnicas com frequência, prometo

Mas antes de tudo, queria deixar claro que este bait post aqui é mais uma reflexão do que algo técnico. Não tem referências, não é uma verdade absoluta. Apenas uma reflexão.

Afinal, como dividimos os níveis de conhecimento? Por exemplo, costumamos ver uma divisão entre básico, intermediário e avançado, certo?

Aí é onde entra minha reflexão.

Um pouco de contexto

Esses dias estava conversando com uns colegas de trabalho e de repente chegamos nesse tema, sobre o que considerar básico ou avançado.

Pra mim, um dos problemas é que esta divisão pode causar um pouco de ansiedade em algumas pessoas, pois elas se consideram no "básico" e se vêem muito longe do conhecimento que consideram "avançado".

O outro problema advém da régua que estamos nivelando. Ao determinar que tudo se começa pelo básico, e ao vermos que o distanciamento para o avançado é muito grande, isto pode nos deixar presos ao que consideramos básico, portanto, sempre nivelando o conhecimento médio para baixo.

O básico não é o que parece

Minha provocação é que o básico não deveria ser considerada a porta de entrada do conhecimento em algum tema.

Ao entrarmos em alguma nova área de conhecimento, estamos de fato em uma superfície, portanto coloco este nível de conhecimento como superficial. Após termos um conhecimento superficial sobre algo, é o momento de entrarmos no básico, o que significa aprofundar um pouco mais neste conhecimento de tal modo que possamos estar dominando este conhecimento básico.

Veja, não vamos considerar o domínio em algo como sendo expert ou avançado naquele conhecimento. Não. O domínio do básico deveria ser de tal forma que todos nós buscamos se tivermos algum interesse e, principalmente, se formos atuar com aquele tema no dia-dia.

Deturparam o básico

Muito se vê comentarem sobre o problema das pessoas saberem o básico ou então criticarem quando alguém compartilha algum tipo de conteúdo considerado "básico".

Algumas definições de básico no dicionário:

Que serve como base; essencial, basilar.

O mais relevante ou importante de; fundamental.

Ou seja, o básico tem muito a ver com o fundamental, ou essencial. Ao meu ver, é extremamente importante dominarmos o básico se quisermos atuar com este conhecimento de forma frequente.

Teu conhecimento é superficial

Muitas vezes, o que pensamos ser o conhecimento básico em algo é, na verdade, um conhecimento superficial.

Sabemos apenas a superfície. Temos uma noção de como aquilo funciona. Mas não conhecemos profundamente.

Avançar para o básico consiste em aprofundar neste conhecimento. E o básico pode muitas vezes parecer complexo.

Mas calma, já explico como dominar o conhecimento básico, e não precisa se desesperar, é necessário apenas um certo grau de dedicação que no fim vai fazer se sentir melhor e mais próximo do que consideramos avançado.

Domínio do conhecimento básico

Okay, mas como dominar o conhecimento básico? Aqui entra uma técnica muito sofisticada que consiste em:

• fazer tutoriais

• praticar

Ah, Leandro. Você tá de BRINCADEIRA COM A MINHA CARA??

Calma, xofem. Tutoriais são extremamente importantes. Faça tutoriais, um, dois, três, quantos puder. Tire conclusões. Descarte o que não vale a pena.

E depois pratique com aquilo que já sabe. Por exemplo, ao aprender uma nova linguagem de programação, é muito útil escrever um projeto, trecho de código, algoritmo, estrutura de dado, whatever o que quiser que você já tenha feito em outras linguagens.

Isto se chama prática. A prática vai fazer você sair do nível "tutorial" e aprofundar em conceitos básicos, o que naturalmente vai te fazer dominar este nível do conhecimento.

Uma breve analogia (detesto analogias mas aqui vai) é quanto aos níveis de inglês, ou qualquer outro idioma. Muitos pensam que fluência em inglês está no último patamar mas não, a fluência está em todos os níveis: é possível saber apenas o básico do inglês mas buscar fluência dentro do básico.

É sobre isto que estou falando.

Saindo do superficial

O lance é que podemos sair do superficial. Este conhecimento de superfície costumo dizer que é como "molhar o pé na piscina". Molhou, a água tá boa? Dá um mergulho, sente a piscina (lá ele com analogia de novo, aff).

O superficial nos dá uma noção, mas sentimos que não dominamos. Sentimos muita dificuldade. Pra mim, muitas dificuldades em algo denunciam um conhecimento superficial, e não o básico.

Ao sair do superficial e buscarmos dominar o básico em algo, estamos subindo a régua, isto nos coloca mais próximos do que consideramos "avançado", mas sem adicionar ansiedade.

Tá mas o quê é avançado?

Pra mim, o avançado é basicamente (trocadilho não intencional) se aprofundar ainda mais naquela área do conhecimento. É quando você, apesar de estar confortável com o conhecimento de base e não ficar bloqueado com frequência, quer entrar mais em detalhes e talvez buscar ser ainda mais proficiente naquela área.

Não vou aprofundar em como entrar no avançado, talvez fique pra outro post. Mas aqui meu foco é saindo de superficial e entrando no básico.

Vamos a exemplos práticos

Por exemplo, em web, o conhecimento superficial seria saber que eu digito algo no navegador e alguma coisa acontece no servidor. Daí vou olhar o servidor pra ver o que aconteceu. Vejo logs, erros, etc e tento entender esses erros, perguntando, pesquisando e usando outros métodos.

Já o conhecimento básico me coloca num ponto onde sei que por trás desse pedido do navegador, está acontecendo a resolução de nome, roteamento, conexão TCP através da internet, onde do outro lado há uma aplicação rodando em uma porta do sistema operacional atravé de TCP, etc e etc. Este conhecimento me ajuda a aumentar o vocabulário na área e a extrapolar para outros contextos que não web, facilitando na resolução de problemas (troubleshooting).

Já o avançado é quando vou hackear roteadores, usar sysdig para fazer bait de hackers no meu servidor, entre outros aspectos (sigh).

Outro exemplo prático

Compiladores. Saber que nossa linguagem é "compilada" para código de máquina é um conhecimento superficial. Conseguimos seguir adiante com este conhecimento? Claro. No dia-dia muitos de nós fazemos CRUD, não é?

Mas o conhecimento básico nos coloca em outro patamar, como entender que está acontecendo a etapa de análise léxica, parsing, otimizações, transformações etc antes de ser gerado de fato o código de máquina. Dominar o básico de compiladores pode ser essencial para identificar pontos de performance em alguma aplicação quando a "água bater no pescoço" em um problema bicudo.

Se você estiver no superficial em compiladores, okay ninguém vai te cobrar nada. Mas imagina fazer parte do grupo que foi lá, arregaçou a manga e fez aquele tweak no interpretador adicionando uma mísera flag apenas porque você sabe o básico de compiladores? Então...

Já o avançado de compiladores considero que seria entender a fundo as otimizações, criar o próprio JIT, fazer patch em runtime, escrever algoritmos de parsing e coisas do gênero.

And so on...

Conclusão

Veja, cara pessoa leitora, que não quero causar aqui algum tipo de entropia. Quero apenas que entenda que é possível dominar o básico sem ansiedade, sem toda a carga imposta para saber coisas avançadas em algo.

Ao dominar o básico, um dia você pode encontrar inspiração e vontade para ir mais a fundo no avançado (mas isto não é de todo obrigatório), mas entenda que o conhecimento básico é que nos faz subir no conhecimento, nivelando a régua pra cima, e não pra baixo.

Mas tudo o que você disse não é o mesmo que básico, intermediário e avançado?

Interprete como quiser, mas a percepção de estarmos no básico nos afasta do intermediário. Bora sair do básico e ir pro intermediário então, se isto ajudar...rs

Mas eu não quero saber o básico, quero ficar apenas no superficial

Tá tudo bem também. É a sua escolha saber o superficial em algo. Se isto não causa nenhuma ansiedade ou te faz mal por não saber coisas mais "avançadas", é perfeitamente aceitável continuar no superficial :)

That's all folks!

First things first

Generally, a background job operates on one or more threads that continuously consume messages from a queue.

In this post, we'll use a Vector to represent our queue.

This Vector is an instance of the standard Rust library implementation known as VecDeque. VecDeque is a double-ended queue that acts as a growing ring buffer.

Data model

To make our solution more organized, we can define 3 structs:

Transmitter

The transmitter (tx) holds an store, which is the queue (Vector) encapsulated by a Arc/Mutex; and an emitter, which is a Condvar, used for synchronization based on a condition.

Receiver

The receiver (rx), pretty much like the transmitter, also holds a store and an emitter.

Channel

Channel holds a transmitter and a receiver.

struct Transmitter<T> {
    store: Arc<Mutex<VecDeque<T>>>,
    emitter: Arc<Condvar>,
}

struct Receiver<T> {
    store: Arc<Mutex<VecDeque<T>>>,
    emitter: Arc<Condvar>,
}

struct Channel<T> {
    tx: Transmitter<T>,
    rx: Receiver<T>,
}

What is an Arc in Rust?

The queue (VecDeque) is going to be shared across the channel for one or more threads.

In Rust, such problem requires shared ownership addressed by a reference counter (Rc), but since we are in a multi-thread scenario, Rc is not thread-safe, that's why we need an atomic reference counter, or simply Arc, which is indeed thread-safe.

You can learn more details about smart pointers by reading my post on Understanding the basics of smart pointers in Rust

How about Mutex?

Since Arc is a reference counter, its references are immutable. For mutability in the underlying data, we need interior mutability using RefCell.

My mentioned post about smart pointers also covers interior mutability, check it out for further details

In the same as Rc, RefCell is not thread-safe. For a thread-safe scenario, we need to synchronize access to data using locks. That's where mutual exclusion (Mutex) comes in.

Okay, and Condvar? What the heck is that?

Condvar is a primitive for synchronization in concurrent systems where we can put a thread to "wait" (suspended) until a given condition is met.

For blocking queues, we basically want the following condition (pseudo-code):

queue = some_array
mutex = os_lock
emitter = os_condvar

// Thread is suspened until the array gets some data
// There's no CPU consume
while queue is empty
   emitter.wait(mutex)
end

// Someone emitted a signal
data = queue.pop

In other process:

queue.push(data)
emitter.signal

Data modeling implementation

Now, let's implement the methods send and recv (receive) in our simulated channel.

Transmitter

The transmitter (tx) will have a method called send, which basically:

• locks the shared queue (store.lock().unwrap())

• pushes data to the queue (push_back(data))

• emits a signal (emitter.notify_one) to notify some suspended thread that is waiting for data in the queue

impl<T> Transmitter<T> {
    fn send(&self, data: T) {
        self.store.lock().unwrap().push_back(data);
        self.emitter.notify_one();
    }
}

Receiver

The receiver (rx) has a method called recv (short for receive) which:

• creates a lock in the shared queue (store.lock().unwrap())

• suspends the current thread until the condition is met, in other words, while the queue is empty, the thread is suspended in the operating system, thus not consuming CPU (emitter.wait)

• once the thread is awaken, it can pops the data from the queue (store.pop_front())

impl<T> Receiver<T> {
    fn recv(&self) -> Option<T> {
        let mut store = self.store.lock().unwrap();

        while store.is_empty() {
            store = self.emitter.wait(store).unwrap();
        }

        store.pop_front()
    }
}

Moreover, the Receiver struct can have an extra method called try_recv which does not block the thread, not using the Condvar condition:

fn try_recv(&self) -> Option<T> {
    self.store.lock().unwrap().pop_front()
}

Channel

Once the Transmitter and Receiver are already implemented, the implementation of Channel is a piece of cake:

impl<T> Channel<T> {
    fn new() -> Self {
        let store = Arc::new(Mutex::new(VecDeque::new()));
        let emitter = Arc::new(Condvar::new());

        Channel {
            tx: Transmitter { store: Arc::clone(&store), emitter: Arc::clone(&emitter) },
            rx: Receiver { store: Arc::clone(&store), emitter: Arc::clone(&emitter) },
        }
    }
}

Note that both Mutex and Condvar are encapsulated in an Arc (atomic reference counter), because we have to share them across tx and rx at the same time.

Main

The main function can me implemented as follows:

• create a channel and binds the tx and rx respectively

• the channel holds a shared Mutex/VecDeque and a Condvar

• tx is used to send data to the channel

• rx is used from the inner thread to receive data from the channel

fn main() {
    // Initialize channel
    let channel = Channel::new();
    let (tx, rx) = (channel.tx, channel.rx);

    // Push data to the channel
    tx.send("Some job to do: 1");
    tx.send("Another job: 2");

    // Process the channel
    let worker = thread::spawn(move || {
        loop {
            let job = rx.recv(); // we could use try_recv too

            match job {
                Some(job) => println!("Job: {}", job),
                None => break,
            }
        }
    });
    
    // Push more data to the channel
    tx.send("Yet another job");

    worker.join().unwrap();
}

We run the code and, Yay, everything is working as expected:

Job: Some job to do: 1
Job: Another job: 2
Job: Yet another job

Rust channels for the rescue

You may be wondering:

Hey Leandro, why doesn't Rust bring all this stuff already built-in? Do we really need to implement a raw queue and use synchronization primitives on our own every time we want to create a channel for threads?

Today is your lucky day. Indeed Rust brings Channels, which employ the same techniques described in this very post, but more robust, of course:

use std::sync::mpsc;
use std::thread;

fn main() {
    // Initialize channel
    let (tx, rx) = mpsc::channel();

    // Push data to the channel
    tx.send("Some job to do: 1").unwrap();
    tx.send("Another job: 2").unwrap();

    let worker = thread::spawn(move || {
        loop {
            let job = rx.recv();

            match job {
                Ok(job) => println!("Job: {}", job),
                Err(_) => break,
            }
        }
    });

    // Push more data to the channel
    tx.send("Yet another job").unwrap();

    worker.join().unwrap();
}

• mpsc stands for multiple producers, single consumer

• mpsc::channel creates a channel with a internal shared queue and returns a transmitter (tx) and a receiver (rx)

• pretty much like our custom implementation, tx.send sends data to the channel, whereas tx.recv reads/pops data from the channel

How cool is that?

References

https://doc.rust-lang.org/book/ch16-00-concurrency.html

https://doc.rust-lang.org/std/vec/struct.Vec.html

https://doc.rust-lang.org/std/collections/struct.VecDeque.html

https://leandronsp.com/articles/understanding-the-basics-of-smart-pointers-in-rust-3dff

Prelude, intro to Rust

It's not intended to be an introduction about Rust. For that, you can follow along this blogpost series by @mfcastellani.

Also, you can read his book (pt-BR). Moreover, I have a live coding video where I explored the Rust fundamentals by covering an introduction to Rust, data types, functions, ownership, references, structs/enums and error handling.

Another content about Rust I higly recommend is presented on this Youtube channel by Bruno Rocha, which creates great videos about Rust as well (pt-BR).

Please note that this post you are currently reading was written during a live coding session (pt-BR) where you can follow the process I use to write blogposts in general and how I created this particular one. It's a novel format I'm experimenting with to share content.

However, if you are looking for introdutory content in english only, the Youtube channel Let's get Rusty provides great content on Rust from basics to advanced.

No more introduction, let's embark on this journey of Smart Pointers in Rust.

Table of Contents

• First things first

• A linked list using Rust

• Meet the Box smart pointer

• Shared ownership using Rc

• Interior mutability with RefCell

• Weak references on a circular linked list

👉 First things first

Rust employs a mechanism for dealing with memory management where it prevents dangling references, double free error and other problems related to memory management.

This mechanism is called "ownership" and through RAII (Resource Acquisition Is Initialization), it follows three basic rules:

• Each value in Rust has a single owner

• There are only one owner at a time

• When the owner's scope is finished, its associated value is dropped and invalidated

When we need to transfer ownership, in case the value is in the stack (fixed-sized types), Rust performs a Copy:

I'm assuming that all code snippets within this post are being executed inside a fn main() {} function

let age = 20;
let copied_age = age;

println!("copied_age: {}", copied_age);
println!("age: {}", age); // age is still valid because Rust performs a "Copy" for data in the stack

As for dynamically-sized types, which live in the heap, Rust performs a Move:

let name = String::from("John");
let other_name = name;

println!("other_name: {}", other_name);
println!("name: {}", name); // name is no loger valid because Rust performs a "Move"

// Error:
// error[E0382]: borrow of moved value: `name`

Copy literally copies the data in the stack, while the Move operation transfers ownership, which means that the former owner is no longer the owner and its reference is completely dropped.

👉 A Linked List using Rust

A linked list is a data structure which represents a collection of nodes where each node points to the next node. This is basically a singly linked list.

Also, we can build a linked list where each node points to the previous node as well. In this case, such a list is called doubly linked list.

🔵 A Singly Linked List

The first version of our linked list will be a singly one. As we evolve to a doubly linked list, we'll bring Rust concepts about ownership, references and smart pointers.

We start by modeling the Node:

struct Node {
    value: i32,
    next: Node
}

We are bound to situations where the next pointer points to "nothing", or simply a null pointer when the list reaches the end, commonly seen in a variety of programming languages.

But Rust has no null pointers. That said, we can represent the next pointer by using the enum Option, which in Rust gives us two possibilities of types:

• None (the end of the list)

• Some(node)

struct Node {
    value: i32,
    next: Option<Node>
}

let head = Node { value: 1, next: None };
assert_eq!(1, head.value);
assert_eq!(None, head.next);

The above code is not yet compiling:

error[E0072]: recursive type `Node` has infinite size
 --> src/main.rs:2:5
  |
2 |     struct Node {
  |     ^^^^^^^^^^^
3 |         value: i32,
4 |         next: Option<Node>
  |                      ---- recursive without indirection
  |
help: insert some indirection (e.g., a `Box`, `Rc`, or `&`) to break the cycle
  |
4 |         next: Option<Box<Node>>
  |                      ++++    +

The Rust compiler is saying that Node has unknown size at compile-time and as such it can't be determined, because the "next" pointer points to another Node which points to another Node and so on, infinitely.

This is a recursive type.

In order to solve this problem, we have to help the Rust compiler to use some abstraction which can allocate data on the heap and determine the size of the Node at compile-time, resolving the recursive type.

Such abstraction is called Box, which is a smart pointer in Rust.

👉 Box

By using Box, we want to allocate the data on the heap.

Also, Box has a known size at compile-time. Being a pointer, the size of the Box is the pointer size, which makes it a good fit for recursive types.

The following code compiles sucessfully:

#[derive(Debug, PartialEq)]
struct Node {
    value: i32,
    next: Option<Box<Node>>
}

let head = Node { value: 1, next: None };

assert_eq!(1, head.value);
assert_eq!(None, head.next);

What if we add one more node, called "tail"?

let tail = Node { value: 2 next: None };
let head = Node { value: 1, next: Some(tail) };

As always (the Rust compilers always wins), it won't compile:

---- ^^^^ expected `Box<Node>`, found `Node`

We have to wrap the tail in a Box:

struct Node {
    value: i32,
    next: Option<Box<Node>>
}

let tail = Box::new(Node { value: 2, next: None });
let head = Node { value: 1, next: Some(tail) };

assert_eq!(1, head.value);
assert_eq!(2, head.next.unwrap().value);

• We wrap the tail box in an Option (Some)

• The head.next points to an Option. Because it's the enum Option, we have to call unwrap to fetch the underlying value

Let's go further in the example and implement a doubly linked list, by specifying the prev attribute on the Node struct.

🔵 A Doubly Linked List

struct Node {
    value: i32,
    next: Option<Box<Node>>,
    prev: Option<Box<Node>>,
}

let tail = Box::new(Node { value: 2, prev: None, next: None });
let head = Node { value: 1, prev: None, next: Some(tail) };

• the head.prev points to None

• the tail.prev points to None (at this moment...)

In order to change the tail.prev, we have to mutate its underlying value, from None to Some(head). May we change the source code:

let mut tail = Box::new(Node { value: 2, prev: None, next: None });
let head = Box::new(Node { value: 1, prev: None, next: Some(tail) });

tail.prev = Some(head); // mutating the tail.prev

And...

error[E0382]: use of moved value: `head.next`
  --> src/main.rs:14:15
   |
9  | let head = Box::new(Node { value: 1, prev: None, next: Some(tail) });
   |     ---- move occurs because `head` has type `Box<Node>`, which does not implement the `Copy` trait
10 |
11 | tail.prev = Some(head);
   |                  ---- value moved here
...
14 | assert_eq!(2, head.next.unwrap().value);
   |               ^^^^^^^^^ value used here after move

Welcome to the ownership saga in Rust!

Let's clarify some points here:

First, a Box has single ownership, meaning that each value holds one owner at a time. Here, in this line:

let head = Box::new(Node { value: 1, prev: None, next: Some(tail) }); // value was moved here

Tail has been moved, that's why we cannot use it later, due to ownership rules.

To fix that, we can make use of the method clone implemented in the Box, which will perform a deep copy (clone) of the value in the heap:

let head = Box::new(Node { value: 1, prev: None, next: Some(tail.clone()) });

tail.prev = Some(head);

Additionally, in the following line, tail.prev takes ownership of the value of head, so the value was moved to the new owner:

tail.prev = Some(head); // value as moved here

Now the solution is calling clone as we did in the tail:

tail.prev = Some(head.clone());

Here's the current solution for a doubly linked list using Box:

#[derive(Clone)]
struct Node {
    value: i32,
    next: Option<Box<Node>>,
    prev: Option<Box<Node>>,
}

let mut tail = Box::new(Node { value: 2, prev: None, next: None });
let head = Box::new(Node { value: 1, prev: None, next: Some(tail.clone()) });

tail.prev = Some(head.clone());

assert_eq!(1, head.value);
assert_eq!(2, tail.value);
assert_eq!(2, head.next.unwrap().value);
assert_eq!(1, tail.prev.unwrap().value);

By using Box, we've solved the problem but we may end up wasting memory, as demonstrated in the following picture:

At this point in time, we have the following abstraction model about ownership, which is single and shares no value in the heap (Box):

We have to find a way to overcome the single ownership problem. What about not taking ownership at all, by using References instead?

🔵 References & Lifetimes

References in Rust do not take ownership, as they allow to work with the reference of the data which is allocated in the heap.

This way, references can be "borrowed" without taking ownership, and as such they are bound to a mechanism called borrow checker.

let name = String::from("John"); // value in the heap. name is the owner
let other_name = &name; // not a move. other_name has a reference to the value in the heap. name is still the owner

println!("other_name: {}", other_name);
println!("name: {}", name);

The above code compiles successfully. The borrow checker ensures that the reference is pointing to some valid value in the heap, thus not "moving" the ownership.

Let's change the code to use References instead of Box:

struct Node {
    value: i32,
    next: Option<&Node>,
}

let tail = Node { value: 2, next: None };
let head = Node { value: 1, next: Some(&tail) };

• The next is an enum Option which wraps a reference to another Node

• The head.next is now using Some(&tail) which is a reference to the tail (other node), instead of a Box which takes ownership

But this code won't compile yet:

error[E0106]: missing lifetime specifier
 --> src/main.rs:4:18
  |
4 |     next: Option<&Node>,
  |                  ^ expected named lifetime parameter
  |
help: consider introducing a named lifetime parameter
  |
2 ~ struct Node<'a> {
3 |     value: i32,
4 ~     next: Option<&'a Node>,

Each reference has an implicit lifetime in the Rust compiler. In our example of a linked list, the compiler can't determine the lifetime of the next pointer because it points to another Node which could have a different lifetime.

Because the borrow checker prevents dangling references by using lifetimes, we have to help the compiler by annotating lifetimes in the struct definition:

struct Node<'a> {
    value: i32,
    next: Option<&'a Node<'a>>,
}

// or, using generics

struct Node<'a, T> {
    value: T,
    next: Option<&'a Node<'a, T>>,
}

It's quite verbose, I know. 😬

Now the version of a singly linked list using references:

#[derive(Debug, PartialEq)]
struct Node<'a, T> {
    value: T,
    next: Option<&'a Node<'a, T>>,
}

let tail = Node { value: 2, next: None };
let head = Node { value: 1, next: Some(&tail) };

assert_eq!(1, head.value);
assert_eq!(2, head.next.unwrap().value);
assert_eq!(None, tail.next);

• The Node and its next (reference) node has a lifetime 'a

• we can use tail/head even after they been applied to the repective nodes, because we took no ownership

But a singly linked list is not enough. We want a doubly one:

#[derive(Debug, PartialEq)]
struct Node<'a, T> {
    value: T,
    next: Option<&'a Node<'a, T>>,
    prev: Option<&'a Node<'a, T>>,
}

let mut tail = Node { value: 2, prev: None, next: None };
let head = Node { value: 1, prev: None, next: Some(&tail) };

tail.prev = Some(&head);

assert_eq!(1, head.value);
assert_eq!(2, head.next.unwrap().value);
assert_eq!(None, tail.next);

We run the code and...

error[E0506]: cannot assign to `tail.prev` because it is borrowed
  --> src/main.rs:12:1
   |
10 | let head = Node { value: 1, prev: None, next: Some(&tail) };
   |                                                    ----- `tail.prev` is borrowed here
11 |
12 | tail.prev = Some(&head);
   | ^^^^^^^^^^^^^^^^^^^^^^^ `tail.prev` is assigned to here but it was already borrowed
13 |
14 | assert_eq!(1, head.value);
   | ------------------------- borrow later used here

What happened here?

The borrow checker checks at compile-time that we can have only one mutable reference at a time in the same scope.

Our example has a scenario where the tail.prev is mutable and is already borrowed to the head.

That's why we simply can't implement a doubly linked list in Rust using references (AFAIK).

Then we should go back to ownership. But what about having a "shared ownership" instead of a "single ownership" like in the Box example?

Enter Rc.

👉 Rc

Rc stands for reference counting, which performs heap allocation, like a Box.

But unlike Box, it enables shared ownership, where one or more owners point to the same value in the heap. Each time an owner comes to the party, it increments the counter. When the owner goes out of scope, it decrements the counter.

Only when all owners are dropped, then the Rc is entirely dropped as well freeing the underlying data from the heap.

Rc brings one caveat: the reference must be immutable. Otherwise, it would lead to double-free errors.

use std::rc::Rc;
let name = Rc::new(String::from("John"));

assert_eq!(1, Rc::strong_count(&name));

let cloned_name = Rc::clone(&name);

assert_eq!(2, Rc::strong_count(&name));
assert_eq!("John", *cloned_name); // Dereference
assert_eq!("John", *name); // Dereference

Each time an Rc is called data.clone() or by using Rc::clone(&data), the data is not being copied on the heap (deep copy). Only the reference is copied and the strong count of references is incremented.

The original owner is still valid after cloning multiple Rc references.

Let's implement the singly linked list using Rc instead of references or Box:

use std::rc::Rc;

struct Node<T> {
    value: T,
    next: Option<Rc<Node<T>>>
}

Cool, now let's add some data to our linked list:

let tail = Rc::new(Node { value: 2, next: None });
let head = Rc::new(Node { value: 1, next: Some(tail) });

assert_eq!(1, head.value);
assert_eq!(2, head.next.clone().unwrap().value);

It simply works! How cool is that?

Time to evolve to a doubly linked list using Rc:

use std::rc::Rc;

struct Node<T> {
    value: T,
    next: Option<Rc<Node<T>>>,
    prev: Option<Rc<Node<T>>>,
}

let tail = Rc::new(Node { value: 2, prev: None, next: None });
let head = Rc::new(Node { value: 1, prev: None, next: Some(Rc::clone(&tail)) });

tail.prev = Some(Rc::clone(&head));

assert_eq!(1, head.value);
assert_eq!(2, head.next.clone().unwrap().value);

Instead of deep copy like in Box, the Rc smart pointer only increments the reference counter. Check Rc::clone(&head) and Rc::clone(&tail).

But it won't compile:

error[E0594]: cannot assign to data in an `Rc`
  --> src/main.rs:24:5
   |
24 |     tail.prev = Some(Rc::clone(&head));
   |     ^^^^^^^^^ cannot assign

Cannot assign data in an Rc!

Even if we used let mut tail = ..., Rc is now allowed to mutate because all references in Rc are immutable.

How about mutating the underlying data even if the reference is immutable? We could achieve that by using "unsafe Rust", where some checks could be done at runtime instead of compile-time.

Even better, what about Rust providing an abstraction which uses unsafe capabilities under the hood but wrapping in a safe API?

Yes, we are talking about RefCell.

👉 RefCell

RefCell is an smart pointer which provides a safe API to mutate underlying data (on the heap) but through immutable references.

This approach is called interior mutability.

The borrow checker won't perform checks, but Rust will check them at runtime. In case we cause a problem regarding mutable data, the program will crash and stop (panic!).

use std::cell::RefCell;

let name = RefCell::new(String::from("John"));
name.borrow_mut().push_str(" Doe");

assert_eq!("John Doe", *name.borrow());

• RefCell wraps a String in the heap

• The reference is immutable

• Through borrow_mut, we get RefMut<T> to mutate the underlying data

• Through borrow, we get a Ref<T> to read the underlying data

In a RefCell, we can have multiple borrows for reading or only one borrow mutable for writing.

With that in place, time to implement our doubly linked list using Rc + RefCell:

    use std::rc::Rc;
    use std::cell::RefCell;

    struct Node<T> {
        value: T,
        next: Option<Rc<RefCell<Node<T>>>>,
        prev: Option<Rc<RefCell<Node<T>>>>,
    }

    let tail = Rc::new(RefCell::new(Node { value: 2, prev: None, next: None }));
    let head = Rc::new(RefCell::new(Node { value: 1, prev: None, next: Some(Rc::clone(&tail)) }));

    tail.borrow_mut().prev = Some(Rc::clone(&head));

    assert_eq!(1, head.borrow().value);
    assert_eq!(2, head.borrow().next.clone().unwrap().borrow().value);
    assert_eq!(1, tail.borrow().prev.clone().unwrap().borrow().value);

Our Node model now is composed of a value and a next pointer which basically is:

• an enum Option

• which wraps an Rc (shared ownership)

• which wraps an RefCell (for interior mutability)

• which points to other Node

• and so on and on and on...

With RefCell, every time we have to write, we use borrow_mut, and every time we have to read, we use borrow.

How wonderful is that?

👉 Thinking about a circular linked list

In order to make our linked list to be circular, we have to make tail.next point to the head:

use std::rc::Rc;
use std::cell::RefCell;

struct Node<T> {
    value: T,
    next: Option<Rc<RefCell<Node<T>>>>,
    prev: Option<Rc<RefCell<Node<T>>>>,
}

let tail = Rc::new(RefCell::new(Node { value: 2, prev: None, next: None }));
let head = Rc::new(RefCell::new(Node { value: 1, prev: None, next: Some(Rc::clone(&tail)) }));

tail.borrow_mut().prev = Some(Rc::clone(&head));
tail.borrow_mut().next = Some(Rc::clone(&head));

....
assert_eq!(1, tail.borrow().next.clone().unwrap().borrow().value);

What's the challenges of a circular linked list using Rc?

🔵 Strong references may never reach zero

Remember that the Rc underlying data is dropped and invalidated when the Rc::strong_count reaches zero.

But in a circular linked list, for instance, we may have a cyclic reference, which in turn will never make the strong_count to reach zero, leading to memory leaks.

In such a scenario, the tail.next is a "weak" reference. Rust provides a way for Rc to have a different counter, called weak_count.

Thus, the weak counter will not be used for deciding when Rust should drop the value from the heap.

For solving this problem, Rc brings a method called downgrade, which does not involve ownership at all and transforms a strong reference into a weak one.

This smart pointer is called Weak and it's a weak reference in an Rc.

Let's see a basic usage of downgrading or upgrading references in an Rc (see below in the comments):

use std::rc::Rc;

// Just a strong reference
let name = Rc::new(String::from("John"));
assert_eq!(1, Rc::strong_count(&name));

// Cloning Rc is a strong reference
let _other_name = Rc::clone(&name);
assert_eq!(2, Rc::strong_count(&name));
assert_eq!(0, Rc::weak_count(&name));

// Downgrade makes it a weak reference
let weak_name = Rc::downgrade(&name);
assert_eq!(2, Rc::strong_count(&name));
assert_eq!(1, Rc::weak_count(&name));

// Upgrade makes it a strong reference again
let upgraded_name = weak_name.upgrade().unwrap();
assert_eq!(3, Rc::strong_count(&name));
assert_eq!(1, Rc::weak_count(&name));
assert_eq!("John", *upgraded_name);

In a linked list, the prev should be the "weak" reference because starting from the head, the Rc has already strong references that make the entire linked list through the next pointers.

Now, let's explore the final solution of this entire blogpost, using Rc for shared ownership, RefCell for interior mutability and Rc::Weak for preventing cyclic references in a linked list:

use std::rc::Rc;
use std::cell::RefCell;
use std::rc::Weak;

struct Node<T> {
    value: T,
    next: Option<Rc<RefCell<Node<T>>>>,
    prev: Option<Weak<RefCell<Node<T>>>>,
}

let tail = Rc::new(RefCell::new(Node { value: 2, prev: None, next: None }));
let head = Rc::new(RefCell::new(Node { value: 1, prev: None, next: Some(Rc::clone(&tail)) }));

// Weak reference (no ownership)
tail.borrow_mut().prev = Some(Rc::downgrade(&head));

// Strong reference (shared ownership)
tail.borrow_mut().next = Some(Rc::clone(&head));

assert_eq!(1, head.borrow().value);
assert_eq!(2, head.borrow().next.clone().unwrap().borrow().value);
assert_eq!(1, tail.borrow().prev.clone().unwrap().upgrade().unwrap().borrow().value);
assert_eq!(1, tail.borrow().next.clone().unwrap().borrow().value);

Wrapping Up

In this very post we demonstrated the fundamentals smart pointers in Rust and the problems they solve about memory management.

This post was written during a live coding while building a doubly linked list by explaining fundamental concepts of ownership, references, borrowing and smart pointers.

I hope you had fun while learning a bit more about the Rust ownership mental model as I did.

Cheers!

References

https://doc.rust-lang.org/book/

https://en.wikipedia.org/wiki/Smart_pointer

https://ricardomartins.cc/2016/06/08/interior-mutability

https://www.youtube.com/watch?v=6VSgMbFNUuQ

Vamos a isso.

Rinha de compiladores

Em Setembro de 2023 aconteceu na tal #bolhaDev uma outra competição em formato de rinha, mas desta vez o desafio era a construção de um compilador/interpretador que fosse capaz de rodar um programa escrito em uma linguagem especificada para a rinha, chamada - guess what -, rinha.

A competição foi criada por duas meninas fantásticas e que entendem muito desse mundo de compiladores: a Sofia e a Gabi. Ambas tinham o intuito de despertar mais o interesse das pessoas nesse tema de compiladores, o que foi atingido com sucesso: 190 projetos foram submetidos em diversas linguagens de programação. Teve até projetos submetidos em Bash (desta vez não fui eu, risos).

Inicialmente eu só tinha interesse em acompanhar esta rinha de perto sem submeter, apenas pra aprender mais com essa galera que manja bastante. Eu já tinha feito algumas coisas bastante básicas sobre compiladores na faculdade há muito tempo atrás.

Mas após ver a live do brabo Navarro, que trouxe uma didática excelente com sua versão em Rust, decidi entrar também com o intuito de aprender mais e praticar algumas técnicas.

Escolhi Ruby porque eu queria testar um negócio. E disto saiu o patropi.

Okay, mas o que era pra ser feito de fato? Vamos voltar duas casas e entender primeiro o que raios é um compilador ou interpretador.

👉🏽 Arquitetura de CPU e código de máquina

Para que uma CPU possa processar informações, é necessário organizá-la em um conjunto coeso de instruções. A este conjunto organizado de instruções para uma determinada CPU chamamos de arquitetura da CPU.

Existem diversos tipos de arquiteturas de CPU disponíveis, e cada CPU traz um conjunto específico de instruções. Exemplos de arquiteturas: x86, x86-64 (64-bits), ARM (baseada em RISC), MIPS, SPARC, PowerPC dentre outros.

As instruções da CPU são mapeadas para componentes da arquitetura chamados registradores. Para manipularmos esses registradores, precisamos utilizar um conjunto de "códigos" que são pré-definidos pelo fabricante da arquitetura da CPU. Estes códigos são chamados de opcodes, ou código de máquina, ou instruções de máquina.

0000000000401000 
  401000:       48 c7 c0 01 00 00 00    
  401007:       48 c7 c7 01 00 00 00    
  40100e:       48 c7 c6 00 20 40 00    
  401015:       48 c7 c2 0e 00 00 00    
  40101c:       0f 05                   
  40101e:       48 c7 c0 3c 00 00 00    
  401025:       48 31 ff                
  401028:       0f 05                   

Escrever programas em código de máquina pode ser bastante desafiador, por isso alguns sistemas operacionais e bibliotecas trazem consigo um programa que auxilia na "montagem" desse código de máquina, possibilitando assim escrever programas em uma linguagem mnemônica com base em letras, números e símbolos, sendo mais fácil de memorizar do que os opcodes.

A estes montadores chamamos de assemblers.

👉🏽 Assemblers

Com um assembler, podemos escrever código de montagem (assembly), que é convertido para código de máquina.

Exemplo de um simples programa escrito em assembly x86_64 que imprime Hello, World! no standard output:

.section .data
hello:
    .ascii "Hello, World!\n"

.section .text
.global _start

_start:
    # write our string to stdout
    movq $1, %rax         # syscall number for sys_write
    movq $1, %rdi         # file descriptor 1 is stdout
    movq $hello, %rsi     # pointer to the hello string
    movq $14, %rdx        # length of the hello string plus newline character
    syscall               # invoke the kernel

    # exit
    movq $60, %rax        # syscall number for sys_exit
    xorq %rdi, %rdi       # exit code 0
    syscall               # invoke the kernel

Após executar o programa com o assembler as que vem acompanhado no GNU/Linux seguido do linker ld, temos o binário com o código de máquina.

$ as -o hello.o hello.s 
$ ld -o hello hello.o
$ ./hello

Hello, World!

Uma forma de fazer o "disassembly" do binário e ver o assembly equivalente, é com o utilitário objdump, onde podemos ver as instruções de máquina (opcodes) mapeadas para cada instrução assembly contida no nosso código fonte:

$ objdump -d hello

hello:     file format elf64-x86-64


Disassembly of section .text:

0000000000401000 <_start>:
  401000:       48 c7 c0 01 00 00 00    mov    $0x1,%rax
  401007:       48 c7 c7 01 00 00 00    mov    $0x1,%rdi
  40100e:       48 c7 c6 00 20 40 00    mov    $0x402000,%rsi
  401015:       48 c7 c2 0e 00 00 00    mov    $0xe,%rdx
  40101c:       0f 05                   syscall
  40101e:       48 c7 c0 3c 00 00 00    mov    $0x3c,%rax
  401025:       48 31 ff                xor    %rdi,%rdi
  401028:       0f 05                   syscall

Espetacular, não?

👉🏽 Tá, mas e os compiladores?

Os compiladores entram justamente na categoria de programas de mais alto nível que convertem para o assembly da arquitetura em questão ou diretamente para código de máquina.

Por exemplo, este simples programa escrito em C:

#include <stdio.h>

int main() {
    printf("Hello, World!\n");
    return 0;
}

Pode ser compilado para código de máquina utilizando o compilador gcc:

$ gcc -o hello hello.c 
$ ./hello

Hello, World!

É muito comum também compiladores converterem para uma representação intermediária (IR) antes de gerar o código de máquina, como é o caso do próprio gcc, LLVM, dentre outros.

👉🏽 E os interpretadores?

A distinção e similaridade entre compiladores e interpretadores não é um senso bastante comum, embora algumas pessoas entendam que interpretador é um tipo de compilador.

Indo pelo sentido prático, podemos dizer que o compilador compila para instrução de máquina. Enquanto que o interpretador vai lendo linha por linha do código fonte e executando.

Interpretadores modernos possuem um processo interno de compilação em tempo real, chamado just-in-time, ou JIT, o que pode inclusive caracterizar interpretadores também no rol de compiladores.

Independente da definição correta ou não de compiladores/interpretadores, uma coisa que devemos ter em mente é que estão acontecendo diversas transformações em camadas até chegar ao código de máquina.

Nesse processo de transformação, acontecem análises e otimizações que vão afetar drasticamente a performance do programa.

👉🏽 Frontend vs Backend

Você pensava que a briga front vs back existia apenas na web, pois não? No mundo dos compiladores também!

To brincando, gente. Não tem briga nenhuma não

Frontend é a etapa que faz a leitura do código fonte e gera uma árvore sintática. Esta árvore, como o próprio nome diz, segue uma estrutura de dados muito comum na computação, o que permite a análise de programas seguindo o conjunto de regras definido na gramática.

Basicamente, o frontend faz a análise léxica (gerando tokens válidos da especificação), e em seguida a análise sintática (parsing dos tokens), gerando a árvore sintática abstrata, ou AST.

Com a AST, o frontend pode ainda realizar análise semântica e até mesmo gerar um código intermediário (IR), se for o caso.

Já no Backend consiste na etapa de, a partir de uma AST ou IR, aplicar otimizações, análise estática (também chamada de ahead-of-time compilation, ou AOT), compilação em tempo de execução (JIT) e por fim a geração de assembly ou código de máquina.

Resumindo, então, alguns tipos de assemblers e compiladores:

1. Assemblers

• NASM

• GNU as

2. Frontend

• Clang (para LLVM)

• GCC

• javac

3. Backend

• LLC/LLI (para LLVM)

• GCC

• JVM

👉🏽 Okay mas e a rinha

Na rinha, foi disponibilizado um frontend para a especificação da linguagem, em formato de Rust crate.

Bastando ter o Rust instalado, adicionamos a crate e, através do comando rinha, temos uma representação JSON da AST:

# examples/hello.rinha
print("Hello, world")

# run frontend
$ rinha -p examples/hello.rinha

{
  "name": "examples/hello.rinha",
  "expression": {
    "kind": "Print",
    "value": {
      "kind": "Str",
      "value": "Hello, world",
      "location": {
        "start": 6,
        "end": 20,
        "filename": "examples/hello.rinha"
      }
...........

O desafio? Escrever um compilador/interpretador para este AST. Simples assim.

Patropi e o trampolim

Minha submissão escrita em Ruby foi batizada de Patropi (idk either). Optei por fazer um interpretador no formato tree-walking interpreter, que basicamente vai caminhando por cada nó da AST e executando.

Como não sou especialista em compiladores e otimizações, pra mim foi o caminho mais sensato naquele momento.

Um exemplo de código muito simples em Ruby, para interpretar o simples print("Hello world"):

def evaluate(term)
  case term
  in { kind: 'Str', value: value }; value.to_s
  in { kind: 'Print', value: next_term }; puts evaluate(next_term)
  else raise "Unknown term: #{term}"
  end
end

Note que o método evaluate é nosso ponto focal. Ele recebe um termo (nó da AST) e tenta buscar por um match específico. Caso dê match com uma String literal, retorna o valor. Mas se der match com um nó Print, chama o evaluate recursivamente.

👉🏽 Recursão

Recursão é o caminho mais intuitivo para manipular uma árvore na computação. Quase todo compilador é feito inicialmente de forma recursiva na manipulação da árvore justamente porque é intuitivo.

Enquanto há nó para percorrer, vou chamar minha função novamente, até chegar no fim do galho

Não vou entrar muito nos detalhes dos trade-offs da recursão, mas se quiser se aprofundar nisto, sugiro a leitura do artigo que escrevi sobre fundamentos de recursão.

Com isto em mente, e sabendo que o pessoal na rinha iria executar alguns programas que exigem muito da memória stack, decidi experimentar uma estratégia não muito ortodoxa e que funciona como alternativa à recursão quando otimizações de recursão de cauda não são possíveis ou são muito limitadas.

A esta estratégia (que também explico com detalhes no artigo apontado), chamamos de Trampoline, ou trampolim.

👉🏽 Trampolim para o resgate

Basicamente, ao invés de chamar a função recursivamente, eu devolvo uma estrutura chamada "continuation", passando o controle para um loop fora da função.

Este loop imperativo toma a decisão de executar uma closure com o valor passado na continuation ou se vai para o próximo nó da árvore. A cada iteração do loop, por não haver chamada recursiva, não há acúmulo na stack frame, portanto diminui drasticamente a chance de acontecer stack buffer overflow, ou seja, praticamente não há chance de estouro de pilha.

Aqui segue uma imagem com a arquitetura do Patropi:

Para mais detalhes de código, basta seguir o link do repositório no Github

👉🏽 And the Oscar goes to...

O ranking oficial está divulgado no repositório da rinha, e em primeiro lugar ficou uma solução escrita em Golang de tree-walking interpreter. Achei incrível, here we "Go" again :P

Minha solução em Ruby, o Patropi, das 190 submissões, ficou entre as 68 que rodaram, amargando a 65ª posição.

Apesar de ter sido divertido implementar o trampolim, Patropi não soube lidar muito bem com Tuplas e falhou em diversos testes...

Fila duplamente terminada em Go

Neste intervalo de estudos, aproveitei também para contribuir para um projeto de algoritmos e estruturas de dados no Github. A ideia do repositório é muito boa, basicamente ali tem dezenas de algoritmos que podem ser implementados por qualquer pessoa em diversas linguagens. Basta contribuir :)

Aproveitei a deixa para submeter alguns algoritmos e estruturas de dados em Rust, Go e Ruby. Mas queria destacar uma fila duplamente terminada (double-ended queue, ou deque) que fiz em Go.

Deque é uma estrutura de dados de fila que permite adicionar ou remover elementos em qualquer um dos lados.

Por exemplo, uma pilha permite adicionar e remover em apenas um lado (LIFO). Em uma fila, adicionamos a um lado e removemos do outro (FIFO).

A versatilidade da deque permite na média um acesso em tempo constante em ambos os lados (início da fila ou fim), tanto para adição (push) ou remoção (pop).

Um caso prático de deque seria no histórico de um navegador web, por exemplo. Como o armazenamento no navegador é limitado, o histórico precisa ter um limite de tamanho. Portanto adicionar e remover em ambas extremidades com o mesmo custo passa a ser uma vantagem neste cenário.

Em Go, poderíamos implementar em baby-steps da seguinte forma. Primeiro, definimos a type struct que terá um slice de inteiros:

package main

import "fmt"

type Deque struct {
	Store []int
}

Agora, temos que implementar as operações do lado direito, Rpush e RPop:

func (deque *Deque) RPush(element int) {
	deque.Store = append(deque.Store, element)
}

func (deque *Deque) RPop() *int {
	if len(deque.Store) == 0 {
		return nil
	}

	element := deque.Store[len(deque.Store)-1]
	deque.Store = deque.Store[:len(deque.Store)-1]

	return &element
}

• RPush: utiliza o built-in append no lado direito, que é uma operação constante

• RPop: manipula o slice, trabalhando apenas com os índices

Para terminar, fazer o mesmo do lado esquerdo:

func (deque *Deque) LPush(element int) {
	deque.Store = append([]int{element}, deque.Store...)
}

func (deque *Deque) LPop() *int {
	if len(deque.Store) == 0 {
		return nil
	}

	element := deque.Store[0]
	deque.Store = deque.Store[1:]

	return &element
}

No lado esquerdo, as operações passam a ter um custo linear, mas na média, por ser uma fila duplamente terminada, esse custo é amortizado caindo pra constante.

Thread pool no Adelnor

Pra finalizar, meu projetinho xodó do momento, o leandronsp/adelnor, precisava de uns ajustes importantes. Cada request HTTP era servido dentro da thread principal, não havia qualquer tipo de concorrência, e portanto o server não conseguia entregar muitos requests.

Resolvi implementar uma thread pool modesta submetendo este PR, em live na Twitch e também no Youtube.

$ gem install adelnor

require 'adelnor'

app = -> (env) do
  [200, { 'Content-Type' => 'text/html' }, 'Hello world!']
end

Adelnor::Server.run app, 3000, thread_pool: 5

Foi um processo interessante. Após subir o server com uma pool de 5 threads, a app conseguiu entregar 4x mais requests do que na versão single-threaded.

E caso queira aprender mais sobre threads em Ruby, recomendo muito este guia.

Conclusão

É isto que tive experimentando ultimamente. No momento, estou fazendo algumas melhorias no Adelnor, nomeadamente implementar modelo de atores com Ractors, mas vou entrar em detalhes disto num blogpost à parte.

Referências

CPU architecture x86 instructions chart Crafting Interpreters Rinha de compiladores reu/rinha-compiladores leandronsp/patropi Fundamentos de Recursão Double-ended queue workingwithruby.com leandronsp/adelnor

Rust, Go e background jobs

Em 2022 eu estava aprendendo Rust.

Numa bela 4a feira de chuva, fiz um tweet dizendo que iria tentar implementar uma lista duplamente ligada em Rust. Minutos depois, fiz outro tweet dizendo que iria desistir e ver Netflix.

Então desisti do Rust.

Recentemente em 2023 comecei uma saga para aprender Golang. Como a sintaxe me incomodou um pouco, talvez pela verbosidade dos if err != nil a dar com telha, decidi continuar kkk

Mas adicionando uma complexidade nisto tudo: voltar a aprender Rust junto com Go.

As vezes eu meto dessas, em 2015/16 decidi aprender Elixir e redes neurais artificiais tudo junto, e saiu o morphine

Nesta segunda tentativa com Rust, bateu um sentimento, confesso. Sentimento bom, no caso.

Com isto, passei a praticar em Rust e Go (e porque não Ruby) estruturas de dados simples que já estou habituado a implementar (pq pratico muito): filas, pilhas, listas ligadas, mutexes etc etc. E claro, programação em sockets como de praxe.

Desta massarocada toda saiu um UNIX server em Go, outro em Rust, pelo que indo de milho em milho, saiu um background job em ambas distintas linguagens.

Cheguei a um background job em Rust muito overkill, vale a pena dar uma olhada, lá abordo lista duplamente ligada, fila duplamente terminada, rpoplpush, blocking queue, DLQ, retries, threads etc.

Tudo isso implementado com os smart pointers em Rust, para resolver problemas inerentes (ok, não são bem problemas) a ownership e borrow checker.

Em breve vou escrever sobre meu aprendizado em Rust com artigos mais detalhados, preciso arrumar um tempo na minha vida, salvar pinguins na Antártida é mais urgente que isso

Mas se você acha que é ̶m̶u̶i̶t̶o̶ ̶m̶a̶i̶s̶ ̶e̶l̶e̶g̶a̶n̶t̶e̶ mais fácil ver um código Ruby, aqui neste arquivo no meu projeto leandronsp/fun também abordo um background job em Ruby com os mesmos conceitos aplicados ali em Rust e Go.

Rinha de backend

Entre Julho e Agosto aconteceu na famosa #bolhaDev no Twitter uma competição chamada rinha de backend, criada pelo Zan do Twitter e nosso arauto do sarcasmo Will Correa.

A ideia era que as pessoas participantes trouxessem a implementação de uma API definida nas regras da competição.

O desafio tinha como requisito uma arquitetura composta por basicamente um NGINX fazendo load balancing para 2 API's mandando dados para um banco de dados, tudo rodando em containers.

Se você quer saber mais sobre containers e Docker, dê uma olhadinha nesta série de artigos que escrevi centuries ago

Pra deixar mais desafiador ainda, havia uma restrição obrigatória de recursos onde o total de containers não podia exceder o limite de 1.5 CPU's e 3GB de memória.

Em uma data previamente estipulada, todas as submissões seriam submetidas a test de stress (violento, diga-se de passagem) através de uma ferramenta chamada Gatling.

Foi uma iniciativa muito bacana pois trouxe à luz pessoas que pouco interagiam por ali e que eram muito talentosas. Deu pra aprender e trocar muita figurinha durante os dias pré-submissão.

Outra coisa boa foi que o polvo lá do Twitter organizou um encontro presencial que iria transmitir a live da rinha, onde deu pra conhecer mais pessoas interessadas no tema.

Plain Ruby, Chespirito e Roda

Decidi participar submetendo uma versão em Ruby (sem Rails) tentando colocar em prova um web framework muito simples que criei chamado Chespirito.

Infelizmente, durante os testes no meu ambiente local não consegui grandes números com o Chespirito e acabei indo de Roda, que por acaso é o pior framework que já vi, pois sou muito hater de DSL's em situações onde não precisamos delas.

Um exemplo da tamanha verbosidade que atingimos com este framework:

r.get do              # GET
  r.on "a" do         # GET /a branch
    r.on "b" do       # GET /a/b branch
      r.is "c" do end # GET /a/b/c request
      r.is "d" do end # GET /a/b/d request
    end
  end
end

r.post do             # POST
  r.on "a" do         # POST /a branch
    r.on "b" do       # POST /a/b branch
      r.is "c" do end # POST /a/b/c request
      r.is "e" do end # POST /a/b/e request
    end
  end
end

Escolhi Roda pq me disseram que era rápido. Não comparei com Sinatra, apenas confiei

Submeti então minha versão naquela terça-feira sombria às 22h42 com Roda e Puma, pois meu ambiente não me ajudou a tirar bons números com I/O assíncrono no Falcon.

Logo mais chegamos no ponto do meu ambiente

Portanto, minha submissão ficou assim:

• Multi-threading com Puma, com uma modesta pool de threads 0:5, que é o default no Puma, e sem CPU workers

• Pool de 5 conexões com o PostgreSQL

• PostgreSQL nos defaults (100 max_connections)

• NGINX nos defaults com um ligeiro aumento para 1024 worker_connections

No docker-compose submetido, dividi os recursos da seguinte forma:

• 0.4 CPU | 1GB mem para as API's (x2)

• 0.6 CPU | 0.8GB mem para o PostgreSQL

• 0.1 CPU | 0.2GB mem para o NGINX

Depois vou explicar como que distribuindo melhor os recursos e diminuindo os números do NGINX e PostgreSQL fez meu troughput melhorar, mas só consegui fazer isto dias depois da rinha ter terminado.

O grande momento, the big moment

Minha submissão Ruby ficou em 20º lugar num ranking de 51 submissões funcionais (quase 100 foram submetidas mas muitas não rodaram lá na máquina dos caras), com um total de 24k inserts no banco de dados após o teste de stress com carga dobrada.

Não achei um número ruim mas eu tinha uma noção de que o desafio era muito I/O-bound, coisa que expliquei nesta thread do Twitter e também nesta outra thread dias depois.

Se I/O-bound ou CPU-bound são termos esquisitos pra você, sugiro dar um passo atrás e aprender os fundamentos de concorrência em sistemas operacionais, neste super guia que escrevi anos atrás sobre o funcionamento da Web

Resumo da ópera

O resumo disto é que depois com mais calma, consegui ajustar melhor meu ambiente de desenvolvimento. Abandonei o colima que tava com performance horrível no meu macOS e abracei o orbstack. So far, so good.

Com isto, pude rodar de forma mais assertiva com restrição de recursos os testes de stress no meu ambiente. Tem a ver com a virtualização do orbstack ser mais performática etc e tal.

A new hope for plain Ruby

Isto abriu portas para que eu voltasse a experimentar Falcon e meu filho Chespirito. Guess what, os números começaram a bater a famigerada dupla Roda/Puma.

Aproveitei também para utilizar o Portainer para visualizar métricas de CPU e memória dos containers no Docker.

Não apenas isto, também mexi nos meus limites no docker-compose, ficando assim, delegando mais recursos para o PostgreSQL que, tadinho, era o que mais apanhava (parabéns guerreiro, tmj):

• 0.2 CPU | 0.3GB para API's (x2)

• 1 CPU | 1.7GB para PostgreSQL (sim, nessa arquitetura, db sempre gasta mais CPU e memória)

• 0.1 CPU | 0.1GB para o NGINX

Diferente de muitas submissões na rinha, fiquei entre poucos que optaram por não utilizar qualquer estratégia de cache ou batch insert de forma assíncrona.

Meu intuito sempre foi experimentar algo que acredito muito e que trago nos projetos em que trabalho: não abusar de cache ou estratégia assíncrona onde não precisa. Cache ajuda mas pode trazer muitos desafios e encarecer custos no fim das contas.

Claro que, para a rinha, tudo era válido. Foi um amontoado positivo de diferentes soluções e troca de conhecimento

Mas como sou chato com custos, eu sempre vou pra solução mais simples possível e que causa menos entropia possível, até que se prove o contrário.

Cenário então fica assim:

• I/O não-bloqueante com Falcon, atendendo requests com multitasking cooperativo (Fibers)

• Chespirito, que não faz grande coisa a não ser rotear mensagens do Rack para a lógica devida, mas com código muito mais explícito e sem aquela DSL ̶h̶o̶r̶r̶o̶r̶o̶s̶a̶ estranha do Roda

Os números melhoraram, indo pra 35k. Not bad. Mas eu tinha uma leve suspeita de que algo errado ainda estava com minha solução. Por ser um desafio muito I/O-heavy, os requests ficavam pouco no Ruby, então eu tinha que melhorar a latência do PostgreSQL.

Foi aí que inverti a lógica.

Fechando a torneira

Nesta thread compartilhei recentemente como consegui atingir 46k inserts, mas em suma eu basicamente percebi que muitos requests à espera (Gatling judia) fazem aumentar a latência e consequentemente ciclo de CPU para fazer gestão das filas nos sockets.

Minha ideia então foi não deixar muito requests à espera, mesmo porque as queries no db são muito rápidas (remember kids, índices corretos salvam vidas).

Para atingir isto, resolvi diminuir o PostgreSQL para 30 max_connections e NGINX para 256 worker_connections (podia até ser 128 ou 64 tbh). Na API, como são duas, deixei uma pool de 15 conexões, pois o PostgreSQL neste caso iria até 30.

O resultado trouxe um troughput melhor e garantiu 46k inserts.

Em breve vou escrever um artigo mais detalhado sobre esta saga do Ruby na rinha

E o Bash?

It turns out que também fiz outra versão e submeti, escrita em Bash script, apenas for fun mesmo. Foi produto de um tweet inocente que fiz, o pessoal não perdoou e fez o tweet viralizar, pelo que me senti obrigado e implementar a API em Bash.

Na verdade, como eu já venho de uma saga ensinando fundamentos de computação nos meus artigos usando Bash, foi tranquilo fazer uma versão minimamente aceitável com mkfifo e netcat.

Submeti sem grandes pretensões, rodei o teste local apenas uma vez e deu um monte de erro, pensei "freak it vou mandar mesmo assim" e foi.

Para meu deleite, a solução em Bash ficou dentre as 51 funcionais da rinha, conquistando a tão sonhada 51ª posição, com um total de 17 inserts.

Isso mesmo, 17 inserts

Twitter não perdoa e então começaram a me chamar de "carinha do Bash", "ministro dos scripts Bash" e etc, mas gente EU NAO PROGRAMO EM BASH. Sou apenas um dev scriptzero que usa Bash as vezes pra facilitar minha vida e automatizar o que não preciso, mas longe de "manjar" de Bash kkkkk

I/O assíncrono e live coding do Leandro

Com o término da rinha, foi gerado um buzz muito alto em torno de I/O, principalmente o famoso I/O assíncrono, ou então como alguns costumam referenciar por I/O não-bloqueante.

Em breve escrevo artigos mais formais e detalhados sobre I/O não-bloqueante, mas recentemente fui de live mesmo, com um formato mais de "explicação", indo lá atrás de forma resumida nos aspectos de concorrência em sistemas operacionais até chegar em I/O não-bloqueante.

Na live eu trouxe exemplos em Ruby, Bash e C. Se você quer dar uma espreitada no que aconteceu por lá, CLIQUE AQUI.

That's all folks

É isto, o intuito deste breve artigo foi fazer um apanhado das coisas que tenho olhado recentemente, em um formato mais informal como costumo usar no Twitter.

Espero que o formato possa ser útil, caso contrário irei apenas continuar com aquele formato ̶c̶h̶a̶t̶o̶ denso e didático.

Claro que não deixarei de escrever os artigos técnicos de costume. E pode ser que eu misture inglês com português e a massarocada toda.

Fiquem ligades.

• Recursão é um tema obscuro ou quer entender mais um pouco sobre;

• Tail call e TCO são meios de comunicação alienígena e;

• Trampoline é nome de remédio

Então este artigo é pra você.

Aqui, vou explicar o que são estes termos de forma didática e os problemas que resolvem, com exemplos em Ruby. Mas não se preocupe pois os exemplos são bem simples de entender, mesmo porque os conceitos aqui mostrados são agnósticos a linguagem.

Portanto, venha comigo nesta viagem interminável.

✋ Para continuar, volte ao topo do post

Agenda

• O que é recursão

• Fibo para os íntimos

• Tail call

• Stack e stack overflow

• Tail call optimization

• Trampoline

• Conclusão

• Referências

O que é recursão

Em programas de computador, somos habituados a quebrar problemas grandes em problemas menores por meio do uso de funções ou métodos.

Recursão é, de forma extremamente simplificada, uma técnica na computação onde estes problemas são quebrados de forma que uma determinada função é executada recursivamente.

Com isto, a função "chama a si mesma" para resolver alguma computação e continuar sua execução.

Fibo para os íntimos

Um exemplo bastante clássico de recursão é descobrir, dada a sequência de Fibonacci, ou Fibo, qual número se encontra em determinada posição.

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55.........

Com isto, a função fib traria resultados como:

fib(0) = 0
fib(1) = 1
fib(2) = 1
...
fib(7) = 13
fib(10) = 55

Temos então uma possível implementação recursiva em Ruby:

def fib(position)
  return position if position < 2

  fib(position - 1) + fib(position - 2)
end

Este código, entretanto, não é performático. Ao tentar buscar o número da posição 10000 (dez mil) na sequência, o programa fica muito lento pois faz inúmeras chamadas recursivas redundantes.

                 fib(10)
             /                \
     fib(9)                 fib(8)
        /          \          /   \
fib(8)     fib(7)     fib(7)    fib(6)
  /      \       /       \       /   \
fib(7) fib(6) fib(6) fib(5) fib(6) fib(5)
   /    \     /     \     /     \     /    \
fib(6) fib(5) fib(5) fib(4) fib(5) fib(4) fib(5) fib(4)
  /   \   /   \   /   \   /   \   /   \   /   \   /   \
...

Consequentemente, quanto maior o input da função, o tempo de execução deste código tende a crescer de forma exponencial, que em notação Big-O seria O(2^n).

É possível reduzir esta complexidade?

E se tentarmos aplicar uma técnica onde a última chamada da função, ao invés de ser a soma de duas chamadas recursivas, passa a ser apenas uma chamada recursiva, sem realizar computações adicionais?

Esta técnica existe e é chamada de tail call, ou tail recursion.

Tail call

Tail call, ou TC, consiste em uma função recursiva onde a última chamada recursiva é a própria função sem computação adicional.

Com isto, reduzimos a complexidade de exponencial para linear, como se fosse um simples loop iterando em uma lista de inputs.

Em notação Big-O isto fica O(n), ou seja, a complexidade cresce de forma linear acompanhando o crescimento do input.

Exemplo em Ruby:

def fib(position, _current = 0, _next = 1)
  return _current if position < 1

  fib(position - 1, _next, _current + _next)
end

Portanto, o número de chamadas recursivas é reduzido drasticamente para algo do tipo:

fib(10, 0, 1)
fib(9, 1, 1)
fib(8, 1, 2)
fib(7, 2, 3)
fib(6, 3, 5)
fib(5, 5, 8)
fib(4, 8, 13)
fib(3, 13, 21)
fib(2, 21, 34)
fib(1, 34, 55)
fib(0, 55, 89)

Repara como que o número de chamadas recursivas diminuiu, ou seja, o código está seguindo um caminho mais linear com esta abordagem.

Assim, ao rodar o programa fib com TC, o tempo de execução é exponencialmente menor do que rodar sem TC, ficando dezenas de milhares de vezes mais rápido.

✋ Claramente um programa que leva tempo exponencial é péssimo em termos de performance, não?

# Sem TC
fib(30) # 0.75 segundos

# Com TC
fib(30) # 0.000075 segundos

Voltando ao exemplo de fib(10000), ao rodar com TC, vemos que a execução é muito mais rápida, porém:

recursion/fib.rb:10:in `fib_tc': stack level too deep (SystemStackError)
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'
        from recursion/fib.rb:10:in `fib_tc'

Uh oh, um stack overflow!

Para entender o que está acontecendo, vamos primeiro entender o que raios é uma stack e stack overflow.

Stack e stack overflow

Quando um programa é executado, é alocada na memória uma estrutura de dados em formato de pilha, chamada Stack, que é utilizada para guardar os dados que estão sendo utilizados em uma função em execução.

✋ Há também outra estrutura na memória do programa chamada Heap, que não é uma pilha e tem outras características que vão além do escopo deste artigo. Para entender recursão, focamos apenas na stack

Quando o programa entra em uma função ou método, cada dado é inserido (push) na stack. Ao terminar a função, é feita a remoção (pop) de cada dado.

A cada chamada de função, é atribuído um novo stack frame. Como uma chamada recursiva nunca termina, o runtime não sabe que é preciso fazer "pop" dos dados e finalizar o frame, então a cada chamada, uma nova stack frame é criada e mais elementos são adicionados à stack.

Adivinha o que acontece quando adicionamos muitos dados na stack a ponto de ultrapassar seu limite na memória do computador?

Sim, acontece o famigerado Stack overflow 💥🪲, e isto explica aquele erro no Ruby ao rodar fib de 10000 com tail call.

✋ Então quer dizer que calcular o fib de 10000 é um problema impossível de resolver com recursividade?

Calma, algumas linguagens empregam uma técnica de otimização que consiste em utilizar a chamada TC com apenas um stack frame, garantindo assim que cada chamada recursiva seja tratada como se fosse uma iteração num loop primitivo.

Com isto, é feita a manipulação dos argumentos e dados da função em uma única stack frame, exatamente como se tivéssemos escrito um loop primitivo. E consequentemente, novas chamadas recursivas de cauda não vão provocar estouro na pilha.

A esta técnica chamamos de Tail call optimization, ou TCO.

Tail call optimization

Devido a sua natureza imperativa, e assim como diversas outras linguagens de propósito geral, Ruby não traz suporte nativo a TCO.

Geralmente esta funcionalidade é mais encontrada em linguagens com forte inclinação ao paradigma funcional, e não ao imperativo.

Mas em Ruby é possível habilitar o modo TCO com uma simples configuração na instrução do runtime do Ruby (YARV), e assim conseguimos executar fib de 10000 sem dor.

RubyVM::InstructionSequence.compile_option = {
  tailcall_optimization: true,
  trace_instruction: false
}

def fib(position, _current = 0, _next = 1)
  return _current if position < 1

  fib(position - 1, _next, _current + _next)
end

# TC com TCO
fib(10000) # 0.02 segundos

Superb! Com TCO habilitado, uma fib 10000 com tail call é executada em 0.02 segundos!

Vale lembrar que TCO é uma técnica utilizada não apenas em recursão mas também em otimização de geração de instruções em compiladores, mas isto foge ao escopo deste artigo.

✋ Okay, mas e quando não for possível habilitar TCO para recursão de cauda ou eu estiver programando em uma linguagem que não tenha suporte a TCO?

Trampoline para o resgate.

Trampoline

Para entendermos trampoline, vamos pensar no problema e em uma possível solução.

Se pensarmos com inteligência, podemos inicialmente concluir que a recursão deve ser evitada, e esta é a premissa número um.

def fib(position, _current = 0, _next = 1)
  return _current if position < 1

  ###################################
  #### Devemos evitar isso!!!!!! ####
  ###################################
  fib(position - 1, _next, _current + _next)
end

Premissa dois, ao invés de retornar uma chamada recursiva diretamente, e se a retornarmos encapsulada em uma estrutura de função anônima que guarda contexto para ser executada em outro contexto?

Sim, tipo uma closure ou lambda para os mais atentos

Em Ruby, podemos utilizar o conceito de lambdas.

def fib(position, _current = 0, _next = 1)
  return _current if position < 1
  
  lambda do
    fib(position - 1, _next, _current + _next)
  end
end

Se chamarmos result = fib(0), por causa da primeira linha de short-circuit (position < 1), o retorno do método é 0.

Mas se chamarmos result = fib(10), o retorno não será uma chamada recursiva, mas sim o retorno será uma função anônima (lambda).

Com isto, o método é então finalizado e a stack é limpa, ou seja, é feito o pop dos dados de dentro do método.

Como lambdas guardam contexto, se chamarmos result.call, a lambda é executada com o contexto anterior, que pode retornar o número final (caso entre no short-circuit) ou outra lambda com o novo contexto.

E assim, ficamos em loop até termos o valor final, enquanto o retorno atual continuar sendo uma lambda. Conseguiu entender o que podemos fazer?

Sim, um loop!

result = fib(10000)

while result.is_a?(Proc)
  result = result.call
end

puts result

Output (um número mesmo muito grande):

33644764876431783266621612005107543310302148460680063906564769974680081442166662368155595513633734025582065332680836159373734790483865268263040892463056431887354544369559827491606602099884183933864652731300088830269235673613135117579297437854413752130520504347701602264758318906527890855154366159582987279682987510631200575428783453215515103870818298969791613127856265033195487140214287532698187962046936097879900350962302291026368131493195275630227837628441540360584402572114334961180023091208287046088923962328835461505776583271252546093591128203925285393434620904245248929403901706233888991085841065183173360437470737908552631764325733993712871937587746897479926305837065742830161637408969178426378624212835258112820516370298089332099905707920064367426202389783111470054074998459250360633560933883831923386783056136435351892133279732908133732642652633989763922723407882928177953580570993691049175470808931841056146322338217465637321248226383092103297701648054726243842374862411453093812206564914032751086643394517512161526545361333111314042436854805106765843493523836959653428071768775328348234345557366719731392746273629108210679280784718035329131176778924659089938635459327894523777674406192240337638674004021330343297496902028328145933418826817683893072003634795623117103101291953169794607632737589253530772552375943788434504067715555779056450443016640119462580972216729758615026968443146952034614932291105970676243268515992834709891284706740862008587135016260312071903172086094081298321581077282076353186624611278245537208532365305775956430072517744315051539600905168603220349163222640885248852433158051534849622434848299380905070483482449327453732624567755879089187190803662058009594743150052402532709746995318770724376825907419939632265984147498193609285223945039707165443156421328157688908058783183404917434556270520223564846495196112460268313970975069382648706613264507665074611512677522748621598642530711298441182622661057163515069260029861704945425047491378115154139941550671256271197133252763631939606902895650288268608362241082050562430701794976171121233066073310059947366875

🔑 Ponto-chave E com isto, amigues, temos a técnica trampoline: um loop primitivo não-recursivo que fica chamando outra função escrita de forma recursiva mas que retorna uma lambda com contexto, até chegar ao valor final.

Este código, sem TCO, para o fib de 10000, leva 0.04 segundos, um resultado muito próximo a TCO e sem causar stack overflow.

Incrível, não? Agora não há desculpas para não escrever uma função de modo recursivo em linguagens que não trazem suporte a TCO 😛

Conclusão

Neste artigo, o intuito foi trazer alguns conceitos que tocam no tema recursão. Estes conceitos fazem overlap com temas muito acadêmicos que, por vezes, dificultam o entendimento de pessoas que estão iniciando na área ou que não têm um background muito acadêmico.

Espero ter esclarecido de forma didática o assunto recursão, se puder deixe nos comentários qualquer correção ou informação relevante.

Referências

https://twitter.com/leandronsp/status/1672043065001869312 https://twitter.com/JeffQuesado/status/1671954585987022882 https://en.wikipedia.org/wiki/Fibonacci_sequence https://en.wikipedia.org/wiki/Recursion https://www.geeksforgeeks.org/stack-data-structure/ https://en.wikipedia.org/wiki/Tail_call https://en.wikipedia.org/wiki/Trampoline_(computing) https://nithinbekal.com/posts/ruby-tco/ https://www.bigocheatsheet.com/ https://ruby-doc.org/core-3.1.0/RubyVM/InstructionSequence.html#method-c-compile_option

Se quer poupar tempo e ir direto ao assunto, para cálculos precisos, prefira decimais de precisão arbitrária ou equivalentes como BigDecimal em vez de números de ponto flutuante.

Além disso, evite arredondamentos desnecessários. Quando necessário, limite o arredondamento apenas na etapa final para manter o máximo de precisão possível.

Se você tá sem tempo, pode parar por aqui pois estas dicas já são suficientes para a maioria das pessoas

Mas se você tem curiosidade em entender mais sobre este assunto, sugiro continuar nesta viagem aos números de ponto flutuante.

Sumário

• Prólogo

• First things first

• Bits não são suficientes

• Bits e inteiros

• Bits e outros números reais

• Representação de ponto fixo

• Representação de ponto flutuante

• Problemas e padrões

• Tipos de dados de ponto flutuante

• Problemas de ponto flutuante na prática

• Decimais ao resgate

• Cuidado com o arredondamento

• Decimais em outras tecnologias

• Conclusão

• Referências

📜 Prólogo

Ah, sim, números de ponto flutuante.

Essas coisinhas que frequentemente aparecem em conteúdos técnicos, cheios de notações científicas e explicações complexas.

É quase certo que toda pessoa que está envolvida com software já tenha se deparado com a noção de que trabalhar com números de ponto flutuante pode ser perigoso, resultando em resultados de aritmética imprecisos, entre outros problemas.

No entanto, compreender todas as razões subjacentes por trás desse tópico crucial em ciência da computação pode ser desafiador para muitos.

No post de hoje, iremos aprofundar nos problemas que os números de ponto flutuante abordam e explorar as armadilhas envolvidas.

Então, pegue uma garrafa de água refrescante e embarque nesta jornada rumo à essência dos números de ponto flutuante.

👍🏼 First things first

Computadores só entendem linguagem de máquina.

Linguagem de máquina é uma coleção de "bits" que contém dados e instruções para a CPU. Representamos esses bits como bits binários e, como tal, é chamado de sistema numérico binário (0 e 1).

01001001 01001000 11001011 01000001 01001000 10001000
01011001 01001000 01000001 01101001 01001000 01001001
11000001 10001000 01001001 11001010 10001000 01001000
11001001 01001000 11001001 01001000 01001000 01001001

Programar diretamente em linguagem de máquina é altamente propenso a erros e muitas vezes ineficiente em diversos cenários. Para lidar com isso, as linguagens assembly foram introduzidas ao longo dos anos, servindo como uma ponte entre as especificidades da arquitetura da CPU e um conjunto de instruções de alto nível.

Uma linguagem assembly (ou simplesmente Assembly) é traduzida em código de máquina por meio de um programa dedicado chamado Assembler. Cada arquitetura de CPU geralmente tem seu próprio assembler associado a ela.

Isso permite que programadores trabalhem com um conjunto de instruções mais gerenciável e legível para humanos, que é então traduzido em código de máquina específico para a arquitetura do processador.

section .data
    number1 dd 10      ; Define o primeiro número como um float de 32 bits
    number2 dd 20      ; Define o segundo número como um float de 32 bits

section .text
    global _start
_start:
    ; Carrega o primeiro número no registro xmm0
    movss xmm0, dword [number1]
    
    ; Carrega o segundo número no registro xmm1
    movss xmm1, dword [number2]
.....
.....

Os avanços no campo da engenharia de computação abriram caminho para o desenvolvimento de linguagens de programação cada vez mais de alto nível que podem ser traduzidas diretamente em instruções de código de máquina.

Ao longo das décadas seguintes, surgiram linguagens como C, Java e Python, entre outras, permitindo que cada vez mais pessoas pudessem escrever programas para computador sem necessariamente saber os detalhes de sua arquitetura de CPU.

Essa conquista significativa teve um impacto profundo na indústria, à medida que os computadores se tornaram mais compactos e rápidos, capacitando práticas modernas de engenharia de software para oferecer um valor substancial aos negócios em todo o mundo.

Computadores entendem bits, mas seres humanos se comunicam muito além de bits.

🔵 Bits não são suficientes

Como mencionado anteriormente, os computadores entendem apenas bits binários.

Nada mais neste mundo pode ser interpretado por computadores.

Bits. Nada mais.

💡 Na verdade, CPUs de computadores eletrônicos entendem apenas a ausência ou presença de tensão, permitindo-nos representar informações usando 0 e 1 (desligado e ligado).

No entanto, a vida real traz desafios em que programas de computador, criados por pessoas para pessoas, precisam representar um conjunto mais amplo de caracteres além de apenas 0s e 1s. Isso inclui letras, números decimais, números hexadecimais, caracteres especiais, sinais de pontuação e até mesmo emojis como este 😹.

Conjuntos de caracteres padrão, como os esquemas ASCII e Unicode, resolvem o desafio de representar números, letras, caracteres especiais, emojis e muito mais dentro do sistema binário.

⚠️ Explorar as complexidades da codificação de caracteres com ASCII e Unicode está além do escopo deste artigo. Isto será abordado em futuros posts

Aqui, nosso foco será especificamente como os computadores trabalham com números na memória, particularmente números inteiros.

🔵 Bits e inteiros

Vamos utilizar o número 65 como exemplo. Ele é representado no sistema de numeração decimal (base 10), tornando-o um número real.

Além disso, ele é classificado como um número inteiro.

Ao realizar conversões com base em potências de 2, podemos representar o inteiro 65 como 01000001 em formato binário de 8 bits. Essa representação binária pode ser convertida de volta e para o valor decimal 65.

De uma perspectiva matemática, como 65 é um número inteiro, ele cabe em um único byte (8 bits). Além disso, realizando potências de 2, sabemos que um único byte pode acomodar 256 números:

2^8 = 256

Falando de forma simplificada, alguém pode assumir que um único byte pode representar inteiros de 0 a 255.

No entanto, inteiros devem representar números negativos e positivos. Com isso, como devemos distribuir igualmente esses inteiros em um único byte?

Empregando uma técnica chamada complemento de dois.

👉 Complemento de dois

Para distribuir igualmente números inteiros negativos e positivos não fracionários dentro de 8 bits, podemos usar uma técnica chamada complemento de dois. Nesta técnica:

• o bit mais à esquerda serve como o bit de sinal, indicando se o número é positivo ou negativo

• todos os bits são invertidos ou complementados

• em seguida, adicionamos 1 ao valor resultante

Desta forma, um único byte representa inteiros que variam de -128 a 127.

2^8 = 256

-127, -126, -125...127, 128

👉 Utilizando dois bytes para representar inteiros

Ao empregar a técnica do complemento de dois, também podemos representar um intervalo de inteiros usando dois bytes (16 bits).

Utilizando o conceito de potências de 2, podemos observar que dois bytes podem acomodar um total de 65536 valores diferentes:

2^16 = 65536

Considerando números negativos, o intervalo se estende de -32768 a 32767, inclusive.

Agora, vamos explorar alguns exemplos utilizando o PostgreSQL.

Se você, como eu, é da turma dos containers, ter um PostgreSQL server prontinho pra ser utilizado é mamão com açúcar:

$ docker run --rm -d \
  --name postgres \
  -e POSTGRES_HOST_AUTH_METHOD=trust \
  postgres 

Em seguida, acesse o terminal psql com o seguinte comando:

$ docker exec -it postgres psql -U postgres

O quê você está esperando para ir logo aprender sobre containers?

No PostgreSQL, o tipo de dado que representa um inteiro de dois bytes é chamado int2 ou smallint:

SELECT 65::int2;
 int2
------
   65

Para verificar o tipo de dado, podemos usar a função pg_typeof:

SELECT pg_typeof(65::int2);
 pg_typeof
-----------
 smallint

Como smallint usa dois bytes, ele só pode acomodar o intervalo que mencionamos anteriormente em termos de bits e inteiros:

SELECT 32767::int2;
 int2
-------
 32767

SELECT -32767::int2;
 int2
-------
 -32767

No entanto, se tentarmos exceder o intervalo:

SELECT 32768::int2;
ERROR:  smallint out of range

Incrível, não?

Além do smallint, Postgres oferece uma variedade de outros tipos de dados inteiros:

No entanto, todos nós sabemos que o mundo não é apenas composto por inteiros. Inteiros são um subconjunto de um conjunto mais amplo de números chamados números reais.

🔵 Bits e outros números reais

Números reais podem incluir inteiros, frações e decimais, tanto racionais quanto irracionais.

Por exemplo, 3.14159 representa o número real π (pi), que é um número irracional. É um decimal não repetitivo e não terminante. O valor de π se estende infinitamente sem qualquer padrão em sua representação decimal.

3.14159265358979323846....

Suponha que tenhamos dois bytes (16 bits), que podem representar 65536 inteiros variando de -32768 a 32767.

Quando se trata de representar outros números reais, como decimais, podemos usar uma técnica chamada ponto fixo que, apesar de não ser eficiente, pode ser utilizada para fins didáticos neste post.

🔵 Representação de ponto fixo

Na representação de ponto fixo, dividimos os 16 bits fornecidos em três partes:

👉 Bit de sinal

O primeiro bit (mais à esquerda) representa o sinal, sendo 1 para negativo e 0 para positivo.

👉 Parte decimal

Os próximos 7 bits representam a parte decimal (fracionária), que pode ter uma precisão de até 0.992188 em nossa simulação:

2^-7 + 2^-6 + ... + 2^-1 =
0.992188

👉 Parte inteira

Os 8 bits restantes representam a parte inteira, que podem ir de -128 a 127 usando complemento de dois:

complemento_de_dois(
    2^7 + 2^6 + ... + 2^1 = 
    127
)

Considerando que a parte inteira, usando 8 bits com complemento de dois, varia de -128 a 127, podemos concluir que, com a representação de ponto fixo, os decimais podem variar de -128.992188 a 127.992188.

No entanto, essa técnica pode nem sempre ser a mais eficiente.

Portanto, vamos explorar outra técnica para representar decimais. Sim, estamos falando da mundialmente e amplamente utilizada representação de ponto flutuante.

🔵 Representação de ponto flutuante

Tomando como exemplo 16 bits, na representação de ponto flutuante, também dividimos os 16 bits em três grupos:

👉 Bit de sinal

O primeiro bit (mais à esquerda) é usado para representar se o número é negativo (1) ou positivo (0).

👉 Parte do expoente

A parte do expoente é atribuída aos próximos X bits. Em nossa simulação, vamos alocar 7 bits para esta parte, enquanto utilizamos o primeiro bit do expoente como sendo o sinal do expoente.

Assim, a faixa para o expoente se estende de -63 a 63, acomodando valores negativos e positivos:

2^5 + 2^4 + ... 2^1 =
63

Esta parte é crucial para definir a precisão aritmética na representação de ponto flutuante.

👉 Mantissa

A parte da mantissa, também conhecida como significante, usa os 8 bits restantes na nossa simulação, permitindo uma faixa de 1 até 255.

Como não estamos representando a parte inteira nesta simulação, não é necessário aplicar complemento de dois à mantissa.

🔑 Agora a parte importante Para calcular o maior número de ponto flutuante positivo, multiplicamos a mantissa pelo expoente. É aqui que entra o tal do "ponto flutuante":

mantissa X 2^expoente

Neste caso, o valor máximo positivo seria obtido multiplicando-se 255 por 2^6, resultando em um número extremamente grande como 2351959869397967831040.0.

Por outro lado, o número mínimo maior que zero pode ser representado como 1 multiplicado por 2^-63, ou 0.00000000000000000010842021724855044340074528008699.

Observe que esta simulação é uma representação simplificada com precisão limitada e pode não refletir a precisão de formatos de ponto flutuante ideais ou padronizados.

🔵 Problemas e padrões

De fato, como mencionado anteriormente, selecionar um número adequado de bits para a parte do expoente na representação de ponto flutuante é crucial para mitigar problemas de arredondamento e truncamento ao lidar com números fracionários.

Padrões como o IEEE 754 foram estabelecidos exatamente para abordar essas preocupações e fornecer um framework consistente para a representação de ponto flutuante. O padrão IEEE 754 define o número de bits alocados para o expoente, mantissa e sinal em formatos de precisão simples (32 bits) e dupla precisão (64 bits).

Esses padrões determinam a representação precisa dos vários componentes de um número de ponto flutuante, as regras para operações aritméticas e como lidar com casos excepcionais.

👉 Precisão simples (4 bytes)

Os números de precisão simples são representados usando 32 bits de memória.

Eles incluem:

• 1 bit para o sinal do número

• 8 bits para o expoente

• 23 bits para a mantissa

De acordo com os padrões do IEEE, a precisão simples normalmente manipula de 6 a 9 casas decimais de precisão.

👉 Dupla precisão (8 bytes)

Os números de dupla precisão são representados usando 64 bits de memória.

Eles incluem:

• 1 bit para o sinal do número

• 11 bits para o expoente

• 52 bits para a mantissa

De acordo com os padrões do IEEE, a dupla precisão pode manipular de 15 a 17 casas decimais de precisão.

Geralmente, a dupla precisão se encaixa melhor quando a alta precisão é necessária, mas esta por sua vez consome mais memória.

🔵 Tipos de dados de ponto flutuante

Muitas linguagens de programação e sistemas de banco de dados aderem aos padrões do IEEE 754, e com o PostgreSQL isto não é exceção.

Vamos ver como o Postgres implementa os tipos de dados de ponto flutuante na prática.

O tipo de dado float4 segue o padrão de precisão simples do IEEE 754, que aloca 1 bit para o sinal, 8 bits para o expoente e 23 bits para a mantissa:

SELECT 0.3::float4;
 float4
--------
    0.3

Por outro lado, o tipo de dado float8 segue o padrão de dupla precisão do IEEE 754, que aloca 1 bit para o sinal, 11 bits para o expoente e 52 bits para a mantissa:

SELECT 0.3::float8;
 float8
--------
    0.3

#####################

SELECT 0.3::float;
 float
--------
    0.3

O tipo float padrão é equivalente à dupla precisão (float8).

☣️ Problemas de ponto flutuante na prática

Vamos mergulhar em cálculos com números de ponto flutuante e ver os possíveis problemas na prática.

Considere uma simples soma de 0.1 + 0.2:

SELECT 0.1::float + 0.2::float;

 0.30000000000000004

Este resultado mostra como problemas de precisão podem surgir em números de ponto flutuante de dupla precisão durante operações aritméticas.

Mesmo seguindo padrões, não estamos imunes a esses desafios de cálculo com ponto flutuante.

No entanto, há uma estratégia alternativa que envolve um truque maroto utilizando inteiros.

💡 Um truque com inteiros

Em vez do tipo de dado float, podemos trabalhar com inteiros. Incorporamos um fator multiplicador com base em uma escala decimal ao armazenar valores e, em seguida, dividimos pelo mesmo fator para restaurar a representação decimal original ao recuperar o valor.

Esse método permite cálculos decimais precisos usando inteiros e escala. O fator multiplicador deve ser escolhido com base na precisão decimal necessária.

Para demonstrar, vamos usar esse truque para realizar 0.1 + 0.2, com o fator multiplicador 1000:

SELECT (0.1 * 1000)::int + (0.2 * 1000)::int;

300

Aqui, cada entrada é multiplicada por 1000 e convertida para um inteiro. Para recuperar o valor original sem perder a precisão, dividimos por 1000:

SELECT (300 / 1000::float);

0.3

Uau, que técnica incrível! 🚀

No entanto, o uso de um fator multiplicador fixo pode ser ineficiente ao lidar com entradas que possuem diferentes casas decimais.

Em vez disso, uma representação de escala variável pode ser usada convertendo a entrada em uma string e analisando o número de dígitos decimais, fazendo assim com que o fator multiplicador seja dinâmico para cada número real.

Mas tenha cuidado, representações decimais de escala variável exigem manipulação cuidadosa de cálculos complexos, escala decimal precisa e várias outras sutilezas da aritmética decimal, que não é tão trivial.

É aqui que entram os decimais.

🔵 Decimais ao resgate

Decimais lidam com os desafios associados a cálculos aritméticos complexos envolvendo decimais. Ao passo em que eles reduzem significativamente os problemas de precisão comumente encontrados em números de ponto flutuante.

Diversas linguagens de programação e sistemas de banco de dados implementam decimais. PostgreSQL oferece o tipo de dado decimal, que oferece uma precisão superior em comparação com floats.

SELECT 0.1::decimal + 0.2::decimal;
0.3

Os decimais também podem ser configurados para precisão e escala arbitrárias:

# Exemplo: aceita números de até 999.99
SELECT 0.1::decimal(5, 2);
0.10

SELECT 999.99::decimal(5, 2);
999.99

Convenientemente, o tipo de dado padrão para decimais no PostgreSQL é numeric, que é idêntico a decimal:

SELECT pg_typeof(0.1);

numeric

⚠️ Cuidado com o arredondamento

Arredondar números decimais programaticamente pode levar a resultados imprecisos. Por exemplo, a soma 25.986 + -0.4125 + -25.5735 teoricamente deveria resultar em zero:

SELECT 25.986 + -0.4125 + -25.5735;

0.0000

Vamos ilustrar como podemos arredondar apenas a soma final para duas casas decimais:

SELECT ROUND(25.986 + -0.4125 + -25.5735, 2);

0.00

So far, so good. Tudo funcionando como esperado.

Com tipos de dados adequados, como decimais, o problema aritmético inerente aos números de ponto flutuante já é resolvido.

Todavia, o arredondamento introduz seu próprio conjunto de desafios. Mesmo que os decimais sejam excelentes para a precisão e aritmética de dados decimais, as operações de arredondamento envolvem algum grau de aproximação.

Para simular um problema com arredondamentos desnecessários, vamos arredondar cada número decimal antes de somá-los:

SELECT ROUND(25.986, 2) + ROUND(-0.4125, 2) + ROUND(-25.5735, 2);

0.01

OMG e agora? 😭

Cada vez que arredondamos um número, estamos adicionando um pouco de imprecisão. Bit a bit, o resultado final pode ficar longe do esperado, pois a memória do computador é finita e não é possível representar todas as casas decimais possíveis resultantes de uma aritmética arbitrária de números reais.

Lembra do resultado da mantissa X 2^expoente? Pois então...

Esses exemplos destacam por que o arredondamento desnecessário deve ser evitado. Como o arredondamento é uma aproximação, é melhor adiá-lo até a etapa final, ou seja, apenas quando formos apresentar os dados ao usuário final.

Decimais em outras tecnologias

Cada linguagem de programação ou ferramenta possui seu próprio tipo de dados para lidar com precisão arbitrária, como os decimais do PostgreSQL.

Ruby oferece a classe BigDecimal, que facilita a aritmética decimal de ponto flutuante de precisão arbitrária.

Da mesma forma, Java também inclui uma classe BigDecimal para este mesmo propósito.

Golang também não é exceção. Ela possui aritmética decimal de precisão arbitrária que resolve os mesmos problemas.

É crucial verificar se a tecnologia que você está usando oferece suporte a precisão arbitrária como decimais. Se você precisar de uma precisão maior, estas soluções costumam ser mais adequadas do que o uso de números de ponto flutuante brutos.

Ao limite, se precisão for algo crítico para teu negócio e a tecnologia utilizada não fornece tipos como os big decimals de precisão arbitrária, prefira então utilizar números inteiros com fator multiplicador (100, 1000, 10000, etc) que contemple as casas decimais suficientes para a precisão necessária.

Conclusão

Neste post, exploramos as complexidades dos números de ponto flutuante.

Investigamos também como os computadores compreendem informações por meio do sistema binário, desde a representação de inteiros e a ineficiência da representação de ponto fixo para decimais, até chegar aos números de ponto flutuante e suas limitações.

Além disso, discutimos como os tipos de dados de precisão arbitrária, como os decimais, abordam esses problemas de precisão inerentes aos pontos flutuantes.

Por fim, discutimos e compartilhamos as melhores práticas para lidar com problemas de arredondamento de números decimais.

Espero que esses tópicos tenham sido apresentados de forma didática, tornando os problemas de ponto flutuante não mais um problema!

Cheers!

Referências

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html https://www.postgresql.org/docs/current/datatype.html https://en.wikipedia.org/wiki/IEEE_754 https://www.doc.ic.ac.uk/~eedwards/compsys/float/ https://en.wikipedia.org/wiki/Floating-point_error_mitigation https://en.wikipedia.org/wiki/Single-precision_floating-point_format https://en.wikipedia.org/wiki/Double-precision_floating-point_format https://en.wikipedia.org/wiki/Decimal_floating_point