Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!hplvec!boyne
From: boyne@hplvec.LVLD.HP.COM (Art Boyne)
Newsgroups: comp.lang.c
Subject: Re: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior
Message-ID: <690004@hplvec.LVLD.HP.COM>
Date: 15 Apr 91 16:03:45 GMT
References: <1991Apr6.091013.26131@daffy.cs.wisc.edu>
Organization: Hewlett-Packard Co., Loveland, CO
Lines: 35

>In comp.lang.c, pardo@june.cs.washington.edu (David Keppel) writes:
>
>    carter@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@hplvla.hp.com