AmiQuake - new 68k Quake Port

[matthey]

What about Cyberpatcher/Oxypatcher? I remember once playing Quake (on 060) and wondered how it crawled. I had accidentally disabled Oxypatcher. I think the speed drop was more than 50%.

Cyberpatcher/Oxypatcher/Redox solve most of the slowdown but take some memory and introduce another potential failure point. They should not be necessary. Any compiler supporting the 68060 and compiled for the 68060 should not use trapped instructions that are not available in the 68060. Exceptions should be reported to the compiler maintainers.

[matthey]

That's the theory !

The reality is very different...

Yea, theory != reality or the world would be much different . Does the latest GCC generate trapped 68060 instructions when compiled for the 68060? The latest vbcc should not at least. It's targeted for embedded devices where there might not be enough memory for the 68060 software support library. The newest GCC versions seem to be targeted for bloated environments with high level languages where speed isn't important any more because it's going to be slow regardless :/.

[matthey]

@NovaCoder
GCC 3.4.0, last time I checked, was calling utility.library for integer math like 32x32=64 which is good. The library function call is a little slower than an inline but then utility.library can be patched with the fastest 68060 specific code like ThoR's Mu 68060.library does for 32x32=64. I believe GCC 3.4.0 was a special Amiga specific GeekGadgets version of GCC. Perhaps you can try GCC 3.4.0 with AmidevCPP to see if the utility.library is used?

I did some DMIPS test compiles that showed vbbc (vc -cpu=68060 -O2) at 55 DMIPS error free with 68060@60MHz and GCC 3.4.0 (gcc -fomit-frame-pointer -noixemul -m68060 -O2 -mregparm=4) at 56 DMIPS with register passed function variables that generated several bugs. Vbcc was using stack passed variables. The DMIPS code used no 64 bit integer math, which if trapped in GCC could make vbcc faster. The testing was with the latest version of vbcc and the latest beta version of vasm (has some nice peephole optimizations added as well as bug fixes). Vbcc is getting better but it's still not very GCC compatible, it has some bugs above -O1 (although -O1 has much better performance than GCC -O1) and it's slow to compile.

GCC 2.95.3 is still probably the best at code generation. It handles the trapped instructions with local replacement functions (no utility.library). I believe the newest 68k GLQuake is compiled with this as it is one of the best optimized 68k programs I've seen. It's very rare that I find a 68k program that I look through the disassembly and not grimace. Unfortunately, GCC 2.95.3 is not very compatible with newer versions of GCC.

@Karlos
68060 compiled code I've seen should run without problems on a 68040 although at a slower speed. Using the utility.library for integer 32x32=64 is nearly as fast for the 68040 but the missing FINT/FINTRZ in the 68040 for floating point is a performance killer. What were the Motorola Engineers thinking? Programs using floating point should provide separate 68040 and 68060 compiled versions because of this.

[matthey]

I'm curious to test it under petunia It only advertises 68020/68882, but implements most of the additional instructions, AFAIK.

I would imagine it will run at very acceptable speed. The floating point may only be double precision instead of extended precision in some cases but that won't matter for games. The 68k used like Java/Android byte code is a good way to get improved code density out of the PPC . If we get the Hyperion folks to continue 68k support, we could mend the biggest split in the Amiga. Otherwise, Hyperion is going to wake up one day and find AROS has more users than AmigaOS 4.x.

[matthey]

If my experiments with DoomAttack on my BlizzardPPC are any measure, perhaps. That ran 640x400 faster than my 040 does 320x200.

Yea, that looks like high end 040 or low end 060 speed. DoomAttack at 640x400 (looks much nicer than 320x200 by the way) has no perceivable slow down on my 060@75MHz while 640x480 has enough hesitation in heavy combat to making it difficult to aim.

[matthey]

sorry to answer to an old post but binary compiled with 4.5.0 should be actually faster than 3.6.x, i guess, as this was the worst afair. matt probably knows better.

I have heard that the newest versions of GCC are generating better code quality now. I don't know if that applies to the 68k. The GCC FPU support for the 68040+ was never complete as trapped/emulated FPU instructions were used. I doubt the newest version of GCC has improved FPU support. NovaCoder uses AmiDevCpp which generates Amiga hunk executables and is quick for developing. The newest versions of GCC only generate 68k ELF executables like AROS 68k uses. There are advantages and disadvantages to the different compilers:

GCC 2.95.3
+ best integer code generation quality
+ Amiga specific support including Amiga hunk format
+ fast compiling
- GCC support is not modern

GCC 3.4.0
+ Amiga specific support including Amiga hunk format

GCC 3.6.x
+ most modern GCC used by AmiDevCpp
+ Amiga hunk format

GCC 4.x
+ modern and sophisticated GCC support
- no hunk format or Amiga support
- no AmiDevCpp
- slow to compile

vbcc 0.9d (yet unreleased)
+ Amiga specific support including Amiga hunk format
+ best 68040/68060 FPU support
+ should work using AmiDevCpp
- below average integer code generation quality
- slow to compile
- limited GCC compatibility

It's not an easy call. NovaCoder is probably using the easiest and fastest Amiga 68k porting and development environment. He is getting good results even if a little better code quality may be possible with more effort.

though, actually i wanted to ask where to download the binaries, especially quake. ive something to test. why not put them on aminet btw?

The Amiga executables are on Aminet:

http://aminet.net/search?query=AmiQuake

They do not include the full game files which may not be included in the license. They are also very large. I use the demo files from the DOS demos for testing. They are easy to find.