AmiDevCpp

Antoni sent me a link to this project, AmiDevCpp. It is a nice little wrapped up IDE for cross compiling applications for the following platforms:

  • AmigaOS (m68k)
  • AmigaOS4 (PPC)
  • MorphOS(PPC)
  • AROS (i386, ppc and x86_64).

Naturally it doesn’t work correctly on Wine.. .Oh well, but for you Windows users out there that haven’t installed Cygwin this is an easy way to cross build stuff for the ancient Amiga platform.

Apparently he was able to rebulid the infamous aclock using this cross compiler…

Super small 64bit OS

it doesn’t do much, but it does work!.. I saw it mentioned here, and the source archive can be downloaded here.

So I went through the steps of  building a 64bit cross tool to build it.. Although Qemu won’t boot the kernel directly, and it uses GRUB which isn’t so bad but I haven’t made a transparent boot system for it just yet…  Maybe I can use a CD-ROM ISO image…

C:\temp\trunk4>build
C:\temp\trunk4>del *.o kernel.bin kernel.ld
C:\temp\trunk4>x86_64-pc-elf-cpp -Iinclude -P -C -DLINKER_SCRIPT -o kernel.ld kernel.lds
C:\temp\trunk4>x86_64-pc-elf-gcc -Iinclude -Xassembler --divide -c -o startup.o startup.S
C:\temp\trunk4>x86_64-pc-elf-gcc -Wall  -nostdlib -nodefaultlibs -mcmodel=large -Iinclude -c -o kmain.o kmain.c
kmain.c: In function 'kmain':
kmain.c:17: warning: unused variable 'n'
kmain.c:15: warning: unused variable 'str'
C:\temp\trunk4>x86_64-pc-elf-gcc -Wall  -nostdlib -nodefaultlibs -mcmodel=large -Iinclude -c -o idt.o idt.c
C:\temp\trunk4>x86_64-pc-elf-gcc -Iinclude -Xassembler --divide -c -o isr.o isr.S
C:\temp\trunk4>x86_64-pc-elf-gcc -Wall  -nostdlib -nodefaultlibs -mcmodel=large -Iinclude -c -o pic.o pic.c
C:\temp\trunk4>x86_64-pc-elf-gcc -Wall  -nostdlib -nodefaultlibs -mcmodel=large -Iinclude -c -o console.o console.c
C:\temp\trunk4>x86_64-pc-elf-ld -nodefaultlibs -z max-page-size=0x1000 -o kernel.bin -T kernel.ld startup.o kmain.o idt.o isr.o pic.o console.o
C:\temp\trunk4>x86_64-pc-elf-objdump -S kernel.bin  1>kernel.asm

The ‘warnings’ are all my fault… As I wanted a string not the 1,2,3,4…

Grub boot flags

 

And here we are in 64bit long mode!

So for the two or three people who care, my archive is here… I may move crap around, but at the same time building a 64bit cross compiler was a real chore.. More so because that x86_64-elf bare targets didn’t exist until some time around 4.3.2 which… is involved to build.

xv6 revisited…

I was hoping to do more with this, but things are going other ways in life.  Anyways a while back I had touched on xv6, a MIT teaching tool and semiport of Unix v6 to the i386!  The best part about it, is that it is SMALL…

I’ve been playing with it the last day on the latest version of Qemu and hit a snag with its SMP support (yes it does have that!) so I played with it, and couldn’t figure it out so I had to turn it off.. It is something ACPI related, and probably along the reason why Windows x64 doesn’t run on new Qemu either..

I’ve built the cross compiling environment needed (A bare elf compiler/linker/assembler) and managed to smash enough of it into a single directory that you won’t need MinGW installed, but can rather invoke ‘build.bat’ which will compile link, dd the disk image, and launch Qemu.

I’ve had trouble with mkfs so… you’ll have to live with a prebuilt root image.

If you want to build your own cross compiling toolchain, there is a good guide here on the OSWiki.  Naturally you’ll want my previous post on some snags I ran into on MinGW if you do choose that as your target environment.

What I’d love to do is port newlib, and see just how useful this xv6 could become..  I would imagine adding signals (well beyond kill) may allow things like bash 1.x to run, and maybe gcc itself.. Which would be cool.

