The AVR is available up to 20 MHz, and does most instructions in a single cycle, and most of the rest in 2 cycles (multiply, 16 bit instructions, branches and jumps, some load/store).

Overall, the AVR is a modestly performing CPU. I use it on a regular basis, but if I need something better, I'll take an ARM (or Cortex). Many choices in the 50-80MHz range, 32 bit, 16 registers, and most instructions take only a single cycle. ARMs also compete well on price. Some sell for less than $2, with integrated Flash, RAM and a bunch of peripherals. The ARM instruction set is also easy for assembler programmers (I've done a bunch of ARM assembly). Thumb/Cortex takes a bit more getting used to, due to some irregularities.

A pointer is an address.



Where are they going to be stored if not in RAM?



It's extremely fair. AVR's target market is, in fact, the same target market that 65xx architecture CPUs target. And, their code takes comparable amounts of time for performing similar tasks.



Hyperbole. The 65816 is a 16-bit CPU, and can index 64K of memory at will. You don't start to get into multi-word operations until you address more than 64K, and even then, it's not that bad.



On the contrary, GCC is exceptionally smart -- it has one of the largest suites of optimizers available in a C compiler. While GCC isn't as smart as, say, an Intel-made compiler, we can pretty much expect this to be the case because Intel has deep knowledge of the CPU, which the authors of GCC don't have.

Still, the performance and code density differences between GCC and Intel's compiler are quite negligible in every case I've seen.

AVR's code generator in GCC is quite smart too.



If the compiler, at that stage of code generation, knew you were going to use the result to compute a pointer, sure. It didn't, so it moved it manually. An SSA optimization pass would have made this discovery by walking the code backwards, but I explicitly mentioned that I didn't use SSA, I used a stack-based code generator with a single code pass.



You're changing the argument. We were talking about optimal register allocation techniques, not computing the expressions given to the compiler. Let's stick to that topic. http://en.wikipedia.org/wiki/Register_allocation

Quote:

I don't think this argument can be used as an excuse to "forbide" them.

If you can accomplish a task without exposing a pointer to the programmer, it's a win. And, as can be seen by a plurality of high-level languages, this is doable, and has been done since the 70s at least (e.g., ML, Lisp, etc.).

Quote:

Do you understand why I don't like Forth?

I don't, because well-written Forth code factors out address computations, and exposes only task-specific words to other modules. This results in a domain-specific language which everyone else then uses. DSLs seem all the rage these days, what with Java annotation libraries and Ruby DSLs yielding significant returns on investment and, thus, making all the headlines in major programming rags. And, to think, Forth had it 30 years ago.

Take notice -- DSLs tends to hide pointers!! (funny, that.)

Judging by what you've written here, you're the type of person who strews pointer arithmetic literally everywhere in your C code. This is a maintenance nightmare, particularly when your code's schema changes.

Just yesterday, in fact, I found myself [i]really wishing hard that Ruby was more Forth-like for some Selenium automation tasks I was performing. Modules and includes, a core mechanism of Ruby's code reuse strategy to implement "traits" and multiple inheritance, started to break down for my code re-use needs. Use of Forth would have resulted in code at least 4x smaller in total line count, and likely in character count as well.

As a general rule, AVR executes one instruction per clock cycle, so a 16MHz part will execute code at just under 16MIPS. The reason it's just-under is because RAM accesses (outside of its I/O space), flash accesses, etc. take longer than one cycle.

The AVR also is a Harvard architecture processor, while the 65xx is a Von-Neumann architecture processor. This means that the AVR literally will be fetching and/or retiring an instruction at the same time it's touching data. The 65xx architecture cannot do this, so its instantaneous instruction throughput is more variable.

Finally, the AVR uses 16-bit instructions, despite it being an 8-bit processor. It fetches these instructions in parallel, hence the single-cycle access.

So, in a very real sense, the AVR cheats at everything it does, but for embedded work, it's all quite well justified.

I seem to recall its interrupt performance is pretty good, as long as you don't save and restore large portions of its register set.

Why would pointer arithmetic cause a maintenance nightmare ? I use it all the time, and have experienced no maintenance problems. I can't recall many errors due to pointer usage either.

If your addressing schema changes, you have to update all the locations you use the relevant arithmetic. When I worked at Hifn, I had about 700MB of C code to maintain (yes, you read that right -- one full CD's worth of C code) which exercised Hifn's various chips in various ways (some would call the tests abusive, even). Well, with each new generation of chip architecture, we would need to adjust the code to compensate for the chip's new memory layout requirements. If this code is at all representative of what most people's C code is like (and based on my experience elsewhere, it certainly is), then every addressing-related change I had to make had to be applied to at least six different source files, each with at least seven or so instances.

jesari asked, why not just write a[i]=b[j+3]? Because, in Forth, that one line can be factored out, given an appropriate name so that it can be reused elsewhere and in virtually any context. In C, you can do this too, but it's more difficult: you either use #define to make it a macro, or you make a function, which incurs the runtime overhead that prevents you from wanting to just type the expression in the first place. But, if the address computation itself changes, this is where C starts to suffer somewhat more than Forth, because in Forth you can just factor out the address computation itself. An array transfer from memory to memory, in Forth, takes the exact same form as an array transfer from persistent storage to persistent storage, or from memory to persistent storage. Only the address calculation needs to change, not the structural integrity of the statement itself.

I've never had any problems with pointers as well. But, given a choice, I'd rather deal with values. Not only do they make more sense, but just as garbage collection eases memory management, thinking in terms of values does similarly as well. As long as you have pointers exposed to the programmer, your compiler cannot optimize memory layout for fear of memory aliasing at run-time. Numerous functional languages today, for example, have extensive optimizations on memory layout, saving considerable amounts of memory over naive expectations.

Can you give an example ? Or explain what you mean with 'addressing schema' ..



Optimization problems due to memory aliasing only affects a small set of applications. For many other applications, the exposed pointers provide more flexibility for the programmer, and better code overall.

That's probably due to a bad software design. With the appropriate techniques, there's no need to change your source code when the memory layout changes. All you need is a new set of #define's for the addresses.



I'm willing to bet that Forth has a runtime overhead that's just as bad. In the end, they're both executing machine code. By the way, most C compilers offer a 3rd option: inline functions.

Since Forth retrieves and deposits its results on the stack, calling a routine is actually a pretty fast operation.

However, you're correct that stack manipulations cut into that performance. Whether C is faster than Forth or vice versa depends, then, on the nature of the program written.

My concern isn't with runtime performance so much as it is with syntactic freedom.