Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior

carter@cs.wisc.edu (Gregory Carter)
Sat, 6 Apr 91 09:10:13 GMT

          From comp.compilers
Related articles
Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior carter@cs.wisc.edu (1991-04-06)
Re: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior ckp@grebyn.com (1991-04-08)
Re: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior albaugh@dms.UUCP (1991-04-09)
Re: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior pardo@june.cs.washington.edu (1991-04-12)
| List of all articles for this month |
Newsgroups: comp.compilers,comp.lang.c
From: carter@cs.wisc.edu (Gregory Carter)
Summary: 32-24 bit address translation coloring
Keywords: C, code, question
Organization: U of Wisconsin CS Dept
Date: Sat, 6 Apr 91 09:10:13 GMT

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]
--

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.