Frage zu Variablen (C++)

Hallo,

also was mich interessieren würde:
Bei Variablen vom Typ short , long.. usw. wird ja nur ein bestimmter Wertebreich abgedeckt.

Woraus ergibt sich dieser??? Wurde das willkürlich festgelegt, oder ist das auf die Struktur des hexadezimalen Systems zurückzuführen?

Was mich weiter interessieren würde:

Ist es möglich, einem Rechner eine "neue" Programmiersprache beizubringen und wenn ja, wie?

C++ wurde ja auch irgendwann mal erfunden... und der Rechner mußte diese erst interpretieren.

Ich mein jetzt z.b. wenn ich versuchen würde eine eigene Programmiersprache zu erfinden (hab ich jetzt nicht vor, aber mich interessiert es halt), z.B. in deutscher Sprache, und ich würde z.B. Befehle definieren wie : Erzeuge Fenster 100*200 , und das soll dann automatisch laufen, dann muß ich ja erst mal dem Rechner beibringen, was ich mit diesem Befehl überhaupt grundsätzlich will.

Wie funktioniert das???

Bei Dos 1.0 mußte dem Rechner ja auch erst das ganze System "gelernt" werden, oder ???

Sorry, für diese vielleicht etwas naiven Fragen, aber mit der Programmierung kenn ich mich überhaupt nicht aus und es ist für mich einfach faszinierend, was so alles möglich ist.

mfg ghostrider

 

Danke für die vielen lehrreichen Erklärungen.

Jetzt hab ich wieder eine Menge dazugelernt.

mfg ghsotrider

 

Danke,

waren wirklich sehr lehrreiche Antworten.

Also Fazit:

Der "Ur-Cpu-Befehlssatz" wird vom Hersteller der CPU festgelegt, die der Softwareprogrammiere dann aber kennen muß, um diese auch entsprechend nutzen zu können.

Hoffe, daß ich hier den richtigen Schluß aus Euren Antworten gezogen habe

mfg ghostrider

 

Der Begriff des Debuggers geht in die Zeit der Röhren-Computer zurück. Damals hatten die Informatiker ein großes Problem, und das waren Insekten. Ameisen usw zogen in die raumgroßen Rechner ein und hie und da kam eines der Viecher in die Beschleunigerspannung (ein paar kV) der Röhren. Dann gab es einen Kurzschluß und alle Röhren, die an der Strippe hingen waren aus. Dann musste der Debugger (Bug ist englisch für Käfer) kommen, den Bug (=der Fehler) finden und herausfitzeln.

Heutige Debugger mache (fast) das Selbe: Sie beobachten den Programmablauf eines ausgewählen Programms und wenn irgendwo ein Fehler auftritt (z.B. eine Zugriffsverletzung oder eine verbotene Aktion - Divison durch Null z.B.) dann wird der Debugger aktiv und meldet die Stelle im Programm zurück, wo der Fehler auftrat und gibt genauere Infos was denn das für ein Fehler war. (z.B. bedeutet "runtime error 200 at 0060:A567" eine Divison durch Null an der entsprechenden Programmstelle. Besitzt man nun den Quellcode und die Map-Datei dazu, dann kann man genau sage, in welcher Zeile des Quellcodes der Fehler auftrat). Weiters kann man sich von dem Debugger auch den Maschinen- bzw Assemblercode des Programms anzeigen lassen.

zum Nachtrag: die Grundbegriffe SIND die Maschinensprache. Der Prozessor versteht nichts anderes als genau diese paar hundert Befehle. Sollte bei einem Befehl auch nur ein Bit nicht stimmen, dann wirft der Prozessor kalt lächelnd eine illegal instruction und der betreffende Thread stürzt ab.

mfg KazHar

 

Danke Harald für Deine sehr aufschlußreichen Erklärungen, ich denke, daß ich jetzt eine Menge wieder dazugelernt habe, vor allen Dingen auch in verständlicher Form...

