Re: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior

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

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