This is the mail archive of the
mailing list for the binutils project.
Re: [PATCHv2 2/2] gas/opcodes: Add initial arc nps400 support
- From: Andrew Burgess <andrew dot burgess at embecosm dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: binutils at sourceware dot org, noamca at mellanox dot com, Claudiu dot Zissulescu at synopsys dot com, Cupertino dot Miranda at synopsys dot com
- Date: Tue, 15 Mar 2016 13:49:57 +0000
- Subject: Re: [PATCHv2 2/2] gas/opcodes: Add initial arc nps400 support
- Authentication-results: sourceware.org; auth=none
- References: <cover dot 1456947552 dot git dot andrew dot burgess at embecosm dot com> <14db4e9931234715abf1fdb281a4d99f54b44852 dot 1456947552 dot git dot andrew dot burgess at embecosm dot com> <mvmzitzho8i dot fsf at hawking dot suse dot de>
* Andreas Schwab <firstname.lastname@example.org> [2016-03-15 14:20:13 +0100]:
> Andrew Burgess <email@example.com> writes:
> > When binutils is configured for NPS400, by specifying 'mellanox' as the
> > vendor name in the target tuple, then the additional NPS400 instructions
> The vendor name should never be used for target selection.
Thanks for taking the time to provide feedback on this patch.
Do you think you could expand on the above sentence please. I think
this is probably the same issue that Nick is referring to in a
different mail, but it is not clear.
What precisely do you mean by "target selection", the target, as I
understood it, was the string that included the vendor name. Do you
mean that the vendor name should never be used to modify the behaviour
of the program being configured?
A follow on to the above then, and please forgive me if this seems
obvious, what is the vendor name for? Why have it in the target
triplet if it can't modify program behaviour?
And finally, what would your recommended route forward be? Is it to
create a new cpu type, and just to share the configuration routine
with arc? And update all arc specific tests to also apply to the new
Again, thanks taking the time to provide this feedback.