[Coco] lwtools assembler difference

William Astle lost at l-w.ca
Tue Sep 1 15:55:43 EDT 2015


If I recall correctly, EDTASM uses the 5 bit offset if there is any 
offset specified, even a literal 0.

What lwasm does is more complicated than you have observed.

If you write 0,x explicitly, it assumes you really want 0,x. There are 
reasons you might (timing critical loops, for instance). And yes, I have 
seen at least one actual real chunk of code that required a 5 bit 0 offset.

However, if you write any expression that is not a literal "0", it will 
evaluate it and if it evaluates to 0, it will use the no offset version.

That is, unless you have pragma "noindex0tonone" in force, in which case 
it will assemble using the 5 bit offset.

Of course, if you force 8 or 16 bit offsets, you'll get those.

The reason a literal "0,x" is treated as "yes, I want the 5 bit mode" is 
this: if you're writing a literal 0 offset, you know for sure what the 
offset is so you could just as easily write ",x" instead of "0,x".

As you noted, the actual outcome is not affected. The resulting code is 
still operationally correct and the same size. Only the cycle count 
changes with 5 bit offsets being 1 cycle slower.


On 2015-09-01 13:16, Dave Philipsen wrote:
> Well, in my comparison of the code generated by the lwtools assembler
> and the stock OS9 assembler I have found a quirk of the lwtools
> assembler.  I won't call it an error because it appears that the outcome
> is not affected and it seems to be a minor thing.  On every other
> assembler I've used including AS6809, CSC6809, and the stock OS9
> assembler the following assembly source:
>
> ldb  ,x
>   or
> ldb 0,x
>
> is assembled in machine code as:
>
> E6 84
>
> which is the indexed addressing mode with no offset
> However, the lwtools assembler (evidently) assembles in machine code as:
>
> E6 00
>
> which is the indexed addressing mode with a 5-bit offset with the offset
> being zero.
>
> I dont have a copy of EDTASM anymore so I can't say how it would
> assemble it.  This just seems to be the case of a smart assembler which
> determines the given offset to be zero and thus translates it as a "no
> offset" postbyte as opposed to a "5-bit offset" postbyte.
>
> Dave Philipsen
>
>



More information about the Coco mailing list