Of course that anyone is free to disagree for any reason, but after having written assembly for about 10 architectures, including several compilers, I definitely prefer SPARC to anything else. The current SPARC V9 ISA spec is about 1/10 of the arm64 ISA (I wrote compilers for both). The instruction encoding is so simple I can assemble in my head.
There are some spectacularly annoying things like the stack bias, but those are easy to hide in the assembler (and those are problems with the System V ABI, not SPARC, embedded ABIs ignore them).
Can you elaborate on “stack bias”?
What are your thoughts about register windows?
I am open mindedly curious as to why you prefer that assembly?
Also, what SPARC hardware are you running?
On SPARC V9 the stack and frame pointers don't point to the top of stack, they point 2047 bytes (0x7ff) away from it. SPARC has 13-bit signed immediates, and much of that range would be wasted if the stack and frame pointers pointed to the top of the stack. Having a stack bias allows more of the immediate range to be utilized at the cost of the assembly (and runtimes) having to keep track of the stack bias.
The offset is chosen odd as to trivially identify 64-bit code in things like register window overflow trap handlers[2].
When I say I prefer some assembly vs. some other assembly, I speak from the perspective of a kernel/compiler writer. Realistically you will never use assembly to write general purpose code. You either target it from a compiler (in which case it better be easier to target), or write some specialized runtime/driver code, in which case it would better have easy to understand semantics and behavior. If you were to write general purpose code in assembly, say write assembly instead of C, an orthogonal CISC architecture would be way easier to write code for. But nobody does that anymore. People only use assembly when they have to (or target it from a compiler) and for that particular case the features of the ISA that matter most are quite different than what a general purpose programmer would want.
SPARC really excels for me because of how easy it is to target and how easy it is for me understand when I am writing runtime code.
I have various SPARC hardware, the most interesting (and the one eventually used for the Go port) being a single-digit serial number S7-2 system[3]
I grew up around cracking and the software piracy scene on the Commodore64 and Amiga so I write UltraSPARC assembler for fun (and profit, since I've always been able to utilize my knowledge and insights when landing job gigs). Does pouet.net tell you anything?
50% of servers in my basement data center are SPARC based.
> If you do a serious degree-level computer architecture class, it'll probably involve MIPS, mainly so that your professor can set some really tough exam questions about the pipeline.
Ha, I remember suffering through this. MIPS has a relatively pretty instruction set but it’s just such a pain to write by hand and the arbitrary choice of forcing delays and pipeline stalls on developers in the way that it did was just really disappointing…
Leon is a 32-bit, SPARC V8 ISA implementation. It's also one of the rare radiation-hardened designs (for use in space equipment where cosmic radiation has a significant influence on correctness of operation).
An OpenSPARC T2 is a SPARC V9b+VIS ISA. All UltraSPARC processors with a SPARC V9 ISA are 64-bit.
Having written the SPARC64 compiler and runtime for Go (and the Solaris port), I assure you I know the difference between SPARC V8 and SPARC V9.
It appears that I have been mislead, back in 2005 when OpenSPARC was released somebody from Sun told me that LEON is based on OpenSPARC, and I haven't bothered to check since. It seems to be a completely different design (it even uses VHDL instead of Verilog). So I was very mistaken about LEON.
However, there have been other (embedded) SPARC V8 CPUs derived from OpenSPARC. I have worked on one myself (on the software side). This one was a very strange one because it only had two register windows (and the ABI didn't use register windows) and they disabled SMT.
This type of modification is extremely easy to do on SPARC because of the way 64-bit works. There are no separate execution modes, there's simply another set of flags that's affected by instructions. The conditional instructions chose which set of flags to use.
I really like SPARC, it's my favorite architecture.
How about synthesizing the GPL-licensed OpenSPARC T2 now?
https://www.oracle.com/technetwork/systems/opensparc/openspa...
I'd love to have SmartOS backported on a FPGA-based, OpenSPARC T2, 19" 1U rack mountable server someday. Free hardware and software all the way.