2026-02-17 A vibe-coded alternative to YieldGimp

If you’re a UK tax resident, short-term low-coupon gilts are the most tax efficient way to get savings-account-like returns, since most of their yield is tax free. This makes them very popular amongst retail investors, which now hold a large portion of the tradable low-coupon gilts.

YieldGimp.com used to be a great free resource to evaluate the gilts currently available. However, it was recently turned into an app rather than a simple webpage. I’m not even sure if the app is free or paid, but I do not want to install the “YieldGimp platform” to quickly check gilt metrics when I buy them.

So I asked my LLM of choice to produce an alternative, and after a few minutes and a few rounds of prompting I had something that served my needs. It is available for use at mazzo.li/gilts/, and the source is on GitHub.

It differs from YieldGimp in that it does not show metrics based on the current market price, but rather requires the user to input a price. I find this more useful anyway, since gilts are somewhat illiquid on my broker, so I need to come up with a limit price myself, which means that I want to know what the yield is at my price rather than the market price. It also lets you select a specific tax rate to produce a “gross equivalent” yield.

It is not a very sophisticated tool and it doesn’t pretend to model gilts and their tax implications precisely (the repository’s README has more details on its shortcomings), but for most use cases it should be informative enough to sanity-check your trades without a Bloomberg terminal.

2025-10-17 Hidden benefits of undefined behavior

I was reviewing some code at work, and something jumped at me when reading some arithmetic:

static inline int64_t int32ToDecimal9(int32_t i) { return i * 1000000000; }

If you’ve had the good fortune of dealing with C or C++ for extended periods you would have recognized the problem. i * 1000000000 will be performed with 32-bit precision, which is almost certainly not what the programmer intended since it will lead to an overflow for any i outside [-2, +2].

So far so good, a classic C footgun – we’ve all been there.

However code using this function was running, and working, which was more surprising. Take a moment to consider why before revealing the solution.

imul    eax, edi, 1000000000
cdqe

2025-09-25 Open sourcing TernFS, a distributed filesystem

A few days ago we open sourced TernFS, a distributed filesystem which has been used in production at XTX for a couple of years now. The project took up a big chunk of my waking hours for a year and a half, and I’m extremely happy that we are now sharing it with the world.

You can find a blog post describing it on XTX’s tech blog, and the source code on GitHub. The repository contains the full git history, which is somewhat unusual for these sort of projects: you can see how the codebase grew rapidly from prototype into a production system.

2025-06-09 inline-verilog: Execute Verilog circuits from Haskell

Like for most of the past 13 years, early June meant attending ZuriHac. The event was as pleasant and well organized as ever.

While talking to Ed Kmett he half-jokingly mentioned that it would be useful to have a Verilog analogue of inline-c, especially to test Verilog circuits against Haskell functions.

A few hours later I had inline-verilog, which lets to do just that.

inline-verilog allows you to embed “nameless” Verilog modules right in your Haskell:

{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE QuasiQuotes #-}
{-# LANGUAGE ScopedTypeVariables #-}
import qualified Language.Verilog.Inline as V
import           Data.Word
import           Foreign.Marshal.Alloc (alloca)
import           Foreign.Storable (peek)

V.verilog

adder :: Word16 -> Word16 -> IO (Bool, Word16)
adder a b = alloca $ \sum -> alloca $ \carry_out -> do
  [V.block|
    module (
        input  [15:0] a,
        input  [15:0] b,
        output [15:0] sum,
        output        carry_out
    );
        assign {carry_out, sum} = a + b;
    endmodule
  |]
  (,) <$> peek carry_out <*> peek sum

main :: IO ()
main = print =<< adder 1 2

The example above will print (False,3).

Input and output arguments are expected to be present in the Haskell context in which the V.block is called. The Haskell types for the input and outputs are automatically inferred from the Verilog code. The output arguments are expected to be pointers in which the outputs will be stored.

Verilog code can also be factored out within a Haskell file using V.verbatim. See tests.hs for a more complex example.

The way inline-verilog works is by invoking verilator to compile each Verilog block to C++, generating C stubs which execute the verilated circuit, and linking everything up with the Haskell executable.

There are some limitations, namely I haven’t implemented or tested:

• Inputs/outputs wider than 64 bits.
• struct ports.
• Multidimensional input/output ports, e.g. reg [15:0] foo [3:0][3:0] .
• Importing.

All of the above should be easy, but it did not fit in the couple of hours it took to cook inline-verilog to its current state.

Also, inline-verilog does not make much sense for non-combinatorial circuits (i.e. stuff that does IO). But to test functional units, it should do the job.