Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sparc removal

lists.debian.org

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Sparc removal

#31

Post by nickpsecurity »

JoshTriplett wrote: post #28
nickpsecurity wrote: post #26

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 versi…

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

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.

Re: Sparc removal

#32

Post by acqq »

JoshTriplett wrote: post #27
omginternets wrote: post #13

> HE, we had sex in Debian for many years, yes, before I put a stop to it Could someone explain wtf this means?

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.

Re: Sparc removal

#33

Post by JoshTriplett »

mzs wrote: post #30
JoshTriplett wrote: post #28

Earlier quoted context omitted.

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.

Re: Sparc removal

#34

Post by nickpsecurity »

JoshTriplett wrote: post #33
mzs wrote: post #30

Earlier quoted context omitted.

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 interf…

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....

Re: Sparc removal

#35

Post by JoshTriplett »

nickpsecurity wrote: post #31
JoshTriplett wrote: post #28

Earlier quoted context omitted.

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

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 chi…

> 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.

Re: Sparc removal

#36

Post by JoshTriplett »

nickpsecurity wrote: post #34
JoshTriplett wrote: post #33

Earlier quoted context omitted.

> 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 interf…

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.)

Re: Sparc removal

#37

Post by nickpsecurity »

JupiterMoon wrote: post #22
amyjess wrote: post #20

Earlier quoted context omitted.

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. :)

Re: Sparc removal

#38

Post by nickpsecurity »

JoshTriplett wrote: post #35
nickpsecurity wrote: post #31

Earlier quoted context omitted.

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 chi…

> 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-no…

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.

Re: Sparc removal

#39

Post by nickpsecurity »

JoshTriplett wrote: post #36
nickpsecurity wrote: post #34

Earlier quoted context omitted.

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

Re: Sparc removal

#40

Post by yellowapple »

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.

Post reply on HN