Scope

Previous: Intro           Next: TMS9900

Tools and libraries

The tools in binutils seem very mature.  I have not found any issues with the assembler, linker, objdump of other tools.  I've done a little bit of work in libgcc but only when it blocks compiler development.

I have steered clear of libc and have no plans to do any work there.  Tursi's libti99 provides printf() and other functions which has been enough for me.

GCC version

One aspect of picking up a development activity that start 13 years ago, is that many of the tools have changed, including the compiler itself.   Gcc-4.4.0 was the latest in 2010 but in 2023, gcc-13.2.0 is the latest.  While tools for retro computing are never going to go out of date (because they already are), environments do change.  Building gcc-4.4.0 with gcc-12.2.0 throws up lots of warnings for example.  But so far nothing has actually broken.

A lot has changed gcc4 and gcc13.  A lot hasn’t changed though and the basics of the machine description is still the same.  So moving to gcc13 doesn’t need a complete rewrite thankfully.  But enough has changed to make the upgrade non-trivial.  All code is now compiled as C++ which immediately causes several compilation errors.  Several #define options give a compilation error that the option is "poisoned" (presumably deprecated long ago). Other significant changes include a change to the way condition codes are handled.  Instead of being implied, they now have to explicitly called out as clobbers to the condition code.  Reload is particularly sensitive to clobbering of condition codes, so it is necessary to make several insns into define_insn_and_split with a condition of “reload done”.  This is documented here.

The size of the compiler has grown very significantly as well.  The line count went up an order of magnitude, with a corresponding increase in build time.  A clean build of gcc13 takes close to an hour on my desktop.  For these reasons, the only currently released versions of the tms9900 are for the gcc-4.4.0 compiler.  There is a dev branch for gcc13 though and initial tests have shown significantly better code output from gcc13.  Once gcc4 is stabilised, my the plan is to rebase the gcc13 branch and continue development there.

Development Philosophy

My approach is a little different to Insomnia's in a few respects.  I'm trying to keep things simple and keep my focus narrow.  I also believe that “Premature optimization is the root of all evil”.  The principles I'm following are:

• Keep the scope narrow. Just the compiler. Happily, the binutils seem quite stable and I haven't had to touch anything there.  I'm not (yet) building any libraries apart from a few essentials in libgcc.
• Deliver functional first and optimal later.  In the past, it looks like a lot of effort has gone into peepholes and other optimisations.  While we are working in a very constrained environment, fine tuning can happen later once we have a fully functional base to work with.
• Avoid changes to GCC.  I'm trying very hard to avoid patching the compiler.  In theory, a backend for gcc should be confined to just a machine description file, a header file to define the target machine and optionally some C support functions.  GCC is something like 3 million lines of code in size.  I haven't enough time left on earth to ramp up on all the internals and certainly not enough to debug any breakage I may cause by tweaking the internals!
• Keep the machine description simple.  No lengthy sequences of opcodes in insns - these can be placed in library functions.  No insns defined for any complex functions including 32-bit ops, floating point, etc.
• Limit the use cases.  The compiler has no support for CRU operations or for interrupts or BLWP.  These are best handled using inline asm calls.  The inline asm can of course wrap C functions as well.