This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Patch] [MIPS] Change opcode membership for the ssnop and ehb instructions
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Catherine Moore <clm at codesourcery dot com>, binutils at sourceware dot org
- Date: Tue, 25 May 2010 03:08:13 +0100 (BST)
- Subject: Re: [Patch] [MIPS] Change opcode membership for the ssnop and ehb instructions
- References: <4BF578C0.80803@codesourcery.com> <87typy9tpr.fsf@firetop.home>
On Sun, 23 May 2010, Richard Sandiford wrote:
> > This patch changes the opcode membership for the ssnop instruction to
> > I1 from I32 | N55. It also changes the opcode membership of the ehb
> > instruction to I32 from I33. For those ASE's which don't support ehb
> > and/or ssnop, the instruction executes as a nop. This change make the
> > disassembly read more cleanly. Does this look okay to install?
>
> I'm not convinced this is a good idea. Do we really want:
>
> .set mips32
> ehb
>
> to be acceptable?
Well, EHB is an assembly idiom for "SLL $0, $0, 3" and likewise SSNOP for
"SLL $0, $0, 1". Both instructions were chosen deliberately to execute
correctly back to the MIPS I ISA. I see no harm with assembling them and,
more importantly, they are much more readable in `objdump' or GDB where
you don't have the luxury of a per-instruction ISA annotation.
With an example hazard-clearing sequence like this:
ssnop; ssnop; ehb
(EHB executes as SSNOP on pre-MIPS-r2 processors) I see no gain with
interspersing this code with .set directives (or even wrapping it all).
What's the cause of your concern?
Maciej