Unfortunately there are no questions on Stack regarding ARM and assembler at all.
My concern — is time critical devices. Let's take for an example one of my AVR-based device (program compiled with GCC) which should do something up to INT0 interrupt. It working with 8 MHz internal oscillator (125 ns one machine cycle) but it took up to 5 microseconds to react for the interrupt. After the code investigation I came to the conclusion that in the beginning of interrupt service routine processor make a lot of work to save it's state which is almost uncontrollable for high level programming languages (such as C is). If I'd use assembler I could for example throw a pin change in the very beginning and keep the rest of necessary calculations after that. Or I could have much more control over the registers' use and therefore much less time to save those registers.
If I'd go to ARM (which I'm planing to do soon) I will have much faster processor core with much more registers and memory space which looks promising. But will I ever be able to have any control over such time critical processes to obtain for example reaction time within let's say hundred nanosecs'?
Best Answer
It's very reasonable to program ARM in assembler. It's a straightforward RISC architecture with few surprises and plenty of registers. You can mix C and assembler provided you have a good understanding of the calling conventions.
There is a special low-latency ARM interrupt mode called FIQ, which swaps out some of the registers to a bank in hardware so they do not need to be saved in the ISR. 100ns latency to doing something useful is still going to be hard - at 100MHz that's 10 clock cycles, and FIQ takes up to 12 before it executes the first instruction.