jesari wrote:
So, now I understand that a,b,i, and j are addresses. I still think it is better to have pointers
A pointer is an address.
Quote:
instead of indices and variables stored in registers instead of RAM,
Where are they going to be stored if not in RAM?
Quote:
I must say your AVR/65816 comparison is not fair.
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.
Quote:
Try to address more than 256 bytes of memory on 65xx processors and you'll find it is a pain in the neck.
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.
Quote:
GCC isn't too smart
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.
Quote:
you can remove the two MOV instructions by doing the arithmetic on the pointer registers (r28:r29) directly.
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.
Quote:
I don't know what are you talking about. a:=b[j+3]; surely is a solvable problem for any compiler...
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_allocationQuote:
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.