GCC and ixemul.library
 

What tools are current for developing or porting applications for classic Amigas using gcc and ixemul.library? Is there something to replace the Geek Gadgets compilation of old?

The latest GG snapshot at back2roots.org is from 1998, but I notice that the latest ixemul.library at amiga.sf.net is from May this year and still expects a GG: assign, so GG isn't completely dead and forgotten. Some other components may also have updated ports in places, but I don't know how well they work together and hunting them down individually would be a chore.

GCC v2.95.3 is still used today and probably generates the best code of any Amiga compiler ever. Newer versions still support 68k but generate any where from fair to horrible code. A lot of UAE Amiga people use the newer versions of GCC because of tools that need the new versions. ixemul.library is best used with the -noixemul GCC option. Use Libnix if possible with GCC. No other compiler that I know of supports ixemul. The only compiler actively supported is vbcc...

http://sun.hasenbraten.de/vbcc/

It has an ixemul/libnix POSIX library that's been updated fairly recently. If you need anything fixed send Frank Wille (Vasm/PhxAss author) an email ...

http://aminet.net/dev/c/vbcc_PosixLib.lha

Vbcc keeps getting better. It's very usable and easy to get started unlike the GCC mega installation. Many people still use SASC as well.

VBCC
Good: easy install, portable, supported, small, above average code
Bad: slow, missing some tools

GCC 2.95.3
Good: good code, portable, fairly fast
Bad: install hell, no support, not very compatible with newer GCC

GCC 3.4.0
Good: more modern GCC support, portable, average code
Bad: install hell, no support, worse code than 2.95.3

SAS/C (Lattice C)
Good: fast, lots of tools (good debugger), polished, above average code
Bad: not portable, no support, not easy to use, old

Yes, indeed! :)
In fact -noixemul prevents using of ixemul.library, which is recommended when you can afford it.

With ixemul.library your programs become an alien on any AmigaOS system. It will behave like a Unix program and uses all sorts of strange assignments for simulate such a system. When possible, you should invest some extra effort to make a real Amiga port.

When you absolutely need ixemul, because of the high complexity of the port, make sure not to use any hacks after the last official ixemul V48.


Some years ago vbcc supported ixemul.library. There was a special config file, startup code and stubs-library for that. After developing PosixLib, and moving my development system from my A3000 to my Pegasos, I seem to have lost the source. Maybe I should check some old hard disks before it is lost forever...

I might add that older compilers like GCC 2 and SAS/C have no C99 support at all, SAS/C does not even support 64-bit arithmetics. This might be problematic when porting modern sources. Apart from that I still think that SAS/C generates the best 68k code.

Thank you both for your insights.

Hiya,

I'm currently coding a port using gcc v2.95.3 and if I use Libnix it crashes so I have to use ixemul.library, haven't found out why yet :(

Maybe I should give vbcc a try instead....

Dear all,

I am trying to compile thttpd (from Aminet) for my Amiga 1200 on Cygwin, I am facing a compatibility problem between "sys/timer.h" that define "struct timezone {...}" as and the expected "time_t timezone" by thttpd. Could anyone help me or point me towards useful ressources? I have been looking on the Web and found several pages but I am a newbie and no page really helped me.

Best!

PS. I am on Windows 7, using Cywin, gcc 3.4.4, installed includes and all found at http://www.zerohero.se/cross/os3.html

Hiya,

Have you tried AmiDevCPP yet? It's a pre-configured setup so it's a lot easier to do stuff.

I'm surprised you left out StormC. And also I don't know why you would think SAS/C is hard to use, because it is very straightforward. Whereas trying to get stuff to compile on GCC tends to be nothing but headaches.

@NovaCoder and Minuous

No, haven't tried yet because I need Cygwin to work and the install warns me that installing AmiDevC++ will change/corrupt (it is unclear to me ;)) my installed Cygwin... and, yes, using GCC gives a headache but it's cool :cool

I'll keep you posted on my findings!
Cheers!

Hi all!

I managed to compile PHP v4.2.3 on Cywin for m68k-amigaos :-) I am putting together a Web page to detail all the steps but, before putting that one on-line and uploading the compiled version into Aminet, I want to make sure that all the PHP tests run...

