Add sparcv9 support to lib/Basic/Targets.cpp

Jakob Stoklund Olesen stoklund at 2pi.dk
Tue Apr 16 08:35:14 PDT 2013


On Apr 16, 2013, at 5:03 AM, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:

> On 16 April 2013 00:59, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>> Hi,
>> 
>> Please review this patch which adds SPARC v9 support to Targets.cpp.
>> 
>> Triple::sparcv9 is the 64-bit counterpart to Triple::sparc. The architectures are very similar, so they share most of the TargetInfo implementation. I included operating systems with known sparcv9 ports in AllocateTarget().
>> 
>> This also fixes two issues with the existing 32-bit sparc data layout string: It was accidentally marked as little endian, and there was no stack alignment. A 64-bit aligned stack is required by the SPARC v8 System V ABI.
> 
> Does the v9 also have a 32 bit mode like the x86_64 cpus do? If so,
> wouldn't it be better to call this sparc64 and the v8 x v9 distinction
> is then more like the SSE x no-SSE in x86 cpus?

It's complicated ;-)

The SPARC v9 architecture was published in 1994. It adds new instructions, doubles the number of floating point registers, and extends the integer registers to 64 bits. It's all backwards compatible, so v8 code runs unaltered. A v9 cpu can run both 64-bit and 32-bit code. It barely cares which it is running, except for a mode bit which tells it to truncate load/store addresses. 32-bit code running on a v9 cpu can use the new instructions and floating point registers. It can't depend on the high bits of its integer registers being preserved across function calls (or by asynchronous signal handlers, I think).

Sun released their UltraSPARC cpu in 1995 with v9 support, and almost every SPARC cpu released since then has had v9 support. It is probably pretty hard to find v8 hardware in use today.

Fujitsu is using the SPARC64 brand name for their line of 64-bit cpus. The first SPARC64 was also released in 1995; they're up to SPARC64 X by now.

I think Fujitsu owns the SPARC64 trademark, and that is probably why Solaris is using 'sparcv9' everywhere to refer to 64-bit code. Disinterested parties like NetBSD/OpenBSD/FreeBSD have 'sparc64' ports.

Anyhow, GCC seems to accept sparcv9/sparc64 as synonyms. Your sys/elf.h header has EM_SPARC and EM_SPARCV9 definitions.

The sparcv9 support was added to the Triple class a while ago, and I think there was some discussion about the name then. I didn't want to change it with this patch which I think is orthogonal.

> LGTM with or without the name change, just explain it in the commit
> message or a comment.

Thanks, r179596.

I think comments about the chosen names belong in the Triple class, so I didn't add any here.

/jakob





More information about the cfe-commits mailing list