> >It does not, and for a very good reason. Since ROM and RAM are 
> >completely separate address spaces, that don't even have the same 
> >pointer width (RAM =
> >12 bits, ROM = 16 or 22? bits), there would be quite a bit 
> of overhead 
> >to create 'universal' pointers. I suppose it could be done using a 
> >24-bit format where the upper bit indicated which memory type to 
> >access, but I just think that would be ugly (and slow).
> 
> But speed may be an acceptable trade off sometimes for the 
> convienience of a function that can accept a pointer to 
> either data or program memory.  HiTechs compiler can do this, 
> but with a small limitation.  If the pointer value is below 
> the maximum data memory address, it is deemed to be pointing 
> to data memory, otherwise it's pointing to program memory.  
> Of course this does introduce some overhead and is 
> problematic if you want to access low program memory with the 
> same pointer.
> However, the linker will always place constant data above 
> this address, so for the majority applications this solution 
> works very well.
> 

I really wouldn't like the idea of not distinguishing the difference
between the two types of pointer. They *are* different, and IMHO a
compiler "hack" to make them compatible is a recipe for disaster.

For a start, rom pointers are *always* const, ram pointers need not be.
And think of the utter mess of trying to deal with pointers-to-pointers,
ie. void **. Eugh.

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