feature article
Subscribe Now

Is an Instruction Set an API?

Recent Google v. Oracle Ruling Raises Questions as Well as Answers

No less an authority than the United States Supreme Court just ruled that a program’s application programming interface can be copied under the doctrine of copyright “fair use.” Google copied thousands of lines of Oracle’s code in order to implement its own version of the Java API without actually licensing the official Java API. The Court ruled that Google didn’t need a license because it’s okay to duplicate the API without one. 

In a sense, this was no big deal because most programmers were already operating under this assumption. It feels logical, and it generally passes the programmers’ sniff test. An API isn’t like “real” code. It’s just an interface, a definition or specification, and not the same as code that carries out the actual function. 

Indeed, the lawyers arguing the case made this distinction, too. They described some parts of Java as “declaring code” and other parts as “implementing code.” The APIs fell into the former category, while the bulk of the software was in the latter. Here’s how they describe it in the official decision: 

“…the declaring code’s shortcut function is similar to a gas pedal in a car that tells the car to move faster or the QWERTY keyboard on a typewriter that calls up a certain letter when you press a particular key. As those analogies demonstrate, one can think of the declaring code as part of an interface between human beings and a machine.” 

There you have it. It’s an interface. 

So… does this interface definition extend to hardware, too? Is the pinout of a device subject to copyright, or the protocol of a serial bus, or the way a DRAM works? To blur the distinction even more, is a microprocessor’s instruction set also an interface, and, if so, is it protected under copyright law? And what effect might such a legal decision have on programming? 

I would argue (in a decidedly non-judicial way) that an ISA is an interface. It’s where the software meets the hardware. Without a defined instruction set there’s no way to program a CPU or MCU. That’s what programming is. 

Now, the mnemonics of that instruction set are a different matter. The processor doesn’t care if you call the MOV instruction MOV or MOVE or mov-it or Loretta. (“I wish I’d spelled creat with an ‘e’,” said Ken Thompson, creator of Unix.) Mnemonics are purely a human-readable shorthand for assemblers and debuggers. The chip never sees them, of course. You could rename every single instruction in your ISA and the chip would be none the wiser. You’d have a miserable time writing code, though. 

Interestingly, you can publish a book of other people’s instruction sets. I’ve done it. The ISA is entirely somebody else’s creation, but writing it all down is permitted under fair use. You do have to write your own original descriptions of what each instruction does, and you have to draw your own diagrams, but the mnemonics themselves and what they do are not protected. 

Can you protect the instruction set of a processor? Case history suggests you cannot. There are obviously copies of Intel’s x86 instruction set as well as previous MIPS workalikes, off-brand ARM chips, 8051 replicas, plus other clones, doppelgängers, knockoffs, reproductions, and imitations of almost every CPU or MCU you can think of. Some of these ISAs are harder to duplicate than others, and some have been more successful than others, but that’s beside the point. Those are technical and commercial concerns, respectively. Creating a CPU that runs someone else’s code is usually on solid legal ground. 

The exception is when you duplicate the internal workings of the processor. That’s not okay. More than a few ARM and MIPS knockoffs met their end because they followed too closely the circuitry required to implement certain operations, not because of the operations themselves. They ran afoul of patent law, not copyright law. Simply having the FOOBAR instruction in your ISA repertoire is generally okay, but you have to implement it with “clean room” hardware that doesn’t step on someone else’s patents. That’s where it gets tricky. Intel and AMD processors have nearly identical instruction sets, but their internal microarchitectures are very different. 

Let’s muddy the waters further. What if the processor is microcoded? Complex processors like those from Intel and AMD crack their complex opcodes into simpler micro-operations (uops). A single x86 instruction might translate into several uops that run under the direction of a uop sequencer. That sequencer is programmed; its firmware lives in ROM inside the processor. So, your Ryzen or Xeon is really running code that enables it to run code. It’s perpetually in x86 emulation mode. The “real” instruction set – the uops – is an internal secret. 

Can you copy that? Is it protected code – the “implementing code” in the above legal definition – or is it simply an interface of “declaring code?” Nobody outside of Intel’s or AMD’s own engineers will ever see or use that microcode, and they can presumably change it any time they want to. The uops are completely invisible to normal programmers, who often don’t know it exists. So, the question may be moot. It’s not much of an interface if nobody interfaces to it. If a microprocessor crashes in the forest and no one’s there to reboot it… 

Looking again at the Google v. Oracle decision, the Supreme Court said: 

“The doctrine of ‘fair use’ is flexible and takes account of changes in technology. Computer programs differ to some extent from many other copyrightable works because computer programs always serve a functional purpose. Because of these differences, fair use has an important role to play for computer programs by providing a context-based check that keeps the copyright monopoly afforded to computer programs within its lawful bounds.” 

They’re saying that programming isn’t the same as artwork, music, photography, stage plays, or movies because it’s functional, not decorative. Thus, the fair use doctrine is needed to prevent computer programs from being completely off-limits. It “keeps the copyright monopoly… within lawful bounds.” 

The Court also hints at an answer to our question of protecting instruction sets: 

“For most of the packages in its new API, Google also wrote its own declaring code. For 37 packages, however, Google copied the declaring code from the Sun Java API. As just explained, that means that, for those 37 packages, Google necessarily copied both the names given to particular tasks and the grouping of those tasks into classes and packages.”