Jetzt würd ich nur noch gerne wissen, für was ein Debugger gut ist.
Nachtrag:

Und diese Grundbegriffe, liegen dann direkt schon in Maschinensprache vor, oder ??? Nachtragende
mfg ghostrider

[Diese Nachricht wurde von ghost rider am 23.04.2002 | 10:21 geändert.]

 

er-Realmode! 386\'er-Virtualmode wäre richtig!!

 

Diese "Grundbegriffe" sind in Hardware gegossen. Die CPU kann garnicht anders als genauso zu reagieren wie das vorgesehen ist (außer sie ist defekt ) und das ist auch nach der Herstellung nicht mehr änderbar (zumindest bis zum Pentium) - Diese Zuordnung heißt übrigens Befehlssatz.
Wenn Du einen Intel-Prozzi durch einen Alpha-Chip ersetzen (mal angenommen er würde auf das Mobo passen) würdest, dann würde der pausenlos "illegal instruction" schreien, weil die Befehlssätze nicht kompatibel sind (Intelkompatibe CPU = CISC - Complex Instruction Set; Alpha CPU = RISC - Reduced Instruction Set)
Das BIOS (=Basic Input/Output System) übernimmt nur die Steuerung der wichtigsten Funktionen des Mobos (Erkennung und Timing der Komponenten, Basisfunktionen der Interruptsteuerung, ...) und bietet einfache Ein/Ausgabe - Routinen (Textbildschirm, Tastatur, Festplatten- und Diskettenzugriff).

