5

I think this is borderline retro, SPARC is in the past it seems...

I'm reading over the SPARC instruction set, which is confusing because every reference I find mixes "real" instructions and the assembler macros, and/or just leaves out whole groups of instructions. The first two sites I went to didn't even list a shift.

But one thing I can't find anything about is the coprocessor instructions. There's not that many of them, and they largely map over the FPU instructions, but there's a queue register which is ... what exactly?

Maybe I'm using the wrong google keywords, but I can't find anything that used these instructions. Anyone have some examples?

7
  • 4
    Wouldn't be so sure about it being past. Fujitsu introduced the last complete new design (S64 XII) just a few years ago and is planing to do new versions until at least 2027.
    – Raffzahn
    May 26 at 20:01
  • 2
    @Raffzahn - Why? Seriously, what's their use case/marketing case?
    – davidbak
    May 26 at 20:44
  • 1
    Server and low end mainframes. Fujitsu is the main developer for Sparc 64. All their (Unix) Servers are SPARC. When they took over SNI they inherited their /390 compatible business as well, which at that time had based the low end machines as well on SPARC CPUs (running an emulation layer). Only the upper and high end machines still had/have did run on true /390 processors which they still continue to develop.
    – Raffzahn
    May 26 at 23:39
  • In addition to the usage mentioned by @Raffzahn, there are still embedded systems using the ESA’s LEON cores, which are radiation-hardened 32-bit SPARC v8 soft cores. They’re not as popular as POWER-based or MIPS-based designs, and they’re slowly being supplanted by ARM (and probably RISC-V in the nearer future) designs, but the fact that the VHDL is licensed under the GPL and the highly diverse set of RTOS options for them means they will likely hang on for quite some time. May 27 at 13:06
  • You can find "The SPARC Architecture Manual" version 8 (the last 32 bit SPARC version) online easily enough as a reference; this is the book that defines what it means to be a SPARCv8 CPU, and has definitions of all the instructions in it. May 30 at 15:39

1 Answer 1

7

The only standardised coprocessor was the FPU (contrary to MIPS or MC68K, for example, where MMU is also handled as coprocessor).

The FPU pipeline can run asynchronously from the main integer processor.

Contrary to integer exceptions, if an FPU exception occurs (unimplemented instruction, overflow, underflow, division by zero...), the program counter[s] do not always point to the instruction that trigger the trap. The Floating Point Queue memorizes the address and opcodes of the instructions in the FP pipeline, so that it is possible to correctly handle the exception.

2
  • 2
    So the C-series instructions went unused? Or do these overlap the F instructions? May 26 at 19:23
  • See appendix F of the SPARCv8 manual (meant to be read in conjunction with chapter 5) - the CPops and FPops get different opcodes, so they don't overlap. It's just that there's no standardised use of the CPops, whereas the FPops are specified in tables F-5 and F-6. May 31 at 17:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .