Hacker News Reader

Comment by nickpsecurity | Hacker News Reader

Unbelievable. Yet again, we have a post on finding x86 alternative that's most FOSS friendly. Yet again, the author is unaware of or ignores the only architecture that's open, has GPL cores, and an ecosystem. That's SPARC. Oracle's T1 and T2 cores are open-source to study. More appropriately, Cobham-Gaisler's Leon3 HW is dual-licensed under GPL and commercial. The Leon4 is 4-cores. SPARC ISA is open. Open Firmware exists.

So, why is SPARC left off in all these analyses? It's right there ready to pick up and deploy. More open, easy to acquire, and trustworthy (far as licensing) than than a POWER chip although slower for sure.

View on HN

I'd imagine people don't bother looking at an oracle technology and just assume it is closed or unsupported due to the ways they generally operate.

That doesn't make it right to do this, but that'd be my guess.

I certainly didn't know SPARC was open until your comment.

As far as I know, Oracle has not made any SPARC intellectual property available since the acquisition of Sun. The T1 and T2 lines were emphatically Sun-era products.

They stay on Slashdot and in my news feed. Here's a few from Oracle and one from Fujitsu:

Oracle T4 http://www.oracle.com/us/corporate/features/sparc-t4-announc...

Oracle M6 http://www.oracle.com/us/corporate/features/sparc-m6/index.h...

Oracle M7 https://blogs.oracle.com/rajadurai/entry/sparc_m7_chip_32_co...

Fujitsu https://en.wikipedia.org/wiki/SPARC64_VI

Yes, new SPACE processors are coming out. The chips are being made available but the intellectual property isn't.

That's true. I'm also against buying Oracle's I.P. because they're too scheming and sue-happy. I'm listing those to show SPARC ISA has a series of implementations competitive with x86 on the high-end. It's actively developed and badass rather than dead. That's all.

So if API's are copyright-able.

And SPARC T1/T2 are GPL CopyLeft.

Shouldn't Oracle have to open source T3/T4/T5/M7 processors also?

(No I don't have the money required to sue Oracle and keep this suit open for the 2 decades settlement will take).

If all of the copyright holders agreed, I think they they could relicense under any licence. This would be especially straightforward for any revision for which Oracle is the sole copyright holder.

No, that's not how open-source licensing usually works.

Assuming Oracle own all the IP rights (having purchased them from Sun), they aren't bound by the terms of the GPL. The GPL grants certain permissions to others if they comply with its terms, but the person who offers the license doesn't lose any rights they already have. They have no obligation to keep successive generations of derivative products open source.

True, that's even spelled out in the GPL itself (that's from GPL 2, but GPL 3 has similar content in section 9):

> 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License [...]

The copyright owner obviously doesn't need the license to have permission to modify the code, so they're not bound by it.

There could be a perception problem there. SPARC has been open for a long time with multiple vendors making SPARC chips. There's no restrictions except IRRC a $99 fee to use the trademark for a SPARC compatible chip.

I thought it was pretty bad as well ...

But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU.

I have much higher hopes for RISC-V, the community is really booming and the architecture is better than SPARC.

I say this as a former Gaisler employee and SPARC proponent :-)

"But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU."

There's definitely drawbacks. I've just not even seen interest in embedded sector of FOSS for SPARC even with open cores. I wouldn't argue stuff like Leon4 in its current form is suitable for replacing a Core Duo or anything. Yet, that it's suitable for many apps but ignored for all apps by FOSS in favor of proprietary MCU's/CPU's might reveal a problem on their side.

Far as RISC-V, the community is booming and I have high hopes for them. Maybe they'll make something. My recommendation was to create Pi-like board with RISC-V SOC by licensing Leon3 or Leon4, replacing SPARC components with RISC-V, and getting the rest w/out effort. I think we would anyway given it's designed for easy configuration/modification. In parallel, continue developing clean-slate replacements. Gives us a rich, interim product to use with full FOSS down the line. What you think of that idea?

I agree that LEON is overlooked in the MCU market.

Wrapping up one or multiple of the RISC-V cores in GRLIB is something I think would benefit both Gaisler and the RISC-V community and something I have thought of doing myself if I had the time!

That's about half the peer review I need on that given your background. Next I need a SPARC opponent with HW/SOC experience background giving same recommend haha. Might send it to some of the academics.

