On Mon, Oct 24, 2016 at 11:54:27AM +0200, Eric Botcazou wrote:
> > mcrxr does not exist anymore. It is not implemented in any IBM non-embedded
> > CPU since POWER4. PA6T does not have it either. In some versions of the
> > 2.0x ISA it does exist, but only in the optional "embedded" category.
>
> Yes, it exists in all (public) versions of the unified 2.0x ISA.
But not in the "Base" category. GCC should not generate mcrxr unless some
flag enabling the "Embedded" category is set (this can of course be set
via -mcpu=), or we have ISA 1.xx . It is probably nicer if we treat
mcrxr separately, with an -mmcrxr flag, with TARGET_MCRXR.
It is "phased out" in 2.02, btw; I cannot find earlier versions right now.
2.02 says:
Warning: This instruction has been phased out of
the architecture. Attempting to execute this instruc-
tion will cause the system illegal instruction error
handler to be invoked.
<http://www.ibm.com/developerworks/systems/library/es-archguide-v2.html>
> > Linux emulates mcrxr, but that is very slow. You could use mfxer, but
> > that is a slow instruction as well (it is microcoded).
>
> So there is no efficient way of accessing the OV flag in recent non-embedded
> CPUs (except for the new mcrxrx instruction in the 3.0 version)?
You can use SO instead, but then you have to make sure it is clear before
you run the OE=1 instruction. SO of course is the cheapest way to access
overflow (it is copied to the CR field on any compare or recording insn).
And yeah something like mcrxrx should have existed long ago :-(
> > That may work better. It also may be better if you expose the OV bit
> > as a separate reg (just like we have CA), instead of putting two machine
> > insns in each template.
>
> Yes, although CA can be seen as behaving like a register to some extent, but
> OV far less so IMO.
How so? It behaves exactly like CA, i.e. exactly like a register (it _is_
a register!)
Segher
