« Reply #1 on: August 29, 2011, 07:37:43 PM »
Personally, I go for C(++) first, then anything that still isn't fast enough after reviewing algorithm changes and profiling I will look at writing assembler replacements for.
Some stuff just doesn't need optimizing. Basic IO, for example, is almost always going to be limited by the speed of the device being communicated with. Event handling is another example. No amount of assembler will basically speed up having to wait for an asynchronous event to happen.
The problem with assembly coding is that unless you keep absolutely up-to-date with each revision of your target architecture, you will always fall foul of bad assumptions in the end.
There are many clock cycle optimisations for the basic 68000 that are slower on the 68020. Likewise, once you master the 020's behaviour, a lot of it ends up being counter-productive on the 68040.
Then there are general changes in system architecture. On the cacheless 68000, precomputed lookup tables were king to speed up various complex operations. As processors have gotten faster in relation to memory, it often ends up quicker to evaluate the expression than it does to precompute it and perform memory lookups, unless you can arrange your precomputed data in a very cache friendly way.
Anyhow, this is somewhat off-topic.
I am not a programmer, only hobbyist and professionally IT support but I get your point that whether you go to machine code is dependant upon what you are trying to do. I had a big project that was very CPU intensive (mainly subset generating algorithms) and I coded this in 68k machine code which was fast but stupid. It taught me about the 68000 but when I converted it to C 12 years later I could then even recompile it on Linux with very few changes and it worked. If I was banging the Amiga hardware then obviously this wouldn't have been possible and I suppose that is one of the cases where assembler rules.

Logged
A1200 desktop, Blizzard 1260, OS3.9BB2, Indivision Mk II, SCSI Jaz, Ethernet
A1200 desktop, Blizzard 1230, OS3.1, Ethernet
A500, OS1.3