atarpara

Open to work | ✯ | prev. @onchainheroes

[atarpara @atarpara]

New article: deriving the math behind Solady's 67-byte, 114-gas sqrt(x) from first principles.

The Solady CLZ PR just merged! 🚀
https://t.co/yQmfRUZOOe

No magic multipliers
Exactly 6 Babylonian iterations
1 floor correction

Full derivation 👇

[atarpara @atarpara]

4/4 DUP3 + SWAP2 = 6 gas. Two opcodes. That's the entire delta.

Solady already uses this in FixedPointMathLib.sol (fullMulDiv):

r := mulmod(x, y, d) ← before check
t := and(d, sub(0, d)) ← before check
if iszero(...) { revert }

Rule: batch intermediates before the revert check.

One unified block → compiler plans the full layout.
JUMPI in the middle → fall-through starts blind.

[atarpara @atarpara]

1/4 Answer: Version D1 is cheaper by 6 gas! 🎉

This behavior is caused by the Solidity compiler's internal "stack scheduling" heuristic during code generation.

It seems counterintuitive to delay a revert check, but on the happy path, it makes a massive difference to stack layout. Here is exactly why:

[atarpara @atarpara]

Solidity Compiler Quiz Challenge

Both functions calculate the exact same mathematical expression.

Which version is cheaper on the happy path, and why? 👇

(Spoiler: This is used in `solady.fullMulDiv()`)

[atarpara @atarpara]

3/4
JUMPI pops condition + destination — whatever's left is exactly what the fall-through block opens with.

Compare both snapshots right after JUMPI:
D1 → [lo, rem, d, extra] all 4 live — SUB/DIV/ADD fire directly
D2 → [b, a, d, lo] rem and extra don't exist yet

In D2, MULMOD needs [a, b, d] on top.

Block B opens with [b, a, d, lo].

Two ops fix it:
DUP3 [d, b, a, d, lo] <--- copy d
SWAP2 [a, b, d, d, lo] <--- reorder args for MULMOD

[atarpara @atarpara]

Solady update:

Added a CLZ variant to LibRLP.

LibRLP.encodeUint() is now 118 gas cheaper.

PR: https://t.co/1o8iuDJ6Ra

More optimizations coming soon.

[atarpara @atarpara]

Solidity Compiler Quiz Challenge

Both functions calculate the exact same mathematical expression.

Which version is cheaper on the happy path, and why? 👇

(Spoiler: This is used in `solady.fullMulDiv()`)

[atarpara @atarpara]

@banteg So, shipping https://t.co/5hbjU9usJj is only meant to solve Solidity's "stack too deep" error?

[atarpara @atarpara]

@real_philogy How does plank manage memory internally compared to solidity?

[atarpara @atarpara]

New article: deriving the math behind Solady’s `cbrt(x)` implementation from first principles.

What is the 0x90b5e5 constant actually doing?

original implementation by @duncancmt

* Why cube root needs magic multipliers
* Why sqrt does not
* Optimal Initial guess
* Exactly 5 Newton Rashson iterations

Full blog post: https://t.co/IoOkoySi4m

[atarpara @atarpara]

@tek_kac @duncancmt check solady CLZ PR.

[atarpara @atarpara]

New article: deriving the math behind Solady's 67-byte, 114-gas sqrt(x) from first principles.

The Solady CLZ PR just merged! 🚀
https://t.co/yQmfRUZOOe

No magic multipliers
Exactly 6 Babylonian iterations
1 floor correction

Full derivation 👇

[atarpara @atarpara]

10 mathematical facts packed into 8 lines of Yul.

Deep math beats brute force in EVM optimization.

Thanks to @duncancmt for formally verifying this in 0x-settler.

Full blog post link : https://t.co/9EDFzshfXx

[atarpara @atarpara]

The quirk: Integer Babylonian iterations get stuck bouncing between floor and ceil forever if x+1 is a perfect square (like x=15).

`sub(z, lt(div(x, z), z))` is the floor correction. It catches the cycle and subtracts 1.

[Jarrod Watts @jarrodwatts]

Ethereum’s next major upgrade, “Fusaka”, goes live in less than 48 hours.

I read all 13 EIPs being included so you don’t have to.

So, here are 13 tweets (with diagrams) to explain the 13 upgrades in simple terms: 🧵

[atarpara @atarpara]

Hey @solidity_lang, the community is eagerly waiting for the Solidity Summit 2025 recordings! 🗓️ The speaker lineup looked amazing. Any ETA on when they’ll hit YouTube or anywhere else?

Thanks!