Steve Hardy wrote: > Perhaps the compiler should allow > > long far * p; > > *p = value1; > p += 0.5; /* ?Que? */ > *p = value2; Nice one, Steve. Actually, there ARE a couple of workarounds for the problem. The original example, which doesn't work because of a bug in MPC, was: long far *p; // In MPC, "long" is a 16-bit word. p = 0x1000; for (x = 10; x != 0; --x) { *p = 0x1234; ++p; // This doesn't work, since MPC // erroneously increments p by 2. } WORKAROUND #1: -------------- long far *p; // In MPC, "long" is a 16-bit word. long p_alias @ p; // p_alias is allocated at the same // address as p. p = 0x1000; for (x = 10; x != 0; --x) { *p = 0x1234; ++p_alias; // This works: p_alias is incremented // by one and, since it's allocated at // the same address as p, it indirectly // increments p by one, as well. } WORKAROUND #2: -------------- long far *p; // In MPC, "long" is a 16-bit word. for (x = 10; x != 0; --x) { p = (0x1000 - 1) + x; // This works, but it's slow. // // The "-1" term, by the way, // is necessary because x is // always in the range [1-10]; // a "for (x=0; x!=10; ++x)" // would remove the need for the // "-1" term, but it would force // the compiler to test for the // end-of-loop with a comparison // rather than with a simple // "DECFSZ x". *p = 0x1234; } -Andy === Andrew Warren - fastfwd@ix.netcom.com === Fast Forward Engineering, Vista, California === http://www.geocities.com/SiliconValley/2499