[Coco] is this a bug?

[Dave Philipsen]

Actually, the Microware assembler included with OS9 should (and in most 
cases does) work for assembling non-native (non-OS9) code. That's why 
they provided the OPT directive with the "M" option.  The JMP 
instruction will assemble correctly assemble in all of its documented 
addressing modes.  And, in fact, you could use JMP with the indexed 
addressing mode under OS9.  JMP    label,pcr   does basically the same 
thing as LBRA  label and does not even cause a warning.  I can't think 
of many reasons you'd want to though.

As far as using 'org', I'm doing it in a non-OS9 environment so it works 
the way it was originally intended.  The OPT  M directive turns on the 
Motorola mode (non OS9).  Granted, because the Microware assembler was 
focused primarily on OS9 it is probably not the best pick for assembling 
non-OS9 programs.  But I am attempting to do my development from within 
the OS9 environment and that's all I've got at this moment.  However, I 
hope to compile the CSC assembler under OS9 soon so that would give me 
an assembler that is a little more comfortable with such code as well as 
the ability to output Motorola S record files.


Dave


On 4/20/2017 12:50 AM, Bill Pierce via Coco wrote:
> Dave, in assembling a bootloader, you may be better off using edtasm or any rsdos assembler. The bootloader is run from rsdos (or autoloaded or rom) and doesn't need the os9 assembler... anything from that point on will. The os9 assembler can only use jmp as in "jmp [label]". Also, you can't specify "org" as that applies differently in os9 assembly since it's PIC. Org becomes a offset for data from DP or the Global data area...
>
>   org $80
> lab1 rmb 2 [$80]
> lab2 rmb 1 [$82]
> lab3 rmb 3 [$83]
> lab4 rmb 2 [$85]
> etc
>
>
>   
>
>   
>
>
> Bill Pierce
> "Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull
>
>
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
>
>
> E-Mail: ooogalapasooo at aol.com
>
>
>   
>
>   
>
> -----Original Message-----
> From: Dave Philipsen <dave at davebiz.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Thu, Apr 20, 2017 12:59 am
> Subject: Re: [Coco] is this a bug?
>
>> On Apr 19, 2017, at 9:45 PM, Robert Gault <robert.gault at att.net> wrote:> > > A phasing error normally means that the location of code changed during the first and second passes of the assembler. Typically this happens with forward addressing when the assembler can't decide whether long or short branches or direct or extended addressing is needed.> > However, in your example there is another problem. :) Remove the opt M and try assembling this small amount of code. I think you will find that it compiles without any errors.> Now with the opt M present, remove the org $2000 and it will compile without error.> > Opt M turns on Motorola-compatible mode which is the default state and not needed. It should not confuse the address counter during assembly.Ok, well actually I believe OPT -M is the default behavior for assembling OS9 program.  And, normally, one would not use ORG.  However, I am assembling a program for an OS9 bootloader which will reside at a specific location in memory so ORG is needed.> > So there is probably is a bug in ASM. Your code generates extended addressing for Entry. Without the opt instruction, the code becomes $E $06, direct addressing. If you reverse the first two lines> org $2000> opt M> you get more phasing errors. None of this should happen.> > The only way to get this code to compile with direct addressing while including the opt M is as follows> opt M> org $2000> start jmp <entry> fcc /TEST/> entry nop> end> > Clearly it should not be necessary to include the <. An assembler should optimize code on its own.> Yes, I believe you are right. The OS9 assembler has a SETDP directive that could be used to force direct/extended addressing in some cases but it doesn't seem to work either.  So I guess if someone is keeping track of these sorts of things for the NitrOS9 repository it could be noted as a bug.  Don't know if anyone would ever get around to correcting it though.  This is the first time I have used the assembler to generate a non-OS9 object file so I'd never noticed the behavior befo
> re.  Fortunately I can just force the extended addressing for now.Dave> Robert> > > -- > Coco mailing list> Coco at maltedmedia.com> https://pairlist5.pair.net/mailman/listinfo/coco-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco
>