Another part of my plan was to get academics to build and public domain the source/verilog/whatever so we can benefit from their cheap EDA licensing and shuttle runs. Pick bare minimum I.P. we need, like DDR or PCI, to get SOC's working. Slowly crank them out at many universities to eventually arrive at a platform with ASIC-proven components. Then, startups can just do integrations with whatever little part is custom for them. Much cheaper. Also, I think analog academics doing open, cell libraries would be a good idea at 350, 180, 90, 45, and 28nm. As money comes in, can just shrink from one tech to another using pre-existing I.P. or cells. People could probably use Qflow OSS ASIC flow with 350nm (maybe 180nm) without or w/ little commercial tooling.

Always looking for HW people's review on these things. What you think?

Academics should absolutely open source their stuff to a larger degree and contribute it a common open source community. I don't think LEON/GRLIB will be that community but may be a part of it. OpenCores did not succeed but I have hopes for what's cooking around FOSSi foundation/LibreCores.

Most academic shuttle runs are still at 90nm, or bigger. There are a few reasons for this: cost of runs, cost of tooling (hundreds of k), and the fact that your assumptions about transistor action and modeling are exponentially more complicated at advanced process nodes.

Academics also sign NDAs about the processes they use, and can only make certain things available; the most open is probably MOSIS, but that's absolutely no good for advanced nodes.

I'd say throw low power and advanced anything out the window, demonstrate a working chip, then look for funding to advance it.

I'd agree that most runs are at 90nm or above. Yet, the rest is confusing given I have quite a few papers with competitive stuff done at 45-65nm with some at 28 or 32nm.

So, why you say forget about it or MOSIS below 90nm if academics are getting working chips done that low?

They sign NDAs for the process and get 100-thousand dollar layout packages for academic prices.

If you have a few spare million dollars, you still can't necessarily release a lot of data due to the NDAs - usually they give you models for the processes that are proprietary (and they invested a lot in developing, and so will consider any breach an act of war).

From my amateurish POV this looks rather peacefully. No Cult of the NDA in sight. Nonetheless too expensive. OTOH, are you aware of the prices mentioned there? http://www.europractice-ic.com/ http://www.europractice.stfc.ac.uk/welcome.html http://cmp.imag.fr/ http://cmp.imag.fr/products/ic/?p=prices2014 http://cmp.imag.fr/products/ic/?p=prices2015 http://cmp.imag.fr/products/ic/?p=prices2016

ahh crap..."which are sent to customers upon signature of a Confidentiality and License Agreement"

anyways, prices...hope that helps

Nick, The larger context of all this issue is defense. So on one side there are the five eyes governments wanting it this way. On the other side(and probably very interested in 100% security), you might have various countries supporting terrorist organizations, terrorist organizations, crime syndicates, russia, china, etc.

Doesn't this context hints to us that 100% security would be much harder than creating some design and manufacturing it using standard fabs?

I've addressed a good chunk of what it takes for system and hardware security in at least two places:

http://pastebin.com/y3PufJ0V

https://news.ycombinator.com/item?id=10468624

There won't be 100% security because underlying physics fights you and our field is too new. Best we can hope for is making attacks hard and physical. There's great work in secure HW/SW architectures that should knock out about all SW stuff with effort. Details published in all kinds of CompSci publications. HW, too, far as implementing it correctly with some security properties. The rest, esp tamper-resistence, is still in infancy far as having stuff that actually works.

Now, what we're talking about in this thread is having an ISA, chip implementation, firmware, and SW stack that is not a black box and is under your control. Preferably without built-in, convenient spyware. Mainstream FOSS users are currently so far away from this that it's a reasonable, interim goal. So, I had to bring up SPARC as an addition to the list that has side benefit of reducing legal risks.

Ok. Maybe that may work. But what about legal risks? extra-legal risks(like vanishing in the dead of night) ? soft risks - how would the wife of someone who is just the customer will respond when guys in black suits will come to her home ?

Or if you're method will work so well, are you sure TSMC/Samsung will even accept you as a customer ?

Because it doesn't seem like something that could scale without the legal/political side and that's really much harder than the tech(which is hard, no doubt).

Many big players have vested interest in hardware platforms that are not tampered with out-of-the-box, or open to easy tampering, by their adversaries.

