Being able to fix bugs like this is one of the reasons we like open
source so much.
I took a look at a copy of the gas source I have online. Thankfully,
the pdp-11 assembly parser is not embedded within nor totally
intertwined with the monstrosity (my opinion; obviously others don't see
it that way) known as "bfd".
If I'm not mistaken, the bug is within binutils/gas/config/pdp11.c . The
routine parse_op_noreg () in that file contains:
if (*str == '@' || *str == '*')
{
str = parse_op_no_deferred (str + 1, operand);
if (operand->error)
return str;
operand->code |= 010;
}
and the routineparse_op_no_deferred() is little more than a large,
complex switch on the next (non-whitespace) char, the first case of
which assumes that if the char is '(', then the mode must be either (rn)
or(rn)+.
It seems that operand->code is being set "wrong", as (at least for
MACRO-11 compatibility) the code above should have the call to
parse_op_no_deferred() set that field to (registerno | (6 << 3)) for a
mode 7 operand, after which the "|= 010" would change it to mode 7. But
within parse_op_no_deferred()*,***as the '@' before "(ER)" was already
eaten before the routine was called, you get mode 1, not mode 6 (again
without being able to consider the '@' within this routine).
Perhaps a fix could involve setting the 010 (octal) bit before (rather
than after) the call to parse_op_no_deferred(), and when it gets in
there, it could use that as a flag saying that finding a '(' will lead
to the mode 6 code path (not the mode 1 code path), resulting in mode 7
(because of the '@')), & the setting of operand->word to 0.
- michael
P.S. Apologies if I've totally missed the boat. it's late and i'm
ghetting punchy....
On 08/21/2012 05:48 PM, Larry Baker wrote:
On 17 Aug 2012, at 9:00 AM, [email protected]
<mailto:[email protected]> wrote:
Well, using the DEC notation for PDP-11 assembler language, @(R0) and
(R0) are indeed two different things, and you seem to have understood it
perfectly right.
Not sure if gas might have its own ideas about notation though...
See the NOTE at the bottom of page 5-5 in Section 5.8, INDEX DEFERRED
MODE, in the PDP-11 MACRO-11 Language Reference Manual on the
BitSavers web site
(http://www.bitsavers.org/pdf/dec/pdp11/rsx11/RSX11M_V4.1_Apr83/4_ProgramDevelopment/AA-V027A-TC_macro11_Mar83.pdf):
The expression @(ER) may be used, but it
will be assembled as if it were written
@0(ER), and a word will be used to store
the 0.
GAS has got it wrong. There really is no addressing mode of the form
@(ER). GAS should either follow MACRO-11 and convert @(ER) to @0(ER),
or it should give an error. It should not convert @(ER) to @ER, which
is equivalent to (ER). That is, it should not be silently eliminating
the @ deferred address operator from the operand.
Larry Baker
US Geological Survey
650-329-5608
[email protected] <mailto:[email protected]>
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