Weil ich übrigens immer "bis zum Pentium" schreibe...
Ab dem Pentium Pro hat Intel einen Trick 17 eingeführt. Die CPUs wurde einfach zu komplex, zu unüberschaubar und zu teuer, weil immer wieder neue Befehle eingeführt wurden (386\'er RealMode-Befehlssatz, Pentium MMX-Befehlssatz usw) und dadurch immer neue Hardware-Teile hinzugefügt werden mußte. Man hat dann ein anderes Konzept gewählt: in jeder heutigen CPU sitzt eine RISC-CPU, die eine CISC-CPU simuliert

mfg KazHar

 

Hallo Kazhar,

freut mich, daß Du Dir soviel Mühe gibst, mir diese Anfängerfragen so ausführlich und geduldig zu beantworten.

Siehe bitte auch meine andere Antwort an jblank.

Jetzt fällt mir noch eine Frage ein:

Ich hab mir den Borland 5.5 Compiler geholt und da ist auch ein "Turbodebugger" dabei. Was macht jetzt ein "Debugger" genau ?

mfg ghostrider

 

Hallo jblank,

erstmal Danke für die Antwort. Ist mir schon klar, das der Prozzi die Binärcodes von Haus aus versteht. Aber um was es mir geht:

Der Rechner könnte doch eben auf die z.B. 101 mit einer beliebigen Atkion reagieren, die aber vielleicht gar nicht erwünscht ist.

Also muß er doch diese "Grundbegriffe" und deren Bedeutung schon vorher "mitgeteilt" bekommen... eben wie schon Kazhar gesagt hat, in seiner letzten Antwort, (Add 5 = im Akku 5 dazuzählen), das eben diese Prozedur damit gemeint ist und nicht 5 Abziehen, was der Prozzi ja theoretisch auch machen könnte, wenn er sozusagen um die Bedeutung selbst nicht "weiß".

Werden diese "Grundbefehle" schon bei der Herstellung der CPU implimentiert oder erst später durch den Programmierer des OS ???

Bzw. werden die evtl. sogar mit im Bios hinterlegt, denn ich könnte ja den Prozzi wechseln....???

mfg ghostrider

 

Sieh es doch mal so:

Der Maschinenbefehl "101" ist quasi das, was der Prozessor von Haus aus schon versteht. Der Befehl "movecdhead" (sprich: die lesbaren Befehle einer Programmiersprache) ist nur aus Lesbarkeitsgründen "besser" als der direkte Maschinenbefehl.

Eine neue Programmiersprache zu "erfinden", heißt dann aber nichts anderes, als einen Übersetzer zu erstellen, der deine eigenen Befehle (zum Beispiel "CDKopf_Bewegen") in die richtigen entsprechenden Maschinenbefehle umwandelt. So ein Übersetzer wird auch Kompiler genannt.

Man kann den Übersetzer natürlich selbst in Maschinencode schreiben, ist aber ziemlich mühsam. Einfacher, du nimmst eine bestehende Programmiersprache, zum Beispiel C, schreibst einen Übersetzer, der deine selbst erstellte Sprache versteht und daraus Maschinencode macht, und lässt dir diesen Übersetzer für deine Sprache dann selbst von der bestehenden Programmiersprache in Maschinencode übersetzen. Fortan hast du einen neuen Kompiler, der deine selbst erfundene Sprache "versteht" und daraus Maschinencode macht. Und den versteht dann der Prozessor direkt.

Maschinencodes sind übrigends wirklich willkürlich (bzw. nach gewissen definierten Standards) festgelegt und unterscheiden sich von Prozessorplattform zu Prozessorplattform. Das heisst, der Maschinencode "101" bedeutet auf einem Pentium was anderes als auf einem RISC-Prozessor. Folglich muss ein Kompiler (also ein Übersetzer) für eine Programmiersprache immer wissen, auf welches Zielsystem das Eingabeprogramm zu übersetzen ist. Übersetzt man ein C programm mit einem Kompiler für RISC-Prozessoren, so ist der entstehende Maschinencode auf einem Intel-System nicht lauffähig.

cya

 

s Befehle so (heute ist das etwas komplizierter und viel unübersichtlicher):
Zuerst läd sie den Befehlscode in ein spezielles Register, den Befehlsdecoder. Dieser Befehlsdecoder hat eine Unzahl von Ausgangsleitungen (das konnen durchaus 100 oder 200 sein), wobei jede dieser sog. Steuerleitungen einen anderen Teil der CPU einschalten kann. Eine dieser Leitungen schaltet z.B. den Addierer ein, eine andere den Subtrahierer oder irgendwelche IO-Schnittstellen. Aber einige dieser Leitungen wirken auch direkt auf den Teil der CPU, die die Befehle lädt.
Wenn der Befehl Parameter besitzt (z.B. ADD 5; Addiere 5 zu der Zahl im Akku; ADD = Befehlsteil, 5 = Parameter), dann werden im 2. Schritt die Parameter geladen.
Wenn das erledigt ist, dann wird der Befehl ausgeführt (die entsprechenden CPU-Teile bekommen den Parameter vorgesetzt) und das Ergebnis zurückgeschrieben.

Der Befehlscode/Parameter bedeutet bei allen x86-kompatiblen CPU\'s das Selbe. Jede CPU die sich so schimpft (sei es jetzt Pentium4, AthlonXP oder VIA-irgendwas) muß auf jeden Befehl das gleiche Ergebnis liefern - auch wenn die Art und Weise wie die CPU auf diese Ergebnis kommt unterschiedlich sein kann.

Bei der Peripherie siht das etwas anders aus, da ist nicht alles so schön genormt - daher braucht man auch Treiber.

mfg Kazhar

 

Hallo RSpezi,

danke erstmal für Deine Antwort.

Ja, ich kann mich noch "dunkel" an die Zeit erinnern, als die ersten Sendungen mit dem "ComputerClub" kamen, da war ich aber noch sehr, sehr jung...

Die bauten damals selber einen Rechner zusammen, und da gings auch um EPROM usw.

War auch noch die Zeit vom gutem C64 ... Sinclair... usw. halt noch die "Computersteinzeit"

 

Hallo KazHar,

erstmal Danke für Deine sehr , sehr ausführliche Antwort und Erläuterung.

Mit "dem Rechner eine neue Programmiersprache beibringen" meine ich folgendes:

als es z.B. Pascal , Fortran , Cobol , Visual Basic , C , C++ und wie sie noch alle heißen noch nicht gab, mußte man ja eben in Assembler Programmieren bzw. direkt in Maschinensprache, also in Binärform.

Wenn ich jetzt z.B. den Rechner anweisen will, daß er zu einem Bestimmten Zeitpunkt z.B. den Lesekopf des CDR-Laufwerks in eine bestimmte Positon fährt, dann muß er dazu ja letztendlich den richtigen Binärcode dazu erhalten.

Ich sage jetzt der Einfachheithalber mal dies würde der Binärfolge 101 und dem Befehl movecdhead entsprechen.

Wenn ich jetzt vorhabe, sozusagen eine auf deutsch basierte Programmiersprache zu erfinden, dann müßte ich jetzt dann doch die Zeichenfolge 101 dann einfach dem Namen des Befehls zuweisen, den ich mir dafür in deutsch Ausdenke, oder ?

Z.B. LesekopfCD bewegen = 101

Und in diesem Zusammenhang würde mich dann wieder interessieren, ob dann diese Binärcodes zur Hardwaresteuerung ebenfalls willkürlich festgelegt worden sind, und wie sie dem Rechner "beigebracht" wurden.

Denn der Rechner muß ja irgendwie "erfahren" bzw. "lernen", daß eben dann, um bei meinem Beispiel zu bleiben, die Binärfolge 101 bedeutet, daß er den Lesekopf des CD-Laufwerks bewegen soll, und nicht mit diesem Befehl das Laufwerk öffnet oder den Lese-/Schreibkopf der HDD bewegt.

Also, wie erfährt der Rechner die eigentliche Bedeutung des Binärcodes ???

Um es nochmal anschaulich zu machen:

Wenn wir den Begriff "Stuhl" sagen, z.B. dann weiß jeder was damit gemeint ist... jetzt könnte man (abgesehen davon dass es keinen Sinn machen würde) hergehen und eine neue Definition einführen... z.B: das mit Stuhl eben nicht mehr Stuhl gemeint ist, sondern z.B. dann eben "Tisch"...

dass müßte man dann eben "lernen". Und ein Computer kann ja nur 0 und 1 in verschiedenen Strukturformen (Reihenfolge) erkennen, aber er muß eben "wissen", [f] was [/f] damit gemeint ist....

also das 101 bedeutet, bewege den Lese/Schreibkopf des CD(R)-Laufwerks , und nicht dann was anderes macht... z.B. den Curser am Bildschirm eine Zeile nach unten zu versetzen oder das eben z.B. 001 eben [f] nicht [/f] bedeutet den Lesekopf der CdR zu bewegen, sondern was anderes.

Also muß dies doch irgendwann mal (willkürlich ?) definiert worden sein... denke ich mal. Denn sonst könnte jeder Rechner (CPU) die gleiche Binärcodefolge doch anderes interpretieren, wenn es nicht normiert und festgelegt wäre, oder ?

Ich weiß, das ist jetzt alles ziemlich abstrackt, aber ich finde es einen sehr interessanten Aspekt in diesem Zusammenhang.

mfg ghostrider

 

Hallo ghostrider!

Da hast Du Dir aber ein paar knifflige Fragen ausgesucht

1) Die Bereiche der Variablen sind nicht ganz so willkürlich wie es aussieht. Aber mit dem Hexadezimal-System hat das nur bediingt zutun, sonder mit den Binärsystem (also dem Zahlensystem zur Basis 2), mit dem die meisten Computer intern rechnen. Das umwandeln der zahlen in das Hexadezimal-System ist nur eine Vereinfachung für uns Menschen, weil Binär-Zahlen schnell sehr lang werden. 100 z.B. wird in Binär-System 1100100b und im Hex-System 64h geschrieben.
Jede Variable hat eine ganz bestimmte "Größe", damit ist der Speicherplatz gemeint, den sie belegt. Eine Variable des Typs short belegt 2 Byte, eine des Typs long 4 Byte. Welche Werte diese Variable annehmen kann ist damit vorgegeben: wenn eine Variable durch 2*8=16 Bit representiert wird, dann kann sie nur 2^16 verschiedene Werte annehmen. Eine vorzeichenlose (nur positive) short-Var beinhaltet 0 bis 65535 (=FFFFh), eine vorzeichenbehaftete short-Var kann -32768 bis 32767 darstellen. Der maximale Wert den eine 1-Byte Variable annehmen kann ist 255 (= 11111111b = FFh).

