• Locked Locked
  • Replies 9 replies
  • Subscribers 119 subscribers
  • Views 3977 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Be kind - i'm very new!

Ziso Regondo
Note: This was originally posted on 15th July 2011 at http://forums.arm.com

Hi all,

I'm a uni student, and one of my major modules involves embedded computer programming on a Keil MCB2370 development board - I believe this has the ARM7TDMI processor built onto it..

A bit of research shows me that this processor (although VERY popular ) is similar to that used in older devices such as iPod Classic first to third generations and iPod fourth and fifth generations, iPod Mini, iPod Nano first generation (according to wikipedia anyway).

My real question is this - how far off am i (hard work and tireless dedication notwithstanding) from working on the latest A4 and A5 chips in use at the moment - i get the feeling we're being prepared for a more general role in embedded computing by programming at this level, when much more superior and current technology is out there...

Any thoughts, pieces of advice, pointers?

Who is employing engineers capable of programming well on the ARM7TDMI and similar processors?
Parents
  • Note: This was originally posted on 25th July 2011 at http://forums.arm.com

    First and foremost, I want to say that probably most people using the latest Cortex-A8 and Cortex-A9 CPUs today probably aren't writing that much assembly code. For embedded stuff on an ARM7 you might end up writing more, due to doing more systems-stuff that requires it, having less performance headroom, and needing tighter hard-real time response. Most code for the latest iOS devices will be higher level, like in C/ObjC/C++. And for writing this code, understanding the ARM CPU running it isn't that important. Usually it'll only be for the most performance-sensitive code that you will consider writing in assembly, and if it exists at all it'll probably be a small percentage of your code.

    Basically, SoCs (system on chips) like A4 and A5 are popular in phones and tablets. Most programmers are doing downloadable apps for these devices, which is not embedded programming. In the embedded world, small microcontrollers are still king: these are usually relatively low-speed CPUs with embedded SRAM (instead of cache) and flash. It used to be that 8-bit and 16-bit dominated this region, but the low end of ARM has filled a lot of the higher end of embedded. Today ARM7 is gradually being replaced by Cortex-M3 (and to lesser extent M4 and M0), and mastering Cortex-M3 is harder than ARM7. But it's still a lot more similar than Cortex-A8/A9.

    In my opinion a lot of the general techniques to writing good ARM assembly can be learned on an old ARM7. BUT, some of the original ARM idioms are not as useful on say, Cortex-A9, and some can be outright harmful. For instance, shifting your inputs on ALU operations end up taking an extra issue cycle (but can still help if you're fetch limited). And conditional execution is turned into branches, so having more than one of these back to back is a bad idea. Really, if you want to do high performance assembly knowing the instruction set well will only get you half of the way there, for the rest you really have to know the CPU.
Reply
  • Note: This was originally posted on 25th July 2011 at http://forums.arm.com

    First and foremost, I want to say that probably most people using the latest Cortex-A8 and Cortex-A9 CPUs today probably aren't writing that much assembly code. For embedded stuff on an ARM7 you might end up writing more, due to doing more systems-stuff that requires it, having less performance headroom, and needing tighter hard-real time response. Most code for the latest iOS devices will be higher level, like in C/ObjC/C++. And for writing this code, understanding the ARM CPU running it isn't that important. Usually it'll only be for the most performance-sensitive code that you will consider writing in assembly, and if it exists at all it'll probably be a small percentage of your code.

    Basically, SoCs (system on chips) like A4 and A5 are popular in phones and tablets. Most programmers are doing downloadable apps for these devices, which is not embedded programming. In the embedded world, small microcontrollers are still king: these are usually relatively low-speed CPUs with embedded SRAM (instead of cache) and flash. It used to be that 8-bit and 16-bit dominated this region, but the low end of ARM has filled a lot of the higher end of embedded. Today ARM7 is gradually being replaced by Cortex-M3 (and to lesser extent M4 and M0), and mastering Cortex-M3 is harder than ARM7. But it's still a lot more similar than Cortex-A8/A9.

    In my opinion a lot of the general techniques to writing good ARM assembly can be learned on an old ARM7. BUT, some of the original ARM idioms are not as useful on say, Cortex-A9, and some can be outright harmful. For instance, shifting your inputs on ALU operations end up taking an extra issue cycle (but can still help if you're fetch limited). And conditional execution is turned into branches, so having more than one of these back to back is a bad idea. Really, if you want to do high performance assembly knowing the instruction set well will only get you half of the way there, for the rest you really have to know the CPU.
Children
No data