Proprietary versus open instruction sets [pdf] | Hacker News Reader

Proprietary versus open instruction sets [pdf]

research.cs.wisc.edu

38 pointsjsnell13 comments

"Audience member: So how do you deprecate something from an open ISA?

[...] Patterson: we can add things to it and we can take things out, but it’s going to be like the US Congress; it’s a slow-changing system, and that’s on purpose. [...] That is why I think it’s not going to add two instructions per month for 40 years like the x86."

Interesting argument: open source hardware will evolve slower than proprietary hardware and thus accumulate less/no 'junk DNA'?

If we get an open instruction set that works like that, I can see the forking happening when important players think standardization is going to slowly or instructions get retired too soon.

If you have the source code to all your software, generally speaking open source (although proprietary software occasionally comes with source code included), and you know how to build it, then removing old instructions from an ISA is feasible. Once the compiler is modified/reconfigured to not emit the removed instruction any more, just recompile everything.

If all your code is bytecode running on a VM (such as Java or .Net bytecode), then you don't even need the source to your applications – just make sure the VM's JIT compiler is not emitting the old instruction any more.

A good example of the later was the IBM AS/400. The high-level languages in which applications were written – COBOL, RPG, PL/I, etc – all compiled to an intermediate bytecode (MI code). The original AS/400s used a proprietary CISC CPU, whose instruction set was never publicly documented by IBM, although I've heard it was inspired by the System/370 mainframe instruction set. The OS would translate MI bytecode (which was documented to customers) into the underlying CISC instructions. Later, when IBM moved the AS/400s to PowerPC, they just had to replace the MI-to-CISC translator with an MI-to-PowerPC translator, and all that old code just worked. (I simplify somewhat – they also rewrote most of the lower-level OS code from a PL/I dialect into C++ – although, that was more of a good idea than something strictly required by the CISC-to-PowerPC migration.)

By contrast, it is very hard for Intel to drop anything from x86, even rarely used features (e.g. BCD arithmetic instructions), because somewhere out there someone has a business critical closed source app which uses that feature, and the source code for it might not even exist any more.

So, at least in principle, an open source ISA could actually drop things faster than many proprietary ISAs do. It really depends on what kind of software ecosystem ends up running on that ISA.

Not to contradict others messages here, but to add to them: the argument (made elsewhere) by RISC-V peeps is that Intel etc regularly introduce rather junky instructions that they can and do patent (the mechanism of), merely in order to continue to patent encumber the collective ISA, and so keep the network effect as their purely proprietary possession, long after the truly significant patents have lapsed; since compatibility would now require the new instructions, too. I'm not making that argument, although it may well be correct, I'm pointing to it.

As an addendum to your list for the other readers, C, C++ and Java AS/400 compilers can also generate MI code.

Also Microsoft already had it for Windows CE, it was called Common Executable Format for eMbedded short CEF.

https://msdn.microsoft.com/en-us/library/ms834338.aspx

Processor independence is also a reason why mobile OSes are going into this direction.

They already take some care with RISC-V to avoid introducing instructions they will likely need to a) supersede or b) deprecate in the future. A good example is the approach they are taking to vectors. Instead of adding a SIMD extension which will need widening or new infrastructure every few months; they are going to introduce a hardware pipelined vector extension which can work on vector units of any width.

I had not heard of the nyami open GPU before. MIAOW is based on an AMD ISA so is probably not going very far. Open source SoCs will want open GPUs after not too long. It might also be cool to have risc-v supported with llvmpipe.

Why is there no mentioning of SPARC or other open source RISC architectures.

SPARC and OpenRISC are mentioned in passing. IIRC, the main issue with SPARC is that there's no general patent grant and no reference implementation under a permissive license (the implications of integrating a GPL core into a larger chip are apparently an open question). As for OpenRISC, the developers of RISC-V disagreed with some design decisions that made it less flexible, and said that fixing them would have resulted in an incompatible architecture anyway [1].

[1] https://riscv.org/2014/10/why-not-build-on-openrisc/

OpenSPARC is under GPL2. That has an implicit patent clause. Leon is under GPL. It was untested in court last I checked whether these would be considered patent licensed too due to wording. Worth trying for somebody as that would be a nice precedent. :)

The entire code for synthesizing the UltraSPARC T1 and T2 is free, open source software. The SPARC V9 reference manual is pretty clear on what a SPARC V9 ISA compliant processor must, and how it must implement it.

Leon (SPARC V8 ISA) is a free, open source implementation, and is a radiation hardened processor.

Why is that not enough?

According to [1], the SPARC v9 and later ISAs are proprietary. I think you implicitly get a license for any patents via (L)GPL if you derive from OpenSPARC or LEON, but not if you create your own implementation.

[1] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...

Don't you think that paying $50 one time license is cheaper than designing one's own instruction set and processor from scratch (that's assuming that one wants to do that, rather than re-use or modify the UltraSPARC T-series code)?

How ironic that the paper thinks that reigster windows, one of the most powerful features of the UltraSPARC processor, which gives the processor 256 virtual registers, is including too much. Wow. Are these guys unfamiliar with the UltraSPARC, or what?!?

Also they imply that delayed branch in MIPS and SPARC is somehow bad, but they don't write that for every branch instruction an UltraSPARC doesn't take, one gets a free instruction execution slot inside of the same clock cycle... what's that all about?

The paper even mentions that SPARC V8 has been turned into a IEEE standard.

This whole paper reeks of the "not invented here", and "we just want to build our own processor and we think everyone should use ours, it's the best!"

The only practical plus I see in OpenRISC's favor is 128-bit addressing.

The only implication of non-free that I could find in the paper mentioning SPARC is that SPARC V9 is proprietary, but proprietary does not mean that it's not open, just that someone owns the implementation.

My conclusion is: "we just wanted to design our own processor no-matter-what, and you should use ours!"

Umm, no, I won't do that, because any new processor needs assembler coders with several decades of experience (I code in assembler, so I know what's involved), and they have to be capable of implementing a compiler which can generate code which can take advantage of the processor. Case in point is Itanium, a very fast processor which left out most of the hardware for an assumption that the compiler will be good enough to generate code which will take advantage of it. That never really materialized and Itanium has gone down in history of computing as "Itanic".

UltraSPARC is a very powerful processor, and when utilized correctly, it is a very fast processor, designed to be fast and designed to be powerful and extensible (SPARC stands for Scalable Processor ARChitecture). The code to synthesize and modify the existing design is free. Not only is it free, it was one of the first, if not the first processor designs ever to be open sourced and made freeware. It has Sun Studio which has evolved enough to take advantage of the processor features, so one can just hit the ground running with the design. 128-bit addressing of OpenRISC and not having to pay a one time $50 USD licensing fee is, in my view, not enough of an incentive to start from scratch trying to fix something (UltraSPARC RISC) which does not need fixing.

Just to keep this clear, since I'm not really clear headed right now (a bit sick).

If some group with the resources and skills wanted to they could take UltraSPARC T1/T2 code, update the CPU with modern techniques for the design, and then ship it off to a fab company to have it built and sold and Sun's patents wouldn't be infringed upon so long as they make it Free software?

I don't know what you would change but from my understanding CPU design has had some major changes since this CPU so I'm assuming there are tricks or things that could be done to speed the thing up but then again I don't know.

I wish someone capable did this. Having a Free CPU would be great. It would be especially great for this sort of RISC CPU to create a new low-power high-performance that was promised.

Remember...

    RISC architecture is gonna change everything - Hackers (1995)

Reply on news.ycombinator.com