I know it’s utterly pointless… But yeah GCC 2.8.1 + EMX 0.9d, hosted (running) on Win32. The main reason is that I wanted to be able use use my substantially faster Win64 machines to build stuff for OS/2. And since I have a 4 core (+4 hyper thread), I want to be able to use make with the -j 16 flag, and say compile QuakeWorld/2 in under two seconds.
I was able to get the binutils 2.6 derived stuff to compile, along with the ‘ancient’ binutils which is notably the linker that EMX depends on. I would imagine this ought to be able to compile PDOS, although my own simple attempt at InfoTaskForce met with spectacular failure. While it does compile fine using an older EMX 0.8h based release.
I had a request to help get a GCC+Binutils running as native win32 exe’s something comperable to the ancient ‘ultra’ N64 toolchain done by Kyoto Microcomputer (resume pdf). One interesting thing about their toolchain is that they used a common object format for MS-DOS, DOS/V and MS-DOS on the PC-98 format, along with Win32. However the Win32 runtime doesn’t like Win64 environments. On Win64 the exew32 driver just complains:
Can’t allocate memory (Error Code=487)
However the stubs in all the exe’s reference exegcc98 exegccv DOS extender’s along with a exegcc. However googling around yields nothing.
Running on a x86 version of Windows, however the tools run and report gcc 2.7.2 release 1.2 and the binutils version is simply 2.6 with BFD version 2.6. So going with this, and the request to keep it 1997 vintage I went ahead with Gcc 18.104.22.168 and Binutils 2.8.1 as they are the end of the line in both trains of code.
To configure is really a snap, as both support the Windows NT platform directly
sh configure --host=i386-winnt3.5 --target=mips-elf
Binutils 2.8.1 notes:
make sure this uses MS-DOS rb wb type constraints!
There is no sbrk on my MinGW32 … so comment out all the sbrk stuff.
My sed LOVES UNIX style text files, so this one shouldn’t be in MS-DOS CRLF format.
mkdir only accepts the path on Win32. Also there is now chown.
Gcc 22.214.171.124 notes:
‘__inline’ for is_reserved_word needs to be commented out.
Set like the following for both ASM_FINAL_SPEC to prevent the t-mips from trying to be run.
#define ASM_FINAL_SPEC “\
Just because we are on Windows NT, doesn’t mean we want an .obj object suffix.
__spawnv : __spawnvp work better as _spawnv : _spawnvp
*((void **)__o->next_free)++ = ((void *)datum);
confuses newer compilers, with this error message:
obstack.h:341:32: error: lvalue required as increment operand
replace it with with:
*(__o->next_free)++ = ((void *)datum);
So at the end I have a cross compiler, and I can generate object files, and link files that the final tool MILD can then use and produce N64 ROM images. It’s not a 100% solution, as I don’t see any mention of MILD being GNU, however the compiler and binutils is running on Windows 10 x64!
I’m using Slackware 4.0 as a starting point, so it’s Binutils 2.9.1 and GCC 126.96.36.199 .. I verified that I can build a static hello world executable, and it runs! …
However Linux 2.0.40 has the same issue, it starts to decompress, and triggers a reboot in both Qemu and PCem. Going in circles I guess. I suppose the next step is to use the exact version they have in Slackware to see if Qemu can actually run that pre-built kernel, and if I can create one via cross compiling.
I should add that on Debian 7.1 I got GCC 188.8.131.52 running, and it too produces the exact same thing.
After getting Linux 0.98 to compile, I thought I’d take a stab at Linux 1.0. I vaugely recall when it was released, and I just remember a much larger push to 1.1. So I guess it really comes as no surprise that in the Linux kernel archives, there is simply the 1.0 tar, and 9 patch files.
I went ahead, and patched up the release, and then tried to build with GCC 2.3.3. This however proved not to be up to the task, as 2.3.3 has issues with some of the assembly macros, so delving into the readme shows that you need to use GCC 2.4.5 or higher. Since I wanted to keep at least the tools on par, I went ahead and build 2.4.5, and once more again used the gcc driver from 2.6.3. I further ended up relying on headers, and checking tool versions from Debian 0.91, which also revealed that they were still using GAS 1.38 back then.
One interesting note while building piggback, which takes the compressed system object, and wraps it in an object file, is that it directly uses the magic “0x00640107”, which is for a later “Linux/i386 impure executable (OMAGIC)” filetype. But because my binutils is so ancient, I needed to change it to “0x00000107” so that the linker would recognize it as a “386 executable not stripped” file. As always when having no idea what I was doing, it was easier to have it make an empty object file, set the type for 12345678 and look for where it occurs in the data stream, and just match it with a known object file. As you can see, it worked.
I don’t know if it is of any interest, but the kernel source, along with a binary is available to download linux-184.108.40.206z, and the same goes for GCC gcc-220.127.116.11z.
And of course, you’ll want the latest download, which includes the pre-built tools, qemu, and build environment to get you started.
So first thing is to build GCC 2… I couldn’t find any of the Linux patches for 2.0, 2.1 or 2.2.. I only tried to build 2.0 from source as targeting a.out i386 but it looks like the 2.0 files on the FSF’s site are missing files?
Anyways GCC 2.3.3 actually includes builtin support of Linux! I was able to build most of it, but just like GCC 2.5.8 for OS/2 EMX, But this time I used the gcc driver from GCC 2.6.3, which added support for Windows NT 3.5 native builds, and I now had my GCC cross compiler!
D:\aoutgcc\src>gcc2 -v -c hi.c -o hi
gcc version 2.6.3 -Linux 2.3.3
cpp2 -lang-c -v -undef -D__GNUC__=2 -Dunix -Di386 -Dlinux -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux hi.c C:\Temp\cca09324.i
GNU CPP version 2.3.3 (80386, BSD syntax)
cc12 C:\Temp\cca09324.i -quiet -dumpbase hi.c -version -o C:\Temp\cca09324.s
GNU C version 2.3.3 (80386, BSD syntax) compiled by GNU C version 5.1.0.
a386 -o hi C:\Temp\cca09324.s
Thankfully the prior binutils and assembler I was using in my GCC 1.40 cross compiler, still cooperated just fine, and I could happily build and link just fine.
From there it was a matter of fighting the makefiles as for some reason as make calls other makefiles they are not passing variables, so I just cheated, and changed the paths, along with editing the dependencies to finding stuff in a more sane manner. Plus all the Makefiles have include paths hard coded into the build process as expected. After fighting for a while, it linked and even better, it runs!
So yeah, using the MCC hard disk image from oldlinux.org and it boots!
Cool stuff, indeed!
As an added bonus I was also able to get 0.97 & 0.98 to compile as well!
DooM is without a doubt one of the most popular PC games of all time. And thanks to it being written in C is also an incredibly portable game. One platform that mysteriously was lacking DooM was the SHARP x68000.
After a bored day of playing with the source to Mariko’s GCC 1.42 / 1.30 that targets the x68000, I thought I would take a stab at trying to compile DooM. Since I’m using such an ancient version of GCC the first stumbling block is that DooM is FULL of C++ style comments, which older K&R & ansi based compilers of the late 1980’s simply cannot handle. So the first phase was to convert all the comments.
In order to convert the comments, I came across this great tool, uncrustify. The pain is that it doesn’t seem to take wildcards, but you can use make to have it do your work for you, or just a batch file…
uncrustify.exe --replace -c 1.cfg cl_main.h
you get the idea.
The key thing is the configuration file that tells uncrustify what to do. To convert C++ comments to C is quite simply:
cmt_cpp_to_c = true
And away we go. Having learned the ‘null’ lesson of Quake 2 the hard way, I started out with a working copy from Windows, via GCC 1.40 for Windows/RSXNT. I figured that by having a ‘known good’ build with the a very close compiler level would be a good start as I don’t want to fight too much with the compiler. After it was running with minimal changes, it was time to start the real fun.
Starting the actual port aka platform issues
The first error I hit was:
Error: Couldn’t realloc lumpinfo
For some reason the SHARP/Hudson LIBC has issues doing a realloc. I have no idea why. Over on nfggames Neko68k had mentioned that he had a disk image with a working version of GCC, that uses different includes/libraries that was able to get further. I wasted some time by trying to bypass the Sharp LIBC malloc function by calling the HumanOS’s malloc directly which did get further but ran into issues when switching from usermode to supervisor mode to directly access the hardware. Once when he shared his disk image, I was able to see how his GCC setup worked, and more importantly linked, so I could alter the GCC cross compiler I was using, and get much further in terms of progress. I could then get from failing malloc to this:
And from there after trying different assemblers, flags, and all kinds of other things we could finally get null DooM running on the x68000 via 68030 emulation on XM6 TypeG.
DooM comes to life
From there, Neko68k was able to do something amazing, add in system support! Which to be honest would have taken me forever to do, I was more impressed that I was even able to get the null version running, but Neko68k blew me away with this:
There is no correct palette setup at this point, there is all kinds of issues but you can see the startup logo being painted!
Then with a lot of improvements, and an added keyboard driver it was starting to look like DooM!
And then Neko68k had a major breakthrough with the video, timer and keyboard, and we now have a playable port!
Issues while cross compiling
Around this time I had noticed that when I built a cross compiled version the video for me was garbled. After some investigating it turns out that m_swap was not being compiled correctly but rather the endian order was being reversed!
I tried re-building, re-configuring my host setup, and I still had the same issue. I tried downloading GCC 1.42 and building an i386 SYSV to AT&T 3b1 cross compiler as it too is 68000 based, and I got the same issue. Maybe it’s a bug in GCC 1.x cross compilers? I don’t know, but since the procedure is small enough, it was easier to just have the native GCC produce an assembly version which I just assemble and link without issue.
Behold! DooM on the x68030!
Yes, there is no audio, but wow it’s playable! I do need to map the keyboard better in the emulator, but the key layout in the source is fine.
For anyone who cares you can follow more of the porting adventure here:
D:\proj\142\gcc-1.42_x68000>gccnew.exe -v -c x.c
gcc version 1.30 Tool#2(X680x0)
hcpp.exe -v -undef -D__GNUC__ -Dmc68000 -Dhuman68k -DHUMAN68K -DMARIKO_CC -Dmariko_cc -D__mc68000__ -D__human68k__ -D__HUMAN68K__ -D__MARIKO_CC__ -D__mariko_cc__ x.c C:\Users\jason\AppData\Local\Temp\x.cpp
GNU CPP version 1.30 Tool#2(X680x0)
hcc1.exe C:\Users\jason\AppData\Local\Temp\x.cpp -quiet -dumpbase x.c -fhuman -version -o C:\Users\jason\AppData\Local\Temp\x.s
GNU C version 1.30 Tool#2(X680x0) (HAS Ver 3.XX syntax)
compiled by GNU C version 5.1.0.
default target switches:
x.c: 5: Message:ì┼ôKë╗é═ìséφéΩé─éóé▄é╣é±
run68 has.x -e -w -u -i . C:\Users\jason\AppData\Local\Temp\x.s -o x.o
D:\proj\142\gcc-1.42_x68000>run68 ..\hlkb\hlk301.x x.o CLIB.L
Hello x68000 from GCC 1.30 Tool#2(X680x0)!
Microsoft Windows [Version 10.0.10586]
I’ve gotten the compiler to build natively as a win32, however the assembler & linker are x68000 programs that I run via run68. libgcc.a is missing so there is no floating point support at all. I have to figure out how to generate it. Right now it’s using the SHARP/Hudson libraries on the C Compiler PRO-68K ver2.1 disks.
I don’t think this will be of value to anyone, but for the hell of it, you can download my incredibly rough port here.
It’s really great, first off there are several versions in the steps of the evolution of the project:
– need gcc 1.4
– few change from official linux-0.01, only some bug fix, + minor change to build it in a linux system instead of minix
– same version as linux-0.01-1.7, which was just ported to work with gcc-2.x and gcc-3.x
– this is the last version
– need gcc-4.x
– use elf binary format instead of a.out, and you have some program working on it
As I actually do have a working GCC 1.40 + Binutils I though it would be great to build his first phase on Windows. With a little playing around in the makefiles, and the build program to open files in binary mode, I had a kernel!
I looked at the source again, and for some reason 99% of it compiled without issue. I recall having all kinds of issues, but clearly I was doing something wrong back then. At any rate, all I really had to do was modify the commenting style in the 8086 boot block code, and modify the image creation tool to open files in O_BINARY mode for Windows, and I got an image that will boot, then panic because it has issues reading the hard disk. I tried the seemingly small ‘fix’ from Linux 0.11 but it’s not working.
As we quickly approach this amazing milestone, I think it’s always interesting to re-visit the roots of Linux, back to the really ancient versions. Thanks to the hard work of oldlinux.org, the oldest intact Linux source code available is Linux 0.10 from November of 1991. A popular writeup on 0.10 was up on kerneltrap.org which appears to have been vaporized, but thanks to archvie.org is preserved.
Since this version is complete I thought it would be fun to run it through the Linux 0.11 build process & toolchain to see if I could get a working kernel. Well I had a few stumbling blocks, the bootblocks and the keyboard assembly driver were giving me issues, and for the sake of time, I went ahead and replaced them with the code from 0.11, and along with minor patching to the IDE disk driver. I added in a simple line to let me know I was actually booting up my franken 0.10 kernel with Qemu. Also I found later versions of Qemu work much better with 0.10 regarding the IDE disk.
I know it’s not much to look at but it really is building and running. I’m using the disk for the 0.11 series, as the userland seems to somewhat work. It’s very touchy, and prone to crashing as it ‘has a bug in the buffer cache’ that I didn’t feel like trying to track down. Nobody should be using this for anything serious anyways.
Install the 0.11 a.out GCC 1.40 on Win32 cross environment (I guess you can build them on Linux too if you so desire), and if you have a working MSYS environment you can run ‘make’ and it should give you a kernel. The command file ‘linux.cmd’ will boot it up, and attach the disk image that I used to test. There are permission errors, and well.. errors. 0.10 was not able to selfhost, but it should be enough to boot, mount the root, and run stuff like the sample ‘hello world’ program.