[Simh] PDP-11 GCC cross-assembler... possible bug... or is just me?

[Michael Bloom]

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, simh-request at trailing-edge.com 
> <mailto:simh-request at trailing-edge.com> 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
> baker at usgs.gov <mailto:baker at usgs.gov>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20120823/afab89f9/attachment-0002.html>