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.
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...
But of course assembly coding has its place in time critical routines and sometimes you just cant get compilers to produce efficient code for your task (i.e. AltiVec optimizations or using special PPC instructions, move16 on 68k and so on).
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.
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.
