Many times when someone tells you that language X is “better” at something they really mean that it has better built-in libraries for that task. Java is a great example. The language isn’t all that different from C++ outside of garbage collection and multiple inheritance, but the standard libraries are super powerful, especially for networking. Even C relies on a library to provide a lot of functions people think of as part of the language — printf, for example. That’s not really part of the C language, but just part of the standard library. When you are writing for a tiny processor, the choice of library is critical and [Keith Packard] offers you one choice: picolibc.
The library has its genesis from two other diminutive libraries: Newlib and the AVR version of libc. It provides support for ARC, ARM, i386, m68k, MIPS, MSP430, Nios II, PPC, RISC-V, Sparc64, x86_64, and the ESP8266/ESP32.
There is documentation for how to graft the library into your projects. That includes a few APIs that it expects from the operating environment. There are also documents on how the library uses thread local storage, locking, and other technical details.
Is it better than other choices? That’s not for us to say. You’ll have to build it on your exact platform and make your own comparisons. However, it is a viable candidate and since it is based on newlib, it should be fairly stable. You can debate if you should use printf, or not. Or you can just lean into it. But you can also use other parts of the library without delving into printf.
Even if you don’t need a tiny library, sometimes reading through library code for your chosen target can be illuminating. For example, how would you write an efficient strchr function? Now, look how they did it. Portability is the devil here since you could probably do even better with some CPU-specific instructions like AVX2 or SSE.
Title graphic courtesy [Priscilla Du Preez]