The Chinese have an interest in having a hardware platform that doesn't have NSA code baked into it; the US government and major US corporations likewise want hardware that doesn't phone home to Unit 61398. The Russians don't want either but probably have their own ambitions. Etc.

I think that in the next few decades it will become quite accepted that you choose your platform based on who your perceived "adversary" is. If you're concerned about the NSA, you buy a system that's Chinese from soup to nuts. If you're concerned about the PLA, you buy from a vendor with the US Government seal of approval.

It remains to be seen -- and in truth, I am somewhat pessimistic -- about the availability of a hardware/software ecosystem that doesn't require compromise. Hardware fabrication is a capital intensive industry, and capital intensive industries are pretty vulnerable to coercion by the governments in which all their capital equipment sits. ("That's a real nice chip fab you have there. It'd be a shame if something...happened...to it. Maybe you want to reconsider your offer to help us out?")

An open architecture that you could get from any number of vendors, and perhaps use to keep the vendors honest, would be a huge step in the right direction, though. But the underlying problem is extremely hard.

> Hardware fabrication is a capital intensive industry, and capital intensive industries are pretty vulnerable to coercion by the governments in which all their capital equipment sits.

If the spec is open then it should be possible for a fancy lab to verify that the hardware is manufactured to spec, right? So if you have it manufactured in Taiwan but then have random samples verified by labs in the US, Japan and Europe, defectors could be detected. Then the manufacturer would have to risk destroying their business by getting caught inserting a backdoor.

At the sizes we are talking about, it's plausible to put in a hardware backdoor that even grinding down could miss...

Look up ChipWorks. They're Number 1 in doing this far as I know. Still potential to hide things or just make it goo expensive to find.

All existing SPARC hardware is very old at this point and has horrible energy efficiency and poor performance compared to the other options, including POWER8 and ARM.

This is possible. I wonder how much of that is its design/I.P. and how much is what process node it's currently on? A port of proven I.P. with existing ecosystem to 28-65nm that ARM and RISC-V are using might fix a lot of that.

There are even more implementations than the ones you mentioned. http://temlib.org/site/?page_id=14 and then http://apple-core.info/outcomes.html , schematic overview http://www.date-conference.com/files/file/date11/ubooth/157.... , necessary toolchain http://sp.utia.cz/index.php?ids=results&id=applecore . Apart from that, i'm thinking something like OpenFirmware should be mandatory for every Vendor, because without MANDATING it, there is no incentive, to abstain from proprietary shit, which locks the customers to it. There is no escaping it. Except to quit.

Those are pretty neat. Didn't know about the Apple many-core. Far as OpenFirmware, I think it should be mandatory along the lines of something like First Sale doctrine. If we bought a device, we should be able to control its use by law. We can't do that with software due to copyright. That implies an open, mandatory firmware available that lets us load our own software in.

I knew you'd like that. The temlib is impressive because of its completeness, though it seems like hobbyist thing, maybe useful for retrocomputing and software archaelogy ;) But this comment http://temlib.org/site/?p=567#comment-210 makes me realize that the design doesn't even fully utilize the almost EOLd Spartan-6 (a low end one, even in its heyday). Now imagine what could be done in something new? Combined with the Utleon3 implementation of the Microgrid concept from http://svp-home.org On something like this f.e. http://www.achronix.com/products.html ? AFAIUI this would smell like Soft Machines VISC, only better, because FREE!

PS: two more pdfs for you to digest wrt Soft Machines VISC http://dist.svp-home.org/doc/foundations-and-achievements-of...

http://dist.svp-home.org/doc/operating-systems-for-many-core...

"makes me realize that the design doesn't even fully utilize the almost EOLd Spartan-6 (a low end one, even in its heyday)"

Yeah, it's impressively efficient. Adds more evidence to our argument that SPARC implementations can be technologically competitive in efficiency with ARM, etc.

"AFAIUI this would smell like Soft Machines VISC, only better, because FREE!"

It could happen. Achronix's FPGA's are badass, too, hitting up to 1.5GHz. Their dev boards are actually cheaper than Oracle's SPARC servers, too, with added benefit of putting custom logic for accelerators in there w/ SPARC I.P.. I haven't studied much of VISC, though, so I have little comment there.

I'll comment on those other links later tonight as I'm off to do some more paying work. :)

To be fair, Oracle winding up with the most open hardware is such an outlier it would be like checking if Stephen Hawking won the Boston marathon.

