Why GCC 1.42 on the Tektronix 4404 – with a C compiler from 1979 | Hacker News Reader

Why GCC 1.42 on the Tektronix 4404 – with a C compiler from 1979

medium.com

36 pointstodsacerdoti11 comments

I am sooo close to getting MAME to run Tek4404. I have been tracking down a timing bug in the scsi emulation for months, but getting very very close.

> (and of course eventually dropping support for Motorola 68010 on which the Tektronix 4404 is built)

I don't think it ever did? Looking here[1] it still seems to be supported.

I know m68k support was going to be removed at one point but it was saved in the end[2]

Nice work though! I wouldn't even know where to start with something like this! you're a wizard

[1]https://github.com/gcc-mirror/gcc/blob/master/gcc/config/m68...

[2]https://www.phoronix.com/news/GCC-11-m68k-Is-Safe

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 think a MAME driver is in the works, but maybe also a whole series of blog posts about roadblocks on that journey.

Very impressed with your persistence, dealing with a poorly documented Unix clone where all the tooling is broken in various ways seems aggravating.

Oh the register allocator bugs they must encounter...

I didn't dive into that but yes, Tek4404 runtime seems to trash d2 and a2 so I had to cross compile with those marked as scratch registers.

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.

Reply on news.ycombinator.com