Verwendet jede API eine API die schlussendlich in Assemblercode geschrieben wurde?

5 Antworten

Ich empfehle Dir mal den Artikel auf Wikipedia anzuschauen. Gleich ganz oben ist ein Bild, das den Unterschied zwischen API und ABI aufzeigt.

Die API ist eine Schnittstellenbeschreibung auf Ebene der jeweiligen Hochsprache und entsprechend abstrahiert. Natürlich endet eine Bibliothek, die in C geschrieben wurde als Maschinencode, ebenso wie ein Binary, das diese nutzt. Die Details der Interaktion auf der Maschinenebene inklusive Calling Convention fallen eben der ABI zu.

Nein.

Meist wird es erst zu assembly Code(meist LLVM IR, aber kommt drauf an welcher Compiler), und dann zu machine Code(je nach Platform). Low level assembly sprachen, wie x86 assembly, wird meist übersprungen und direkt zu machine Code.

Außerdem, mit einem API hat das nichts zu tun. API ist eine Schnittstelle mit der eine Software auf einen andere software zugreift.

Du meinst wohl eher Kompilierung oder ähnliches.

Nein. Assembler wird eigentlich kaum noch verwendet. Komplette Betriebssysteme werden in Kompilierten Hochsprachen wie C oder C++ geschrieben und unter dem Kernel etc des Betriebssystems ist eigentlich keine API mehr sondern direkt die Hardware.

Wenn du nun dein Programm schreibst dann ruft es die API des Betriebssystems auf und diese ist eben dann sehr wahrscheinlich in C oder C++ geschrieben.

Denkbar sind da aber alle Kompilierten Hochsprachen oder auch theoretisch Assembler, wobei der bis auf wenige Ausnahmen, wie gesagt, kaum noch verwendet wird.

Man könnte hier natürlich noch sagen, dass das OS selbst den Microcode im Prozessor als eine Art weitere schicht hat, aber das hat nicht mehr wirklich etwas mit einer API zu tun.

Naja, nicht unbedingt "APIs die APIs verwenden die APIs verwenden", aber im Prinzip hast du schon recht.

Der Prozessor kann nur Maschinencode ausführen. Auf unterster Ebene werden dann irgendwann halt nicht mehr "APIs" benutzt, sondern irgendwann landest du halt bei einzelnen Befehlen und Anweisungen (in einer Methode z.B.). Diese werden dann vom Compiler in Maschinencode übersetzt und werden dann vom Prozessor ausgeführt.

Oder die Befehle und Anweisungen werden von einem (Bytecode-)Interpreter ausgeführt. Beim Interpreter geht das Spiel dann halt weiter: der ist wieder mittels Klassen und Methoden implementiert, die irgendwann halt auch einzelne Anweidungen und Befehle verwenden - die wieder in Maschinencode implementiert sind.


Dairo892 
Beitragsersteller
 17.10.2023, 04:57

Also wenn man eine hohe API benutzt landet man Ende immer bei einer API die schlussendlich direkt mit Maschinencode oder Assemlbercode geschrieben wurde und z.B.: kein kompilierte Code einer hohen Sprache ist?

VanLorry  17.10.2023, 05:01
@Dairo892

Nein, heutzutage normalerweise nicht. In der Regel wird immer eine Hochsprache verwendet (oft C++ oder C), die mit dem entsprechenden Compiler dann aber in Maschinencode übersetzt wurde.

Dairo892 
Beitragsersteller
 17.10.2023, 05:04
@VanLorry

Man kann doch aber nicht mit reinen C++ Code eine Anwendung mit z.B.: eine GUI erstellen dafür braucht man doch auch wieder Bibliotheken die dir APIs zur verfügung stellen?

jort93  17.10.2023, 05:13
@Dairo892

Du brauchst keine Bibeltheken dafür. Reiner c++ code geht auch.

Dairo892 
Beitragsersteller
 17.10.2023, 05:15
@jort93

Also reichen die ganzen Konzepte und Schlüsselwörter von C++ aus um alles zu entwickeln ohne eine API zu verwenden?

jort93  17.10.2023, 05:42
@Dairo892

Ja. Es ist Turing vollständig, man kann also alles programmieren.

Da CPUs und das "Drumherum" ausschließlich Maschinencode "verstehen", ein solcher Binärcode aber für uns absolut unübersichtlich ist, "landet" letztlich natürlich jede Hochsprache als Maschinencode im Rechner. Völlig egal, ob API oder sonstwas.

Lax formuliert kann man sagen, Maschinencode ist die unterste, direkte Ebene, Assembler "gleich darüber", die Hochsprachen wiederum darüber. Maschinencode und Assembler "wissen" nicht, wie das was sie tun sollen in der jeweiligen Hochsprache, wie sie dort definiert, klassifiziert sind.