Lmao. Yeah, that would be ridiculous. Truth is more reasonable:

https://news.ycombinator.com/item?id=11424195

Because Oracle tends to be hostile towards anything open source? With such an attitude, why ever bother supporting their technologies?

SPARC is owned by SPARC International, a non-profit. Its specs and everything are open:

http://sparc.org/technical-documents/

One embedded implementation with a ton of supporting I.P. is GPL'd, FPGA-proven, ASIC-proven, and rad-hard in some verisons:

http://www.gaisler.com/index.php/downloads/leongrlib?task=vi...

And then there's Oracle, their badass chips, and their evil ass lawyers. We can stay away from all that. SPARC is better and safer than Oracle but very importantly SPARC != Oracle.

Is there are repository for this? Or do they still do the cathedral model?

I'm pretty sure it's the catheral model. I'm not even sure that they're doing open-source with Leon4 onward as pretty much nothing happened with GPL'd Leon3 and GRLIB. Comp Sci people and companies doing rad-hard, space apps are still getting and building on it.

Best way to deal with them is to straight-up license their tech for a Pi- or router-style board. Then fab, assemble, and sell that joker. That gets the ecosystem going. CompSci people doing CPU's or RISC-V work can keep building reusable components both can use. Then we just pay for the integrations.

I've done school-size CPUs with http://www.clash-lang.org/ --- it would be fun to convert someone's "real-world" design into Haskell with it. 'Twould really show off that order of magnitude code size reduction :).

I suppose cathedral vs bazaar doesn't affect that at all, but experience has ingrained in me "source tarball ==> won't easily build" biases.

What is more unbelievable is the Management Engine itself, not a nitpick about a platform being left out of the list of alternatives. It did not seem like he was creating a comprehensive list, just a first attempt.

The management engine is a result of a steady stream of changes, enhancements, proposals, etc going back probably a decade. There was demand from business and government sectors for easier repair/management, better security, and lock-in from software/media segments. Consumers largely were apathetic and stayed out of those discussions as usual. However, there was demand among some of them for cheaper repairs and better malware protection. Management Engine was one of results of all that.

One could see it coming years in advance. Matter of fact, I fought solutions like that in favor of instrumented, robust coprocessors that did that. They could cost $20-30 more. They could even be in an embedded PCI card that also did I/O offloading, firewalls, and security monitoring with secure RTOS. Many extra benefits to justify extra $20-200 depending on form factor. Yet, people wanted dirt cheap, integrated solution.

They got it...

Not to mention that ARM's ABI is hidden behind a paid NDA. ARM is even less open than x86

I'm not sure I know what you mean by ABI here? ABI in this case to me would mean Application Binary Interface, IE the C ABI that's defined by the platform and not the processor.

A number of architectures have published standard ABIs. ARM, PowerPC, MIPS, Itanium are all in this category. In some cases these are explicitly embedded ABIs (sometimes EABI).

For ARM, all major OSes I'm aware of use the ARM EABI2. (Note both the Linux kernel and gcc support other ABIs, so there is a real practical choice here.)

For PowerPC, at least all the little-endian 64-bit work for POWER8 has been done targeting the standard ABI. (I have no memory of whether big-endian ABIs for PowerPC follow the standard.)

"Oracle's T1 and T2 cores are open-source to study."

If you had to pick a Oracle (Sun?) T2 based system to purchase off of ebay, with the interest in using it as a "more free, more open" system, what would you buy ?

What OS would you run on it ?

I wouldn't. I'd use Gaisler's immediately because it's fully open and already FPGA qualified. I'd then buy a good FPGA board. Then I'd run it on there. It would probably run like a multi-core version of my old Pentium II. Yet, I programmed, hacked, gamed, and so on with it. Later, I'd put it on an eASIC Nextreme or actual ASIC if money came in for better performance, power, and unit pricing.

Which FPGA would you use? High-end FPGAs (and FPGA software) are very proprietary and locked down.

"I'd use Gaisler's immediately because it's fully open and already FPGA qualified. I'd then buy a good FPGA board. Then I'd run it on there. It would probably run like a multi-core version of my old Pentium II."

Sorry, let me clarify ...

Pretend you have three kids. But at the same time you'd like to tinker with a fully open system from loader on up.

Is there an old sun sparc that would make rms happy that I could buy on ebay ?

