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!"