> From: Andrew Warren <fastfwd@IX.NETCOM.COM>
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: C-compilers for PIC
> Date: Friday, 13 June 1997 07:48
>
> Mike Smith <PICLIST@MITVMA.MIT.EDU> wrote:
>
> > > MPC seems to have its share of detractors, too.
>
> I replied:
>
> > Name one, Mike.
>
> and Mike replied:
>
> > Just have a look at the number of happy, satisfied customers for
> > MPLAB-C
>
>     Mike:
>
>     MPLAB-C is NOT the same as MPC.
>
>     MPC is Bytecraft Limited's compiler; MPLAB-C, Microchip's
>     compiler, is based on (and still almost identical to) a VERY old
>     version of MPC.
>

Versionitus strikes again.  MPC *looks* more like a contraction of MPLAB-C
than a contraction of ByteCraft compiler.  I'll try to be more careful in
future...

> > >         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".
> > >
> > > [example snipped]
> > >
> > >         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?
>
>     Um, yeah.  Re-read the first paragraph of my description of the
>     problem.
>
> > 0x1000 12 <- pointer starts here
> > 0x1001 34
> > 0x1002 12 <- pointer after one iteration
> > 0x1003 34
>
>     No... Since the 17Cxx program-memory is 16 bits wide, THIS is
>     what actually happens when the pointer's erroneously incremented
>     by two:
>
>         0x1000 1234 <-- pointer starts here
>         0x1001 0000
>         0x1002 1234 <-- pointer after one iteration
>         0x1003 0000
>

As pointed out in a previous mail - I was thinking PC - where you can
access on byte boundaries this way.

MikeS
<mikesmith_oz@relaymail.net>