|
|
|
| Authored by: s65_sean on Tuesday, May 01 2012 @ 06:14 PM EDT |
| Why would anyone buy a CPU that they couldn't program? [ Reply to This | Parent | # ]
|
| |
| Authored by: sproggit on Tuesday, May 01 2012 @ 06:18 PM EDT |
This is the obvious example to quote when we are discussing instruction
set compatibility. Back in the day there were several companies that started
up in the clone x86 market.
At the time there were companies like AMD and Cyrix who made chips that
were plug-compatible with Intel based motherboards, but which offered
faster processing per CPU cycle. Intel spent a lot of time and money trying
to fight off AMD and others, but as I recall Intel's arguments got nowhere
when AMD and others showed that they had implemented their own silicon
that just happened to recognise the same binary codes as x86.
Intel were still worried about competition, though, so their solution was to
ignore the software and microcode of their processor designs and instead
focus upon the physical design properties of the sockets that the CPUs
slotted into. That's why that, for example, the Pentium 2 family of chips
moved from sockets to slots and a verticle packaging. It is also why Intel
have regularly changed socket designs over the years - to make it harder
for the clone manufacturers.
Ironically, AMD often had the better chip designs (first to true 64 bit, better
graphics instructions) but Intel always had the better fabrication technology.
With hindsight some may argue that Intel's real killer blow in the
marketplace was not, in fact, a technical breakthrough, rather what was
claimed to be success in inducing hardware suppliers to abandon AMD
processors...
But you raised a fascinating point which I had not previously considered,
because, after all, AMD's processor microcode is binary compatible and yet
delivered via different silicon. Much like Google and Harmony have
implemented Java methods, but written their own code. And don't forget
that because chips are physical things Intel have the added advantage of
applying patent protections as well. They do not, to my knowledge, rely on
the style of fast-talking argument that BSF applied here.[ Reply to This | Parent | # ]
|
| |
| Authored by: tiger99 on Tuesday, May 01 2012 @ 06:32 PM EDT |
| ...., when real men allegedly programmed in assembler, certain of Intel's design
team, who had worked on the 8080. left to form Zilog, and allegedly for legal
reasons had to invent a new set of mnemonics for the instruction set, which was
a superset at binary level. Effectively they gave it a completely new API. Wikipedia However, no such
thing has ever happened since, indeed Intel has apparently done nothing to
prevent the same API being used by various manufacturers of x86 clones, which
suggests that every semiconductor manufacturer realised that the API "might" be
copyrightable, but enforcing it would just be plain stupid. Anyone who can't use
it freely will not buy their hardware, which is the thing that earns them
money. Actually, at assembler level, where there is a one to one mapping
between lines of code and machine instructions, it is not all that hard to
re-write the API with a new set of names, and run a simple script to edit the
program source to match. The assembler likely just needs a new instruction
table. I don't believe that this has any relevance to the Oragoogle case,
because higher level APIs as in Java have no direct relation to the hardware,
and in any case multiple versions of non-Java, using the exact same API names
and parameter definitions, have been allowed for years. IANAL, but laches or
estoppel or something like that comes to mind. Oh, and one last thought,
binary numbers cannot be copyrighted, and the ABI is pure binary numbers, raw
instructions and data, but the binary code is a directly derived work of the
assemnly level API. I don't see how copyright law can handle that. [ Reply to This | Parent | # ]
|
|
|
|
|
