Not to mention the fact that SPARCs, even under a common OS, are great for finding bugs that just don't happen on i386. Notably, the C standard only allows casting properly-aligned memory (e.g. typically, a chunk of memory with an address that is a multiple of four can be interpreted as a 32-bit integer, but this may not work for "unaligned" memory) - SPARCs will terminate your process with SIGBUS if you try this, whereas i386/amd64 machines will (slowly) perform the requested operation.
There are more differences, many related to multiple CPUs (SPARCs are not "cache-coherent".)
You can actually request that x86 machines trap on unaligned accesses too, by setting the AC flag in EFLAGS (pushf; orl $(1<<18), (%esp); popf). Unfortunately, it's common for the C standard library implementation to rely on aligned accesses on x86, so this isn't really feasible.
Comments
Not to mention the fact that SPARCs, even under a common OS, are great for finding bugs that just don't happen on i386. Notably, the C standard only allows casting properly-aligned memory (e.g. typically, a chunk of memory with an address that is a multiple of four can be interpreted as a 32-bit integer, but this may not work for "unaligned" memory) - SPARCs will terminate your process with SIGBUS if you try this, whereas i386/amd64 machines will (slowly) perform the requested operation.
There are more differences, many related to multiple CPUs (SPARCs are not "cache-coherent".)
You can actually request that x86 machines trap on unaligned accesses too, by setting the AC flag in EFLAGS (pushf; orl $(1<<18), (%esp); popf). Unfortunately, it's common for the C standard library implementation to rely on aligned accesses on x86, so this isn't really feasible.