My intention to revive "sparc" is because it uses the V8 instruction
set as opposed to the V9 instruction set used by "sparc64". V8
supports more software (e.g., _javascript_ JIT is not supported on
V9) and more older hardware.
Commonly accessible C8 CPUs are MicroSPARC, SuperSPARC and HyperSPARC (of course there's a zillion other implementations like LEON, but those are not 'commonly' available). That's 20 years old 32 bits hardware. I love them (currently trying to rebuild some recent software on Solaris 7 and 8 in v7 and v8 on my SS20s :-), but do you really think a recent Linux would work (let alone "work well") on those? Even NetBSD has trouble on such old hardware.
Also, a *lot* of software wants multithreading nowadays, and will require some form of synchronization (including ICU for Unicode, and other unlikely places). V8 doesn't have Compare-And-Swap, only Swap and Test-And-Set, like v7. It's possible to emulate CAS, but it requires an extra memory byte for the lock, which is non-trivial to do properly in the multi-process case (inefficient multi-thread is trivial). GCC doesn't supply such emulation, so lots of software will fail because symbols like __sync_fetch_and_add_4 are missing (C++11 atomic uses those nowaadays).
Don't take me wrong - I would *love* to be able to update my SS5-110MHz running Debian 4 to a newer Debian. I'm just not sure whether it's worth the hassle compared to say, trying to improve NetBSD or OpenBSD...