You can download my work here.  Check it out, it’s cool!

building a cross compiler under MinGW snag in collect2

rm -f collect2.exe
gcc -DCROSS_COMPILE -DIN_GCC     -g -O2  -DHAVE_CONFIG_H  -o collect2.exe collect2.o tlink.o hash.o intl.o underscore.o version.o  obstack.o       -ladvapi32 ../libiberty/libiberty.a
collect2.o: In function `handler':
C:\MinGW\msys\1.0\src\gcc-2.95.3\gcc/collect2.c:527: undefined reference to `kill'
collect2.o: In function `scan_prog_file':
C:\MinGW\msys\1.0\src\gcc-2.95.3\gcc/collect2.c:2269: undefined reference to `pipe'
C:\MinGW\msys\1.0\src\gcc-2.95.3\gcc/collect2.c:2292: undefined reference to `fork'
collect2: ld returned 1 exit status
make[1]: *** [collect2.exe] Error 1
make[1]: Leaving directory `/usr/src/gcc-2.95.3/gcc'
make: *** [all-gcc] Error 2

Ugh, isn’t that annoying? Well it turns out from the mailing list

The mingw32-hosted GCCs does not need ‘collect2.exe’ hence
set USE_COLLECT2= nothing (empty) in the <gcc_obj_dir>/gcc/Makefile

This needs to be fixed in GCC mainlne.

Regards.
Nitin.

And the other half….

fixincl.c:316: error: `SIGQUIT' undeclared (first use in this function)
fixincl.c:316: error: (Each undeclared identifier is reported only once
fixincl.c:316: error: for each function it appears in.)
fixincl.c:323: error: `SIGALRM' undeclared (first use in this function)
fixincl.c: In function `internal_fix':
fixincl.c:808: warning: implicit declaration of function `pipe'
fixincl.c:816: warning: implicit declaration of function `fork'
fixincl.c:845: warning: implicit declaration of function `sleep'
fixincl.c:860: warning: implicit declaration of function `fcntl'
fixincl.c:860: error: `F_DUPFD' undeclared (first use in this function

Which is fixed by changing

STMP_FIXINC = stmp-fixinc

into

STMP_FIXINC =

Oops!



Quake1 & MS-DOS

And because I had a request for it, here is a 7zip containing a makefile, and source suitable for building quake under MS-DOS.

I sourced it from the Doom makefile, and cross built it under OS X… It builds in under 5 seconds using all 4 cpu’s on my OS X box with my OS X to MSDOS DJGPP cross compiler…. I had forgotten that the gpl’d source included MS-DOS support.. I had taken the video part from Chi Hoang’s DOS port of DOOM and gotten it to run until I remembered.. Oh well a few hours wasted.

So there it is, Quake1 built on a mac, and running on DOSBox on a PC.....

And speaking of Quake, it’s on sale too!

But just for today, on steam…..

Cross compiling for MS-DOS (DJGPP) from OS X

So building on DOOM, I thought I’d try to build a djgpp cross compiler from my main OS X box, as compiling under DOSBox is… just too slow. Luckily Delorie has a page on building a cross compiler.

I started out with binutils-2.9.1, just as he does, with a few things thrown in…

First I had to run configure like this, as OS X didn’t exist back then, let alone x64 cpu’s..
./configure --target=i586-pc-msdosdjgpp --host=i386-netbsd --prefix=/usr/local/djgpp
Next the following error is thrown…

strerror.c:463: error: conflicting type qualifiers for ‘sys_nerr’

So I just edited libiberty/strerror.c, and commented out the following line.

Next up was a strange error in gas/targ-cpu.h

targ-cpu.h:374: error: array type has incomplete element type
targ-cpu.h:378: error: previous declaration of ‘flag_16bit_code’ was here

I simply commented out the lines.

Then later while compiling gas/write.c it bombs out because of an undefined type.. One of which was commented out in targ-cpu.h . The easiest fix is to go to the start of the relax_align procedure and just add in the definition:

extern const struct relax_type md_relax_table[];

