jmsynge@sqm.dec.com (James M Synge, DTN 381-1545) (05/04/87)
I've found a bug in the Manx 3.4a assembler which those who write their own assembly code might be interested in. The -N option (disable certain code optimizations) causes the wrong op codes to be generated for at least the JSR and JMP instructions when you are using the far code, far data model. It is generating PC relative op codes, but allowing space for the Abs.L (absolute long) addressing mode. I.E. there is a word in the instruction stream that shouldn't be there. The 4EBA and 4EFA which I've marked as WRONG in the following assembler output listings (striped to the essentials) are PC relative (thats what the A means) and they should be 4EB9 and 4EF9. AS -LN BUG.ASM Aztec 68000 Assembler 3.4a 2-3-87 1 0000: public _SomeWhereElse 2 0000: public _Here 3 0000: 4 0000: _Here: 5 0000: 4eba xxxx jsr _SomeWhereElse 6 0004: 4efa xxxx jmp _SomeWhereElse AS -CDLN BUG.ASM Aztec 68000 Assembler 3.4a 2-3-87 5 0000: 4eba xxxx xxxx jsr _SomeWhereElse <<< WRONG 6 0006: 4efa xxxx xxxx jmp _SomeWhereElse <<< WRONG AS -L Aztec 68000 Assembler 3.4a 2-3-87 5 0000: 4eba xxxx jsr _SomeWhereElse 6 0004: 4efa xxxx jmp _SomeWhereElse AS -CDL BUG.ASM Aztec 68000 Assembler 3.4a 2-3-87 5 0000: 4eb9 xxxx xxxx jsr _SomeWhereElse 6 0006: 4ef9 xxxx xxxx jmp _SomeWhereElse Summary: Don't use the assemblers -N option until this is fixed. (This posting is also being sent to well!manx in the hopes of getting to the man!) I was using it becuase I didn't want ANYBODY messing with my code (I put in enough bugs myself, thank you very much :^). James Synge USENET: {decvax, ucbvax, allegra}!decwrl!sqm.dec.com!jmsynge ARPAnet: jmsynge%sqm.DEC@decwrl.DEC.COM #include <disclaimer.h> "Ken Olsen can speak for Digital, not me!"