Sparc removal | Hacker News Reader

Sparc removal

lists.debian.org

64 pointsbuster40 comments

I spent a lot of time in the past few months trying to fix enough of the issues with Debian/SPARC to keep it from having to be removed.

Honestly the port isn't in terrible shape. The specific problems listed as reasons for removing it are exaggerated. GCC is not dropping 32-bit SPARC code generation and the kernel works well overall. There were a few issues causing a lot of breakage, in particular, a register corruption bug in the kernel memcpy routine and a problem with the gold linker that was corrupting string literals in certain cases. Those two bugs blocked everything depending on nettle or qt, 800+ packages.

The real issue is that Debian has high expectations that take maintenance to fulfill. Particularly with the autobuilders, the machines that produce binary packages from source. When a build fails there needs to be somebody that fixes the problem. If an autobuilder crashes it can be restarted but if it's crashing every day there needs to be someone to track down the problem.

If there is nobody responding to issues it's ok for a while. The people responsible for packages and the autobuilder infrastructure work around problems where they can (running old kernels) but eventually it becomes too much to ask.

So I don't like this decision but it's understandable. The specific problems are exaggerated but the fundamental one isn't: nobody was doing the work to keep everything together.

> The real issue is that Debian has high expectations that take maintenance to fulfill.

Without meaning to diminish your insightful post and good point: as a Debian user, I have to say, this does not sound like an issue to me.

Sorry if it wasn't clear but I specifically meant the issue for the sparc port. I was not criticizing Debian in any way.

What trips me out about this is that SPARC is one of the most open of the legacy ISA's. It doesn't have so much baggage like Intel. It's RISC. It's documented well even for firmware writers, unlike Intel's black boxes. The license to use the name cost $100 rather than ~$1 mil for MIPS or $1-15mil for ARM. The top, proprietary offerings scream with performance and reliability. There are also multiple open-source versions that can run on FPGA's and one which gets fabbed. And, unlike OpenRISC or RISC-V, you get a whole ecosystem of code and toolsbuilt for the architecture.

Now, I understand people not buying it for desktops when they want to run browsers, flash, etc. However, it's strange for a crowd (Linux in general) that's historically about promoting openness and fighting black boxes to have so little uptake of an ISA like SPARC. Then a popular one drops it due to nobody maintaining it. A demand side of the equation like that is why few companies build or open better ISA's. The vendors think most are all talk and no wallet on the issue if it's about hardware.

Having learned SPARC assembly in the past, it most certainly does have a pile of backward-compatibility baggage of its own. For instance, https://en.wikipedia.org/wiki/Delay_slot

It's really not all that bad, there's also the cache coloring and memory ordering stuff, but it's well documented at least. There is a lot more historical baroque stuff about x86, like int 80, syscall, or sysenter? For extra credit how do you find-out and are you sure your approach works on Cyrix and Via too?

> It's really not all that bad, there's also the cache coloring and memory ordering stuff, but it's well documented at least. There is a lot more historical baroque stuff about x86, like int 80, syscall, or sysenter?

That's not relevant for current processors; it only matters if you need to support older processors, and in any case you always use the most capable interface provided by your processor. The older interface only matters if you support processors that are well over a decade old. Current processors have to support old software; current software need not support old processors. So unless you're hacking on the guts of the Linux syscall layer...

> For extra credit how do you find-out and are you sure your approach works on Cyrix and Via too?

Cyrix doesn't exist anymore, and VIA doesn't appear to have any current-generation hardware. So, unless you used to work on them and you have to avoid regressions, you can almost certainly safely ignore legacy hardware, just as you shouldn't optimize code for the Pentium 4 anymore. Especially if you're writing 64-bit code.

Good points. Important to note that "current generation" hardware means something different to VIA given they focus on low power and embedded. They do plenty with 20-30 watts, though:

http://www.via.com.tw/en/products/processors/quadcore/index....

By "current generation", I was going by the fact that Wikipedia shows no new models since 2011. If there's something new since then, great.

(And everybody is focusing on low power and embedded these days. Not least of which because "high performance" and "low power" are really two sides of the same coin, since if you use less power you generate less heat, and speed depends heavily on heat dissipation.)

That makes more sense. Remember that it's an embedded board company (mainly), so they don't iterate as much on SOC's. The last processor, the quad-core VX11/H, was in 2012 and one of a few on 40nm. Does a lot of stuff for a x86 SOC in 5.8W (max). Their last board design was 2014. So, they're still chugging along. Most likely two things: slowly moving their I.P. to costly 40nm and developing new ones; moving slower in general because of terrible, financial situation IIRC. In long run, they'll probably die because they tried to compete in x86 and even mighty AMD with their volume & engineers haven't pulled that off.

Far as low power, not everybody is focusing on x86-compatible, low-power chips these days. I only know three vendors: Intel, AMD, and VIA. So, it's that stuff that's relevant to a VIA comparison if we're talking x86 and legacy software/OS needing it. Students in labs throw together low-power, ARM/MIPS clones as a side effect of their simplicity and process node. x86 is so complicated that it took smart, HW engineers to do that with only a few companies trying and most gone. It's again why I'm anti-x86: entirely too complicated compared to multi-core RISC with hard-wired accelerators. See Cavium's Octeon III for an awesome example of that.

http://www.cavium.com/OCTEON-III_CN7XXX.html

