This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/9] binutils,gas,opcodes.elf: remove never used SPARC features and upgrade hwcaps.


From: jose.marchesi@oracle.com (Jose E. Marchesi)
Date: Sun, 05 Oct 2014 14:36:38 +0200

>     
>     > This patch removes support from GNU binutils for the following SPARC
>     > features, which were never released to the public or implemented:
>     > 
>     > - The transactional memory instructions of the cancelled Rock
>     >   processor (UltraSPARC-AT10): CHKPT and COMMIT.
>     > 
>     > - The %cps ancillary state register, also introduced in the
>     >   UltraSPARC-AT10, along with the associated rd/wr instructions.
>     > 
>     > - The RANDOM instruction.
>     
>     These hw capability ELF flags are encoded into binaries and you
>     therefore cannot just repurpose them however you like.  You will
>     therefore have to allocate new capability flag values for these
>     features.
> 
> I agree in that it is funny to redefine bits like that in a public
> interface, but allocating other bits for the JF* caps would imply to
> diverge from Solaris.  Is that what you want?

The problem is that if readelf sees the bits set in the binary (and
I know for a fact there are binaries out there with them set) it will
report the wrong value.

So yes that means we must not repeat what Solaris's has done.

>     Furthermore, even though full transactional memory support never got
>     into a publicly released processor, recent chips do implement the %cps
>     register and implement the chkpt instruction as an unconditional
>     branch.
> 
> Huh, which recent chips?.  Every of the following specs document
> %asr28 as reserved, and %cps is not mentioned at all:

My bad, I misremembered this one.

> Likewise, to my knowledge the chkpt instruction is not documented on any
> of the Sun, Oracle or Fujitsu published specs.

It's a specially coded branch, which older chips interpret as a branch
always.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]