Running In Printf

February 22, 2026 by Al Williams 7 Comments

You may or may not know, but printf is a Turing-complete language, once you exploit all the strange and wonderful format characters in it (especially %n). But who has time to write code as printf modifiers? Now, thanks to [sebsite], you can at least write in a slightly higher level assembly language and compile to printf. Practical? No. Cool? Undeniably.

As an example, the page shows fizzbuzz written in the assembler:

<pre><code>alias i, fizz, buzz

->fizz ([i] + 1) % 3 == 0
->buzz ([i] + 1) % 5 == 0
->i [i] + 1
->exit [i] == 100

[i] if !![i] & ![fizz] & ![buzz]
"Fizz" if [fizz]
"Buzz" if [buzz]
"\n" if [i]</code></pre>
<pre>

The alias keyword defines constants and, owing to default values, sets i to zero, fizz to one, and buzz to 2. The “arrow” statements store a result into a variable (so the first assignment sets the resulting value into fizz).

Continue reading “Running In Printf” →

Linux Fu: Customizing Printf

October 24, 2023 by Al Williams 13 Comments

When it comes to programming in C and, sometimes, C++, the printf function is a jack-of-all-trades. It does a nice job of quickly writing output, but it can also do surprisingly intricate formatting. For debugging, it is a quick way to dump some data. But what if you have data that printf can’t format? Sure, you can just write a function to pick things apart into things printf knows about. But if you are using the GNU C library, you can also extend printf to use custom specifications. It isn’t that hard, and it makes using custom data types easier.

An Example

Suppose you are writing a program that studies coin flips. Even numbers are considered tails, and odd numbers are heads. Of course, you could just print out the number or even mask off the least significant bit and print that. But what fun is that?

Here’s a very simple example of using our new printf specifier “%H”:

printf("%H %H %H %H\n",1,2,3,4);
printf("%1H %1H\n",0,1);

When you have a width specification of 1 (like you do in the second line) the output will be H or T. If you have anything else, the output will be HEADS or TAILS.

Continue reading “Linux Fu: Customizing Printf” →

Beyond Printf(): Better Logging Practices For Faster Debugging

July 21, 2020 by Maya Posch 27 Comments

All of us who do some programming know that logging is a time-tested way to output messages about the internal state of our code. With varying degrees of adjustable granularity, these messages allow us to keep track of not only the state of the application, but also its overall health. When things do end up going FUBAR, these log messages are usually the first thing we look at as a software equivalent of a Flight Data Recorder in an airplane.

Spending some time and care in not only designing the logging system, but also in deciding what should be logged and at what level, can make our future self appreciate life a lot more. We’re all familiar with the practice of ‘printf-debugging’, where logging is added as part of the usual post-crash autopsy as one tries to figure out what exactly went wrong. It’s one way of doing it, and eventually it works, but we can do much better.

People are lazy, and you’re only going to stick to good logging practices if they are at least as easy if not easier than sprinkling printf() statement throughout the code. Yet at the same time we want to be able to handle things like log levels and newlines without too much extra typing. The most successful logging libraries are built with this

Continue reading “Beyond Printf(): Better Logging Practices For Faster Debugging” →

Hackaday Podcast 071: Measuring Micrometers, The Goldilocks Fit, Little Linear Motors, And 8-bit Games On ESP32

June 12, 2020 by Mike Szczys 3 Comments

Hackaday editors Mike Szczys and Elliot Williams fan through a fantastic week of hacking. Most laser cutters try to go bigger, but there’s a minuscule one that shows off a raft of exotic components you’ll want in your bag of tricks. Speaking of tricks, this CNC scroll saw has kinematics the likes of which we’ve never seen before — worth a look just for the dance of polar v. Cartesian elements. We’ve been abusing printf() for decades, but it’s possible to run arbitrary operations just by calling this Turing-complete function. We wrap the week up with odes to low-cost laptops and precision measuring.

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (60 MB or so.)