Good point. Is there a list of such issues somewhere so readers can compare baggage to baggage? I predict Intel's baggage will come out worse but it's worth noting any problems in SPARC. Future SPARC implementations or other RISC ISA's might be sure to avoid them.

Remember, though, that one of best reasons to ditch stack-based architecture like Intel is more flexibility in what you can efficiently run on the RISC chips. The reason is they don't enforce many structural decisions. Academics in 2010 merely trying to implement a reverse stack, immune to worst overflows, on x86 immediately hit a 10+% performance penalty due to fighting against the ISA. I doubt a register-driven architecture would've had a similar penalty for changing its stack implementation.

> I doubt a register-driven architecture would've had a similar penalty for changing its stack implementation.

That's not a penalty; that's an optimization for the common case. That's going to be the case on any sufficiently common code pattern in RISC as well: if you recognize a common instruction pattern that you can run faster (peephole-style), that's going to give that pattern an advantage over any similar-but-not-quite-the-same instruction pattern. A lack of optimization is not the same thing as a "penalty"; not every code pattern can be optimized.

Or alternatively, if you left off that optimization, all kinds of stacks would look equally fast, or rather equally slow.

I agree totally with your whole comment. I just find that the common case, hardware or software, often has something to do with a class of security, reliability, or maintenance issues I'm trying to counter. RISC optimizations like register windows didn't hurt me much.

Plus, some specializations were quite helpful. Alpha's PALcode had more uses than I can remember. PA-RISC and Itanium had advanced memory and page protections. Intel's segments were useful to its credit as they're way more efficient than address space or paged protection. So, some structures I don't mind if they provide benefit without holding back improvements.

Very likely wrong alignment. This causes hard SIGBUS faults, and SPARC64 is one of the good platforms to catch such misaligned pointers. You cannot repro it in qemu on Intel.

But I don't know what ElfW(Rel) expands to. Maybe only a 4byte word, not 8. The backtrace doesn't display the register content (THANKS gdb maintainers), and the op didn't provide the registers neither.

  0xfffff8010000cda4 in elf_dynamic_do_Rela (skip_ifunc=<optimized out>, lazy=0, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>

https://lists.debian.org/debian-sparc/2015/07/msg00013.html

OpenBSD still supports it. It's very stable too.

It supports cool stuff like acting as an ldom host too.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/...

Better documentation link which shows how to set it all up: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/...

Huh, and here I was figuring that switching Solaris to OpenBSD on my SPARC hardware would mean not getting to tinker with logical domains anymore. I'm glad to see that my assumptions are incorrect, and that my Sun Fire T2000 will have an actual reason to be running in all its loud, jet-engine-sounding glory :)

Supports some hardware that Linux never did, as well.

NetBSD welcomes all SPARC owners

what about openSPARC, one of the only truly open cpu designs one can load into an fpga

And the Gaisler Aeroflex cores that are both open-source and fabbed onto boards they sell. People who want open hardware can get a bit closer with a 4-core SPARC board. :)

openSPARC was amazing at the time, but now the last published design is almost a decade old, and last I tried a few months ago I couldn't even download everything that was necessary to load it on an FPGA.

Not to mention that the reference software you could run on that FPGA is not available any more.

The linked message says it could come back as sparc64 - the Debian port was a 32 bit userspace, optionally 64 but kernel, while on new sparc machines you probably would want to use sparc64 userspace. For embedded/fpga sparc it is less clear. Anecdotally though I think there are more NetBSD/OpenBSD users on sparc than Linux.

This port only ran on 64-bit machines. Support for 32-bit sparc cpus was dropped years ago.

Well darn; I guess now I can't run Debian on my Sun Fire T2000.

Not that I particularly care, since I've found OpenBSD to be much better on non-x86 (particularly SPARC and PowerPC) hardware than pretty much every GNU/Linux distro I've tried (Debian included), but it's still unfortunate; diversity is nice to have in a platform, even if I'm pretty happy in BSD-land.

Oh well. Perhaps if us SPARC users are lucky, more illumos distros will start supporting SPARC. Tribblix looks interesting; if I can ever get my Blade 1500 running again, I'll have to try that one out on it.

><liw> HE, we had sex in Debian for many years, yes, before I put a stop to it

Could someone explain wtf this means?

Probably related to the "Simple editor for X".

Ah, that makes more sense than OSS devs getting laid ;)

Hey, Ian Murdock did name Debian after him and his girlfriend...

They did break up though.

This whole sub-thread: DAAAAAAMN! Haha. Let it be a warning to OSS developers thinking of mixing business and pleasure. Except for the pleasure of coding. :)

It's one of those old "jokes", like the SEX instruction: https://en.wikipedia.org/wiki/SEX_(computing)

It's an email signature in poor taste, referring to a very old package intentionally named to be in equally poor taste: http://archive.debian.org/debian/pool/main/s/sex/

This kind of thing shouldn't be in an email signature at all, but especially not in a mail sent to a widely distributed announcement list.

It seems that the author of the program himself isn't proud anymore, omitting the accomplishment of making and naming it from his CV.

Note -- this is 32-bit SPARC, not SPARC64. I am surprised to see that Debian does not have an official SPARC64 port (it has an unofficial one).

Support for 32-bit sparc was dropped years ago. This was the port for 64-bit machines even though it used a 32-bit userland.

What's byhand?

BYHAND are uploads that are not normal packages and need manual intervention to be processed.

CRAPS!

Reply on news.ycombinator.com