Frage zu Instruction Sets, x86, x86-64 usw...

[multimolti]

Hallo!

Ich habe mal eine Frage zu dem Instruction Set oder einfach der Art, auf der heutige Prozessoren basieren. Soweit ich es verstanden habe, wird immer noch das x86-Set bzw. die 64bit-Erweiterung x86-64 benutzt. x86 ist aber mittlerweile schon über 30 Jahre alt.
Das immer weiter auf den x84ern aufgebaut wurde, liegt soweit ich weiß, um Kompabilität zu alten Programmen zu Gewährleisten.

Aber wäre es da nicht sinnvoll, da heutzutage sowieso keiner mehr 30 Jahre alte Programme laufen lässt (zumindest bei Rechnern zuhause), sich ein neues Set auzudenken, was etwas moderner ist, und die Prozessoren darauf aufzubauen? Alte Programme könnte man ja evtl. emulieren, wenn sowas geht.

Oder gibt es sonst noch einen Grund, warum so eine alte Grundlage verwendet wird? Oder gibt es einfach keine Neuerungen, sodass ein neues Set nicht nötig ist? Soweit ich weiß, sind SSE und 3DNow usw. aber Erweiterungen zum Instruction Set, also besteht wohl doch Bedarf nach neuen Befehlen.

Könnt ihr mir das mal erklären? Danke!

EDIT:
Da fällt mir gleich noch eine Frage ein: Bringen die breiteren Datentypen/Pointer/Adressen bei 64bit eigentlich überhaupt etwas, wenn keine Programme ausgeführt werden, die besonders große Zahlen brauchen? Wenn man ein 64bit System hat, besteht doch ein Vorteil darin, dass das Programm jetzt Zahlen speichern kann, die bis zu 2^64 anstatt 2^32 groß sind. Aber wenn man einfach mal an ein normales Konsolen-Programm oder evtl. ein Chatprogramm denkt, brauchen die doch sowas großes überhaupt nicht.
Welche Art von Anwendungen können also von den 64bit am meisten profitieren?

 

[Traben]

Ich denk ich spreche für alle wenn ich Sage: Jedes Programm das 64bit auch ausnuzt. Ich meine mich daran Erinnern zu können, als damals die AMD 64 CPU's rauskamen, wie viele anwendungen schneller liefen oder schneller Starteten bzw verarbeitet werden konten als mit einem Vergleichbaren Pentium Prozessor. Allerdings waren das sekunden. Die später zu Minuten werden etc. etc.
Kann mir da jemand recht geben oder laber ich da nur mist?

Ansonsten profitieren heutzutage am meisten Programme wie Photoshop,Studio3D etc. von 64bit. Da gilt es viel Daten zu verarbeiten und ich erinnere mich noch wie damals ein Freund mit Photoshop 7 ein Bild gerendert hat das ca. 1500x1500 pixel groß war. Für einen Filtereffekt hat er auf einem Athlon XP ca 5-10 sekunden gebraucht.
Ist also schon Sinnvoll die 64bit Bandbreite.

Umgekehrt wiederum greifen selbst heute noch Programme auf 32bit bzw SSE zu. Warscheinlich weil der Code einfach simpler ist. Verbessert mich und lasst uns nicht dumm sterben!

 

[norse]

So tief stecke ich nicht mit drinn,allerdings muss ich dem Traben schon rechgeben und ..mag auch was zum Thema sagen.

Das man sich auf die alten Grundlagen zurückruft hat seine Gründe.
Siehe Grakas, im grunde bauen die alle immernoch auf die Rendertechnik auf, und? das funkitoniert super, sie wird bloß immer weiter erweitert und verbesser.

Bei den Prozessoren nicht anders.

Ich denke die alten Programmen werden alle eh emuliert, man recnet nicht mehr so wie die ganz früheren. Aber man brauch im Grunde immer eien alte, Primitive Grundlage, denn ohne diese kann man am Ende nicht mit dem Computer kommunizieren, denn er kann sich nicht weiterentwickeln. Für ihn gab, gibt, und wird es immer nullen und einsen geben.

das 64bit deutliche vorteile bringt liegt wohl auf der hand. Im Grunde kann jede Anwendung davon profitieren!
Spiele, Bildbearbeitung, Videoschnitt...im grunde in jedem Bereich gibt es Programme die merkbar von den 64bit profitieren.