Cheers!

Cool well done.

Something I tried to setup (and failed!) was to use C++ Eclipse IDE on Windows using mingw.

If someone could get that working it would be a great way to write 68k for classics using gcc.

This thread should really be moved to the coding section BTW, way too boring for most people to read :)

I've moved the thread to the Coders.Language forum as suggested. :great

@Photon/CFOU!: If this is not suitable, please feel free to move it to another sub-forum. :)

I haven't try yet but I will eventually! I like Eclipse also and use it for, mostly, developing in Java... But I did not want to try before I got something working with the command line... Did you check these two pages out, could they help?

- Eclipse with Cygwin GCC
- Eclipse CDT with Cygwin GCC: automatic discovery of symbols and
paths

Thanks Prowler!

Cheers!

Yep I tried those pages but still failed to get it working (lack of brain power).

;)

Same here! ;)

Still cannot figure out how to tell Eclipse to use m68k-amigaos-gcc... but will keep trying!

Let's do a thread update shall we -> Eclispse Amiga style

;)

Hi NovaCoder!

Great catch! Indeed it works on a simple code, let's try now on complicated stuff... One thing though that I (currently) do not understand and how does Eclipse magically generate the makefiles...

Cheers!
Tygre

Here are my benchmark results for different compilers - using the dhrystone 2.1 benchnmark from aminet (more benchmarks may follow):

1. gcc-4.0.4 -O3 -fomit-frame-pointer -m68000
2. gcc-2.9.3 -O3 -fomit-frame-pointer -m68000
3. vbcc-0.8j -O=65535
4. sas/c 6.58 opt optgo nostkchk
5. gcc-4.0.4 -Os -fomit-frame-pointer -m68000
6. gcc-2.9.3 -Os -fomit-frame-pointer -m68000
7. vbcc-0.9e -O=65535

read more

EDIT: "gcc-3.4.6 -O3 -fomit-frame-pointer -m68000" is on par with gcc-2.9.3!

The following are my dhrystones/second results on my 68060@75MHz.

1. d-g404o 238095
2. d-g293o 172413
3. d-vbcc08j 172413
4. d-sas 133333
5. d-g404s 109289
6. d-vbcc 100000
7. d-g293s 85836

Position number 6 and 7 swapped for me but results on a 68000 are likely much different. I might have to look into what caused the performance loss with vbcc. I would also like to see 68020 results as optimizing for the 16 bit 68000 is much different than the 32 bit 68020+. It would be helpful to see if the newer version of vbcc suffers from the same slow down when compiled for the 68020.

Your web page "The recent vbcc 0.9e claims to be the best compiler." is not how I interpret this old test results page (tests probably done with an old version of vbcc) referring to PPC code generation of which vbcc has a better backend.

Edit: It looks like there are minor differences in the 2 vbcc binaries until the function at offset $3e0 for both where the old binary has two 32x32=32 multiply inlines and the new one has seven 32x32=32 multiply inlines. This looks like a bug which needs to be looked into. The vbcc 0.9e code generation is very similar to the old vbcc although I notice a few small improvements otherwise. It may help to have d-vbcc and d-vbcc08j compiled with debug symbols as well as the exact original source code. We should contact Frank Wille if he doesn't notice this thread soon.

I can more or less confirm the results using a Dhrystone 2.1 port from our vbcc testsuite (the source bebbo provided doesn't compile - missing "timer").

I still had gcc 2.95.3 executables and vbcc 0.8 or 0.7x from 2001, which printed the following results on my 68060/50MHz:
Compiled with vbcc 0.9e (-cpu=68060 -fpu=68060 -O3 -speed) it only gave me 72464 Dhrystones. Certainly a bug. We will have to look into it.