new os3.x software ?

[matthey]

There are still some active classic developers and we are still developing. I am currently working on a new version of ADis disassembler. I look for bugs by comparing reassembled programs (from ADis) with the original. Differences are usually bugs in ADis or Frank Wille's vasm. Frank has fixed several bugs already too. Sounds pretty boring, but vasm is used in the C compiler vbcc and one of the HUGE problems is poorly optimizing 68k C. I am also experimenting with reassembling AmigaOS 3.9 libraries for 020+ with ADis. I can usually speed up and save a few k per library. It needs to be very bug free though. I would like to make a new exec.library with several enhancements at some point. I'm working with a group of developers to try and get Warp3D and StormMesa working better as well. I've already fixed some bugs in the Voodoo drivers. Warp3D suffers from aweful 68k code optimization. I asked Hyperion for help or source to Voodoo drivers but they did not answer my e-mail. The biggest problems us developers run into is...

1) Many Amiga users do not report bugs or communicate. We can see that Amiga users download our programs. Don't be afraid to drop an e-mail. Many Amiga developers have suspended work on projects because they didn't think users were using their programs and/or there weren't any more bugs reported. There are some very active and vocal users on the other hand, namely the ones posting in this thread .

2) There isn't a good optimizing C compiler for 68k. Vbcc is comming along but it's a huge project to make a crossplatform multi-CPU C compiler. GCC has generated some horrible code and some of the newer versions have gotten worse. Many C developers don't even know when their code runs at 1/2 speed. This is more common than you think.

3) We don't have source code to fix old programs. Many old authors don't bother to release source code because they think the classic Amiga is dead. Thomas Richter is ready to release a new layers.library if he had permission. He thinks we could come up with the sources for the classic OS and continue developement if we had permission. Warp3D could be 50% faster if we had the sources. We need a free the OS3.x campaign. Maybe a Hyperian support your software campaign too.

In conclusion, it's rather frustrating developing for the Amiga classic. We are making progress though. Get involved and help someway. There will likely be more fpga Amiga's (Natami or enhanced MiniMig) so 68k can have a future if we plan for it. The classic Amiga is too good and fun to die.

[matthey]

Can do you it the other way around as well?
My minimig craves for it. :hammer:

68020 code can be made to work on the 68000 but it is much more difficult. Code has to be added to support missing instructions for example. The 68k is forward compatible but not backward. From 68000 to 68020 is mostly just deletion and some minor optimizations. Vasm performs many of the optimizations for me on reassembly. It's still possible to do 68020 to 68000. If there isn't many 68020 instructions it can be trivial. It's easy to miss things like the scale factor not being used on the 68000 though. I am really wanting to do a 68020+ for the new BoingBag updates and Natami right now. You might try learning assembler to do the modifications yourself. I really wanted a good disassembler with floating point support. I had never done a program bigger than hello world in C but now I have ADis working well enough to reassemble libraries. You also now have the tool I created to help you. You see how this works .

[matthey]

@kolla
The gains in optimizing for the 68020+ is significant in some cases. It's also easier for an assembler programmer. It's almost as easy to make a 68000 version for a compiled program. I still like to see cpu optimized versions of compiled programs but the trend is not too. It's probably because it doesn't matter much for UAE. I can compile you a 68000 version of ADis if you want to try it. The tricky part about the 68000 is that it only allows byte accesses to odd addresses. It's hard to be 100% sure of this even with testing. It also makes some programs very difficult to modify from 68020->68000.

[matthey]

@DavidF215
I'm pretty sure bernd_afa's SDL uses Warp3D. It works well but it's still slow because SDL can only work in a few graphics formats. Many SDL programs also use ixemul which is also slow. These are usually coded with GCC which doesn't optimize well. Get the picture?

[matthey]

Really interesting...

And following that concept:
Do any of you know of an assembler & dissasembler that can work nicely together and that that its compiler/linker can generate optimized binaries for 020/30/40/60 FPU and non FPU?

