3 ms·

Proprietary versus open instruction sets [pdf]

38 points by jsnell 10y ago

Someone 10y ago
"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.
- skissane 10y ago
  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.
  - Nomentatus 10y ago
    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.
  - pjmlp 10y ago
    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 https://msdn.microsoft.com/en-us/library/ms834338.aspx Processor independence is also a reason why mobile OSes are going into this direction.
- microcolonel 10y ago
  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.
gravypod 10y ago
Why is there no mentioning of SPARC or other open source RISC architectures.
- 0xcde4c3db 10y ago
  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/ https://riscv.org/2014/10/why-not-build-on-openrisc/
  - nickpsecurity 10y ago
    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. :)
  - Annatar 10y ago
    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?
    - 0xcde4c3db 10y ago
      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-146.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...
phkahler 10y ago
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.
deleted 10y ago
[deleted]

38 points by jsnell 10y ago

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

skissane 10y ago
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.
- Nomentatus 10y ago
  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.
- pjmlp 10y ago
  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 https://msdn.microsoft.com/en-us/library/ms834338.aspx Processor independence is also a reason why mobile OSes are going into this direction.
microcolonel 10y ago
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.

gravypod 10y ago

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

0xcde4c3db 10y ago
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/ https://riscv.org/2014/10/why-not-build-on-openrisc/
- nickpsecurity 10y ago
  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. :)
- Annatar 10y ago
  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?
  - 0xcde4c3db 10y ago
    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-146.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...

phkahler 10y ago

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.

deleted 10y ago

[deleted]