20180309

I've got two projects ongoing right now: the blue pill boards came in, and the Forth project.

I've been jumping back and forth between the two; I've missed bare metal programming, but now I get to deal with the vagaries of memory mapping and linker scripts and whatnot. I've also constrained myself to not use any HAL, and making myself write my own.

I still need to get working on Open Data Structures; I see Wally's been working through it but I've not spent nearly enough time on it.

A cool thing I learned about today: a C compiler bomb. I was able to understand what it was doing by looking at it (and confirmed by reading a writeup on it), so that's encouraging. Here's the program::

    main[-1u] = {1};

What it does is say that main is an array (defaulting to the int type, which on the platform I built it on is a uint32_t); -1u is the largest unsigned integer possible --- so it allocates a static (global) array of 4294967295 elements of 32-bit integers, which translates to 17179869180 bytes, which translates to 16 GiB. The resulting binary has to have this array space in the binary because there is some intialisation done. This initial array will be put in the read-only data space, which is included in the text segment. A similar program might be::

    int
    main(void)
    {
            int arr[-1u] = {1};
            return 0;
    }

More compactly::

    main(){int arr[-1u]={1};}

However, the goal of a compiler bomb is to maximise the ratio of the resulting binary size to the source code; the earlier example clocks in at 14 bytes, while the second program has 25 bytes; this cuts the ratio down by almost half (which, coincidentally 1,227,133,512.9:1 --- over a billion bytes generated for every byte in the source program). This isn't really useful at all, but it's an interesting peek into how the compiler works and how programs are built.


Tags: