John Payson <PICLIST@MITVMA.MIT.EDU> wrote:

> Is the compiler storing consecutive items in your data structure in
> consecutive words?

    Yes.

> If so, incrementing a pointer should advance it to the next
> address.  If not, it should increment the pointer in such a way as
> to move from one item to the next.

    We're in violent agreement here.

> > The pointer is pointing to 16-bit objects; the size of a (*p) is
> > 16 bits, and each one of these *p's fits in a single 16-bit
> > memory location in the program space.
>
> Certainly each one CAN fit in a single word.  Are you also implying
> that the compiler does, in fact, allocate them that way (while it
> would be silly of the compiler to store values using only the low
> byte of each word, it would not violate the C standard by so doing).

    Yes; the compiler does put each 16-bit value in a single word.

> Fair enough.  And you're saying the handling of int (16-bit)
> quantities doesn't just store half of the number in each of two
> addresses?

    Yes.

> The data type MPC calls an "int" is a "char".  The data type MPC
> calls a "long" is an "int".

    True.

    The type it calls a "char", though, really IS a "char"... So
    that's gotta count for something.

> MPC does not, as far as I know, support [32-bit] "long"'s (the
> only compiler I know that does is HiTech's beta).

    True... But twenty bucks says that by the time HiTech's compiler
    is out of beta, MPC will also directly support 32-bit types.

> Personally, I *NEVER* use the defined type "int" to refer to an
> 8-bit number in CCS.  Instead I *ALWAYS* do:
>
> typedef long ui; /* Unsigned int */
> typedef char ub; /* Unsigned byte */

    Me, too... The real code from which I extracted the example
    code-fragments in my previous message uses "typedef unsigned
    long word" and "typedef unsigned char byte"; I omitted those
    typedefs for brevity.

> > In any case, though, portability is the least of my concerns.
>
> True, but if the compiler's doing something which is compliant with
> the C standard but runs contrary to your expectations, you may be
> expecting something you shouldn't.

    Words to live by.

    In my case, I reach all my program-space memory through access
    functions, so I won't have to change much code when this MPC bug
    is fixed.

    Additionally, I copy all program-space values to buffers in the
    register space before performing any operations on them (and I
    copy them back afterward, of course)... Aside from the speed and
    space benefits, this'll protect me when and if a new version of
    MPC provides a method for accessing program-space memory that's
    less of a kludge than the current "long far pointer" arrangement
    (which is currently the ONLY way that MPC allows access to
    16-bit objects in the program space).

    -Andy

=== Andrew Warren - fastfwd@ix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499