This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] A few ppc assembler fixes
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "Peter Bergner" <bergner at vnet dot ibm dot com>
- Cc: "Hal Finkel" <hfinkel at anl dot gov>,"Alan Modra" <amodra at gmail dot com>, "BillSchmidt" <wschmidt at linux dot vnet dot ibm dot com>, "Binutils" <binutils at sourceware dot org>
- Date: Thu, 23 Apr 2015 14:01:59 +0100
- Subject: Re: [PATCH] A few ppc assembler fixes
- Authentication-results: sourceware.org; auth=none
- References: <1429746727 dot 21947 dot 60 dot camel at otta> <5538B04A0200007800074F57 at mail dot emea dot novell dot com> <1429791153 dot 21947 dot 81 dot camel at otta>
>>> On 23.04.15 at 14:12, <bergner@vnet.ibm.com> wrote:
> On Thu, 2015-04-23 at 07:41 +0100, Jan Beulich wrote:
>> Hmm, should assembling of instructions really be tied to specific
>> implementations rather than to ISA version? Or, shouldn't there
>> be an option to allow ISA-compliant code to assemble even if
>> there is no implementation of these insns (in which case I'd
>> assume the POWER<n> to represent such, whereas things like
>> E500MC might indeed represent specific implementations)?
>
> How would that solve this issue, since both operand orderings
> are ISA complaint? If it were as easy as is the insn listed
> in the ISA, then accept it, I'd be for it, but with server
> vs embedded and lots of "optional" categories, I'm not sure
> the code would be any cleaner. ...and it would take a complete
> rewrite of this code to move to an ISA versus cpu enablement
> format.
Oh, this wasn't about the operand ordering part, but the part
removing or altering the POWER<n> attribute on some insns.
Jan