>> In its most-current incarnation (version 1.30d), MPC has very few
>> problems... The only code-generation bug that I've seen involves
>> "long far pointer" math on the 17Cxx parts:
>>
>>     Unlike all other PICs, the 17Cxx parts allow reads and
>>     writes to the PROGRAM memory; in MPC, those program-space
>>     accesses are accomplished through the use of "far pointers".
>>
>>     If you want to read or write the entire 16-bit word at a
>>     program-space address, you need to use "long" far
>>     pointers... To write 0x1234 to address 0x1000, for example,
>>
>>     The problem occurs when you try to perform any MATH on the
>>     pointer.  Let's say, for instance, that you want to fill 10
>>     contiguous locations with 0x1234... You'd probably do
>>     something like this:
>>
>>         long far *p;    // In MPC, "long" is a 16-bit word.
>>
>>         p = 0x1000;
>>
>>         for (x = 10; x != 0; --x)
>>         {
>>             *p = 0x1234;
>>             ++p;
>>         }
>>
>>     In C, "incrementing" a pointer doesn't necessarily add 1 to
>>     it; rather, it adds the SIZE of the object to which the
>>     pointer points.  That is, if you have a pointer to a 10-byte
>>     structure at address 0, "incrementing" that pointer will make
>>     it point to address 10.
>>
>>     When math is performed on "far" pointers, however, MPC
>>     fails: In the "for" loop above, p is erroneously incremented
>>     by TWO at each iteration, since it's a pointer to a "long"
>>     and MPC doesn't realize that each location in the program
>>     space is SIXTEEN bits wide, not eight.

> I don't get it.  You are storing a 2 byte value at a pointer location, then
> incrementing the pointer.  If it only increments the pointer by one, or
> indeed any other number but two, the pointer will be pointing at the wrong
> location.


Incorrect.  Not all memory architechtures are octet-address oriented.

Lots of commonly known CPUs ARE octet-address oriented.  Examples
include the Intel X86 series, Motorola 68000, IBM 360/370, and the
DEC PDP-11.  Since the PDP-11 is built that way and the original
designers of UNIX & C developed on it, most C compilers (and C
programmers) assumes it's always true.  It isn't.

Some memory architechtures have a word size other than 8-bits.
For example, each memory location/address in a DEC PDP-8 is 12
bits, in a DEC PDP-10 is 36 bits, in a DEC PDP-15 is 18 bits,
and in a CDC 6000 series is 60 bits.  In each of these machines,
incrementing a memory address pointer aims at the next location
of XX bits, where XX is _not_ equal to 8.

In the PIC 17C4X's program memory, the word size is 16 bits.

In all PICs, the data memory does use octet-oriented addresses.
Each address represents a location holding 8 bits (word size = 8).


> Maybe its a mis-understanding on my part of MPC, and its use of the far
> modifier, or ignorance of the 17xxx parts.  Can you do accesses to
> program space in them, unlike the 16cxx's?

Yes.  See the "Table reads and table writes" section in the 17C4X
documentation and the TLWT, TABLWT, TLRD, and TABLRD instructions.


> 0x1000 12 <- pointer starts here
> 0x1001 34
> 0x1002 12 <- pointer after one iteration
> 0x1003 34

In PIC 17C4X program memory, this is incorrect.  Your drawing
should be:

    0x1000  1234  <- pointer starts here
    0x1001  ????  <- location missed due to bug
    0x1002  1234  <- pointer after one interation


> (I don't know whether MPC is big or little endian)

Little or big endian is dependant on the CPU/memory architechture,
not the compiler.  It implies that objects larger than 8 bits are
written 8 bits at a time.  In the PIC 17C4X's program space, it's
a non-issue as 16-bit words are written as whole quantities.

                                                Lee Jones

-------------------------------------------------------------------
Jones Computer Communications             lee@frumble.claremont.edu
509 Black Hills Dr, Claremont, CA 91711         voice: 909-621-9008
-------------------------------------------------------------------