If they pipeline the architecture such that if you branch out of a loop and into another it takes an indeterminate period of time to reload the pipeline .... How'd they manage to sell that? This clearly makes their claim of "100 MIPS" false, except for loops shorter than whatever the pipeline is.

with proper coding the pipeline will miss only where you, as most often is the case, do not care. There are means of making "precise timing loops" run at full and precise speed.

So, yes, if what you want is to bitch, the cache stinks, if what you want is fast code it works.

BTW a cache miss is simple to calculate: 40ns if on 4 byte boundary up to 70 (40 + 30) if not.

as far as makes their claim of "100 MIPS" false" sure, only 'ideal' code runs at that speed; however 85 MIPS seems to be 'the rule' for 'typical un-tuned code' with 'tuning' you can easily make e.g. an ISR run at 100. There are, in the SILabs community, those that align the start of ISRs on a 4 byte boundary and make the first 4 bytes plus the vector 'permanent cache store' that way you can get an ISR to 'fly'. So, the correct statement (but this is marketing) would be "100 MIPS for critical code ~85 MIPS for the rest".

Other companies (e.g. Cypress) start off the chip by loading the code from flash to CODE RAM and then run from RAM to get access times that flash can not provide. Again "some like the mother, some like the daughter"

Erik