Table of Contents for Programming Languages: a survey

SPARC

Included because listed on:

http://alanclements.org/processors.html

and b/c it's an official Debian port

"As of 2008, Itanium was the fourth-most deployed microprocessor architecture for enterprise-class systems, behind x86-64, Power Architecture, and SPARC." -- https://en.wikipedia.org/wiki/Itanium#cite_ref-ITJungle_1-0

"Both SPARC and MIPS share another horrid feature - delayed branches. These create a dependency between instructions, in which the branch takes effect after the next instruction, rather than immediately. When using assembly code, you have to know which instructions have a delayed effect, and what rules apply to the instruction (or, sometimes, instructions) in the "delay slot" following it. The delay slot is restricted in various ways: for instance, you can't put another delayed branch there....SPARC also has a crazy feature all of its own, the "rotating register file", which makes code incredibly hard to understand because it's very hard to follow the movement of data across function calls. On SPARC, the registers are not numbered r0 to r31, they're assigned other names like o1 and g1, and some are remapped at call/return. This legacy feature makes some big assumptions about the typical number of registers that need to be preserved across a call, and forces the programmer to remember which registers get remapped and how they are remapped. " [1]

"On PowerPC?, as on SPARC and MIPS, the mechanism for storing 32-bit immediates can only encode a 32-bit value by splitting it across two instructions: a "load high" followed by an "add". This is a pain. Sometimes the two instructions containing the value are some distance apart. Often you have to decode the address by hand, because the disassembler can't automatically recognise that it is an address. " [2]

Opinions

• "Register windows turned out to be a bad idea..." -- [3]
• "In spite of the "S" in "SPARC", it does not actually scale down super well." [4]
• "The only truly bad design choices I can come up with is integrating flags into the program counter (which they got rid of) and making the Jazelle state part of the base ISA (which you can stub out). Everything else seems more or less okay." -- FUZxxl
• "Actually, the whole manner in which pc is a general purpose register is definitely closer to a cute idea than a good one. uqadd8 pc, r0, r1 anyone?" -- TNorthover
• "In the original ARM design this made a lot of sense since it removed the need for indirect jump instructions and allowed for the flags to be accessed without special instructions. Made the CPU design a lot simpler. Also, returning from a function becomes a simple pop {pc}. Yes, in times of out-of-order architectures it's certainly a good idea to avoid this, but it's a fine design choice for pipelines designs. Note that writing to pc is undefined for most instructions as of ARMv6 (IIRC)." -- FUZxxl