> >         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.
> >
> >         For "near" pointers (which MPC uses to point to addresses in
> >         the register space), pointer math works fine.
> >
> >         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.  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, you can!  (Of course, you have to have Vpp present to do so...)

> 0x1000 12 <- pointer starts here
> 0x1001 34
> 0x1002 12 <- pointer after one iteration
> 0x1003 34
> (I don't know whether MPC is big or little endian)

The 17Cxx parts have 16-bit words on the code-space (EPROM) side, so:
 0x1000 1234 <- pointer starts here
 0x1001 FFFF
 0x1002 1234 <- pointer after one iteration
 0x1003 FFFF
 0X1004 FFFF <- pointer after second iteration
Even though the TABLRD and TABLWT instruction pass one byte at a time, the
program memory must be given a 16-bit visit on every other byte, and TBLPTR
is a (16-bit) pointer to 16-bit words, not to bytes.

I'm not sure whether you can call the 17Cxx either little-endian OR
big-endian, except that low/high byte pairs are allocated low address for
the low-order byte (e.g., PRODL/PRODH are 18h/19h) that makes it
little-endian, eh?

Peter F. Klammer, Racom Systems Inc.                   PKlammer@ACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708