This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] MIPS: Enable tlbinv and tlbinvf instructions for microMIPS; and mips32r3 and above
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Andrew Bennett <Andrew dot Bennett at imgtec dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>, "rdsandiford at googlemail dot com" <rdsandiford at googlemail dot com>, Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Date: Fri, 20 Nov 2015 14:12:58 +0000
- Subject: Re: [PATCH] MIPS: Enable tlbinv and tlbinvf instructions for microMIPS; and mips32r3 and above
- Authentication-results: sourceware.org; auth=none
- References: <0DA23CC379F5F945ACB41CF394B9827721126E79 at LEMAIL01 dot le dot imgtec dot org>
On Fri, 25 Sep 2015, Andrew Bennett wrote:
> Currently the tlbinv and tlbinvf instructions are only enabled if the user
> enables the EVA ASE. There are two issues with this. Firstly these
> instructions are now in the Virtualization, not the EVA ASE (please see:
> http://imgtec.com/mips/architectures/virtualization/). Secondly they can
> be optionally supported in MIPS ISA mips32r3 and above (in mips32r6 they
> are supported by default). This patch addresses these issues by:
>
> 1. Enabling the tlbinv and tlbinvf instructions by default for microMIPS
> (because microMIPS is also mips32r3).
>
> 2. Enabling the tlbinv and tlbinvf instructions for MIPS when the ISA
> is mips32r3 and above, or if the user enabled the EVA or Virtualization
> ASEs.
FWIW I think this approach is dangerous. The rationale behind ISA/ASE
options is to safety-guard code produced against hardware capabilities.
If I specify, say, `-march=mips32r3' (rather than e.g. `-march=cpu-foo'),
then I want to be sure that code produced will run on any MIPS32r3
processor. And if a feature is optional, then undoubtedly there will be
cases where a piece of hardware is missing it. I want to be made aware of
it at the build time rather than at the run time two years on when a piece
of binary fails.
So given my understanding of the availability of these instructions the
following arrangements seem viable to me:
1. `-march=mips32r2' or lower: no way to enable these instructions other
than via a temporary `.set' override in source code,
2. `-march=mips32r3' to `-march=mips32r5': these instructions are disabled
by default and can be enabled with `-meva', `-mvirt' or `-mtlbinv',
3. `-march=mips32r6' or higher: these instructions are unconditionally
enabled.
Of course any individual processor specified with `-march=' instead can
enable or disable these instructions based on its implementation.
Maciej