That's not what I said, nor is it what I believe. However, this forum provides ample demonstration that SOME 'C'-programmers are way past "quite" stupid, and, in fact are not only totally stupid but abysmally lazy, too.


I've not spent much time at that, simply because that doesn't matter much to me. I've spent time communicating with the sales and the support people associated with various compilers for various MCU's, and concluded that it's not worth risking even a single dollar on their products. I did buy one C-51 compiler years ago, but won't do that again anytime soon.


I've no doubt that compilers for ARM, MIPS, and other similar type and size computing engines execute code generated by compilers do that very well. They were, after all, designed with the compiler in mind. The X86, of which I'm not particularly fond, was designed a decade earlier at at time when 'C' was not so widely used. In the '80's most colleges were still teaching PASCAL as the primary instruction language. Some were even teaching BASIC, which is really not a modern language at all.


That's why I advocate in favor of ASM rather than 'C' for use with the 805x core.



Microcomputers and, ultimately, microcontrollers, evolved as a substitute for large amounts of logic IC's. 805x's are relatively simple when compared to the entire spectrum of computers, but quite "up there" considering when they were developed. Yes, they've evolved somewhat, mostly in the amount of on-chip memory can be contained within a single IC, and, to lesser extent, the peripherals that can be incorporated in the core. The current trend may ultimately lead to 805x's with a full complement of both code and data memory on the chip. I doubt that will ever happen with ARM or other 32-bit RISC's, not that the technology won't eventually allow it. 805x's can executed code at a pretty good clip without caches and other features that make cycle counting practical. Until ARM and other such cores make precise timing of code execution, they'll never suit all applications, since some will always require what the 'C' compiler can't be relied-upon to produce, namely precisely timed code execution. Now, one can determine, empirically, how long a given compiled code segment takes to execute, but if one changes even one minor feature, e.g. location in memory, the timing can suffer severe impact.

I primarily use microcontrollers as a substitute for discrete, or programmable, logic. They're not computing engines from where I sit, but, rather, they're ways of generating, routing, and switching signals.

I have, at times, considered using a compiler to generate macros that I can use in code written in ASM. By that I mean that there often are small code segments that are non-critical in their timing. The compilers don't make this particularly convenient, however.

ARM jealously retains the rights to their core, while MIPS is available in several open-source versions in VHDL or in Verilog. This makes MIPS, which is supported as well as ARM and on which LINUX is just as happy to run, a more attractive option for integration into programmable logic and, ultimately, into ASIC. I've always liked the ARM as a microcomputer core, since it is cheap, can be fast, and is well supported with open-source tools. However, I don't consider it viable as a microcontroller core for tasks not explicitly supported by on-board peripherals, since it's difficult to program in ASM, as you've pointed out.

About that documentation ... A successor should be able to read the documentation and, from that alone, fully understand every detail of what the system does, without even looking at one line of code. Further, it should be absolutely clear when reading the code listing, why each and every clause has the syntax that it has, based on the system requirements. If it doesn't do that, then it is simply not properly documented. That's MUCH easier to do in ASM than in a high-level language. If the documentation and listings don't make everything crystal-clear, then it's likely the reader isn't sufficiently familiar with the instruction set and instruction timing.

As for the "religious" issue ... I guess we'll have to agree to disagree. I can understand the desirability of using a small ARM-core single-chip microcomputer, but by its very central characteristics, it differs considerably from the classic microcontroller. Further, for its cost, ARM can't well compete with the performance of current-generation 805x one-clockers. That may change, of course, but I won't hold my breath.

RE