Eshed Schacham

Abusing the Harvard Architecture in Nand2Tetris Assembly

Sat, 08 Nov 2025 00:00:00 +0000

Every now and then, when one writes assembly code by hand, one notices opportunities for optimisation.

Some are concise and elegant, it’s usually a good idea to use those.

Some are complicated or convoluted, you might use them if the benefit they bring is significant.

Then there are those who are outright ludicrous. You’d never use these in any production code, but if you think of one, you’re definitely going to jokingly suggest it to your coworkers just to see their horrified faces. Or maybe write about them in a blog post.

16-bit Fast Inverse Square Root

Sat, 23 Aug 2025 00:00:00 +0000

If you’re not familiar with the Fast Inverse Square Root algorithm, I thoroughly recommend reading about it before continuing. Not necessarily because the details are important, but because it’s such a mind-blowingly impressive hack.

If you are already familiar with it, you might remember that it’s based on a magical constant (0x5F3759DF¹), carefully chosen to minimise the algorithm’s relative error.

This constant was chosen by smart people who reasoned about how the algorithm works and derived formulas for picking the best constant for the job. Using the same process, they also derived the constant for double precision (64-bit) floating point numbers - 0x5FE6EB50C7B537A9. If you’re into that kind of thing, you can read all about it in Matthew Robertson’s A Brief History of InvSqrt

Nowadays, with 16-bit floating point numbers being all the rage, whether half-precision or bfloat16, I wondered if anybody derived the magic number for these formats. A short search produced no results, so I figured I might just do it myself.

Unfortunately, this late at night I’m incapable of following all the sophisticated math done by the aforementioned smart people, but I do have one advantage - there are only 2¹⁶ 16-bit floating point numbers² and only 2¹⁶ possible magic numbers, totalling just over 4 billion combinations. So let’s take an inspiration from one of my favourite articles - There are Only Four Billion Floats–So Test Them All! - and simply test them all!

With the half library giving me a pleasant interface in Rust for 16-bit floats, and the algorithm already existing, all that is left to do is to hack together two nested loops:

use half;
use num_traits::float::Float as _;

// Switch which line is commented out to choose between half and bfloat16
type f16 = half::f16;
// type f16 = half::bf16;

fn isqrt_half(x: f16, magic: u16) -> f16 {
    const THREE_HALVES: f16 = f16::from_f32_const(1.5);

    let x2 = x * f16::from_f32_const(0.5);
    let mut y = x;
    let mut i = y.to_bits();
    i = magic.wrapping_sub(i >> 1);
    y = f16::from_bits(i);
    y = y * (THREE_HALVES - x2 * y * y);

    y
}

fn main() {
    let mut max_err = [f16::ZERO; u16::MAX as usize + 1];
    for magic in u16::MIN..=u16::MAX {
        for i in u16::MIN..=u16::MAX {
            let f = f16::from_bits(i);
            if !f.is_normal() || f <= f16::ZERO {
                continue;
            }
            let expected = f16::from_f64(f.to_f64().sqrt().recip());
            let actual = isqrt_half(f, magic);
            let err = (actual - expected).abs() / expected;
            max_err[magic as usize] = err.max(max_err[magic as usize]);
        }
    }
    let (constant, error) = max_err
        .iter()
        .enumerate()
        .filter(|(_, c)| c.is_normal())
        .min_by(|(_, a), (_, b)| a.partial_cmp(b).unwrap())
        .unwrap();
    println!("Best magic: {constant:#04X}, Relative error: {}", error);
}

Less than a minute later, we get the results: for the half-precision format, the best constant is 0x59B7 and for the bfloat16 format, the constant is 0x5F35³.

Let’s compare the new constants with the ones for 32- and 64-bit floats:

Format	Constant	Maximal Relative Error
half	0x59B7	0.0028362274
bfloat16	0x5F35	0.008483887
single (32-bit)	0x5F375A86	0.0017512378
double (64-bit)	0x5FE6EB50C7B537A9	0.0017511837

We see that the accuracy of the algorithm using the half format is much better than using bfloat16, likely due to the latter’s lower precision⁴. But even with bfloat16, the maximal error is lower than 1%, a testament to the robustness of the algorithm.

Is this useful for anything? Probably not, since the algorithm itself is more or less obsolete. Nevertheless, these magical constants deserve to be put on the internet, so here they are.

Later the constant 0x5F375A86 was shown to produce better results. ↩
We actually have even less than 2¹⁶, since the algorithm is only defined for normal positive numbers, of which there are 30720 half precision floats and 32512 bfloat16s. ↩
When skipping the Newton-Raphson step, the constant for half is 0x59BB and the constant for bfloat16 is 0x5F37. ↩
bfloat16 has 7 bits of mantissa, while half has 10. ↩

Solving Super Six

Fri, 02 Aug 2024 00:00:00 +0000

Super Six (a.k.a Rio and plenty of other names) is not a good game, it’s repetitive, heavily luck dependent, and repetitive. Nevertheless, it has two major qualities - it’s short and simple. These qualities translate into a much more interesting one - it’s solvable for two players!

While the game itself is a mediocre subject for a blog post, the maths behind solving it are not only interesting themselves, but they can also be used to solve other two-player games.

Encoding tic-tac-toe in 13 bits

Mon, 26 Feb 2024 00:00:00 +0000

The other day I happened upon a post by Chris Barrick detailing how to encode a tic-tac-toe game state in 15 bits, itself a response to an earlier post by Alejandra González detailing how to encode a tic-tac-toe state in 18 bits.

In their posts, Chris and Alejandra mention 10 bits as the absolute minimum, since there are only 765 possible game states. This number, however, takes mirroring and rotations into account¹, while Chris’ and Alejandra’s solutions do not. If you include mirrorings and rotations, the number of states jumps to 5477 that gives us a theoretical minimum of \(\left\lceil{\log_2{5477}}\right\rceil=\left\lceil{12.419...}\right\rceil=13\) bits.

For physicists, the difference between 13 and 15 might look negligible, but hey, consuming 15% more space is no joke.

The 765 figure considers the following two boards (and a few others) as the same state: ↩

Finding Binary & Decimal Palindromes

Sun, 15 May 2022 00:00:00 +0000

Recently I’ve had my 33rd birthday and since I’m a nerd I also checked the binary representation of that number, which is 100001.

OMG, I thought to myself, 33 is a palindrome in both bases! I immediately checked when my next palindromtastic birthday would be:

That’s a tad over my life expectancy, but arguably reachable. After that, the numbers get big quite fast. Exponentially fast. The On-Line Encyclopedia of Integer Sequences has an entry for the sequence of these numbers, with a list of the 147 known elements (at the time of writing this post). The largest known number is 9335388324586156026843333486206516854238835339 with 46 decimal and 153 binary digits. That’s quite large indeed.

Life is short, let’s spend what little we have on finding even bigger palindromes!

Finding Evidence for GPL Violation with Ghidra and Friends

Sun, 14 Jul 2019 00:00:00 +0000

Let’s say you’ve worked a few years on an open source project released under the GNU General Public License (GPL) and let’s say you’ve spied an application that is eerily similar to your project but whose owner claims no infringement of your rights.
How would you find evidence for such infringement or lack thereof?
Obviously, I don’t know the answer to this question as it will vary depending on your case. I can, however, tell what I did when faced with this situation, which I hope you will find educational or even entertaining. This post is somewhere between a write-up and a tutorial. Hopefully it is interesting as both.

Hang on to your trousers, we’re going in!