Probably he wanted to relive in the 90s where software are simple and less convoluted. Another reason at this point the modern GCC would abandon the old quirky .r format and instead use ELF everywhere so it might be a deliberate choice...Unless he is also trying to bootstrap GCC for Tektronix4404 which is sort of:
> Bootstrapping any compiler typically requires using the existing host compiler to build some native arithmetic functions (long multiply, divide etc) on which everything else will be built. You then use your native compiler to build a (non-optimal) compile of the new compiler.
Just for the record, Tek4404 never had gcc on it. The .r file format is proprietary to TSC (makers of Uniflex). I tracked down the grad student (at the time) Clem Cole that did the porting of K&R C for Tek4404 and there was a lot of time pressure to get it done.
This was a fascinating read! I truly enjoy deep dives into the relics of the early(ier) years. I'm curious if there exists a virtual machine for the Tektronix 4404, I think it'd be fun to tinker with devices like those in software since it's unlikely one will ever pass through my hands.
I was referring to gcc bugs. Doing Linux kernel development 20+ years ago certain complex functions with lots of register spills would occasionally trip up gcc's register allocator on i386. Architectures with more registers and less complex constraints on how they were used would not trigger those bugs as frequently. Eventually, gcc got better and those kinds of bugs went away, but I got to spend many hours looking at the assembly gcc produced and raw Oopsen.
There is a branch of m68k GCC still alive and maintained today that supports palmos calling convention which is similar to this but not the same: d0-d2/a0-a1 are not preserved.
