Today we built a flat-pack bookcase and had a picnic in the garden.
Once Newlib was built, the stage 2 compiler also built without too much more trouble, giving a “working” compiler executable. But, nothing will link because the runtime initialisation code is missing (usually called “crt0″, and providing a function “_start” written in assembly language that is called immediately on program load and sets up the C runtime environment then calls “main”). I added very simple/dummy versions to libgloss, which is supplied as part of Newlib and contains such code for a variety of other processors/systems. That means we can almost link a “hello world”-type program, although some more stub functions are needed before that’ll work!
But before doing that, it’s important that we have an emulator or instruction-set simulator to run stuff on without getting too grubby with the real hardware just yet. So I looked around at what people had written, and found something that looks like it’ll almost do the trick, though it’s currently hard-wired for performing “in-circuit emulation” reverse-engineering. The requirements for testing GCC are fairly minimal, it just needs to emulate the CPU itself and a single (possibly fake) peripheral to provide character-stream output, so adapting it for that shouldn’t be too hard.
Handily the real hardware provides a simple memory-mapped UART device: using that for test output seems like a good idea, since then running the same code on hardware later on becomes a possibility. So, I’m adding basic support for the UART to the emulator.
Newlib is now building! Only minor tweaks needed to the compiler proper to get it going (mostly minor bugs in insn patterns that led to things being emitted that were not recognized by the assembler). There’s no actual target-specific stuff yet in Newlib: it’s relatively easy to get a “dummy” version going on a new system, but you have to contend with autotools, which is never as fun as it should be. Then you only have to fill in a few stub functions to make it actually do stuff, but that’s not done yet.
The stage 1 compiler is now building! That’s the one that will be used to build the C library (which will be newlib, I guess). Just a couple of small bits were getting in the way. I also tried running some code for the CPU on the real hardware, but not yet stuff generated by GCC… still a bit early for that.
This evening I have been working on a GCC port for a mystery processor. A lot of work has been done towards this aim already by various other people, but attempts have so far failed (the chip does not have documentation publicly available, but it seems that good-enough information for a basic compiler port has been obtained via reverse-engineering). Sadly efforts towards both reverse-engineering and porting a compiler seem to have somewhat stalled over the last couple of years.
I’ve got GCC as far as compiling some of libgcc now (the internal library of compiler support routines). But, register elimination (part of how the compiler manages access to stacked data within functions) has been causing some problems (some offsets looked wrong, and elimination seemed to fail entirely in some circumstances): it’s not at all clear why this should be, since this particular mystery processor doesn’t really do anything at all unusual with regard to stack frames, and other ports (with virtually identical requirements) work fine.
The existing patches, and my new work, are based on a version of the compiler that is a couple of years out-of-date. Rebasing to a newer version (mostly just “git format-patch” and “git am”) seems to have done something to fix the elimination problem, but has caused some other stuff to break. But that’s now mostly fixed too!