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.
PREV INDEX NEXT