Yes. One of the most important goals of the UltraSPARC project
was full binary compatibility with existing SPARC
hardware and software.
If it isn't compatible, it's a bug!
There are some things you should keep in mind though: if you
broke the rules but got away with it in the previous generations
of SPARC machines, your luck may just have run out.
When developing the UltraSPARC it was discovered that some code
generators didn't leave all "reserved" bits in opcodes zero.
Such instructions are either illegal instructions which are trapped
and fixed in the UltraSPARC kernel or they are legal V9
instructions which will modify the program behaviour. All such
programs can be run through "cleanv8", a program designed
to correct the bogus instructions.
No instructions of the second category have been found, so even without
"cleanv8" you should be safe.
Another thing is the memory map on UltraSPARC, some applications
use an mmap(MAP_FIXED) call with an address that is illegal to use
on UltraSPARC. Such calls are inherently non-portable. Such
applications are relatively rare. One such applications is MAE,
which should work again after "setenv MAE_NOMMAP_ENGINE".
A third problem discovered is in device drivers that copy data
from/to userland directly, bypassing copyin(9f)/copyout(9f). On V8
SPARCs, such device drivers would work most of the time, but fail
mysteriously with panics when the system is stressed and page
mappings disappear; but on the UltraSPARC the drivers will fail
always. The kernel will panic and will tell you in which
module the panic occurred.
Starting with Solaris 2.6, the Solaris device drivers must be MT-Safe.
Starting with Solaris 7, device drivers must come in a 64 bit variant.
Systems only supported on Solaris 8 and later will not boot a 32 bit