• Please review our updated Terms and Rules here

Building gcc1.27 for Uniflex on Tektronix 4404

Elektraglide

Experienced Member
Joined
Mar 24, 2023
Messages
171
Location
UK
Well that was fairly brutal. but I have managed to get gcc1.27 built and running on the Tektronix 4404. The native C compiler is kinda terrible, so building gcc - even though back then gcc is fastitiously K&R syntax for bootstrapping, was a lesson in misery.

Even if it got through the native cpp (which often died because of the long statements), lots of:

517: && !reg_mentioned_p (((((p)->fld[3].rtx))->fld[0].rtx),
** FATAL ERROR: Expression too complex - internal table overflow.

** FATAL ERROR: Internal table overflow - "switch" item count.

etc. So I tried premasticating all the source files on my Mac. ie resolve all the includes into single large files and then just compile on the Tek4404. No dice, still explodes. I had a go at strength reducing large expressions etc but if you've ever looked at the C that gets generated from a machine description, its not made for human eyes, so was very error prone.

Finally bit the bullet and used m68k gcc cross compiler on the Mac to generate .o files and then wrote a utility to convert the ELF32 .o files into Uniflex relocatable files (.r files). Given there isn't any docs on the Uniflex file format, just getting something simple like this working perfectly took quite a while. Its here if you're interested:

tek4404 github repo

After much head scratching when printfs turn into infinite loops, turns out Uniflex clobbers a2 and d2 on function calls. So added:
-fcall-used-d2 -fcall-used-a2

Rebuilt everything but turns out the native assembler which I am relying on has various odd quirk. eg it knows of quick variants of instructions (movq etc) but you cannot use them in your code, you have to let Mr. Assembler decide to do that..whatev!

So lots of editing a tm-4404.h to get assembler output that was acceptable.

And finally! Got a hello world program running through cpp, into cc1, and into asm and into the link-loader. Woot!!
I've made a fork of gcc1.27 for anyone interested in the madness: gcc1.27 fork for Tek4404

Screenshot of the gcc running on Tektronix 4404..

fullcompile.png
 
Great work! That's pretty neat that you were able to bootstrap GCC on a system with 1 or 2MB of RAM! I can feel your pain getting gcc up and running. I just bootstrapped GCC 3.4.6 on my Pentium III PC running UnixWare 7.1.1 today.

P.S. I liked your new window system video on youtube. Another herculean feat.
 
In the end I switched to gcc1.43 which had a bunch of fixes. These gcc builds predate bintools etc - nice and simple.
So I used gcc cross compile to m68k on Mac of the gcc files to get .o files. I then wrote a .o to Tektronix relocatable format (.r files) so I could run a batch conversion of the .o with the hope of using the native Linker on Tek4404. But the linker dies because too many files, so I then wrote a util called rcat that could concatenate .r files together into a big file. Sort of like a halfway house linker in that it has to adjust all the relocation info, aggregate symbols etc etc. And that worked! I now have gcc1.43 working on tek4404. A good few insane side missions along the way - one was gcc when compiling generates some floating point values during code generation that are not IEEE compliant - they're not used to emit code, but Tek4404 floating point sigfaulted on misformed floats. Disassembling the code, turns out Tek4404 checks every single float operand, on every single float operation for validity. Performance was apparently not the goal here! So I patched the code with 4e75 (rts) to avoid such insanities.

When I get some time, I'm going to finish up rcat as a full linker. Its around 5x faster than the native one.

And before that I am sooooo close to getting Tek4404 working on MAME.
 
And for completeness and sharing the full crazy of this project, this is the workflow I've been using to get Tek4404 working on MAME:

I have the original 6809 source assembler for Uniflex. Uniflex on Tek4404 in 68000 is clearly based on this code, but is different and.. well in 68000 not 6809 and has no symbols.

So you look at the 6809 assembler, cross match with Ghidra 68000 disassembly, then single step the 68000 in MAME debugger to see what happens. Rinse. Repeat. It is a real pleasure.

Screenshot 2024-11-03 at 07.45.52.png
 
Back
Top