Xref: utzoo comp.compilers:1894 comp.lang.c:38072
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!world!iecc!compilers-sender
From: ckp@grebyn.com (Checkpoint Technologies)
Newsgroups: comp.compilers,comp.lang.c
Subject: Re: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior
Summary: Skip this if you're not into 68Ks
Keywords: C, code,
Message-ID: <1991Apr8.133307.27870@grebyn.com>
Date: 8 Apr 91 13:33:07 GMT
References: <1991Apr6.091013.26131@daffy.cs.wisc.edu>
Sender: compilers-sender@iecc.cambridge.ma.us
Reply-To: ckp@grebyn.com (Checkpoint Technologies)
Organization: Grebyn Timesharing
Lines: 28
Approved: compilers@iecc.cambridge.ma.us
Apparently-To: decuac!comp-compilers

In article <1991Apr6.091013.26131@daffy.cs.wisc.edu> carter@cs.wisc.edu (Gregory Carter) writes:
> (unsigned int)(*((unsigned int *)0x00ff8e20L)) = 0x03;
>                       MOVE.W #$0003, $00ff8e20
>...
> (unsigned int)(*((unsigned int *)0xffff8e20L)) = 0x03;
>                       MOVE.W #$0003, $8e20
>
>This is obviously not correct.

This may not be obvious, but it *is* correct.  The compiler is doing you a
favor.

The 68K has "absolute short" and "absolute long" addressing.  Absolute
long means that a whole 32 bit absoluet address follows.

Absolute short means that only a 16 bit word follows, and it should be
*sign extended* to 32 bits before being used.

The value $8E20, when sign extended into a full 32 bit address becomes
$FFFF8E20.  This is just what you asked for, and the compiler found a
briefer way to code it.
-- 
ckp@grebyn.com
[brychcy@informatik.tu-muenchen.dbp.de (Till Brychcy) also pointed this out.
-John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.