
Proprietary versus open instruction sets [pdf] - jsnell
http://research.cs.wisc.edu/multifacet/papers/ieeemicro16_card_isa.pdf
======
Someone
_" 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
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
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.

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

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

~~~
0xcde4c3db
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/)

~~~
Annatar
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
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-...](https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-146.pdf)

~~~
Annatar
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_.

~~~
gravypod
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)