Continue reading “Hackaday Podcast 071: Measuring Micrometers, The Goldilocks Fit, Little Linear Motors, And 8-bit Games On ESP32” →

Tic-Tac-Toe Implemented In Single Call To Printf()

June 5, 2020 by Donald Papp 34 Comments

[Nicholas Carlini] programmed a C implementation of two-player Tic Tac Toe, and he did it in a single call to printf(). The arguments for that single function call get mind-bendingly complex, so it may come as no surprise that it was written for The International Obfuscated C Code Contest (IOCCC).

Most of us are aware that printf() is one of those functions that is considerably more complex under the hood, and capable of far more, than it may appear to be. But did you know that it is capable of Turing-complete computation?

[Nicholas] clearly steps through the theory, so give it a read. In short, a maze of arguments handles the logic of the game while an embedded scanf() reads user input, and printing the game board is always preceded by an escape code to clear the screen.

[Nicholas] is certainly no stranger to in-depth understandings; we’ve seen his work before in demonstrating how to fool speech recognition with hidden commands, including a powerful example showing how two virtually identical-sounding audio files transcribe entirely differently.

Debugging With Serial Print At 5333333 Baud

February 25, 2018 by Donald Papp 28 Comments

Debugging with printf is something [StorePeter] has always found super handy, and as a result he’s always been interested in tweaking the process for improvements. This kind of debugging usually has microcontrollers sending messages over a serial port, but in embedded development there isn’t always a hardware UART, or it might already be in use. His preferred method of avoiding those problems is to use a USB to Serial adapter and bit-bang the serial on the microcontroller side. It was during this process that it occurred to [StorePeter] that there was a lot of streamlining he could be doing, and thanks to serial terminal programs that support arbitrary baud rates, he’s reliably sending debug messages over serial at 5.3 Mbit/sec, or 5333333 Baud. His code is available for download from his site, and works perfectly in the Arduino IDE.

The whole thing consists of some simple, easily ported code to implement a bare minimum bit-banged serial communication. This is output only, no feedback, and timing consists of just sending bits as quickly as the CPU can handle, leaving it up to the USB Serial adapter and rest of the world to handle whatever that speed turns out to be. On a 16 MHz AVR, transmitting one bit can be done in three instructions, which comes out to about 5333333 baud or roughly 5.3 Mbit/sec. Set a terminal program to 5333333 baud, and you can get a “Hello world” in about 20 microseconds compared to 1 millisecond at 115200 baud.

He’s got additional tips on using serial print debugging as a process, and he’s done a followup where he stress-tests the reliability of a 5.3 MBit/sec serial stream from an ATMega2560 at 16 MHz in his 3D printer, and found no missed packets. That certainly covers using printf as a debugger, so how about a method of using the debugger as printf?

Backchannel UART Without The UART

July 18, 2017 by Inderpreet Singh 22 Comments

Anyone who has worked with a microcontroller is familiar with using printf as a makeshift debugger. This method is called tracing and it comes with the limitation that it uses up a UART peripheral. Believe it or not, there are 8051 variants out there that come with only one serial block and you are out of luck if your application needs it to communicate with another device.

[Jay Carlson] has a method by which he can piggyback these trace messages over an on-chip debugger. Though the newer ARM Cortex-M software debugger already has this facility but [Jay Carlson]’s hack is designed to work with the SiLabs EFM8 controllers. The idea is to write these debug messages to a predefined location in the RAM which the debugger can access anyway. His application polls a certain area of the memory and when it finds valid information, it reads the data and spits it out into a dedicated window. It’s using the debugger as a makeshift printf!

[Jay Carlson] used slab8051.dll interface and put together a C# program and GUI that works alongside the SiLab’s IDE. The code is available on GitHub for you to check out if you are working the EFM8 and need a helping hand. The idea is quite simple and can be ported to other controllers in a multitude of ways like the MSP430 perhaps. For those of you who like the Teensy, you might want to take a look at adding debugger support to the Teensy 3.5/3.6.