Next up was gcc. I couldn’t get 2.8.1 to build, instead I built gcc-2.95.3.

I had to configure gcc like this:
./configure --target=i586-pc-msdosdjgpp --host=i386-netbsd --prefix=/usr/local/djgpp
And it threw the same error as binutils… with the same fix (commenting out the line in libiberty/strerror.c).

strerror.c:465: error: conflicting type qualifiers for ‘sys_nerr’

I also had an error pop up like this:

./config/i386/i386.c:142:22: error: macro “strcat” requires 2 arguments

And again I just commented it out.

Under OSX the makeinfo parts crashed, so I simply removed them from the makefile. With a little more tweaking the cross compiler was ready!

REMEMBER TO FOLLOW DJ’s steps too!

The cool thing is that now I can run make with the -j4 flags allowing gcc to run on each of the cpu cores letting me build doom in under 3 seconds!

i586-pc-msdosdjgpp-gcc -O2 -DNORMALUNIX dos/doomdef.o dos/doomstat.o dos/dstrings.o dos/i_system.o dos/i_sound.o dos/i_video.o dos/i_net.o dos/tables.o dos/f_finale.o dos/f_wipe.o dos/d_main.o dos/d_net.o dos/d_items.o dos/g_game.o dos/m_menu.o dos/m_misc.o dos/m_argv.o dos/m_bbox.o dos/m_fixed.o dos/m_swap.o dos/m_cheat.o dos/m_random.o dos/am_map.o dos/p_ceilng.o dos/p_doors.o dos/p_enemy.o dos/p_floor.o dos/p_inter.o dos/p_lights.o dos/p_map.o dos/p_maputl.o dos/p_plats.o dos/p_pspr.o dos/p_setup.o dos/p_sight.o dos/p_spec.o dos/p_switch.o dos/p_mobj.o dos/p_telept.o dos/p_tick.o dos/p_saveg.o dos/p_user.o dos/r_bsp.o dos/r_data.o dos/r_draw.o dos/r_main.o dos/r_plane.o dos/r_segs.o dos/r_sky.o dos/r_things.o dos/w_wad.o dos/wi_stuff.o dos/v_video.o dos/st_lib.o dos/st_stuff.o dos/hu_stuff.o dos/hu_lib.o dos/s_sound.o dos/z_zone.o dos/info.o dos/sounds.o dos/i_main.o \
-o dos/dosdoom

real 0m1.174s
user 0m2.626s
sys 0m0.679s

How’s that for fast?

For any curious OS X 64bit users out there you can download my binary toolchain here.

I would imagine that if you stuck with versions of binutils & gcc that build on your platform you too should be able to build a MS-DOS DJGPP cross compiler. And there is nothing like native 64bit tools for building for DOSBox… Oh and DOOM runs just fine, although I guess screen shots of the cross compiled exe is… redundant.

OpenWatcom for the DEC Alpha

Someone had contacted me about running some Fortran programs on the DEC Alpha with Windows NT. Now I know that DEC had released some compilers for the Alpha, the Digital Visual Fortran thing which some people still sell for around $600 USD.

OUCH.

But luckily a friend mentioned that I should look at the source code for Open Watcom.

So, I figure for the hell of it, I’ll show how to build a Dec Alpha cross compiler for both C & Fortran. First I’m using Open Watcom 1.8, the current ‘release’ version. You are on your own for older or newer versions.

First install Open Watcom 1.8, with whatever your host is (I’m running on win64, so I’m using the win32 install), and set the target for 32bit NT. We will need the headers so this is the easiest way to ensure your Watcom can make NT exes.

Next you are going to need the file owaxp0401.zip. This is a pre-compiled version of the compiler & libraries for the DEC Alpha. All we need from this is the libaxp directory, which you can just unzip to your Watcom directory.

Now we’ll need to copy some files to satisfy the build process.

C:\WATCOM\binnt>copy wcl386.exe bwcl386.exe
C:\WATCOM\binnt>copy wlib.exe bwlib.exe
C:\WATCOM\binnt>copy wrc.exe bwrc.exe

