7 ms·
Yes, The SPARC architecture manual. Punch that into Google or DuckDuckGo and it should be the second link (you want the SPARC V9 instruction set architecture).
by Annatar 10y ago
Yes, The SPARC architecture manual. Punch that into Google or DuckDuckGo and it should be the second link (you want the SPARC V9 instruction set architecture). I would post the link I found, but since I actually have the physical book, I'm uncertain as to whether posting a link to a PDF of a possibly copyrighted book would get me in trouble with Hacker News or not.
I've done some SPARC assembler programming for fun, and for someone with 6502 / MC680x0 assembler background, SPARC has a really exotic assembler (register windows and synthetic instructions, most notably). It also illustrates just how complex and powerful the Scalable Processor ARCitecture is; for a RISC CPU, it has loads and loads of advanced features all designed for high performance, which leads me to think that the existing compilers generating SPARC code must be crap, since some of the SPARC processors (notably UltraSPARC II, UltraSPARC III, and UltraSPARC T1) are generally known to be slow when it comes to non-parallelized, number crunching performance. The design of the SPARC processors and their assembler is in direct opposition to that.
- gravypod 10y agoHow much does the hard copy run you? I am thinking of porting my hobby OS to the architecture so it's probably worth having around in hard copy form.
- Annatar 10y agoPrices vary. I might have bought it new off of Amazon for $90, but I don't remember any more. http://www.amazon.com/SPARC-Architecture-Manual-Version9-International/dp/0130992275/ http://www.amazon.com/SPARC-Architecture-Manual-Version9-Int...
- userbinator 10y agoIt shouldn't be a problem to link to it, because you can find a newer version of it sitting on Oracle's site as well as SPARC's official site: http://sparc.org/technical-documents/specifications/ http://sparc.org/technical-documents/specifications/ are generally known to be slow when it comes to non-parallelized, number crunching performance I think that's due to a similar set of design decisions that lead to the Itanium also being an amazing benchmark performer, but dismal in "general purpose" code. IMHO SPARC and Itanium are architectures that have optimised heavily for the sort of massively parallel, predictable/few branches, predictable-memory-access-pattern that "high performance computing" benchmarks show off, but at the expense of the small, branchy, less predictable "serial byte/bit manipulation" that tends to be common in other, more general-purpose code. To use a car analogy, it's like a dragster vs. a rally car.