I have few benchmark application complied for SPARC V8 32-bit architecture. I used them for performance evaluation of SPARC 32-bit processor. However, few application fall short of in performance. I want to test the performance with a 64-bit SPARC V9 architecture ( like OpenSPARC T1/T2). My question is will the compiled binaries for the 32-bit SPARC V8 architecture run in SPARC V9 architecture without any modifications? Are the binaries in both architectures compatible?
问题:
回答1:
Presuming that you are using the same Operating System though perhaps at a newer version. Then yes. Solaris Sparc is very binary backward compatible. Each revision of the Sparc architecture was designed with this in mind.
Things you should keep in mind:
- Sparc v7 is the lowest common denominator however in practice Sparc v8 wil cover 99% of machines.
- Sparc v7 lacks hardware floating point so it will be slower in most all cases
- Sparcv8 code will be faster in some cases than Sparcv9 64bit code due to half the instruction load overhead.
- the optimal code for a Sparc v9 is most often Sparc v8+ which is basically 32bit code with some extensions that for the most part only 64bit machines have. Due to this most all 64bit Sparc Operating Systems ship most code as 32bit with some 64bit code where it needs access to more ram or 64bit only extensions for performance such as with software based encryption.
- While the ISA for Sparc is quite static performance is not.. for instance Sparc T1 Niagra CPUs are dog slow for any single threaded task but run like champs when you load them with many tasks . However some of the Fujitsu Sparc chips probably rival Intel for speed in every area. Also I wouldn't be the least bit supprised if some of the older Ultra workstations were alot faster than Niagra T1/T2 for single to a couple threads. Once you get into the area of many threads a Niagra style CPU will start to shine.
So remember Sparc v7 , Sparc v8 and Sparc v9 are not chip architectures they are Instruction Set Architectures. The performance for Sparc is mainly dependent on the implementation of the CPU Architecture. Thew newest Sparc processors from Oracle are improving single threaded performance much more than in the past something to keep in mind as well (even if they would burn a hole in your wallet the size of Texas).
If your performance is falling short and you are designing a FPGA based CPU seriously consider improving your CPU design to increase throughput.
回答2:
Terminology confusion ...
SPARC is a little bit like ARM. You have:
- the SPARC chip architectures (as far as they were developed by Sun Microsystems / now Oracle) are named
sun4[a-z]
; actual tapeout only forsun4
,sun4c
,sun4d
,sun4m
,sun4u
andsun4v
This corresponds toARM[1-9]
,ARM11
,Cortex-...
, i.e. evolution of the CPU design. - SPARC CPU instruction sets are 'versioned' -
sparcv7
,sparcv8
/sparcv8+
,sparcv9
; some of these are 32bit,sparcv9
is 64bit
This corresponds toARMv[0-9]
, revs on the instruction set. - operating modes (32bit / 64bit on SPARC);
ARM here has Thumb[2], 32bit ARM and ARMv8/64bit.
In this context, sparcv9
is the 64bit instruction set and therefore requires the 64bit operating mode; the same binary encoding might have different meanings in 32bit/64bit modes and therefore sparcv7/8
code will not run in 64bit mode.
Still, sun4u
and sun4v
CPU architectures support the 32bit mode - with a sparcv8+
instruction set plus a few extensions, and sparcv8
in itself being a superset of sparcv7
.
Sun/Oracle pride themselves of their binary backwards compatibility; all current SPARC CPUs should run existing 32bit binary code without problems. I assume, in this context, that you're talking about Solaris binaries ?