Is assembly language an API of sorts?

[Maximilian]

Am I understanding it correctly? Different processor architectures do fancy things with 1's and 0's that are pretty complex so they present an API of sorts which consist of the assembly instructions which can be used more easily that trying to directly manipulate the transistors on the chip (which as far as I can tell today would be freaking impossible).

 

[KWiklund]

No. Assembly language instructions represent the fundamental operations that the microprocessor carries out. The mnemonics allow for a human-readable input, but they really just stand for the actual binary codes for the instruction. The binary codes in turn specify which blocks in the datapath are active for a given instruction. While this is a bit of an over- simplification for newer, more complex chips, it's still the basis on which they operate and is certainly true for simpler microcontrollers and older chips.

 

[Markbnj]

The term API is sufficiently broad and subjective that you can stretch into a lot of different contexts. You could _almost_ stretch it to cover assembly language and call it an API to the processor... but it would be a real stretch since few if any 'applications' are coded at that level anymore. In any event, it would be obviously outside the spirit of the definition.

KWiklund, the most fundamental instructions that a CPU executes are opcodes. Assembly language instructions are mnemonic symbols for opcodes. A nit, perhaps, but if we're talking fundamental.

 

[brandonb]

I've always taken an API as an interface. Meaning, it abstracts out the implementation and provides an interface to work with.

Much like a datatype would be (string, integer)... You work with the interface or the API, but the implementation of how that works behind the scene is unknown, and handled by the implementation even though you are working with the interface in your program.

 

[KWiklund]

KWiklund, the most fundamental instructions that a CPU executes are opcodes. Assembly language instructions are mnemonic symbols for opcodes. A nit, perhaps, but if we're talking fundamental.

I'm well aware of this. What I was getting at though was that the opcodes themselves represent particular choices of what is going on in the datapath itself (eg. the inputs to a particular multiplexer, etc). A common lab exercise for when I was an undergraduate for example used to be to build a simple system out of TTL chips that included many of the basic operations found in a simple CPU including ALU and memory access.

but it would be a real stretch since few if any 'applications' are coded at that level anymore

In general this is true, especially for general purpose processors. You'll still find a fair bit of it in embedded and DSP programming. Even then, it's mostly used only for performance-critical functions, or in those few chips without well-developed tools.

@Maximillian. If you're interested in this at a deeper level. I'd recommend looking at Mano and Kine's book on digital design. They build on this subject from the ground up. Hennesy's book is also often recommended, but is usually used for upper-level undergraduates rather than as an entry-level book like M&K's is.

 

[Merad]

Assembly language is part of an Instruction Set Architecture (ISA) that documents the behavior of a family of processors. It tells you what instructions are available, registers, addressing modes, etc. Conceptually I guess it's a kind of API, because you don't have to know how a processor actually implements any of this stuff, only the effects of the instructions.

For example, most x86 CPUs break each instruction up into multiple RISC like micro-ops. The exact sequence of μops may also vary between processors. All you need to know is the documented "API" that says, for example, addl %eax, %ebx will add eax to ebx, store the result in ebx, and set status flags.