Auch wird schon an Größerem gearbeitet alà 80bit? *ist gelogen, die genaue zahl weiß ich nicht*

Hinter diesem INstruction Set steckt eine ganze menge und auch hinter dem x86, 64bit, 32bit etc. ich würde nicht sagen das da irgendwas veraltet ist oder so.
Es ist ein sehr komplexes thema was nicht einfach nur mit langen zahlen zu tun hat, da gehört noch mehr dahinter.

Und außerdem, wenn etwas auf etwas sehr altem aufbaut, heißt es doch nicht, dass es schlecht sein muss? warum auch?
wenn es nunmal keine bessere Variante gibt bis heute? oder schlichtweg einfach nicht möglich ist es anders effektiv zu machen?

War jetzt nicht ganz so hilfreich^^
Ist ein ganz interessantes Thema doch find ich das es etwas zu eingeschränkt betrachtet wird, da gehört noch eine ganze mehr Mehr dazu.

lg
Norse

 

[Chris0974]

x86 Befehle sind definitiv noch wichtig! Da auch 64 Bit Programme auch noch 8 und 16 Bit Daten verarbeiten müssen! Stichwort: Textausgabe (ANSI Text (8 Bit) bzw. Unicode Text (16 Bit)) 64 Bit bedeutet eigentlich nur, dass sie auch mit so großen Daten-Typen ohne umstendliche Trixereien verarbeiten können. Beispiel: Unter 32 Bit muste man für eine 64 Bit groß Variable bei einer addition den wert in 2 Teile Teilen. Und diese dan mit der ebenfals geteilten 2. Variable einzeln addierent dann noch den Übertrag berücksichtigen, und abschliesend wieder zusammen setzten. Mit den Neuen 64 Bit Befehlen kann man sich diese Rechnerei sparen, da man jetzt nur noch 1 Addition benötzigt.

Das Beispiel in Pseudo-Code (in Klammern sind Erklährungen zu den Kommandos) und zeigt die Addition von 2 64-Bit Variablen (var3 = var1 + var2)

32 Bit Version:

