Xref: utzoo comp.compilers:1899 comp.lang.c:38103
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!iecc!compilers-sender
From: albaugh@dms.UUCP (Mike Albaugh)
Newsgroups: comp.compilers,comp.lang.c
Subject: Re: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior
Keywords: code, assembler
Message-ID: <1229@dms.UUCP>
Date: 9 Apr 91 15:36:27 GMT
References: <1991Apr8.133307.27870@grebyn.com>
Sender: compilers-sender@iecc.cambridge.ma.us
Reply-To: albaugh@dms.UUCP (Mike Albaugh)
Followup-To: comp.sys.m68k
Organization: Atari Games Inc., Milpitas, CA
Lines: 49
Approved: compilers@iecc.cambridge.ma.us


	I was originally going to say the same thing, but stopped when I
actually read the question:

>From article <1991Apr8.133307.27870@grebyn.com>, by ckp@grebyn.com (Checkpoint Technologies):
> In article <1991Apr6.091013.26131@daffy.cs.wisc.edu> carter@cs.wisc.edu (Gregory Carter) writes:
>> (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 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.

	Such favors I don't need. Assuming that Greg correctly transcribed
the assembly output (rather than making a mistake dissasembling actual
machine code) the "correct" outcome from the above requires an assembler
that has some non-intuitive way of marking "I want a 32-bit address here"
and _defaults_ to using short addressess. This is definitely not the
way any of the five 68000 assemblers I have used work, and seems to me to
violate the "principle of least surprise". Now, if the assembler had
taken
	MOVE.W #$0003, $0ffff8e20

and generated a 16-bit address (as all the ones I've used do) I would
accept it as a "favor". But If I have to code

	MOVE.W	#$0003, $8e20.YES_I_REALLY_MEAN_IT

to access the equally legitimate address $00008e20, I don't consider that
a "favor". My personal suspicion is that either Greg (or one of his
software tools) mis-disassembled some machine code, or the compiler
was intended to emit a variety of 68000 assembly syntaces, and the
marker for "use short address" was accidentally omitted in his "flavor".
The second scenario also postulates an intended assembler that is _not_
smart enough to figure it out for itself, so I am dubious...

					Mike

Mike Albaugh (albaugh@dms.UUCP || {...decwrl!pyramid!}weitek!dms!albaugh)
[I've sent followups to comp.sys.m68k, since this seems to be more related
to details of 68K assembler syntax than any compiler issue. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.