Fuzix for Pico Computer 2/3 v0.2 - self-hosted C compiler

The machine now compiles C on its own.

cc is Alan Cox's Fuzix Compiler Kit retargeted to a bytecode machine, running on the hardware — not a cross-compiler. Write a C file on the Pico Computer, cc prog.c, bcrun prog.bc, and that is it.

# cc hello.c
# bcrun hello.bc
hello from Fuzix

Dialect is C89 plus declarations after statements: the full type system, structs and unions by value, enums, typedefs, function pointers, switch, goto, 64-bit long long, double-precision floating point, and a runtime library with stdio, string, memory and file I/O. #include <stdio.h> works.

Correctness is measured rather than asserted: 165 of the 175 applicable tests in the public c-testsuite conformance suite pass with output byte-identical to gcc, and a set of samples in the tree is diffed against gcc on every change — on the board as well as on the host. Bitfields are the only part of C89 missing, and are refused with a diagnostic rather than half-implemented. The manual's The C compiler chapter lists the limitations.

The samples are on the card in /root/cc if you want something to compile.

Two long-standing crash bugs fixed

Both were shared Fuzix code that is correct where int is 16 bits and wrong where it is 32 — a class of fault worth knowing about on any 32-bit Fuzix target.

Filesystem corruption. blk_alloc refilled the block free list with a copy length of sizeof(int) for a uint16_t field, running two bytes past s_free[] onto s_ninode, the inode free-list count. Every refill restored a stale inode count and resurrected already-allocated inodes naming live files.

panic: no free buffers with the pool empty. freebuf() computed a buffer's age from uint16_t operands against an int16_t; at 32-bit int those promote to signed, so once the LRU counter wrapped every buffer looked negatively aged and the kernel panicked with all twenty buffers free. It had been hunted as a leak for some time — the dump that settled it showed 18 of 20 buffers reading busy 0.

Also timer_expired(), whose magnitude comparison read a freshly set timer as already expired whenever its deadline wrapped — a source of occasional spurious SD errors. That one is wrong at either int width.

Also since v0.1

• Flash writes made safe for PSRAM and the XIP cache, taking MMBasic's QMI save/restore approach
• Interrupt-driven console in both directions — serial file transfers went from lossy to 14K in about four seconds
• Console line editor and command history restored, after the user-memory corruption that had forced their removal was traced to an unaligned initial user stack pointer in _execve
• Process pool pinned to its own linker region, so growth is a link error rather than a silent relocation of userland
• bufs reports the kernel buffer cache; devtools/bufwatch.py samples it between steps of a workload

Files

File	Purpose
fuzix.uf2	Kernel image — flash via BOOTSEL drag-and-drop
pc3-sd.img.gz	SD card image, now with the compiler (gunzip, then write to a card ≥ 128 MB)
FUZIX-PC3-MANUAL.pdf	User manual: installation, SD setup, BBC BASIC, the C compiler, pin usage
SHA256SUMS	Checksums for the above

One kernel image serves both the Pico Computer 2 and 3; the board is detected at boot. See the manual for installation. Sources: branch pc3; the SD image is built by Applications/CC/mkccimage.sh.

Note on the tag name

The tag is pc3-v0.2, not v0.2 — upstream Fuzix already uses v0.2, v0.2.1, v0.3 and v0.4 for Alan Cox's own releases. v0.1 was free only because upstream's numbering happens to start at 0.2, so PC3 releases are namespaced from here on.