1 start: move eax, var1............. (unterer Teil von var1 ins 1.Register (eax))
2 ........ move ebx, var2 ........... (unterer Teil von var2 ins 2.Register (ebx))
3 ........ add eax,ebx ................ (addition der Register (ergebnis ladet im 1.Register)
4 ........ move var3, eax ........... (Register (Ergebnis) nach var3 (untere Teil))
5 ........ move eax, var1 + 4....... (oberer Teil von var1 (= adresse + 4 byte) ins 1.Register)
6 ........ bnc sp1 ..................... (bei keinen Übertrag sprung nach sp1)
7 ........ inc eax ...................... (registerinhalt um 1 erhöhen)
8 sp1:.. move ebx, var2 + 4....... (oberer Teil von var2 (= adresse + 4 byte) ins 2.Register
9 ........ add eax, ebx .............. (addition der Register (Ergebnis ladet im 1.Register))
10 ...... move var3 + 4, eax ..... (1.Register(Ergebnis) nach oberer Teil von var3 (= adresse + 4 byte))
ende:

dauer: ungefähr 10 taktzylen
(die genaue zykenzahl kann ich nicht so profromer sagen, da unterschiedliche Prozessoren nicht immer nur 1 taktzyklus für eine Anweisung benötigen (allerdings bei so einfachen Anweisungen wie move und add sollten bei modernen Prozessoren auch nur 1 taktzylus benötigen))

64 Bit Version:

1 start: move eax, var1 .......... (komplette var1 ins 1 Register (eax))
2 ........ move ebx, var2 ......... (komplette var2 ins 2 Register (ebx))
3 ........ add eax, ebx ............ (Register addieren)
4 ........ move var3, eax ......... (ergebnis nach var3)
ende:

dauer: ungefähr 4 taktzylen
(auch hier gild wie oben unterschiede der Prozessortypen)

Ich denke dieses Beispiel verdeutlicht das es sich den Geschwindigkeits vorteil!

Grüße Christian

PS.: Sorry an alle Programmierer, der hier gezeigte Code ist nur ein Pseudo-Code und soll nur die Unterschiede verdeutlichen!

 

[multimolti]

Das klingt durchaus sinnvoll, aber bekräftigt doch auch meinen Gedanken, dass nur große und aufwändige Programme, die auch wirklich 64bit-Zahlen brauchen, davon profitieren.

Wenn man sich jetzt z.B. ICQ anschaut oder den Media Player dürften die doch kaum einen Vorteil haben, da die eh nicht so viel Rechnen. Wenn ich mir jetzt Renderer/Photo Shop/Videobearbeitung/etc. anschaue, glaube ich gern, dass es einen Geschwindigkeitsvorteil gibt

 

[Chris0974]

Bei ICQ hast du (multimolti) sogar recht! Aber Media Player und auch sehr viele andere Programme profitieren eher "Indirekt" von den 64-Bit Befehlen und nicht immer auf den 1. Blick ersichtlich, z.B. mussen sie sehr oft Speicherbereiche von A nach B kopieren bzw. verschieben und bei solchen Aktionen können die 64-Bit Befehle ihre Stärke voll ausnutzten. Wenn ein Speicherbereich beispielsweise 20 KiByte groß ist dann benötigt so eine Kopier-Schleife bei 32-Bit 5120 duchläufe, da pro durchlauf immer nur 4 Bytes gleichzeitig verschoben bzw. kopiet werden kann. Bei 64-Bit benötigt man nur noch 2560 durchläufe, da hier jetzt 8 Bytes pro Durchlauf kopiert werden kann, dass sind nur halb soviele durchläufe und auch dauert auch nur die hälfte der Zeit und so macht sich auch bei diesen Programmen 64-Bit deutlich bemerkbar. Jetzt wird einer von euch auf die Idee kommen MMX bzw. SSE ins Spiel bringen (da sie mit ihren Befehlen 128-Bit und mehr verarbeiten, aber das könnt ihr euch abschminken, da
1. die Umschaltung zur MMX bzw. SSE-Erweiterung relativ viel Zeit verschlingt (oft 10 bis 20 takte)
2. verarbeiten sie die 128-Bit nur in ihren Registern (für das füllen bzw. endladen der Register werden wiederum nur die Standardbefehle (64-Bit/32-Bit) benutzt)
(solche MMX bzw. SSE befehle können nur ihre Stärke verwenden wenn z.B. bei 3D-Spiele Vektoren bzw. Matrizen umfangreich berechnet werden)

20 KiByte ....... 20480 Bytes

32-Bit ........ 4 Bytes (20480 / 4 = 5120)
64-Bit ........ 8 Bytes (20480 / 8 = 2560)

Einen großen Nachteil gibt es allerdings bei 64-Bit: Adressen sind nun auch 64-Bitig also benötigen sie den Doppelten Platz gegenüber 32-Bit (aber das gab es auch schon beim Übergang von 16 auf 32-Bit bzw. 8 auf 16-Bit)

Was ICQ und ander Chat-Programme betrifft, das Programm ist so und so auch bei 32-Bit verwöhnt, da die Programm eh die meiste Zeit auf eine Eingabe warten! (Selbst wenn du 10.000 Tasten in der Sekunde tippen könntest, "langweilt" sich das Programm! Um das Programm zum "schwitzen" zu bringen, müsstest du schon 1.000.000.000 Tasten pro Sekunden tippen können und mit mehr als 10.000 Chat-Partener gleichzeitig chatten. Selbst auf sehr langsamen Rechnern!!! ) Wer nur Chattet bzw. nur im Internet surft, der braucht keinen schnellen PC, da der "Flaschenhals" die Internet-Leitung ist (inklusive ADSL, Kabel usw.) Um die Fehlerkorrektur bei Übertagungsfehlern kümmer sich ein Spezial-Chip auf der LAN-Karte bzw. im Modem (bei externen Geräten) und nicht der Hauptprozessor des PC (und selbst wenn, sollte selbst ein 500 Mhz. Prozessor damit klarkommen) und was nutzt dan ein schneller Rechner, der einige TiByte/sec verarbeiten kann, wenn die Daten (Bilder, Video, etc...) wie eine Schnecke (nur im KiByte/sec-Bereich) durch die Leitung "kriechen".

Programme wie Word haben ebenfalls diesen Eigenschaft, die meiste Zeit zu warten! Dort Profitiert man nur wenn riesige Dokumente bearbeiten werden und mit viel Schnickschnak (Formatierungen, Zeichnsätzten) versehen sind. Die "Automatische Rechtschreib Prüfung", die kann schon von 64-Bit Profitieren, aber das fällt auch nicht wirklich ins Gewicht (nur bei manuellen Start über den Menüpunkt "erneut Prüfen" bzw. wenn ein Doc geladen wird, ansonsten läuft das ganze nur nebenbei ab.) Beim Ausdrucken des Dokuments, kommt die Kopier-Aktion wieder ins Spiel, da eine Kopie des Dokuments in den Ducker-Buffer geschrieben wird und erst die Kopie ausgedruckt wird. Das Original kann ja in der Zwischenzeit ja veränder, gelöscht oder sonst irgendwie veränder werden. Also auch hier ist ein High-End-Rechner unterfordert!

Office-Programme wie Access, Power Point, Excel und Co. würden am meisten von 64-Bit profitieren (erst mit MS-Office 2010 wird es eine x64 Version geben, wie es bei der konurrenz aussieht habe ich zur Zeit keine Kenntnisse), da sie mit sehr großen Datenmengen handierne müssen bzw. Bilder, Videos, großen Zahlen bearbeiten. Hier zahlt sich 64-Bit aus, auch durch den größeren Arbeitsspeicher, der mit 64-Bit verwaltet werden kann (mehr Bilder usw. müssen nicht auf die Festplatte ausgelagert werden). Die größeren Cache im Prozessor erlauben eine schnellere Verarbeitung der am meisten benötigten Daten (hat zwar nichts mit 64-Bit zu tun aber es ist nun mal Tatsache das 64-Bit-Prozessoren riesige Mengen davon haben, Beispiele: AMD Phenom II x4 6 MiByte-Cache, 8 MiByte bei Intel Core I7)

Die 3D-Spiele profiteren am meisten von allen Programmen von 64-Bit. Texturen, Matricen, Vektoren müssen oft von A nach B kopiert oder verändert werden. Detailierte Landschaften, grössere Sichtweite, grössere Levels usw. also die ganze Palette, alles was mehr Speicher und höhere Verarbeitungsgeschwindigkeit benötingt kann bei geschickter Programmierung enorm beeiflusst werden.

 

[multimolti]

Okay, noch mal eine Frage zur ersten Idee: Also muesste man die normalen 32bit-Programme einfach ohne Aenderung am Code noch mal in 64bit kompilieren, damit sie dann von den schnelleren Daten-Kopier-Moeglichkeiten gebrauch machen?

Das Problem ist ja, dass die meisten Programme bisher ueberhaupt keine 64bit-Version anbieten.

 

[Argead]

Ohne jetzt groß Ahnung vom Programmieren zu haben würde ich sagen, dass man da schon ein bischen mehr machen muss als nur neu zu kompilieren.

Ansonsten wären ja alle Programme für x64 verfügbar, da einmal neu kompiliern jetzt ja nicht so ein Aufwand ist.

Übrigens, in diesem Thread hatte midnight auch schon mal die Idee ne neue Architektur zu entwickeln.

 

[multimolti]

Ohne jetzt groß Ahnung vom Programmieren zu haben würde ich sagen, dass man da schon ein bischen mehr machen muss als nur neu zu kompilieren.

Ansonsten wären ja alle Programme für x64 verfügbar, da einmal neu kompiliern jetzt ja nicht so ein Aufwand ist.

Übrigens, in diesem Thread hatte midnight auch schon mal die Idee ne neue Architektur zu entwickeln.

Ich meinte ja auch nur die Datenspeicher/kopiermöglichkeit. Die meisten Programme benutzen heute schon den Zahlenwert double, der eine 64bit-Zahl darstellt, und wenn man dieses Programm jetzt noch mal in 64bit kompiliert, ohne etwas am Code zu ändern, könnte es ja sein, dass alle Operationen mit double-Werten dann automatisch vernünftig optimiert werden.

 

[Chris0974]

Ich meinte ja auch nur die Datenspeicher/kopiermöglichkeit. Die meisten Programme benutzen heute schon den Zahlenwert double, der eine 64bit-Zahl darstellt, und wenn man dieses Programm jetzt noch mal in 64bit kompiliert, ohne etwas am Code zu ändern, könnte es ja sein, dass alle Operationen mit double-Werten dann automatisch vernünftig optimiert werden.

Da irrst du dich:
Gleitkomma-Datentypen (sind alle Zahen-Typen mit Kommastellen: 0,5, 1,9 usw.) wie double (64-Bit) und float (32-Bit) werden nicht von der CPU selbst bearbeitet sonder von der FPU. Die FPU ist seit dem 80486 ein fester Bestandteil der Prozessors, und sie arbeitet wie MMX und SSE eigenständig und hat ihre eigenen Register! (vorher waren es eigene Chips 8087;80187;80287;80387) FPU-Befehle und deren Daten werden von der CPU nur an sie weitergereicht. Werend die FPU die Befehl bearbeitet, wartet die CPU auf die Ergenisse, um diese abschließend in den Speicher zurückzuschippern. Die FPU-Befehle wurde seit damals nicht mehr verändert! (abgesehen von ein paar Optimierungen an der Schaltunglogik, damit die Befehle schneller ausgeführt werden können)

Übrigens die FPU arbeitet Intern sogar mit 80-Bit Genauigkeit, egal ob float oder double (die Rechenergebnisse werden beim zurückschreiben in den Speicher nur auf die jeweilige Datentype-Größe gerundet (daher kommt es auch zu Rundungsfehlern, wenn die Daten in den Speicher zurück geschrieben werden und erst zu einen späteren Zeitpunkt weiterverarbeitet werden!) Aus mir nicht bekannten Gründen wurde es, meiner Meinung nach, verabseumt auch einen 80-Bitigen Gleitkomma-Datentyp in die Programmiersprachen einzubauen. Ich denke, das würde doch viele Rundungsfehler verhindern. Vieleicht könnte einer von euch mir die Gründe erklären. (Meine Anfragen bei Programmier-Foren hat dazu nichts brauchbares ergeben. Antworten wie "So eine Genauigkeit ist für die meisten Anwendungen nicht nötig! Wer es doch braucht, kann ja mit Assembler arbeiten!" finde ich nicht gerade "Hilfreich"!!!)

Die neuen 64-Bit-Befehle beziehen sich nur auf die Integer-Datentypen (sind nur Ganze Zahlen: 1, 2, 3, 4 usw. also ohne Komma). !!!Alle Programme arbeiten primär mit Integer und verwenden Gleitkomma nur für Spezialfälle bei denen es auf Kommastellen ankommt!!! Bei Grafischen Betriebssystem wie Windows und co. fällt sehr viel Verwaltungskram an, die alle keine Kommazahlen benötigen. Um z.B. Fenster zu Positionieren (da es keine halben Bildpunkte geben kann!). Scheifenzähler, Nachrichten-Codes, Zeichencodes (ANSI,Unicode), Speicheraddressen usw. sind alle Integer.

Bevor es die FPU gab, haben Programme Kommazahlen nur simuliert.
Aufgrund der Art und Weise wie der Computer die Integer- bzw. Gleitkomma-Datentypen speichert, können Integer-Datentypen um ein vielfaches schneller verarbeitet werden. (höhrer Rechenaufwand bei Gleitkomma, da sie aus {Vorzeichenbit}{Vorzeichenbit des Exponententeils}{Exponententeil}{Mantisenteil} bestehen)

Excel, zum Beispie, arbeiten sogar heute noch in den meisten Fällen mit Integer. Wenn man z.B. Zellen auf Währung formatiert sind! Werden nun Währungszellen mit den Inhalt € 12,34 und € 56,78 summiert, so rechnet Excel intern in Zentel-Cent (12340 + 56780), das Ergebnis (69120) wird dann als € 69,12 ausgegeben. Die Zehntel Centstelle wird fürs kaufmännische Rundungen gebraucht (bei Divisionen) (Kaufmännisches Runden: Zehntel-Centstelle < 5 abgerundet, ansondesten aufgerundet). Selbst Datum/Zeit angaben werden Intern mit "vergangenen Millisekunden seit "Mitternacht 1.1.1900" gerechnet! So speichert auch Windows das Aktuelle Datum!

Eine halbwegs verständliche Beschreibung wie Computer mit Gleitkomma bzw. Integer-Datentypen arbeiten bzw. zu deren Aufbau, findest du hier:
Integer: Integer (Datentyp) ? Wikipedia
Gleitkomma: Gleitkommazahl ? Wikipedia
FPU Funktionsweise und Aufbau: Gleitkommaeinheit ? Wikipedia
(an alle Wiki-Gegner: nun in manchen Fällen sind Wiki-Seiten doch zu was zu gebrauchen!)

 

[multimolti]

Hmm Schade, das wäre ja zu schön gewesen =(

Dazu dann noch mal gleich eine Frage:
Ich habe ein Programm geschrieben, indem ich ein Bit-Array verarbeiten musste. Also immer nur Einsen oder Nullen. Ich habe mir gedacht, um es möglichst Speicher-Effektiv zu machen stelle ich das Array durch bools dar, die ja eigentlich nur ein Bit benötigen. Wenn aber jetzt alles sowieso mit 32- bzw. 64-Bit rechnet, lohnt sich das dann überhaupt? Oder kann ich auch gleich int nehmen?

 

[Chris0974]

Einige Programmiersprachen wie C++, C# oder Java stellen Bit-Array-Klassen zur Verfügung. Diese Klassen sind Speicher-Effitient Programmiert, sodass sie wirklich auch nur ein Bit verwenden! Der nachteil dieser Klassen ist nur, dass um die einzelen Bits zu setzen bzw. zu auslesen einen zeitlichen overhead benötigen. Grund dafür ist das Prozessoren immer nur ein ganzes Byte betrachten.

Um z.B. das 3 Bit eines Bytes auszulesen muss der Prozessor folgendes machen:

code in C/C++

bool GetBit (unsigned char * array, int iBitnummer) /* array ist das Bit-Array; iBitNummer ist das Bit das Gelesen werden soll */
{
int iByteIndex = iBitnummer / 8; /* in welchen Byte befindet sich das Bit */
unsigned char cBit = 1 << (iBitnummer % 8); /* den wert des Bits berechnen (1, 2, 4, 8, 16, 32, 64 oder 128) */
return (array[iByteIndex] & cBit) == cBit; /* und schliesslich das auslesen des Bits */
}
void SetBit (unsigned char * array, int iBitNummer, bool bSet) /* array ist das Bit-Array; iBitNummer ist das Bit das Gesetzt bzw. Gelöscht werden soll; bSet bestimmt ob das Bit gesetzt oder gelöscht wird)
{
int iByteIndex = iBitnummer / 8; /* in welchen Byte befindet sich das Bit */
unsigned char cBit = 1 << (iBitnummer % 8); /* den wert des Bits berechnen (1, 2, 4, 8, 16, 32, 64 oder 128) */
if (bSet) /* soll bit gesetzt werden? */
array[iByteIndex] |= cBit; /* Bit setzen mittels Binären OR */
else
array[iByteIndex] &= ~cBit; /* Bit löschen mittels Binären AND mit dem Kompliment von cBit (=255-cBit) (~cBit ist schneller da es sich um einen direkten Prozessor-Befehl handelt) */
}

Übrigens der Datentype bool in C++ und C# ist 1 Byte groß, ein array von 10 bool ist 10 Bytes groß
Der Datentype BOOL aus dem Win32-SDK ist hingegen 32-Bit groß und ein array von 10 BOOL's ist daher auch 320 Bytes groß

Die oben vorgestellte Methode ist benutzt hingegen wirklich nur 1 Bit im array (ein array mit 10 Bits würde 2 Byte benötigen, da der Speicher nur mit Byte einheiten arbeitet)

binäre darstellung
11111111 11...... (1 bedeutet genutzt . bedeuten ungenutzt)

du kannst es auch abwandeln wenn du z.B. weist, das du nicht mehr als 64-Bit benötigst, kannst die Funktion auch folgent abwandeln

bool GetBit (unsigned __int64 & bitarray, int iBitNummer)
{
unsigned __int64 bitwert = 1 << iBitNummer;
return bitarray & bitwert;
}
void SetBit (unsigned __int64 & bitarray, int iBitNummer, bool bSet)
{
unsigned __int64 bitwert = 1 << iBitNummer;
if (bSet)
bitarray |= bitwert;
else
bitarray &= ~bitwert;
}

ist sogar effizienter als die 1. Variante aber nicht so flexibel

falls du es nicht sogut lesen kannst habe ich die den code auch als bit beigefügt

 

[Chris0974]

Sorry
hat beim 1. mal nicht geklappt mit dem hochladen.

hier der Quelltext nochmal in der .zip