0 Members and 1 Guest are viewing this topic.
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.