| ??? 11/03/06 15:59 Read: times |
#127326 - No ... it's not just a complaint ... Responding to: ???'s previous message |
I'm just not "up to speed" on the nomenclature they use to describe the features, hence, don't know what to tell the search engine to find.
I'm just after a bit of "spiritual guidance" in order to determine whether I can accomplish my task. (see my comment <http://www.8052.com/forum/read.phtml?id=127323>) If the cache, pipeline, prefetch queue, or whatever it is, is adequately documented, it should be precisely predictable, in which case it won't screw anything up. If it's not well described, well, maybe one of you guys with experience with the series will know what's not in the doc's. I know getting unpublished information is like pulling teeth, or worse. I did not intend this query to be an indictment of SiLabs' architecture. My comment Erik Malund said: was intended simply to reflect that it, like many "first-page" assertions, was misleading. Richard Erlacher said: "as far as makes their claim of "100 MIPS" false" Erik Malund said:
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".
So long as it's POSSIBLE to write a loop that takes the same amount of time irrespective of which path it takes, and do so without lengthening the thing by more than a very few cycles, the caching (or whatever they really do) won't rule its use out. What is the basis for your comment about the 85 MIPS rate? Can you direct me to any documentation that supports the sort of function I want to create? RE |
