But it wouldn't be convenient on the ARM, since the ARM instructions has already reserved bits to specify which register to use and reserved bits to inform if the register should increment or decrement. So there are no need for duplicating the 8051 extension - the ARM solution is already a super-set.


But the timing isn't part of the instruction set. This is a single instruction for the ARM too. All newer processors can load and increment in a single instruction. In this case it is just a question of how the specific ARM has the memory connected (remember that the ARM is sold as a core and the chip manufacturers may decide what kind of memory interfaces to integrate) that controls if there will be a need of extra clock cycles because the execution stalls.


Yes, I know how this extension has been implemented in some 8051 derivatives. But the extension is meaningless in the ARM since the actual load/store instruction in the ARM already has dedicated flags for this. There is no need to use a configuration register somewhere to get the ARM to know which register to use for a memory access, or if the register should be updated after the access. It is actually the reverse situation from what you consider. The 8051 has a hack to try to become almost as convenient as the ARM (or x86 or PPC or MIPS or ...) but the 8051 hack only comes halfway.


Dangerously close to religious war here - I consider many of the ARM chips available to be microcontrollers. It is just a question of what kind of peripherials etc that has been integrated, and how they have been integrated. The microcontroller world is not a subset only allowing some 4- and 8-bit processors.


I don't think you understood what I was talking about. In the 16-bit x86 world, the processor accessed all memory based on four segment registers, CS, DS, ES and SS. They are basically a form of index registers. And pointers could be defined that had their addressable range defined as offsets relative to one of these segment registers. That is extremely close to teaching a 8051 C compiler to define pointers that are relative to one of several index register. In the end, a compiler vendor can do a lot with extended attributes for pointers. Just as Keil have already added attributes for the different memories in the 8051, that concept can be extended further. All it takes is that Keil see an interest in it and that they can make money by extending the language further.

But the 8051 isn't the only processor in this world with special features that a HLL compiler needs to take into account. It's just that the 8051 represents a quite small market for a compiler vendor. There are a huge number of 8051 chips in use, but a very large part of the chips are used in quite few products developed by even fewer developers. And it is an even fewer number of developers who needs (and are interested in paying for) compiler extensions for MAC, multiple index, ... For the ARM, the quality of the compiler is an important factor if ARM wants to sell their core to other companies. For the x86, the amount of money to spend on development tools are almost infinite.



First off: You are basically saying that C developers are quite stupid. Such a claim only falls back on yourself. Don't assume that people who do other things or uses other tools than you are not clever and professional and openminded... Maybe you do see failed projects and have to make them work. But in that case you have to remember that you will not see the working projects.

But this isn't a question of PC or microcontroller. The question is: Have you spent time looking at the generated code for the biggest/best compilers on the market? They just happen to not include any 8051 compiler, since there isn't market enough to invest millions of dollars in a 8051 compiler. But have you looked at the code generated by the ARM compiler? I definitely think that it produces sensible code.

I have spent time looking at ARM output for time critical sections. I have also written my own assembler code. I have been able to win on instruction counts on several occations. But I may not have won on cycle count, because the compiler can rearrange the instructions in ways that is hard to do for me without losing track of the contents in the registers - unless I document the source in ways that the next developer will shoot me.

Right now, you are programming a 8051 chip. It is one of the simplest processors in the world to program by hand in assembler. It is one of the least suitable processors for a HLL language. If you look at many of the newer architectures - where the transistor count wasn't important in the design - you will note the reverse. They are designed to be easy to implement compilers for but can be extremely hard to program for a human being who can't keep 20 or 50 or 500 facts in the head at the same time. I'm ok with moving a few individual assembler instructions two or three steps up or down in the code, to optimize access patterns but that is my limit. I can't keep track of 20 or 50 instructions that are moved +/- 20 steps up or down or more.

I think you are condemning compilers based on experience with small compilers maintained by maybe 1 or 2 developers, totally missing the advances there have been in code quality for the best compilers. You are always free to have any opinion you like, but be careful in underestimating things.

The world where you can count individual clock cycles in your loop is quickly shrinking because of the additions of caches, out-of-order execution, extra shadow registers, ...