since more than 50 people have followed me since yesterday, i think its time to formally introduce myself.
my name is aruj, a btech student.
i’m someone obsessed with understanding how things actually work, not just using systems, but breaking them down and rebuilding them from first principles.
i started on the systems side, thinking about data flow, performance, and how abstractions break at scale. over time, that curiosity pulled me deeper into electronics, because software is ultimately just control over hardware.
right now, i’m exploring both, but mostly electronics, learning how things behave at the hardware level. trying to connect both worlds instead of treating them separately.
glad you’re here, here’s to a better and successful future 🥂
wanted to understand what actually happens underneath, so I built a mini SQL engine in C from scratch.
here’s what it does:
• pagebased storage engine (4KB pages)
• manual row serialization (no struct padding traps)
• SQL parser (tokenizer + AST)
• query execution pipeline
• hash indexing for O(1) lookups
cooked this up. every frame generates a structured point grid, deforming it using multiple layered wave functions, and masking it with an expanding procedural envelope while assigning ascii characters procedurally, varying opacity from local curvature and wave intensity, and then rendering it directly to the canvas.
a lot of tweaking until the terrain felt alive, especially because it was my first time trying it :p
learnt this while reading Patterson & Hennessy and then going down the tomasulo/register renaming rabbit hole.
modern CPUs don't execute your code exactly as written. register renaming is one of the best examples.
the ISA defines registers like RAX, X5, or R1, and software treats them as fixed storage locations. but inside a modern CPU, these aren't the actual registers that hold data, they're just architectural names defined by the ISA.
the processor uses a larger pool of physical registers internally. during execution, the rename stage maps each architectural register to a physical register, allowing instructions to execute efficiently without unnecessary dependencies.
so when your code says: r1 = r2 + r3
the CPU may internally turn that into: p47 = p12 + p13
then update some rename table like: r1 ~> p47
the program behaves the same, but the hardware works very differently. not every dependency you see in assembly is a real dependency.
some are true dependencies: an instruction genuinely needs a value produced by an earlier instruction. Those cannot be avoided.
others are false dependencies. they appear because the ISA provides a limited number of architectural registers, so the compiler has to reuse the same register names even when the values are unrelated.
register renaming removes these false dependencies by assigning different physical registers to different values.
example:
I1: r1 = r2 + r3
I2: r4 = r1 + r5
I3: r1 = r6 + r7
I4: r8 = r1 + r9
I2 genuinely depends on I1.
but I3 does not depend on I1.
they just both write to r1.
register renaming deletes this nonsense. internally:
I1: p10 = p2 + p3
I2: p11 = p10 + p5
I3: p12 = p6 + p7
I4: p13 = p12 + p9
now the machine can see the truth.
I2 waits for I1.
I4 waits for I3.
I3 does not wait for I1.
this is the point.
register renaming does not remove real dependencies.
it removes fake dependencies created by bad naming pressure. and honestly, that is most performance engineering, stop confusing the interface with the implementation.
for CS people, this is basically hardware SSA. the compiler does SSA to reason about code while the CPU does register renaming to survive your code at runtime.
for electronics people, this is where the cute abstraction starts bleeding. because “just rename the register” means renaming tables, freeing lists, having a physical register file, ROB, issue queue, multiport pressures, bypass paths, etc.
the hardware cycle is doing the same thing for multiple instructions per cycle, handle dependencies inside the same rename group, recover from branch mispredicts, keep exceptions, without leakinf wrong-path state architecturally.
this is why computer architecture is beautiful. every simple abstraction is sitting on top of a pile of electrical junk. register renaming lets the CPU execute out of order without hesitation.
inside, the CPU is running a speculative dataflow engine with versioned register state, over branches, and cache misses. and this is also why “assembly is close to hardware” is only half true. assembly is close to the contract.
not the actual machine.
the actual machine is microps, physical registers, reservation stations, reorder buffers, predictors, queues, bypass networks, and other hardware designed to abstract away the complexity of execution.
source that taught me the mental model: register renaming as the separation of logical/architectural registers from physical registers, mainly to eliminate false dependencies and expose instruction-level parallelism. also worth reading around Tomasulo’s algorithm, because that is where the whole dynamic scheduling + hardware renaming + reservation-station brain damage starts to click.
@astrobase_space the amount of fluid dynamics, combustion chemistry, controls, metallurgy and pure engineering obsession packed into this frame is so fucking cool.