Ok, now with that out of the way, run c:\watcom\owsetenv.bat to setup your environment, and now let’s extract the source to 1.8. I’m just going to use c:\temp as a place to put it. Also you will have to edit the setvars.bat file, and change the following:

set OWROOT=c:\temp\ow18src
set WATCOM=c:\watcom
set DOC_BUILD=0

Now I suppose you could save this into a batch file, and kick that off, and this will build the needed libraries, then the C compiler.

cd c:\temp\OW18src\bld\builder\nt386
wmake
cd c:\temp\ow18src\bld\dwarf\dw\osi386\
wmake
cd c:\temp\OW18src\bld\yacc\nt386
wmake
copy yacc.exe \WATCOM\binnt\byacc.exe
cd c:\temp\OW18src\bld\re2c\nt386
wmake
copy re2c.exe \WATCOM\binnt\re2c.exe
cd c:\temp\ow18src\bld\cg\risc\axp\nt386\
wmake
cd c:\temp\ow18src\bld\sdk\rc\wres\flat386\mf_r
wmake
cd c:\temp\ow18src\bld\cfloat\osi386
wmake
cd c:\temp\ow18src\bld\as\alpha\inline\osi386\
wmake
cd c:\temp\ow18src\bld\owl\osi386\
wmake

Now this will build the cross compiler…

cd c:\temp\OW18src\bld\cc\wcl\nt386.axp
wmake
copy wclaxp.exe \WATCOM\binnt
cd c:\temp\OW18src\bld\cc\nt386.axp
wmake
copy wccaxpc.exe \WATCOM\binnt\wccaxp.exe
copy wccdaxpc.dll \WATCOM\binnt\wccdaxp.dll
cd c:\temp\OW18src\bld\as\alpha\nt386
wmake
copy wasaxp.exe \WATCOM\binnt

Now for the Fortran 77 compiler. Please note that the default flags include -we which will cause the compiler to error if there is a warning. And as luck would have it, one function doesn’t declare a prototype… So you can either remove the -we flat from the mif file, or fix the c file… The choice is yours.

cd c:\temp\OW18src\bld\f77\wfl\nt386.axp
wmake
copy wflaxp.exe \WATCOM\binnt
cd c:\temp\OW18src\bld\f77\wfc\nt386.axp
wmake
copy wfcaxp.exe \WATCOM\binnt
attrib c:\temp\OW18src\bld\f77\f77lib\flags.mif -r
notepad c:\temp\OW18src\bld\f77\f77lib\flags.mif

Do a search and replace on -we and replace it with nothing…

cd c:\temp\OW18src\bld\f77\f77lib\winnt.axp\_s
wmake
copy flib.lib \WATCOM\libaxp

With all that out of the way, let’s build some test programs…

Let’s start with hello.f for the Fortran compiler.

C234567
program hello
print *, ‘Hello!’
end

c:\temp>wflaxp hello.f
Open Watcom F77 Alpha AXP Compile and Link Utility Version 1.8
Portions Copyright (c) 1990-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
wfcaxp hello.f
Open Watcom FORTRAN 77 Alpha AXP Optimizing Compiler Version 1.8
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
hello.f: 3 statements, 40 bytes, 1 extensions, 0 warnings, 0 errors

Open Watcom Linker Version 1.8
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating a Windows NT(AXP) character-mode executable

c:\temp>

Watcom Fortran cross on Dec Alpha

Watcom Fortran cross on Dec Alpha

Ok, now that’s enough for now…! Later I’ll show how to build these compilers so they’ll run on the Dec Alpha.

Microsoft eMbedded Visual C++ 4.0

Well I was looking for a way to cross compile to the MIPS and also if I could use my old Platform builder 2.11… Anyways Platform builder has cross compilers, but no libraries, I figured you need the eMbeded Visual C++.. And as luck has it, you can download it right here!. Also you’ll probably want service pack 4.(local mirror), and don’t forget the code TRT7H-KD36T-FRH8D-6QH8P-VFJHQ

