Inspired by Building and using a 29-year-old compiler on a modern system, i thought I too could get this ancient version of GCC working. At the time I never had bothered with the older version as I had always assumed that there were many fixes and adaptations to GCC for it to run on MS-DOS via GO32/DJGPP. However after doing this, its obvious that GO32/DJGPP was rather built around GCC’s stock output, which would sure make a lot more sense.
And it turns out that the target machine being an i386 Sequent running BSD is the best match, both in turns of underscores, and debugging format. At first I had tried the AT&T SYSV i386 target, however it couldn’t link anything from the standard libraries that DJGPP has as they all have a leading underscore. After starting to mess with internal macros to turn things on and off, and re-define how various portions of assembly are emittied, I found the Sequent target and went with that and everything was fine, and using the existing build infrastructure for GCC 1.39 I now could actually run hello world!
gcc_v1 -v -E hello.c -o hello.i
gcc version 1.39
cpp_v1 -v -undef -D__GNUC__ -DGNUDOS -Dunix -Di386 -D__unix__ -D__i386__ hello.c -o hello.i
GNU CPP version 1.39
gcc_v1 -v -S hello.i -o hello.s
gcc version 1.39
cc1_v1 hello.i -quiet -version -o hello.s
GNU C version 1.27 (80386, BSD syntax) compiled by GNU C version 5.1.0.
gcc_v1 -v -c hello.s -o hello.o
gcc version 1.39
as -o hello.o hello.s
gcc_v1 -v -o hello hello.o
gcc version 1.39
ld -o hello C:/dos/xdjgpp.v1/lib/crt0.o hello.o -lc
go32 version 1.12.maint3 Copyright (C) 1994 DJ Delorie
hello from DJGPP v1/GCC 1.39!
Wasn’t that great? Then going through my ‘test’ programs I went to try to build the infocom interpreter, and that is when things went off the rails.
funcs.o: Undefined symbol __udivsi3 referenced from text segment
options.o: Undefined symbol __divsi3 referenced from text segment
options.o: Undefined symbol __divsi3 referenced from text segment
print.o: Undefined symbol __divsi3 referenced from text segment
print.o: Undefined symbol __udivsi3 referenced from text segment
support.o: Undefined symbol __divsi3 referenced from text segment
gcc_v1: Program ld got fatal signal 1.
I’ve had some issues with GCC and these ‘built in’ functions before. This was an early major stumbling block back in the x68000 GCC days, where after a lot of searching I was able to find 68000 versions of various math routines that were in the native Hudson Soft assembler to link in. While GCC 1.x does have a libgnu/gnulib to include these functions it warns you over and over to not use GCC to build them, but rather the native CC. But the problem is that I don’t have a native CC.
But I managed to save myself after googling around by finding srt0.c from 386BSD. Namely these two:
.globl ___udivsi3
___udivsi3:
movl 4(%esp),%eax
xorl %edx,%edx
divl 8(%esp)
ret
.globl ___divsi3
___divsi3:
movl 4(%esp),%eax
xorl %edx,%edx
cltd
idivl 8(%esp)
ret
I ended up having to removing a single underscore, but now I could link infocom, and even better it runs!
Wanting to try something far more exciting, I went ahead and tried to build DooM. However GCC 1.27 has an issue with m_fixed.c I fired up GDB to at least take a look, although I’m not sure where the fault lies.
FixedMul
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Breakpoint 1, 0x752c5ad5 in msvcrt!_exit () from C:\WINDOWS\System32\msvcrt.dll
(gdb) bt
#0 0x752c5ad5 in msvcrt!_exit () from C:\WINDOWS\System32\msvcrt.dll
#1 0x752bb379 in msvcrt!abort () from C:\WINDOWS\System32\msvcrt.dll
#2 0x0045805c in final (first=0xe066a0, file=0x75312688 <msvcrt!_iob+128>, write_symbols=NO_DEBUG, optimize=0)
at final.c:653
#3 0x00403198 in rest_of_compilation (decl=0x722718) at toplev.c:1296
#4 0x0040fbce in finish_function () at c-decl.c:3272
#5 0x004040c0 in yyparse () at c-parse.y:224
#6 0x0040239d in compile_file (name=0xe00def "C:/dos/xdjgpp.v1/tmp/cca02992.cpp") at toplev.c:837
#7 0x00403a33 in main (argc=11, argv=0xe00f90, envp=0xe01598) at toplev.c:1556
With the code being:
#ifdef REGISTER_CONSTRAINTS
if (! constrain_operands (insn_code_number))
abort ();
#endif
So I assume some error with constrain_operands? Not that it makes it any better. However I know this one file compiles fine with 1.39, and since we are on the i386 another alternative is just to used the assembly version that was hiding in the readme..
DooM mostly built by GCC 1.27
And much to my amazement, it works! Keeping in mind that this is using an a.out tool chain, along with the last DPMI enabled GO32 extender.
Considering the compiler dates back from September 5th, 1988 it’s really great to see it running.
I’ll have to upload source (GCC 1.27/DooM) & binaries later. But I imagine it should also run on EMX/RSX for a Win32 version.