2) Ich habe nicht verstanden, was Du damit meinst "dem Rechner eine neue Programmiersprache beibringen". Prinzipiell kannst Du Dir jeden x86-Kompiler (also ein Kompiler, der Code für eine Intel-Cpu oder kompatibel ausgibt) aus dem Netz saugen, installieren und schon hast Du eine neue ProgLang auf Deinem Rechner.

3) Klar könntest Du Dir eine eigene Programmiersprache schreiben, das ist aber ein bisschen schwerer als "Hallo Welt" .
Es gibt da verschiedene Möglichkeiten: Die einfachste ist, man schreibt den Kompiler (das Programm das den Quellcode in ausführbaren Maschinen-Code übersetzt) und die Bibliotheken (eine Art Programm-Schnipsel-Sammlung, aus deren Bestand dann das eigene Programm wie aus einem Baukasten zusammengesetzt wird) in einer anderen Programmiersprache - C bietet sich dafür an. Dadurch erspart man sich eine menge Arbeit, aber man ist etwas eingeengt. Die aufwendigste Methode ist, Kompiler und Bibliotheken in Assembler oder gar Maschinencode zu schreiben. Damit fängt man quasi bei Null an und darf auch so Dinge wie Hardwareinterfaces, Variablendefinitionen und -Representation usw selber machen. Meistens wählt man aber einen Mittelweg und schreibt nur die Teile, auf die man besonderen Wert legt in Assembler.
Das was Du ansprichst (Sprache auf Deutsch umstellen) läßt sich aber viel einfacher mit einem Satz Macros oder einer "Übersetzungs-Unit" erreichen, die einfach OpenWindow durch ÖffneFenster ersetzt.

