The ISA as an API You Cannot Extend
June 18, 2021

Machine-interface noteOriginally posted 2021-06-18; rewritten here around the ISA as a fixed hardware/software contract.

Included: instruction sets, software portability, custom datapaths, timing, state placement, and why hardware literacy changes what a programmer can express.

An ISA Is a Contract

An instruction set is the public contract a program receives from a processor. That contract is valuable because it gives portability, tooling, operating systems, debuggers, compilers, and decades of accumulated practice.

It is also a boundary. If the needed operation is a new datapath, a different state placement, a timing-critical circuit, or a small parallel machine, software cannot add that primitive by naming it. The program can only compose the instructions the machine already exposes.

What Software Cannot Add by Itself

Software can emulate missing behavior, but emulation keeps paying for the original execution shape. A custom hardware path can put storage, routing, comparison, accumulation, and control where the work actually happens.

That is why Verilog or another hardware-description path is useful for software engineers. It teaches timing, registers, fanout, resource sharing, and the cost of moving data. Those constraints are present whether or not the software layer admits them.

Useful Scope

The practical point is knowing when the ISA is the wrong level of expression. Some systems need a new instruction. Some need a coprocessor. Some need an FPGA region. Some need to stay ordinary software because the fixed contract is exactly what makes them maintainable.