Grundrechenarten in C

Billy12345 schrieb:

Mir geht es darum wie z.B. die unten stehende C Anweisung (Division der Zahlen) intern

Das hängt vom Zielsystem ab. Hat das einen eingebauten Divisionsbefehl, dann so wie im Beispiel von SeppJ.
Wenn nicht, dann ist der DIV-Befehl in einer (Assembler-)Unterfunktion.

Billy12345 schrieb:

bzw in der Programmiersprach C realisiert ist.

So wie du es hingeschrieben hast.

Ich nehme an, du willst wissen wie diese Unterfunktion funktioniert.
Da schaust du am besten mal bei den Systemen vorbei, die keinen eingebauten DIV-Befehl haben.
Das waren früher die Prozessoren in den Heimcomputern 6502 bzw Z80 und heute noch bei Mikrocontrollern: http://www-user.tu-chemnitz.de/~heha/Mikrocontroller/Division.htm

Aber wie schon gesagt, ist das nicht anders als bei der schriftlichen Divison (Grundschule) im Dezimalsystem.

Beim Dualsystem im Computer kann man allerdings noch ein paar Vereinfachungen machen.

merano

SeppJ schrieb:

.., die rechnet auch nichts. Diese Sprache kann man in die Maschinensprache eines x86-Prozessors übersetzen. Das kann ich nicht mehr zeigen, die menschenlesbare Variante davon wäre ein wilder Zeichensalat.

Wie bitte ? Alle Maschinencodes kann man (notfalls) von Hand auch in einem Hexeditor eingeben. Was soll daran wild sein ?

; 9    : 	int a=2; 

  0001e	c7 45 f8 02 00
	00 00		 mov	 DWORD PTR _a$[ebp], 2

; 10   : 	int b=3; 

  00025	c7 45 ec 03 00
	00 00		 mov	 DWORD PTR _b$[ebp], 3

; 11   : 	int ergebnis=0; 

  0002c	c7 45 e0 00 00
	00 00		 mov	 DWORD PTR _ergebnis$[ebp], 0

; 12   : 	ergebnis=a/b;

  00033	8b 45 f8	 mov	eax, DWORD PTR _a$[ebp]
  00036	99 		cdq
  00037	f7 7d ec	 idiv	DWORD PTR _b$[ebp]
  0003a	89 45 e0	 mov	DWORD PTR _ergebnis$[ebp], eax

Kommentar: Nach dem Optimieren mit einem aktuellen Compiler bleibt von diesem Code fast nichts über, lediglich
das bereits absehbare Ergebnis.

SeppJ

merano schrieb:

Wie bitte ? Alle Maschinencodes kann man (notfalls) von Hand auch in einem Hexeditor eingeben. Was soll daran wild sein ?

Das ist nicht der Maschinencode, sondern eine Darstellung als Hexadezimalzahl für Menschen. Der Maschinencode selbst ist das, was du siehst, wenn du eine Executable am Bildschirm ausgibst. Wilder Zeichensalat.

Bashar

Der Zeichensalat ist weiter weg vom Maschinencode als die Hex-Zahlen.

Th69

Sehe ich auch so.
Am nächsten dran wäre wohl die Darstellung aus 0 und 1 (also als Bits).

merano

SeppJ schrieb:

Das ist nicht der Maschinencode, sondern eine Darstellung als Hexadezimalzahl für Menschen. Der Maschinencode selbst ist das, was du siehst, wenn du eine Executable am Bildschirm ausgibst. Wilder Zeichensalat.

Was soll man von jmd. halten, der eine Binärdatei als Textdatei öffnet ?

Das ganze ist ohnehin weit vom ursprünglichen Thema weg und der Fragesteller nicht mehr interessiert.

SeppJ

Th69 schrieb:

Sehe ich auch so.
Am nächsten dran wäre wohl die Darstellung aus 0 und 1 (also als Bits).

Was haben Bits damit zu tun? Entgegen landläufiger Meinung arbeiten Prozessoren nicht mit Bits. Bits sind ein Konstrukt aus der Informatik.

Th69

Und darum spricht man auch nicht von 8-Bit-, 16-Bit-, 32-Bit- oder 64-Bit-Architektur?

Natürlich weiß ich, daß Prozessoren intern aus Transistoren und FlipFlops bestehen - letztere stellen aber das Äquivalent zu einem Bit dar.
Und ein Prozessor-Befehl (Opcode) ist einfach ein Datenwort (bestehend aus mehreren Bits), s. Prozessor - Wortbreite.

Bashar

Ich glaub SeppJ hat zuviele Trolle gefrühstückt.

SeppJ

Th69 schrieb:

Und darum spricht man auch nicht von 8-Bit-, 16-Bit-, 32-Bit- oder 64-Bit-Architektur?

Weil sie diese Informationsmenge gleichzeitig verarbeiten können. Die Sprache der Maschine beruht aber nicht auf Bits sondern eben aus elektrischen Signalen. Und zwar immer gleich ganz viele auf einmal. Eine serielle Folge von Bitinformation ist die völlig falsche Vorstellung.