View Single Post
Old 21 May 2016, 02:22   #12
Registered User
Join Date: Jun 2010
Location: USA
Posts: 69
Originally Posted by matthey View Post
It is good to know who the bad players are (not always clear) who will try to sabotage or road block your efforts before you begin. Yes, I would likely get censored on certain other web sites for saying something similar. Hmm, actually I already did.

Sounds reasonable. Some of the internal data accesses are not so hidden. Most undocumented LVO functions are known and setpatches can be watched even if a pain. I don't think the newer AmigaOS libraries will be too much of a problem.

It remains to be seen how well you could do without assembler. Optimizing with 68k assembler probably could do better than the AmigaOS graphics.library which is probably some C and 68000 optimized code. Compatibility is the hard part. I haven't done much Amiga custom chip programming so I can't help you much there.

68k assembler is easy to read and compact but it is not as structured or forgiving as C. It took me longer to learn C than 68k assembler but then there is more to know with C and some of it is hidden.

GCC 2.95.3 gives better integer code quality on the 68k usually. It is not compatible with modern GCC, doesn't fully support C99 and the FPU support is basic. I would use vbcc also. If you stick with C99, then it should be compatible with GCC and other compilers. There are likely to be some improvements in code quality even if the 68k backend doesn't get much attention (what I expect but I hope I'm wrong). The active support is great and more important than code quality at this point. Vbcc could give worse code quality. It is right there with SAS/C and GCC 3.x depending on the code. It does best with 32 bit integer datatypes while doing a poor job of trying to promote most smaller datatypes to 32 bits. Promoting integers is good for most modern processors, including the 68060 sometimes, but is sometimes slower and generates larger code on the 68k (the 68020/68030/68060 are slowed by fetching larger instructions). The later ColdFire received the instructions needed to efficiently promote everything but even then dropping .w and .b sizes reduced the performance compared to the 68060. The ColdFire v5 is only faster than the 68060 because it is clocked higher.
The most important thing is stability and functionality, so I think making it work at any speed using C is the right way to go.

Any of those compilers will produce acceptable code for the 99% cases, but none of them will fix that 1% that needs to be as fast as possible.

Thanks for the input.
Heiroglyph is offline  
Page generated in 0.05966 seconds with 9 queries