The key part here is, “Google necessarily copied… the names given to particular tasks…” which makes it sound like cloning mnemonics is okay, which we kind of already knew. After all, AMD uses the same mnemonics as Intel, even for new instructions that were added long after those companies’ licensing agreement expired. And other x86 chipmakers use the same mnemonics, too. 

If copying the mnemonics is okay, is copying the binary encoding okay? That’s what really matters, since mnemonics are only human-readable, but opcodes are machine-readable. Precedent would suggest that it’s legal. We wouldn’t have binary compatible processors otherwise. 

Bottom line, copyright law has little to say about microprocessors. You can’t prevent someone from describing your instruction set, or even duplicating its essential functions. In both human- and machine-readable form, cloning an existing ISA is fair game. Or fair use. 

Patent protection still applies, of course, and it’s the more relevant concern in most cases. You can’t copy another processor’s circuitry if such circuitry is covered by patent. (You can if it’s not patented.) For most basic CPU operations, that’s not too onerous. It’s pretty easy to build an adder or a shifter without violating patents. Complex instructions are harder, and sometimes an instruction seems to be deliberately designed to throw legal landmines in front of the clone makers. 

The third way to protect IP is to treat it as a trade secret. Patents and copyrights both require disclosure. You get limited legal protection in return for describing your technique well enough that others can duplicate it after that protection expires. Trade secrets offer no such protection, but also no disclosure. It’s… a secret. That’s a good approach for recipes (e.g., Coca-Cola) and magic tricks, but risky for electronics, which can often be reverse engineered. If someone discovers your trade secret, you have no recourse. 

The Supreme Court decision has clarified some software issues but seems to have little bearing on hardware, or the interface between hardware and software. That’s probably a good thing. Microcoded or hardwired, patented or open source, it looks like copyright law doesn’t apply to CPUs. Until it does.

2 thoughts on “Is an Instruction Set an API?”

  1. to do it right, the law has to get into ideas and and their representation and lack of physical being and originals and copies and what makes up what we call reality itself ( the only commonality of intellectual property with actual property is the sense that it is proper to someone )….tricky stuff, and I guess they’ll really be earning their pay

  2. How would an intellectual property case be handled in which a copyrighted algorithm description, text or graphical code, is synthesized directly to substrate hardware and not to a Turing processor. This is the case with patent US 10,181,003. Specific synthesized hardware from an algorithm description is not claimed but the hardware function of each atomic hardware part is claimed. It seems to me with this Supreme Court ruling, copying a Flowpro Machine or GPU algorithm description and compiling it to a Turing processor is “fair use” copyright material.

    I am a proponent of SEPs (Standards Essential Patents) because they support standards, revenues, and fairness in licensing without using copyright as a legal fence around intellectual property. That fence just got easier to get over.

Leave a Reply

featured blogs
Jul 29, 2021
Circuit checks enable you to analyze typical design problems, such as high impedance nodes, leakage paths between power supplies, timing errors, power issues, connectivity problems, or extreme rise... [[ Click on the title to access the full blog on the Cadence Community sit...
Jul 29, 2021
Learn why SoC emulation is the next frontier for power system optimization, helping chip designers shift power verification left in the SoC design flow. The post Why Wait Days for Results? The Next Frontier for Power Verification appeared first on From Silicon To Software....
Jul 28, 2021
Here's a sticky problem. What if the entire Earth was instantaneously replaced with an equal volume of closely packed, but uncompressed blueberries?...
Jul 9, 2021
Do you have questions about using the Linux OS with FPGAs? Intel is holding another 'Ask an Expert' session and the topic is 'Using Linux with Intel® SoC FPGAs.' Come and ask our experts about the various Linux OS options available to use with the integrated Arm Cortex proc...

featured video

Breakthrough FPGA news from Intel

Sponsored by Intel

As part of the numerous portfolio announcements associated with the launch of the 3rd Gen Intel® Xeon® Scalable processor, Intel also disclosed some breakthrough FPGA news: Intel® Agilex™ FPGAs now deliver industry-leading power efficiency and performance.

Click here for more information about Intel® Agilex™ FPGAs.

featured paper

Configure the charge and discharge current separately in a reversible buck/boost regulator

Sponsored by Maxim Integrated

The design of a front-end converter can be made less complicated when minimal extra current overhead is required for charging the supercapacitor. This application note explains how to configure the reversible buck/boost converter to achieve a lighter impact on the system during the charging phase. Setting the charge current requirement to the minimum amount keeps the discharge current availability intact.

Click to read more

featured chalk talk

Industrial CbM Solutions from Sensing to Actionable Insight

Sponsored by Mouser Electronics and Analog Devices

Condition based monitoring (CBM) has been a valuable tool for industrial applications for years but until now, the adoption of this kind of technology has not been very widespread. In this episode of Chalk Talk, Amelia Dalton chats with Maurice O’Brien from Analog Devices about how CBM can now be utilized across a wider variety of industrial applications and how Analog Device’s portfolio of CBM solutions can help you avoid unplanned downtime in your next industrial design.

Click here for more information about Analog Devices Inc. Condition-Based Monitoring (CBM)