ADis and vasm work well together as do IRA and vasm. Most of the time, a program can be disassembled and reassembled without errors. The biggest key is removing instruction errors from the disassembler and assembler. This is what I have been testing for and Frank Wille and I fixing. Vasm optimizes and will usually save several hundred bytes by simply disassembling and reassembling. However, an experienced assembler programmer (me should look for mistakes and do further optimizations. I can remove dead code, do a better job than patch020 for integer math routines while recovering space, and switch to faster memory copy routines while saving space again. It is still possible to make mistakes or have a problem with disassembled code. It is especially difficult to tell a small amount of code from text or data. Much testing should be done.

Vasm does some optimizations based on the CPU (and FPU) selected but not much. There is not much to be gained here unlike optimizing for a CPU with a compiler. Most OS components do not use the fpu at all. Using the fpu is almost always slower than using integer routines.

I should have some libraries for you to start testing before long. They are datatypes.library and diskfont.library. I chose these 2 because they are small, relatively easy and usually resident in memory so will save ram. I have finished my preliminary testing of ADis and Vasm for errors and I'm working on Warp3D libraries 1st. I am learning as I go. I'm still not 100% sure I can produce error free enough reassemblies with optimizations to distribute but I should know within the next few weeks.

[matthey]

@DavidF215 & fishy_fiz
GCC for PPC code generation is not nearly as bad as 68k. The newest 4.x versions of GCC still does not generate optimized code for 68k. Some of the newer versions are worse. GCC 2.9.5 may generate the best 68k code. VBCC and SAS/C generate better code in most cases. VBCC is still being updated with Amiga support which includes an awesome optimizing assembler. Frank Wille has some other developing tools he is supporting as well. Thomas Richter is actively supporting his Mu (mmu) tools. I am making a much improved version of the ADis disassembler that is already very useful. We have some of the low level tools but some of the high level tools are very sophisticated and require a lot of time and skill to perfect. Making a cross platform C compiler which supports most CPU's is a huge project much like these multi platform web browsers that we don't have. I think we are gaining some momentum and users back. If we could get a fpga solution like Natami or MiniMig+ with AGA and 020+, we might have something.

[matthey]

Well, let's take the old game "Payback" as an example. On a 68020, would game play responsiveness and performance be noticably slower if the code was compiled with GCC (not optimized compiler) as opposed to SAS/C (optimized compiler)?

GCC is more commonly thought of as a optimizing compiler than SAS/C but the 68k code generator has been so bad on some versions that it completely sabotages any effort toward optimizing. SAS/C didn't do anything complicated but did most of the simple things right. There is still room for improvement with SAS/C. It's register management is not so good but I can find very few simple (peephole) optimizations. GCC has tons. VBCC is the best at peephole optimizations because vasm, it's assembler, optimizes many of them. These small optimizations can really add up too. The Warp3D W3D_AvengerLE.library I recently edited went from 282,312 bytes to 236,908 bytes with primarily 3 optimizations (plus what vasm makes) and dead code removal. I deleted approximately 4600 useless NOP instructions alone. One test showed a 14% increase in speed on the 68060 but that would vary. The Warp3D.library is even worse optimized and one of the worst optimized libraries I have ever seen. It's kind of funny looking at who wrote Warp3D that they didn't see this. I would guess that these libraries would be 20%-50% faster and smaller if they had used SAS/C. It may be possible for Payback to be up to twice as fast if Warp3D and Payback were compiled with a good 68k optimizing compiler (doesn't exist yet) and minor optimizing algorithm changes were done.

[matthey]

@DavidF215
Actually, Payback is pretty CPU bound since it is a 3D game.  Having a better compiler would make a HUGE difference.  As for GCC vs. SAS/C, they both optimize code but neither produces near-perfect code so comparing those two might not be the best idea.  The main advantage of SAS/C is its top-notch debugger.

Have you tried BDebug by Ralph Schmidt in the Barfly archive on Aminet? It's very powerful but still has a bit of a learning curve...
http://aminet.net/dev/asm/BarflyDisk2_00.lha

I used to use Metascope which is the friendliest debugger but It sadly doesn't support the 68060.

If somebody would offer a bounty for porting LLVM and its associated versions of GCC and the Clang C compiler to OS 3.x, I'd gladly take it.  It doesn't have a decent source-level debugger yet but that can be left for a later bounty.

That would be interesting and probably easier to work with than GCC but it doesn't look like it supports 68k? Wouldn't that be a lot of work? It would be nice for the PPC Amigas.

[matthey]

@DavidF215 & AppleHammer
I would recommend using C and VBCC for any new Amiga projects. It's the easiest to install, generates pretty good code and getting better, and it's supported on all flavors of the Amiga. Have a problem or bug then drop Frank Wille an e-mail. If you need C++ then probably your best option is GCC for now but realize it's going to be very slow and eat a lot of memory.

vbcc web site: http://sun.hasenbraten.de/vbcc/
Amiga coding help can be found here...
http://utilitybase.com/
http://eab.abime.net/forumdisplay.php?f=37