I think the last generation of SPARC-based workstations in wide production were the Ultra 45s. They were made until 2008, according to Wikipedia [1]. They sell for surprisingly high prices [2], for an almost-decade-old computer, on eBay.

You could probably get an old Apple PowerPC-based system for considerably less than that, and a LibreBoot-compatible x86 system for even less, but they do exist if you wanted to play around with the architecture.

And they do look pretty cool as well.

[1]: https://en.wikipedia.org/wiki/Sun_Ultra_series

[2]: See eBay item 121411279863, which is a Ultra 45 1x 1.6 GHz SPARC with 2GB RAM and 250GB HDD for almost $2k, asking price. Not sure if that's a realistic ask, but it's what they want for it.

Oh, so any sun sparc workstation of that era would work.

Understood - thank you.

There is nothing open about Ultra 45 workstations in the context of this thread (it uses Open Firmware, but that's about it).

Note that Ultra 45 workstations are extremely slow, much slower than you expect. They were very slow even when they were new. Think Pentium 2 performance.

Is SPARC unpopular because of its power consumption?

There used to be a lot of competition between several types of RISC machine and several x86 vendors. I know about the consolidations on x86 side. I'm not sure why SPARC lost favor versus others, though. I wasn't able to afford RISC workstations back when all that was happening. It would be nice for one of older folks to chime in on what made SPARC unpopular back then.

It was the cost/performance ratio, not of the CPU itself, but of the entire thing, including software. Sun sold highly performing, but extremely overpriced hardware that rode in on the hype it built around the architecture but failed to deliver on flexibility and bang for the buck.

I was involved in launching an ISP where the whole shebang ran on Sun boxes, and which was over-dimensioned to the point where I once stepped into the data center and found a waist-high box full of E250/E450... Feet. The purple plastic ones you had to remove to rack mount the things.

Two years later we'd shrunk down most of the whole thing (except the storage bits, where SPARC still had good performance) to a few racks of Compaq and Dell boxes that were vastly cheaper to maintain (both because they were cheaper, period, and because we didn't need to wrestle with Solaris and the compilers of the time to get stuff working on them).

This was back in 1999 or so, and I never saw a SPARC system in production after 2005 (until a few months back when I visited a telco customer who still swears by them for a very specific purpose).

I still have one of those plastic feet on my desk at home, as a reminder of the folly of buying single-vendor solutions. It sucks as a paperweight. :)

Thanks for the enlightening comment. That makes plenty of sense. It's part of the reason I didn't try to buy one: price/performance numbers just didn't make sense.

So, why is SPARC left off in all these analyses?

Guessing it's the entry-level price of US$39,821.00 for Oracle's smallest server?

Then you are missing the point he is making. LEON is a GPL implementation of SPARCv8 which you can download and use in an FPGA, tape out your own ASIC or buy one of the existing SoCs built with it (might not be that easy...). In other words, more open than the alternatives listed.

Exactly. There's a ton of implementations ranging from free for FPGA's to S-ASIC's from eASIC to embedded CPU's from Gaisler to cloud servers from Oracle to mainframes from Fujitsu & Russia. One can also legally clean-slate a SPARC chip without legal fears. Unlike POWER, ARM, and MIPS. The ISA, its docs, a firmware standard... all of that already open.

So, why is it not on the table for... anything in FOSS? Doesn't seem rational. Even a bit hypocritical given vendors like Gaisler and nonprofits like SPARC International have met FOSS halfway or almost wholly. Unlike the others that sue FOSS developers.

This makes me wonder why we don't see sparc chips in things like routers or other hardware that doesn't require lots of binary compatibility from 3rd party software.

Because ARM and MIPS chips are a lot more power-efficient.

Because the chip-makers and chip buyers are using ARM and MIPS in power-efficient SOC's. They could do the same with SPARC. They just didn't for whatever reasons.

Far as power efficiency, kristoffer might be able to chime in as it's not in the data sheets for Gaisler. That's suspicious: either the numbers are bad or they leave it off given its meant for customization. Anyway, the Leon4...

http://www.gaisler.com/index.php/products/processors/leon4?t...

...uses 30,000 gates per core. Same ballpark as ARM and MIPS. Power use should be similar or at least acceptable if comparing ARM, MIPS, and Leon on same ASIC process. They often do rad-hard given it makes it resistant to SEU errors. That takes plenty of extra circuitry. Numbers I have for those, the high end, are 15mW per 1Mhz for Leon3RadHard and for Leon4RadHardQuadCore max was 6watts per one slideshow.

