Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior

[Art Boyne]

>In comp.lang.c, pardo at june.cs.washington.edu (David Keppel) writes:
>
>    carter at cs.wisc.edu (Gregory Carter) writes:
>    > (unsigned int)(*((unsigned int *)0xffff8e20L)) = 0x03;
>    >translates to:
>    >                       MOVE.W #$0003, $8e20
>    >This is obviously not correct.
>
>    I'll agree that it isn't what I *expected* but it is *correct*.
>    Here are some other correct implementations:
>
>     * Compiler refuses to compile the program
>     * Program aborts when executed
>     * Program runs `rogue'
>     * Program assigs 3 to memory location 0xffff8e20
>
>    Remember, dereferencing a hard-coded address (in C) has
>    implementation-defined effect.
>
>    In the meanwhile, I agree that the one it chose is non-intuitive.

You don't seem to understand:  MOVE.W #$0003, $8e20, assuming that the
compiler generated the 3-byte 68000 opcode [0x31FC,0x0003,0x8e20]
(immediate operand to absolute short address), will indeed assign 3 to
location 0xffff8e20, *exactly* the desired result.  This is because the
68000 will *sign-extend* a 16-bit absolute short address to 32 bits.

To assign 3 to location 0x00008e20, absolute long (32-bit) addressing must
be used to avoid the sign extension.  This is the 4-byte opcode 
[0x33FC,0x0003,0x0000, 0x8e20].

Now, if the compiler generated the absolute long address instruction above
in this case, I would call it a bug.

Art Boyne, boyne at hplvla.hp.com