bug in 4.2 \"as\"

[FIRTH at TL-20B.ARPA]

We have found several bugs in the way our 4.2 "as" handles displacements.

(1) In code such as this:

	.text
    lab:
	.word 0
	movw lab,r0

    a longword pc-relative displacement is generated for the operand "lab",
    even though byte displacement is evidently enough, and even though the
    documentation claims the assembler will select the correct displacement

    No fix found yet.

(2) Code such as this

	movw B`lab,r0

    is rejected with a syntax error.  The reason is that the parser believes
    that, if you specify a displacement, you must inevitably go on to specify
    an explicit register, eg "B`lab(r1)"

    To fix this:

    file asparse.c, routine yyparse()
    after label overdisp:

    	if (val == LP || sawsize) {

    change to

	if (val == LP) {

(3) Code such as this

	movw B`(lab-.)(pc)

    is rejected with "relocation error", even though the documentation says
    it is legal to subtract two relocatable symbols with the same base

    No fix yet

(4) Explicit displacements are ignored, even when you can set them, so

	W`symb(r1)

    assembles a longword displacement if the Symb is not yet known.

    To fix this, in file asscan2.c, routine scan_dot_s()

    4 lines after case ALPH:

	ch |= 0100;    /*convert to lower*/

    change the constant or'd into ch to be 040.  You might also want to
    put an error check in that part of the code!

(5) Even after fix (4), explicit displacements will be ignored if they
    are larger than necessary, eg

	W`4(r1)

    assembles with a byte displacement (again, contrary to the documentation)

    No fix yet.

(6) The assembler refuses to let you specify "short literal" (S^) mode.
    However, in a case such as this

	movl $b-a,r0

    it will assume a full 32-bit immediate literal on pass1.  If it happens
    that "b-a" is less than 64, eg because they are both relocatable and a
    small distance apart, a subsequent pass will try to make the operand a
    short literal, and everything else dies of phase error

    No fix yet.

If others have found fixes, I'd be grateful if you could mail them to me
direct

Robert Firth
-------