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

> In standard C, the following are the requirments for pointers and
> types:
>
>     [Rules 1 through 7 deleted....]
>
> [8] For any type of pointer 'foo', {foo++;} will increment foo by
> the size of a (*foo).
> ....
> If [MPC is] packing the bytes two per word and incrementing the
> pointer by two bytes worth, then it's acting in error.

    John:

    I suspect that you understand the symptoms of the problem
    perfectly, but that you mis-spoke and said "incrementing the
    pointer by two BYTES worth" when you meant "by two WORDS worth".

    Just to make sure, though, let me clarify a little:

    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.

    However... MPC performs no special-case handling of the "long
    far" pointers that it uses to access program-space memory; it
    erroneously performs math on those pointers EXACTLY the same way
    that it (correctly) performs math on the "near" pointers that are
    used to access the register space.  That is, it increments
    pointers to "longs" (16-bit objects) by TWO, not one, whether
    they point to the 8-bit register space OR the 16-bit program
    space.

    By the way... "char far" pointers (pointers to 8-bit objects in
    the program space) work fine; MPC stores chars one per address,
    leaving 8 bits of each program-space memory location unused.

> If you're packing the bytes two per word (e.g. you created an array
> of constant integers) then you're making a non-portable assumption
> (that sizeof(int)==2).

    My array is of constant longs [in current versions of MPC,
    sizeof(long) is 16 bits].  If it HAD been an array of constant
    integers, it would've worked fine, but only because sizeof(int)
    is 8 bits in MPC.

    In any case, though, portability is the least of my concerns.

    -Andy

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