This always sets off a hot debate, over which is better, assembly, or C /(pick your personal variant)
Most people are fairly cognizant of the differences, but because more people program in C, the knowledge base available in assembly is annoyingly small, especially for such as these relatively new ARM cortex products.
From the manufacturer's (or in this case the designers(ARM)) point of view, benchmarking is mostly going to happen on code compiled with C, and so the instruction set must work well when the C compiler is written for it.
Certain features, may be great for C, and yet, because they are ultimately there for solving algorithms fast, concisely, and with a minimum of code, the same can often be said for the same processor, but with a non C compiler, or, for low level Assembler.
Among some people, there is a belief that a low level language is beneath them, and a high level language, is one to aspire to.
Certainly, if you want to impress management types, with little technical savy, you may be able to convince them of this theory.
One can put this same theory into a different perspective, by saying that a high level language makes things easy and does most of the work for you, and that with a low level language, you have to do most of the work yourself. This, however, presents a concern to some minority among us, If most of the work is already done for us, then how do we know it's being done properly ? Progressing from this point, you will hear people benchmarking compiler's relative performances, and spouting strange (large) figures for a project's required memory size and processor speed.
Look on manufacturer's websites, and you will see: "does not need to be programmed in assembler"
I think this issue is still critical for those of us who want to make leading edge products, and not merely meet goals set by an administration team.
There are, obviously things that C is quite good at, but it's well known that highest performance comes from processor specific analysis with respect to the required tasks. So, even if your preferred tool is C, now and then, to speed things up, you will need to at a minimum, do some inline assembler.
I once bought a standalone Atmel programmer, and being a curious person, I did a quick look at the PC front end executable file in ASCII format. Strangely, the exe file had a collection of porn site URLs !
When you use other people's tools, you don't really know what's happening.
I'm still trying to teach myself assembler for the cortex-m3, and it's a frustrating process. Dale Wheat has some on line documents relating to his tests on the Luminary and STM cortex projects, and there is something to be learned from them, but I need more.
For example, looking through the assembly instruction set summary, there branch instructions, but the documentation on stack usage is very sketchy, I can't see obvious ret / return / return from interrupt instructions.
There are branch with link instructions, pop instructions, but I think the closest is the pop registers and PC variant of the POP instruction. This is a RISC processor as I understand it, and I have memories of analysing the AVR instruction set and finding one of the instruction mnemonics was actually a very general instruction, but relating specifically to the PC (program counter)
It used to be normal to tidy these sorts of things up at the ARM/Luminary/ST level, but the closest I can find so far, seems to be a book: ["The Definitive Guide to the ARM Cortex-M3" by Joseph Yiu.], although as I don't have it, I can't say how relevent it is.
As a non C programmer, I look at the very long list of cortex-m3 instructions, and I wonder, how many of them are actually compiled into projects by the current C compilers. We don't always need to use all the features, but a good understanding of the processor makes big differences to code speed and density
Manufacturers are selling their 32 bit products over the 8 bit ones by telling us that we get more MIPs per MHz, but programming in assembler means we do the job in less MIPS anyway ! therefore, a good Assembly programmer can make their project run at lower power than a good C programmer can, in C alone, anyway.
Does anyone know of an on line reference that gives cortex-m3 instruction usage in a format similiar to the olh Motorolla 68HC11 manuals ? i.e. opcode, technical details, example usage, register changes.
?
thanks...
Graham.
