OT - assembler versus C for Amiga development

[commodorejohn]

The problem with C on small systems is that everybody uses GCC, which just plain isn't designed for efficiency so much as for massively multi-platform reliability. I don't know if there's a decent C99 compiler for 68k out there, but it would sure help things if there were.

That said, I kind of agree with Franko - 68k assembler is the nicest I've ever used in terms of programmer-friendliness, and it's pretty much guaranteed to be better than GCC at least. If you're doing an Amiga-specific project that's fairly simple in organization, I don't see a reason not to use it - it'll help majorly on low-end Amiga systems (and yes, people still use them,) and for those of us with a slightly beefier setup, the extra efficiency is just gravy

[commodorejohn]

VBCC is largely C99 compliant.

Hmm. How's the code quality?

What is a good 68k assembler to use today? I may  have use for it more for 68000 system-agnostic than for Amiga-specific.  Soething I could use with easy68K or ide68k simulator and other things  that don't have much of a system attached to the CPU. For all 68K  flavors 68000 to 68060, but at least 68000.

I agree with Karlos that Devpac is quite nice; if you want to code on a  non-Amiga platform, vasm (which SamuraiCrow already linked, but it bears repeating)  apparently supports Devpac's directives on top of the standard Motorola  syntax.

One final comment on the overall subject, as far as  I'm concerned, you don't need to know anything about assembler to be a C  programmer, but writing assembly language gives you a much better  insight into how to write C optimized for a given platform.

Everybody that wants to write fast code in any compiled language should  be a bit familiar with assembler at least, just to understand the inner  workings of how their kit works.

Amen. Amen. Even if you never write a single project in assembler, understanding the nuances of your architecture(s) is crucial to being able to write good code for them.

[commodorejohn]

I sort of agree but I wouldnt recommend it. It can lead to bad habits. I know coder who used to write lenghty C# methods because he knew there is always small overhead when calling subroutines in assembler code. Obviously that is not relevant to C# anymore and often not relevant to low level languages like C/C++ even.

I sometimes see this similar behaviour in my code when I am monitoring generated assembly to optimize software pipelined loops...

That it so true. It is also possible beat machine language if you select better algorithm. Bubble sort is always slow no matter how many hours is spent to squeeze last clock cycles away. Refactoring is so much easier in higher level languages and you are also more productive.

Yes and no. Unthinking application of optimization techniques learned by rote is going to lead to convoluted code that probably isn't even that optimal, whether you're writing in C, assembler, Forth, or what-the-hell-have-you. And while you're absolutely right that intelligent refactoring can make much more difference than a couple assembler tweaks ever will, I wouldn't say that's "beating machine language" - refactoring is refactoring no matter what it's written in.

This is why I love Michael Abrash. His Black Book is specifically geared towards 386/486 optimization, but there's so much information in there just as suitable to any architecture...one key point of which is "the best optimizer is between your ears." Learning how to identify problem areas and optimize them intelligently will serve you well in any language.