4a) Dos (egal in welcher Version) ist eigentlich kein echtes Betriebsystem. Das Einzige was es kann und tut ist Laufwerke verwalten (DOS = Disk Operating System) und Programme starten alles andere muß in die User-Programme eingebaut werden. Das ist übrigens auch der Grund warum manche Dos-Spiele nicht unter WinNT funktionieren: Die Spiele versuchen, das was sie unter Dos tun mussten (Grafikkarte/Soundkarte direkt ansprechen), auch unter Windows - und das dürfen sie dort nicht, weil da das OS die Hand drauf hat.

4b) Wie bekommt man ein Betriebsystem in einen Rechner? Antwort: Mühsam!!
Im Ernst: Heuzutage kommt man um einen 2. Rechner (auf dem bereits ein anderes OS drauf ist!) nicht herum. Dort muß man das neue OS schreiben (das ist um einiges komplexer als ein Programm schreiben), also den Bootloader (das Programm im Masterbootrecord der Festplatte/Diskette), den Kernel (das eigentliche OS - verantwortlich für Hardwarezugriffe, Programmverwaltung/Multitasking, Treibereinbindung, uvm), ein User-Interface und vielleicht ein paar Programme dazu.
Die ersten Rechner mußte man anders konfigurieren: die hatten einen sog. Rom-Baustein eingebaut (der Bios-Chip im heutigen Rechnern ist der letzte Rest davon), den konnte man rausnehmen und ein Programm reinbrennen. Baute man ihn wieder ein, dann hatte man ein neues OS

mfg KazHar