System Requirements

  • Supported Operating Systems: Windows 2000; Windows XP
  • Microsoft Windows® 2000 Professional SP2, Microsoft Windows 2000 Server SP2, or Microsoft Windows XP Professional
  • A desktop computer with a Pentium-II class processor, 450 MHz or faster
  • 96 MB (128 MB recommended) memory for Windows 2000 Professional or Windows XP Professional. 192 MB (256 MB recommended) memory for Windows 2000 Server.
  • 200 MB hard disk space
  • CD-ROM drive
  • VGA or higher-resolution monitor. A Super VGA (800 x 600 or larger) monitor is recommended.
  • Mouse or compatible pointing device

If your machine is NOT up to this kind of capability, then you can download the older eMbedded Visaul C++ 3.0, that will run on Windows NT 4.0 (i386 of course). Purdue also had a nice walkthrough on installing the 3.0 tool kit.

I DO recommend that you install IIS on your cross compiling machine, as it’s an easy way to move your object files to the MIPS host for linking.

It is worth noting that Visual C++ 4.0’s emulator will NOT run under Virtual PC.. They use the same call set, and it thinks VPC is Windows CE… I know it’s confusing.

I would imagine everyone could run this. Well if they were so inclined.. Well the installation is pretty simple but now for the ‘fun’ stuff.

First let’s download the source code to Quake.. ID software has been most kind to provide the Quake engine under the GPL!. So we can use it for a MIPS cross compile test.. (As far as I know there is no Dec Alpha cross compiler, but there is a PowerPC.. Anyone use a PowerPC NT machine?). You can download it here. .This went nowhere, as it turns out WindowsCE and Windows NT use different models for floating point, and are incompatible.

Ok with your embedded tools installed, we are now going to merge our Visual C++ MIPS CD so we use it for libraries & include files.. Since we are all going to use the same compiler it’ll be somewhat easy.. I’m using the tools out of “C:\Program Files\Microsoft eMbedded C++ 4.0\EVC\WCE400”

11/27/2001. 03:00 AM........ 1,073,152 C1XX_MP.DLL
11/27/2001. 03:00 AM.......... 581,632 C1_MP.DLL
11/27/2001. 03:00 AM........ 1,056,768 C2_MP.DLL
11/27/2001. 03:00 AM........... 69,632 CLMIPS.EXE
06/13/2001. 03:00 AM.......... 180,276 MSPDB60.DLL

To make it “feel” like visual c++ 2.0 I’m going to put them in the c:\msvc20\bin directory on my HOST pc (Vista Pro x64).. Then I simply copy the include & lib directory from the MIPS Visual C++ CD into the corresponding directories on my host.. We are ALMOST there.

The next thing I did was to grab an intel copy of Visual C++ 2.0 (I almost be dammed near all of them can do this..) and take it’s linker.. The linker out of the embedded tools is obsessed with the WindowsCE subsystem which won’t help us at ALL.

09/16/1994. 01:00 PM........... 67,584 DBI.DLL
09/16/1994. 01:00 PM........... 12,980 LINK.ERR
09/16/1994. 01:00 PM.......... 420,352 LINK.EXE

Go ahead and place those files into the c:\msvc20\bin directory.

Now we just need to create a simple batch file to keep our environment in order:

set LIB=c:\msvc20\lib
set PATH=c:\msvc20\bin;%path%
set include=c:\msvc20\include

Save that to something like mipvars.cmd, and run it & we should be ready to start compiling!

To test the cross compiler I’m going to build a SIMPLE program that has 2 files.

hi.c


#include <stdio.h>

extern int bob(void);

void main(void)
{
printf("%d",bob());
}

bob.c

int bob(void)
{
return 3;
}

Ok, now we compile it like so:

C:\msvc20>clmips *.c -o bob.exe
Microsoft (R) C/C++ Optimizing Compiler Version 12.20.9419 for MIPS R-Series
Copyright (C) Microsoft Corp 1984-2001. All rights reserved.

bob.c
hi.c
Generating Code...
Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.

/out:bob.exe
/out:bob.exe
bob.obj
hi.obj
LINK : error LNK1104: cannot open file "corelibc.lib"

Oh no trouble!. Because this was all ripped from the embeded tools it wants to think it has corelibc not libc.. But we can cheat, just copy libc.lib to corelibc.lib and I’ve also copied rpcndr.lib to coredll.lib to satisfy the linker.. Now when we re-compile:

