Xref: utzoo comp.compilers:1892 comp.lang.c:38022
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!iecc!compilers-sender
From: carter@cs.wisc.edu (Gregory Carter)
Newsgroups: comp.compilers,comp.lang.c
Subject: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior
Summary: 32-24 bit address translation coloring
Keywords: C, code, question
Message-ID: <1991Apr6.091013.26131@daffy.cs.wisc.edu>
Date: 6 Apr 91 09:10:13 GMT
Sender: compilers-sender@iecc.cambridge.ma.us
Reply-To: carter@cs.wisc.edu (Gregory Carter)
Organization: U of Wisconsin CS Dept
Lines: 35
Approved: compilers@iecc.cambridge.ma.us

I recently had a problem with a compiler for my MEGA STE 4/50.  I was
wondering if any of you can report the same problems with Borland's
compiler?

When I attempt to move 0x03 into the address 0x00ff8e20 I get the
following:

 (unsigned int)(*((unsigned int *)0x00ff8e20L)) = 0x03;
 which translates to:
                       MOVE.W #$0003, $00ff8e20

 Ok, I expect that, thats no problem....BUT when I do this:

 (unsigned int)(*((unsigned int *)0xffff8e20L)) = 0x03;
 which translates to:
                       MOVE.W #$0003, $8e20

This is obviously not correct.

I thought about the compiler cutting 8 bits off the top half of the
address since the 68000 doesn't use this space anyway.  But, this isn't
what I expected.  Anyone know why they (BORLAND) decided to do address
coloring in this fashion?

Its a curiosity right now, but when I was going through my profs unclear,
nonportable, nonfunctional class examples, IT TICKED ME OFF. Made life
generally !pleasant.

Any help greatly appreciated.

Greg Carter
[Looks like a bug to me. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.