Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior

[Mike Albaugh]

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

>From article <1991Apr8.133307.27870 at grebyn.com>, by ckp at grebyn.com (Checkpoint Technologies):
> In article <1991Apr6.091013.26131 at daffy.cs.wisc.edu> carter at 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 at 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 at iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.