C:\msvc20>clmips *.c -o bob.exe
Microsoft (R) C/C++ Optimizing Compiler Version 12.20.9419 for MIPS R-Series
Copyright (C) Microsoft Corp 1984-2001. All rights reserved.

bob.c
hi.c
Generating Code...
Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.

/out:bob.exe
/out:bob.exe
bob.obj
hi.obj

That’s right, we got an executable!. Now if you run it on your x86(or x64) host you’ll get this:

c:\msvc20\bob.exe is not a valid Win32 application.

And of course, since you installed IIS on your HOST (or cross compiling VM) you can connect to it from your MIPS VM, download the exe & run it.

MIPS cross compile
MIPS cross compile

I’m kind of surprised it worked.. It does go to show though, that somewhere inside Microsoft they have some COOL cross compiler technology, it’s just too bad they didn’t make it into an easy package for the RISC stuff.. But now that the MIPS is coming back to life via Qemu, and NT 4.0 can be had for $5 a retail box on ebay, I figure it’s worth this much for those people who can find Visual C++ for MIPS/RISC.

easy68k & sozobon

Easy68k

I know this is a little weird to follow, but I thought it was somewhat interesting. Anyways I’ve been reading up on some CP/M stuff, and found some interesting m68k stuff. There is this really cool m68k simulator/test environment called easy68k. Ok so the 68000 isn’t exactly the hottest chip, but for anyone that’s used a Mac, Amiga, Atari ST, SEGA Genesis, or old SUN the m68000 was the end all be all CPU. Anyways you can download the easy68k simulator from here:

http://www.easy68k.com/

Now I’ve never been really all that good with assembly. I know one day I should learn, but until then, there is higher level languages, and of course the best ‘medium’ level language C. Back in the day the ‘sozobon’ compiler was somewhat portable, and a good & easy 16 bit C compiler. Now as far as I know there really hasn’t been any activity on this since 1991, so it’s getting hard to find, and of course the archived copies I found needed LZH.. You can find some archived copies here:

http://umich.edu/~archive/atari/Languages/Sozo2/

Since I didn’t want to go thru a big ordeal, I found an extracted copy of the sources here:

http://cd.textfiles.com/crawlycrypt1/program/compiler/sozobon/

Building the sozobon compiler

Using wget I pulled down the source code. It’s worth noting that unlike GCC this is SMALL… although it only targets the 68000 cpu. The only source that I’m using is the actual C compiler. I suppose if I were better I could map the simulator, and setup the assembler & linker to target the environment all the way… However for now I’m just interested in showing the relationship between a compiler, to the assembler. Now the source is old enough that it uses the reserved word inline in gunk.c I simply changed it to Xinline. I’ve attached a diff for those who like diff’s however as you can see it’s really simple, I just renamed them, so they don’t conflict.


--- gunk.c Fri Feb 22 05:33:34 1991
+++ gunk-fix.c Mon Mar 9 14:35:33 2009
@@ -37,7 +37,7 @@
int (rewri)(); / rewrite function */
};

-int m_unfold(), unfold(), m_cast(), cast(), m_inline(), inline();
+int m_unfold(), unfold(), m_cast(), cast(), m_inline(), Xinline();
int m_hardas(), hardas(), m_fcmp(), fcmp(), m_md_shf(), md_shf();
int m_eident(), eident(), m_incdec(), incdec(), m_fldas(), fldas();

@@ -48,7 +48,7 @@
{m_eident, eident},
{m_incdec, incdec},
{m_hardas, hardas},
- {m_inline, inline}, /* must cast before inline /
+ {m_inline, Xinline}, /
must cast before inline */
{m_fcmp, fcmp},
{m_fldas, fldas},
{0}
@@ -424,7 +424,7 @@
return 0;
}