I'll take 6watts consumption in a router in exchange for quad-core, IOMMU-enabled, fault-tolerant, open CPU. What about you? Would 6 watts kill it for you?

> I'll take 6watts consumption in a router in exchange for quad-core, IOMMU-enabled, fault-tolerant, open CPU.

The router vendor surely looks at the cost of the CPU - ARM and MIPS cores are probably much cheaper.

Remember, I mentioned the SOC vendors as well. They currently license MIPS and ARM. Many choose MIPS due to cheap license. ARM's license, royalties, and restrictions are ridiculously expensive. SPARC has a cost advantage over it. So, once again, it's neither energy nor costs that are reasons they chose MIPS and ARM over SPARC.

Keep guessing.

I'm not so sure: Because currently ARM processors are currently sold in a large volume (if not for a technical reason then by momentum) they can be made a cheaper by economy of scale. This does not mean that this has to stay in the future, but currently this seems to be the case.

Now there's a good argument. Here's the real value, though, straight from ARM themselves: the ecosystem. They've built a whole ecosystem of boards, firmware, software, everything around ARM you get when you license their tech. It might be cheaper with economy of scale as well although licensing and royalties have to factor in. I'd default on MIPS there since they can be up to 10x cheaper than ARM. But yeah, a Freescale iMX ARM was like $4 per 100 units last time I looked it up.

So, it's mainly the ecosystem with companies and FOSS people wanting to benefit from what's already there instead of improve FOSS HW ecosystems. There's currently, but not indefinitely as you said, a cost advantage for the mass market SOC's as well for PPC, ARM, MIPS, and possibly SuperH.

> a Freescale iMX ARM was like $4 per 100 units last time I looked it up.

$4 per 100 units (4 pennies each), or $4 per unit in quantity of 100?

Power consumption is of course very much dependent on the chosen fabrication process and SoC configuration. A LEON3/4 core is comparable to something like a ARM Cortex-M7 and it is not the ISA (when comparing ARMv7 vs SPARCv8) but the implementation that will affect power most. LEON is quite small and power efficient.

Node selected for fabrication does not equalize power consumption. You could go to the same node with other, inherently more power efficient architecture and gain even more oomph per watt. Power efficiency stems from the architecture itself; manufacturing process is a red herring (and a costly one). What you're saying is pretty much like "seasoned bodybuilder would kick white-belt karate practitioner's ass, so it's clear that bodybuilding is better than karate."

Compare things that are alike. If you take a manufacturer (say: TSMC), pick its node (say: 16nm FF+) and you decide on a package (physical manifestation of RTL primitives in the silicon) you get better performance per watt on one architecture over some other. ARM and MIPS are inherently very power efficient. You can't just take SPARC and make it more power efficient than these two. It doesn't work like that.

It's also not true that ISA doesn't matter. ISA impacts bandwidth requirements heavily. This in turn impacts latency and latency hiding, cache requirements and many other things. In fact data transfer is typically as costly as (if not more expensive than) computation. Getting data to all the right places on the schedule eats power like crazy. This is exactly why ARM has Thumb. It's not like internally core does different things than it would do with wide ISA. It's just that stuff's more densely packed, which helps tremendously.

Which brings me to my last point. There's an open architecture that's quite nice. It's SuperH (or SH2 in its open source form), which in turn is what ARM's Thumb is based on. It's not perfect, but it's pretty solid. Omitting it in the OP makes me think author isn't very thorough with his research. But everything has to start somewhere. ;)

I said fabrication process AND RTL architecture matters more than ARMv7 vs SPARCv8. They are both quite nice RISC architectures. Nothing in either one is especially power hungry.

Sure you have Thumb, that saves a little on memory bandwidth which is good. But nobody uses it anyways, and you might run slower so you can't sleep as fast.

I like the J2 (the open source sh) project as well but it doesn't have a MMU which rules it out for anything but simpler embedded projects.

There were: http://www.kaltech.co.il/pdf/LEONSPARRAIDProcessor.pdf

I'm very into operating system development. Does anyone know if the SPARC architecture offers the same problems that other systems require?

Some things like GDT, or lack of a hardware discovery that are anyoying.

Anyone here worked with this?

Reply on news.ycombinator.com