Instruction Cycle Times

[sab964]

Posted on October 02, 2006 at 20:11

Instruction Cycle Times

[sab964]

Posted on May 17, 2011 at 09:32

Hello to all,

I need to know the instruction cycle time of each assembler instruction as I program a time critical application. I can't find detailed information about instruction cycle times (not on ARM homepage, not in the Addison-Weseley Architecture Reference Manual). Thank you and kind regards

[sab964]

Posted on May 17, 2011 at 09:32

Hi Steve,

thank you for your response and your programming hints (I'll check it out). I know that most of the instructions are one cycle instructions but I also know that there are some 2 and some 4 cycle instructions and I wanted to know which instructions are effected. We have really heavy performance problems with the STR912 so I need to check it out. We use the STR912 at 96MHZ and ALL settings are set for maximum speed (flash, sram,…) and we use ARM mode only. And with this settings it seams the ARM needs 29,2ns each assembler instruction (175us for 6000 instructions consisting of simple instructions like mov, bne, sub, cmp). Wallie

[stefano239955_stm1_stmicro]

Posted on May 17, 2011 at 09:32

Hi Wallie,

I think that you have to read the book with more attention ;) ARM is the acronym expansion to Advanced RISC Machine. As RISC the processor has - Hard-wired instruction decode logic - Single-cycle execution apart some istruction, like mul the execution time is one cycle. I suggest you to have a look to

http://www.pinknoise.demon.co.uk/ARMinstrs/ARMinstrs.html

with google search also for ''ARM Programming and Optimisation Techniques'' is a nice paper who describe how to optimize your code.

[roger_lynx]

Posted on May 17, 2011 at 09:32

I can't find detailed information about instruction cycle times

I highly recommend this book: ''ARM System Developer's Guide'' Designing and Optimizing System Software by Andrew Sloss, Dominic Symes, Chris Wright (I call it ''SSW'') ISBN: 1-55860-874-5 , Hardback It is about U$60, but worth every penny. The ARM ARM by David Seal is also an excellent book, but more architecture related (opcodes, etc.), for clock cycle counting (i.e optimization) the SSW book is the right tool. Not all instructions excecute in one cycle, and even if they do, under certain circumstances when the pipeline stalls, these instructions might produce a result 3-4 cycles later, especially with branching being involved. There is much, much more to it to get the predictability out on nanosecond-level. This is why [most] people like programming Java on quad-CPU umpteen GHz core! :) Nobody counts picoseconds, there. But I got carried away: For example one might need to optimize the algorithm first before the coding actually starts, for example: rather than using multiple LD/ST, use LDM/STM. Fill up/empty out the registers by this method since it takes longer to do 5*LD then LDM for 5 regs. And so on and on. Another suggestion is to look at ARM9 docs from ARM to understand how the pipeline works and how to take an advantage of it rather than to fight it - like in aikido :) Get the SSW book! Read it. Study it. Then code. And pray somewhere in-between. Good luck!

[sab964]

Posted on May 17, 2011 at 09:32

''NOP = mov r0, r0; that is normal for compiler to do...

plus loop unrolling going on?'' -> No, it was really ''true'' assembler code implemented in a very direct way. We wanted to know, if the STR912 does the 96MHz and: The STR912 did it. ''So let's start reading the books to count pico seconds... Nah...nanoseconds are enough.'' -> ok: Nanoseconds for the ARM, Picoseconds for the FPGA we have on our board ''At the least the manuals are readable, i.e. not ''Jinglish'' *and* with errors'' ->I hope ST will soon relase an update..it's really tricky with that manual although it is really readable and much more paper as for e.g. the ST10F168 in the early days (if my memory serves me right there was a manual with about 5 pages at the bgeinning...) ''What would you expect for $5,000?'' ->That the purchased features work - as our customers expect from our applications IAR semms to be better. We actual try the 30 days trial...no problems..no side effects...faster code...hm hm hm. Maybe we have to change...

[sab964]

Posted on May 17, 2011 at 09:32

Thank you for your hints.

It's our first ARM project, the documentation of ST is full of errors (very bad Reference Manual) and the KEIL we use is also not really ''up to date'' - but it's getting better each day. Today we made a very simple check - 1000 lines with move r0,r0 in a while(1) and a final toggel LED (I love copy and paste!) and the performence was exactly what we had expected: 10,5us for one while(1) what is about 10,4ns each cycle considering the toggle LED and the branch at the end of the while(1). So let's start reading the books to count pico seconds...

[roger_lynx]

Posted on May 17, 2011 at 09:32

It's our first ARM project, the documentation of ST is full of errors

(very bad Reference Manual) and the KEIL we use is also not really ''up to date'' - but it's getting better each day. Hm. At the least the manuals are readable, i.e. not ''Jinglish'' *and* with errors, then you would be climbing the wall! I did it once, and it was enough. ARM has quite a steep learning curve, as you can confirm. After a year or two you'll be a pro. :) 1000 lines with move r0,r0 in a while(1) NOP = mov r0, r0; that is normal for compiler to do... plus loop unrolling going on? So let's start reading the books to count pico seconds...Nah...nanoseconds are enough. There many optimizations techniques you'll learn about from that book. And with a proper compiler's setting, you might be able (soon) to go back to your C coding. re: KEIL, it will be okay, once they'll integrate RV in uV3. What would you expect for $5,000? Perfect solution? ;)

[roger_lynx]

Posted on May 17, 2011 at 09:32

-> No, it was really ''true'' assembler code implemented in a

very direct way. We wanted to know, if the STR912 does the 96MHz and: The STR912 did it. Okay, good for you - everybody: what time is it? ''It is assembly time!'' -> ok: Nanoseconds for the ARM, Picoseconds for the FPGA we have on our board Could have said so...:-) ->That the purchased features work - as our customers expect from our applications IAR semms to be better. I...tend to...agree, to a degree. I use 4.40. Nice. No point on arguing about the meaning of the word ''should'', or similar semantic constructs.