-inline(np)
+Xinline(np)
NODEP np;
{
register NODEP nmp, cmap;
@@ -782,7 +782,7 @@
register NODEP tp;

spar1 = "%fpcmp";
- inline(np);
+ Xinline(np);

tp = copyone(np);
tp->n_left = np->n_left;

Now with that out of the way, you should be able to build with the make.unx


% make -f make.unx
gcc -DUNIX -O -c d2.c
gcc -DUNIX -O -c decl.c
gcc -DUNIX -O -c expr.c
gcc -DUNIX -O -c fix.c
gcc -DUNIX -O -c fun.c
gcc -DUNIX -O -c g2.c
gcc -DUNIX -O -c gen.c
gcc -DUNIX -O -c gsub.c
gcc -DUNIX -O -c gunk.c
gcc -DUNIX -O -c main.c
main.c:424: warning: 'optnl' was declared implicitly 'extern' and later 'static'
main.c:417: warning: previous declaration of 'optnl'
gcc -DUNIX -O -c md.c
gcc -DUNIX -O -c nodes.c
gcc -DUNIX -O -c out_st.c
gcc -DUNIX -O -c p2.c
gcc -DUNIX -O -c pre.c
gcc -DUNIX -O -c tok.c
gcc -DUNIX -O -c subs_c.c
gcc -o xhcc d2.o decl.o expr.o fix.o fun.o g2.o gen.o gsub.o gunk.o main.o md.o nodes.o out_st.o p2.o pre.o tok.o subs_c.o

Writing hello world!

OK, with the compiler built, let’s write a simple C program. I’ve setup a simple main, and calls to a ‘putc’ and an ‘exit’ that currently don’t do anything. We will have to fix that in the assembly source.. but for now it’s nice as it sets up a place holder.



char MESSAGE[]="this is a message";
void putc(c)
char *c;
{

}
void exit()
{}

void main()
{
int j;
j=0;
putc(MESSAGE);
exit();
}

Now we can compile the source file (x.c) and use the -S flag, so it only outputs an assembly source, that we can then massage to work with easy68k.


% ./xhcc -S x.c ; cat x.s
.data
.globl _MESSAGE
_MESSAGE:
.dc.b $74,$68,$69,$73,$20,$69,$73,$20,$61,$20,$6d
.dc.b $65,$73,$73,$61,$67,$65
.dc.b 0
.text
.globl _putc
_putc:
bra L1
L0:
;var 4 8 _c
L2:
unlk a6
rts
L1:
link a6,#-0
bra L0
.globl _exit
_exit:
bra L4
L3:
L5:
unlk a6
rts
L4:
link a6,#-0
bra L3
.globl _main
_main:
bra L7
L6:
;var 2 -2 _j
clr.w -2(a6)
move.l #_MESSAGE,-(sp)
jsr _putc
add.w #4,sp
jsr _exit
L8:
unlk a6
rts
L7:
link a6,#-2
bra L6
.data

As you can see from the source below the following changes were made:

-Added the ORG $1000
-Changed the formatting of the _MESSAGE into a format that easy68k’s assembler likes.
-Removed all the .globl statements.
-Renamed the _main section to START & and add the end start tags.
-Populated the exit procedure with the ‘exit’ code from easy68k’s example
-Changed putc to use the d0 register instead of d6, and added the print string code from easy68k.


ORG $1000

_MESSAGE dc.b $74,$68,$69,$73,$20,$69,$73,$20,$61,$20,$6d
dc.b $65,$73,$73,$61,$67,$65
dc.b 0

_putc:
bra L1
L0:
;var 4 8 _c
move.b #14,d0
trap #15

L2:
unlk a0
rts
L1:
link a0,#-0
bra L0

_exit:
bra L4
L3:
L5:
unlk a6
rts
L4:
move.b #9,d0
trap #15
link a6,#-0
bra L3

START:
bra L7
L6:
;var 2 -2 _j
clr.w -2(a6)
move.l #_MESSAGE,-(sp)
jsr _putc
add.w #4,sp
jsr _exit
L8:
unlk a6
rts
L7:
link a6,#-2
bra L6
end start

conclusion

Now you can run the code in the simulator, and watch it enter the ‘start’ section, call the putc with the address of _MESSAGE, return to the main, and then call the _exit procedure, which calls the sim68k exit program interrupt. I’ll leave this as an exercise to the read for any real value…. I just thought it was cool, that without really learning any assembly I was able to write a basic ‘hello world’ type program in an hour….