Fork And Run: The Definitive Guide To Getting Started With Multiprocessing

Since the early 2000s, the CPU industry has shifted from raw clock speed to core counts. Pat Gelsinger famously took the stage in 2002 and gave the talk the industry needed, stating processors needed specialty silicon or multiple cores to reduce power requirements and spread heat. A few years later, the Core series was introduced with two or four-core configurations to compete with the AMD Athlon 64 x2.

Nowadays, we’re seeing heterogeneous chip designs with big and little cores, chiplets, and other crazy fabrication techniques that are fundamentally the same concept: spread the thermal load across multiple pieces of silicon. This writer is willing to put good money into betting that you’ll see consumer desktop machines with 32 physical cores in less than five years. It might be hard to believe, but a 2013 Intel Haswell i7 came with just four cores compared to the twenty you’ll get in an i7 today. Even an ESP32 has two cores with support in FreeRTOS for pinning tasks to different cores. With so many cores, how to even write software for that? What’s the difference between processes and threads? How does this all work in straight vanilla C98?

Continue reading “Fork And Run: The Definitive Guide To Getting Started With Multiprocessing”

C23 Programming For Everyone

Here’s a history quiz: What architecture did the first C++ compiler target? Of course, it is a trick question. The original C++ — known then as C with classes — compiler wrote out standard C code that you then compiled for whatever your target was. This has a lot of advantages since C compilers are everywhere. Now we are seeing a similar approach to bring C23 to the world with Cake. Cake can translate C23 or other versions to C99 which you can then compile with normal compilers.

While the old C++ compiler, cfront, needed special steps to compile (since it was built using C++), you can build cake for Windows or Linux easily. However, it can also be built with emscripten and you can try it yourself in your web browser.

Continue reading “C23 Programming For Everyone”

The Big List Of Naughty Strings Helps Find Those User Input Problems

Any software that accepts user input must take some effort to sanitize incoming data, lest unexpected and unwelcome things happen. Here to make that easier is the Big List of Naughty Strings, an evolving list of edge cases, unusual characters, script-injection fragments, and all-around nonstandard stuff aimed at QA testers, developers, and the curious. It’s a big list that has grown over the years, and every piece of it is still (technically) just a string.

These strings have a high probability of surfacing any problems with handling user input. They won’t necessarily break anything, but they may cause unexpected things to happen and help point out any issues that need fixing. After all, many attacks hinge on being able to send unexpected inputs that don’t get properly sanitized.

Finding bad inputs is not always entirely straightforward, but at least the Big List of Naughty Strings is available in a variety of formats to make it easy to use. [Max Woolf] has been maintaining the list for years, but if you haven’t heard of it yet and think it might come in useful, now’s the time to give it a look. Now you can help ensure your system can handle things like someone registering a company named ; DROP TABLE “COMPANIES”;– LTD.

Diff Tool Knows What You Mean

We will admit to not being particularly artistic, but we do remember an art teacher telling us that sometimes it is better to draw what isn’t there instead of what’s there — a concept known as negative space. [Wilfred] makes a similar point when explaining his “fantastic diff” tool called, appropriately, difftastic. He points out that when comparing two programs, the goal isn’t so much to determine what changed, but rather what stayed the same. The more you can identify as the same, the less you have to show as a change.

The tool compares source code in a smart way, assisted by tree-sitter which has many different languages already parsed, at least well enough for this purpose. According to [Wilfred’s] post the tool supports 44 different languages ranging from bash and YAML, Verilog to VHDL, and C++ to Rust, among others.

Continue reading “Diff Tool Knows What You Mean”

KittyOS: Writing A Toy OS For The ATmega168 From Scratch

Writing an operating system for a computing platform is one of those non-trivial tasks few people actually need to do, regardless of whether it’s for a small microcontroller or a larger general-purpose computer. Many of us spend a large amount of our time working on producing robust code for embedded systems, occasionally diving deeper into the abstraction when we’re stuck on a problem. Quite often this work is sitting on top of an RTOS, which we consider a solved problem. [Jonathan Diamond] had picked up a fair bit of knowledge of some of the low-level AVR black magic, as well as some details of how operating systems work internally, and so decided to have a crack a building a toy operating system called KittyOS, for the learning experience alone.

[Jonathan] hastens to add that this is not a practical OS, but a learning platform that needs a few more bells and whistles added to be useful. Aimed at the 8-bit AVR ATmega168 with its mere 16kB of flash and 1kB of SRAM, the diminutive chip can still perform more than well enough to host the rudimentary OS — up to four application tasks, and some basic system call support.

Already, KittyOS sports preemptive multitasking, with prioritization and support for applications written in C. Hardware support is a bit limited, with just serial I/O and a spot of GPIO, but that’s more than enough for a demonstrator. Applications can be loaded into any of the four available slots, with per-slot run state control, using the Python-based host interface. The post is a long one, with an absolute ton of the gory details we love around these parts, and we’re very glad [Jonathan] took the time to make a proper write-up as well as a demonstration video, which can be found after the break.

Continue reading “KittyOS: Writing A Toy OS For The ATmega168 From Scratch”

Choose Your Own Vector Map

There are adults out there driving who were born after Google Earth came out. Potentially distressing facts aside, those who were around to remember the magic of scrolling in and out with infinite levels of detail was an experience that burned into our brains. Perhaps still curious 21 years later, [Craig Kochis] dove into how vector maps work by implementing one himself.

Some standard helper functions convert latitude and longitude into Mercator coordinates (x and y coordinates on the screen). He used WebGL to draw a canvas, making the whole thing interactive on the webpage itself. The camera position and zoom level stored as a matrix that is used to transform the map projection. By grabbing polygons that describe the shape of various borders and then converting those polygons into triangles with earcut, [Craig] has a part of a country rendered to a screen. Continue reading “Choose Your Own Vector Map”

Recreating DOOM On A Homebrew 8-Bit CPU

[James Sharman] has been working away on a 8-bit CPU of his own design. Naturally, with his computing device largely functional, the obvious question was asked: can it run DOOM? [James’] latest video explores this question, showing just how close he was able to get.

[James’] 8-bit pipelined CPU also has its own UART, VGA adapter, and sound adapter all built up on discrete components on various PCBs. There’s also a custom interface for a SNES controller as an input device. However, it’s fundamentally well below the specs that DOOM originally required at launch. His 8-bit CPU runs at just 4 MHz, with 64 KB of RAM. This compares poorly to the 32-bit, 33 MHz Intel 386 chips and 4 MB of RAM originally recommended to run the game.

In lieu of running the real thing, [James] demonstrated the limitations of his machine by coding his own demo, nicknamed Doomed. It’s able to average 19 fps video output at a resolution of 80×60, and consists of over 5,000 lines of hand-written assembly code. Fundamentally, it’s a basic 3D engine not dissimilar to Wolfenstein 3D, though without any actual gaming interactions involved.

[James] could have simply stated the machine won’t run DOOM. However, trying to get something similar up and running was a useful learning experience, and in his own words, highly satisfying. This attitude of pushing on in the face of adversity is what propels many other DOOM porting efforts.

Continue reading “Recreating DOOM On A Homebrew 8-Bit CPU”