On Wed, 23 Jul 2008, Tamas Rudnai wrote:

> Hang on a minute!
> 
> > Put the following through your compiler:
> >
> > int main(void)
> > {
> >   int arr[6];
> >   arr[2] = 788;
> >   2[arr] = 788;
> > }
> 
> Without checking any PIC compilers I am telling you that you _could_ compile
> this without any pointers involved. Why? Because in midrange and 18F there
> is no real software stack and someone may can cheat with the local variables
> and use overlayed data area instead of stack, then as the address of 'arr'
> is well know at compilation time it can easily calculate the address of
> arr[2] so there is no need to involve any pointer aritmetics here - with
> PICs it does make difference in both code size and execution speed as well.

Ok, no one else has responded to this so I'll jump in.

What you say is correct, in this case 'arr' could be considered a constant 
and 2 certainly is a constant so yes you could compute the address of 
arr[2] at compile time and reference that direectly at run time. The 
problem with C is that the underlying stack based model, combined with the 
way pointers are passed around, the way source files are compiled into 
seperate modules with minimal information common to each module through 
header files, the way functions need to be re-enterent and have a 
parameter passing protocol to deal with all kinds of problems - well all 
this makes it very hard to do.

What you are advocating is the use of a static compile time stack instead 
of a dynamic runtime stack.

> It may or may not being used by C compilers for PIC, maybe only with
> sophisticated optimalization switched on (you may ask people here who are
> developing C compilers for PIC if it could be done - like Matt from Hi-Tech
> or Walter frm ByteCraft or even Wouter I think relevant on this subject with
> his JAL compiler and I am pretty sure Olin has a good experteese on modular
> development in assembly level plus knowledge on compiler technology). I did
> not say anyone actually doing this, I only say it _can_be_done_.

The XCSB compiler uses a static stack and generates highly efficient 
runtime executables. It has a lot in common with C but XCSB is not C. 

It does track the use of pointers and arrays across function calls and can 
optimise some pointer arithmetic to direct memory accesses. It can also 
greatly reduce function call overheads by noticing when arguments to a 
function dont change from call to call and in many cases embed the 
argument directly into the function body. It does lots of other clever 
things as well. All this means that there are restrictions on the language 
that make it much more MCU friendly than C.

I could have made the grammer of XCSB resemble that of C and simply called 
it C with restrictions, but hey I figured, why not try and address some of 
things that lead to bad coding practice while I'm at it.


Regards
Sergio Masci
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist