Ich suche vergeblich eine Angabe die Art der Addier/Subtrahier-Einheit des originalen Intel 8086. War das ein Carry-Look-Ahead oder was anderes? Ist es wichtig für einen software-kompatiblen Nachbau, welche Art dort verbaut ist, also hatte man per Software Einfluss/Zugriff direkt auf diese Komponente? Hat jemand einen Schaltplan und andere Angaben genau dazu?
Mike B. schrieb: > Ich suche vergeblich eine Angabe die Art der Addier/Subtrahier-Einheit > des originalen Intel 8086. Wozu? Mike B. schrieb: > Ist es wichtig für einen software-kompatiblen Nachbau, welche Art dort > verbaut ist, also hatte man per Software Einfluss/Zugriff direkt auf > diese Komponente? Für einen Emulator reicht es, wenn alle Instruktionen identisch ausgeführt werden. Ein guter Emulator kann das sogar zyklengenau. Der interne Aufbau der ALU ist irrelevant.
S. R. schrieb: > Der interne Aufbau der ALU ist irrelevant. Auch für einen Hardware-Nachbau, der software-kompatibel sein soll?
Na klar, als ob jemand diese uralte ALU ernsthaft nachbauen wollte... Wird das wieder so ein "ich baue eine CPU" Thread, der ins leere läuft?
Mike B. schrieb: > Auch für einen Hardware-Nachbau, der software-kompatibel sein soll? Ja mein Gott dann muss er halt softwarekompatibel sein - wie er das macht ist egal. Soweit mir bekannt ist gibt es beim Carry keine verschiedenen Erscheinungsformen - Carry ist Carry. Georg
Mike B. schrieb: >> Der interne Aufbau der ALU ist irrelevant. > Auch für einen Hardware-Nachbau, der software-kompatibel sein soll? Willst du einen Transistor-Nachbau machen oder reicht es, wenn originale Software in Originalgeschwindigkeit drauf laufen soll? Software-kompatibel ist was anderes als Hardware-identisch. Gag am Rande: Solche Emulatoren gibt es schon. FPGA-Modelle ebenfalls.
:
Bearbeitet durch User
georg schrieb: > Soweit mir bekannt ist gibt es beim Carry keine verschiedenen > Erscheinungsformen - Carry ist Carry. carry-ripple carry-look-ahead Carry-Skip carry-select Conditional-Sum-Addition Es gibt bestimmt noch ein paar mehr.
S. R. schrieb: > Software-kompatibel ist was anderes als Hardware-identisch. nein, Hardware-identisch wird es nicht, aber es soll in diskreter Hardware umgesetzt werden Und es soll 8086 kompatible SOftware/kompatibler Code drauf laufen, zumindest Teile von PC-DOS 1.10 sollten funktionsfähig sein.
Mike B. schrieb: > georg schrieb: > >> Soweit mir bekannt ist gibt es beim Carry keine verschiedenen >> Erscheinungsformen - Carry ist Carry. > > carry-ripple > carry-look-ahead > Carry-Skip > carry-select > Conditional-Sum-Addition > > Es gibt bestimmt noch ein paar mehr. Da spielt hier alles gar keine Rolle. Am Ende der Ausführung des Befehls gibt es einen Update für das Carry-flag im Statusregister. Ob mit oder ohne look-ahead kann niemand von außen erkennen und es interessiert auch überhaupt nicht.
georg schrieb: > Soweit mir bekannt ist gibt es beim Carry keine verschiedenen > Erscheinungsformen - Carry ist Carry. Bei mancher CPU entspricht ein Borrow bei der Subtraktion einem gesetzten C-Flag (8086), bei anderen einem gelöschten (ARM).
:
Bearbeitet durch User
Helmut S. schrieb: > Am Ende der Ausführung des Befehls > gibt es einen Update für das Carry-flag im Statusregister. Ob mit oder > ohne look-ahead kann niemand von außen erkennen und es interessiert auch > überhaupt nicht. Heisst also, dass es 8086-kompatiblem Code (z.B. Assembler) nicht interessiert, auf welche Art (CR/CLA/CS/...) das Addier-/Subtrahierwerk der ALU aufgebaut ist, solange die von A.K. erwähnte Vorgabe des Borrow eingehalten wird?
:
Bearbeitet durch User
Mike B. schrieb: > Heisst also, dass es 8086-kompatiblem Code (z.B. Assembler) nicht > interessiert, auf welche Art (CR/CLA/CS/...) das Addier-/Subtrahierwerk > der ALU aufgebaut ist? Weshalb sollte das ein Programm interessieren? Einzig das Ergebnis zählt, nicht der Weg dorthin. Das ist ebenso unwichtig wie die Frage, wieviele Bits pro Iteration bei der Implementierung der Division erledigt werden (wenn man es - anders als damals beim P5/P54 - richtig macht ;-).
:
Bearbeitet durch User
A. K. schrieb: > Mike B. schrieb: >> Heisst also, dass es 8086-kompatiblem Code (z.B. Assembler) nicht >> interessiert, auf welche Art (CR/CLA/CS/...) das Addier-/Subtrahierwerk >> der ALU aufgebaut ist? > > Weshalb sollte das ein Programm interessieren? Einzig das Ergebnis > zählt, nicht der Weg dorthin. Das ist ebenso unwichtig wie die Frage, > wieviele Bits pro Iteration bei der Implementierung der Division > erledigt werden (wenn man es - anders als damals beim P5/P54 - richtig > macht ;-). wenn es SW-kompatibel sein soll muss sichergestellt sein, dass es keine Möglichkeit geben darf, dass das Addierwerk der ALU direkt von der Software gesteuert wird. Denn wenn es das gäbe, denn würde es auch sicher jemanden geben, der dies ausgenutzt hat. Und dann wäre es wohl sinnvoll, die gleiche Hardware (CS/CLA/...) zu verwenden, sonst wäre es ja nicht vollständig kompatibel und würde später in irgendwelchen Code zu Problemen führen.
Mike B. schrieb: > Und es soll 8086 kompatible SOftware/kompatibler Code drauf laufen, > zumindest Teile von PC-DOS 1.10 sollten funktionsfähig sein. Dafür brauchst du aber weit mehr als nur eine ALU oder CPU. Nachdem im letzten Thread "irgendeine" funktionsfähige CPU aus diskreten Bauteilen das Ziel war, willst du nun einen funktionsfähigen PC aus diskreten Bauteilen bauen, verstehe ich das richtig? Wie stellst Du Dir das in der Praxis vor? Wie viele Millionen Euro stehen Dir zur Verfügung, und wie viele Turnhallen hast du Platz? Ich dachte, wir hätten im letzten Thread (Beitrag "Re: diskrete CPU") schon herausgefunden, dass das nichts wird. Nach deinem Beitrag hatte ich eigentlich das Gefühl, dass du ganz grob die Komplexität überblickt hast. Nun bin ich mir da nicht mehr so sicher. Willst du dem cpu_builder etwas beweisen?
Stefanus F. schrieb: > Mike B. schrieb: >> Und es soll 8086 kompatible SOftware/kompatibler Code drauf laufen, >> zumindest Teile von PC-DOS 1.10 sollten funktionsfähig sein. > > Dafür brauchst du aber weit mehr als nur eine ALU oder CPU. Hab ich was anderes angedeutet? > Ich dachte, wir hätten im letzten Thread (Beitrag "Re: diskrete CPU") schon > herausgefunden, dass das nichts wird. ROFL, du bist ein Held! der thread war nich von mir... oder auf welchen thread > Nachdem im letzten Thread "irgendeine" funktionsfähige CPU beziehst du dich?
:
Bearbeitet durch User
Mike B. schrieb: >> Dafür brauchst du aber weit mehr als nur eine ALU oder CPU. > Hab ich was anderes angedeutet? Ich wollte Dir nur auf den Zahn fühlen, was du da genau vor hast und ob Dir der Aufwand bewusst ist. Die ALU ist natürlich ein Teil, mit dem man anfangen kann. >> Ich dachte, wir hätten im letzten Thread (Beitrag "Re: diskrete CPU") >> schon herausgefunden, dass das nichts wird. > ROFL, du bist ein Held! > der thread war nicht von mir... Ist mir schon klar, aber du hast doch hoffentlich die vorherigen Beiträge gelesen bevor du dich dort eingebracht hast. Die wenigen Beiträge danach zeigen, dass das Ding mit einer großspurigen Angeberei ins Leere gelaufen ist. Das wollen wir doch nicht wiederholen. > oder auf welchen thread ... beziehst du dich? Den verlinkten. Hier nochmal: https://www.mikrocontroller.net/topic/goto_post/5536973
Mike B. schrieb: > wenn es SW-kompatibel sein soll muss sichergestellt sein, dass es keine > Möglichkeit geben darf, dass das Addierwerk der ALU direkt von der > Software gesteuert wird. Du denkst zu sehr um die Ecke. Integer-ALUs sind auch gegenüber Microcode abgeschlossene Gebilde, d.h. selbst Microcode sieht sie als Blackbox mit bestimmter Funktion, steuert nicht jedes Gatter einzeln. Der x86 Programmierer sieht davon erst recht nichts. Bei beispielsweise einer Implementierung der Multiplikation wäre zwar ein Gebilde vorstellbar, in dem Microcode mehrere unvollständige Adder nutzt (wie etwa CSA). Aber auch da wäre das nur für den Entwickler des Microcodes relevant, nicht für den x86-Programmierer.
:
Bearbeitet durch User
Mike B. schrieb: > Hardware-identisch wird es nicht, aber es soll in diskreter > Hardware umgesetzt werden Auch dann ist es ziemlich genau völlig egal, wie du das machst. Hauptsache, die Befehle verhalten sich aus Sicht des Befehlssatzes genau so, wie das auf dem Vorbild der Fall war. Dazu brauchst du im Zweifelsfall nichtmal eine ALU.
Stefanus F. schrieb: > Ist mir schon klar, aber du hast doch hoffentlich die vorherigen > Beiträge gelesen bevor du dich dort eingebracht hast. In der Tat, sonst hätte ich nicht gesehen, dass er Großes vorhat, es aber noch gar nicht weiss. > Die wenigen Beiträge danach zeigen, dass das Ding mit einer großspurigen Angeberei > ins Leere gelaufen ist. Ich kann dir nicht ganz folgen, denn a) habe ich soweit ich erinnere nur den einen post verfasst b) der thread-Ersteller nach meinem post noch ziemlich lange weiterdiskutiert c) jener auch bisher nach meiner Einschätzung zeitlich noch gar nicht die Möglichkeit gehabt die geschichte ins Leere laufen zu lassen, (schliesslich schraubt man sowas nicht in 1-2 Wochen zusammen) d) kann ich nicht den Hauch von "großspuriger Angeberei" in dem erwähnten thread erkennen, die Bezeichung die du wahrscheinlich suchst nennt sich m.M.n. "blinde Naivität". >> oder auf welchen thread ... beziehst du dich? > Den verlinkten. Hier nochmal: > https://www.mikrocontroller.net/topic/goto_post/5536973 Was war in diesem Post falsch? Dass ich ihm die Arbeitschritte vorgeschlagen hab in der er m.M.n. am besten vorgehen sollte? Ist sowas falsch und/oder verwerflich?
A. K. schrieb: > Integer-ALUs sind auch gegenüber > Microcode abgeschlossene Gebilde, d.h. selbst Microcode sieht sie als > Blackbox mit bestimmter Funktion, steuert nicht jedes Gatter einzeln. > Der x86 Programmierer sieht davon erst recht nichts. > > Bei beispielsweise einer Implementierung der Multiplikation wäre zwar > ein Gebilde vorstellbar, in dem Microcode mehrere unvollständige Adder > nutzt (wie etwa CSA). Aber auch da wäre das nur für den Entwickler des > Microcodes relevant, nicht für den x86-Programmierer. DAS ist die Antwort auf die ich gewartet habe. "Der Hardware-seitige Aufbau der ALU ist auf der Seite der auf dem Microcode aufsetztenden Software irrelevant." Ist dies beim 8086 zu 100% sicher?
Mike B. schrieb: > Was war in diesem Post falsch? Nichts. Du hast wohl nicht mitbekommen, dass der TO dort urplötzlich behauptete, er sei schon fertig aber sei gerade verhindert, es vorzuführen. Nun sind einige Tage verstrichen und er hat immer noch gar nichts zum vorzeigen. Es endete mit Prahlerei, heißer Luft und Häme. Ich möchte Dir gerne eine Wiederholung dieses Szenarios ersparen.
Mike B. schrieb: > Ist dies beim 8086 zu 100% sicher? Findest du nicht, das Körbe flechten auch eine schöne Beschäftigung ist? Jedenfalls eine sinnvollere, als bar jeder Vorstellung dessen, was man tatsächlich vorhat, sich einer solchen Aufgabe zu widmen. Grundlagenkenntnisse erwirbt man nicht, indem man Leuten in Foren Löcher in die Hosen fragt.
Mike B. schrieb: > Ist dies beim 8086 zu 100% sicher? Der 8086 ist so unglaublich komplex, dass du ihn sogar relativ vollständig verstehen lernen kannst. Du kannst dir auch vorher einen 8080 vornehmen, der ist noch einfacher verständlich, und statt "PC-DOS 1.10" (was du sowieso nicht hinkriegst) läuft da CP/M drauf. Warum du das nicht hinkriegst? Weil PC-DOS ein Kommerzprodukt für den IBM-PC/XT ist. Den musst du auch noch nachbauen - da ist ein bisschen mehr drin als nur ein Prozessor. Installier dir lieber PCem, hast du mehr von.
Ich weiss nicht ob Ken Shirriff den 8086 schon in den Fingern hatte, aber er verdeutlicht in seinen Artikeln ganz gut wie man so einem Bauteil auf den Zahn fühlen kann. Den (deutliche einfacheren) Zilog Z80 hat er schon komplett auseinandergenommen. http://www.righto.com/
Mike B. schrieb: > Ist es wichtig für einen software-kompatiblen Nachbau, welche Art dort > verbaut ist, also hatte man per Software Einfluss/Zugriff direkt auf > diese Komponente? Nein und nein. Im Befehlssatz ist jede Instruktion beschrieben, was sie macht und welche Flags wie beeinflußt werden.
Mike, habe ich Dich richtig verstanden, dass du einen abgespeckten PC aus einzelnen Transistoren bauen wirst?
Stefanus F. schrieb: > Mike, habe ich Dich richtig verstanden, dass du einen abgespeckten > PC aus einzelnen Transistoren bauen wirst? "willst" Prozessor, RAM, I/O über Tastatut+Bildschirm reicht, evtl. Diskette Vorgabe 8086 kompatibel, ein PC-DOS 1.10 sollte also in Teilen drauf laufen Das haben andere auch geschafft,wenn auch oft mit eigenen/Misch-Systemen wie der Megaprocessor oder der Space-Age I, aber es geht.
S. R. schrieb: > und statt "PC-DOS 1.10" (was du sowieso nicht hinkriegst) läuft da CP/M > drauf. immer diese negative vibrations hier im Forum, tss tss tss > Warum du das nicht hinkriegst? Weil PC-DOS ein Kommerzprodukt für den > IBM-PC/XT ist. Den musst du auch noch nachbauen - da ist ein bisschen > mehr drin als nur ein Prozessor. https://de.wikipedia.org/wiki/PC_DOS#Versionsgeschichte So ein richtig Schlauer du bist! erst PC-DOS 1.20 war für den XT
Hier wollt mal wer nen 8080 in DTL bauen: http://lovqvist.net/8080/index.html Hat dann aber wegen einiger Probleme nicht hingehauen. Also lesen und lernne bevor man die Fehler nochmal macht. Jetzt baut ers in CMOS: http://lovqvist.net/homebuilt%208080%20mk%20ii/index.html
Ganz ehrlich Mike: So verlockend diese Idee auch sein mag (hatte ich auch mal, als ich noch naiv war), sie wird Unmengen von zeit, Platz und Geld verschlingen. Ich kenne deine Ressourcen nicht. Ich würde jedenfalls lieber was anderes mit besserem Verhältnis zwischen Aufwand und Nutzen versuchen. Zum Beispiel ein Perpetuum Mobile bauen. Die kann es zwar theoretisch nicht geben, aber es macht wenigstens Spaß und dabei kommen oft beeindruckende Konstrukte heraus, die man transportieren und vorführen kann. Hast du Familie? Fall ja, dann schau doch mal, was die gebrauchen können. dieser MP3 Player für Kleinkinder im Hölzernen Koffer ist ganz nett. Meine Familie hat sich über eine simple Ampel gefreut, die den Status des WLAN und Internet Anschlusses anzeigt. Oder wie wäre es, einen Fahrrrad-Blinker mit Sirene zu bauen, der Wetterfest ist. Mein Sohn hätte so etwas gerne. Den würde ich Dir eventuell sogar abkaufen.
Mike B. schrieb: > ein PC-DOS 1.10 sollte also in Teilen drauf laufen Definiere mal, was du damit meinst. Warum gerade PC-DOS 1.10? Was bedeutet "in Teilen"? Du siehst im Debugger, dass ein paar Instruktionen ausgeführt wurden? Das Teil bootet und zeigt "A>" an? Du kannst echte Programme damaliger Zeit darauf ausführen (gibt es überhaupt welche?) und sie laufen vernünftig? Was willst du überhaupt? Einen "Computer mit 8086 drin" oder ein "IBM-PC Klon"? Nur auf letzterem kannst du "PC-DOS 1.10" mit zeitgenössischer Software sinnvoll ausführen. > Prozessor Okay, der 8086 wird hier diskutiert. Machbar. Vergiss nicht, dass du auch noch ein IBM-kompatibles BIOS brauchst, aber es gibt taugliche Varianten im Netz. > RAM Ist machbar, 128 KB SRAM sind günstig. > I/O über Tastatut+Bildschirm reicht Du brauchst also einen richtigen KBC, kompatibel zum 8048. Außerdem brauchst du eine MDA- oder CGA-kompatible Grafikkarte, denn was anderes gab es nicht und Software geht davon aus. > evtl. Diskette Wirst du brauchen (DOS = DISK Operating System). Mit exakt 120/160 KB. Mit was anderem kann dein PC-DOS nicht umgehen. Außerdem: FAT von DOS 1.x ist nicht kompatibel mit FAT von DOS 2.x. Du stellst da ziemlich bescheuerte Anforderungen auf, die dafür sorgen werden, dass dein Projekt quasi schon gescheitert ist. Es sei denn, du willst einen PC nachbauen, und ich habe nicht das Gefühl, dass du das willst (oder kannst). Einen "Computer mit 8086" aufzubauen ist dagegen eher kein Problem. Im Netz fliegen die OEM-Sourcen für MS-DOS/PC-DOS rum, legal gibt es mindestens FreeDOS. Alle diese Systeme sind portabel, wenn man die IO.SYS/IBMBIO.COM anpasst (wozu man natürlich die Sourcen braucht). Für einen DOS-tauglichen Computer brauchst du mindestens 128 KB RAM (ab Adresse 0), einen Massenspeicher (einige zig KB reichen), einen Timer und irgendeine Form von textbasiertem I/O (UART reicht). Auf sowas sollten viele Programme der frühen 80er laufen. Spätere DOS-Programme sind auf den IBM-kompatiblen PC ausgelegt und sprechen z.B. direkt Grafikspeicher oder andere Hardware an.
Mike B. schrieb: > https://de.wikipedia.org/wiki/PC_DOS#Versionsgeschichte > So ein richtig Schlauer du bist! > erst PC-DOS 1.20 war für den XT Merke: Du kannst nicht lesen und hast außerdem auch keine Ahnung. a) Es gab kein PC-DOS 1.20. b) Der IBM-PC hatte einen 8088, keinen 8086. Der war im XT drin.
Stefanus F. schrieb: >> 128 KB SRAM sind günstig. > Aber nicht aus diskreten Bauteilen! Stimmt. Aber glaubst du ernsthaft, dass Mike jemals einen IBM-PC aus Transistoren zusammenstöpseln wird? Zumal er ja nur von der CPU sprach... kann ja eine selbstgelötete CPU mit fertigem RAM-Chip werden - sonst wird das eh ein Zwölfjahresplan, mindestens. Wenn das ein ernsthaftes Projekt werden soll, wird er hier Hilfe bekommen, gerne auch von mir, weil ich solche Projekte toll finde (und auch schon selbst gemacht habe). Solange das aber nur Gedankenfürze jenseits der Realität sind, bin ich raus. Schade eigentlich.
:
Bearbeitet durch User
8068 Nachbau .... vergiss es. Ich habe mitte 80' eine 8086 Maschine selbst zusammengebaut. Mit EEPROM, usw. Den code auf papier geschrieben, per ASM Instruction manual in Hex uebersetzt auf dem firmen EPROM Programmer eingetippt. Ich kam soweit wie einem Editor auf einem 4 Zeilen LCD, die Hardware incl. Dynamisches RAM liefen. Eine sehr gruendliche Einfuehrung in diese Microcontroller Technologie. Ich kann also sagen, ich weiss wovon ich rede. Ein Jahr spaeter hatte ich dann das Geld fuer den ersten PC. 8088 mit 4MHz. 640k RAM. eine Floppy. Und als teure Option eine 10MByte Harddisk. Leider hat's Microsoft von da an verbockt. Sie haben aus Spargruenden verschiedene Unguenstigheiten eingebaut. Ich denke, du schaffst nicht mal, dass das BIOS gescheit bootet. Sorry. Moeglichkeit 1 : Bau ein 8086 System von Grund auf, mit fertigen Komponenten, einem 4x20 LDC, oder einem 640x480LCD. Dann schreib das BIOS, irgendwie... ein heutiger Compiler kann's aber nicht. Der geht von einem loader aus, den du nicht hast. Oder schreib mit heutigen Toolseinen zum System passenden Linker, wenn du einen alten Compuler findest der Object code generieren kann. Moeglichkeit 2 : Bau dir ein System mit einem modernen Controller. Schreib einen compiler dazu.
S. R. schrieb: > b) Der IBM-PC hatte einen 8088, keinen 8086. Der war im XT drin. Auch der XT verwendete den 8088. Den 8086 gab es nur in teils mehr und teils weniger kompatiblen Geräten.
:
Bearbeitet durch User
Der 8088 und der 8086 sind Code-identischl. Der einzige Unterschied war der 8 bit, resp der 16bit Datenbus. Da wollten ein paar Pfeifen ein paar Tracks auf de Platine sparen... und da haben ein paar Pfeifen auch etwas gespart.
Zitronen F. schrieb: > Der 8088 und der 8086 sind Code-identischl. Der einzige Unterschied war > der 8 bit, resp der 16bit Datenbus. Da wollten ein paar Pfeifen ein paar > Tracks auf de Platine sparen... und da haben ein paar Pfeifen auch etwas > gespart. Klar. Waren aber mehr als bloss ein paar Leitungen, denn der Aufwand von 8-Bit DMA per nur mässig geeignetem DMA-Controller aus der 8080-Ära macht bei einem 16-Bit Bus auch was aus. Das hatte erst den AT aufwändiger gemacht.
Fuer IO-Geschichten hatte Intel speziell dazu passend den IO Prozessor 8089 entwickelt. Eine super Maschine. Leider von IBM und MS vollkommen ignoriert. Schade. Der waere toll gewesen. Den hatte ich damals auch eingebaut und implementiert.
S. R. schrieb: > Solange das aber nur Gedankenfürze > jenseits der Realität sind, bin ich raus. Schade eigentlich. Bis auf diesen hat der Moderator ja schon die ganzen verbal defekten Ausgüsse der User bereinigt. Man sollte denken, auf µc.net hat man es mit Menschen zu tun, deren Bildung auch für ein gewisses Level an Anstand und Benehmen reicht. Hier aber wird man (regelmäßig) mit Schimpfwörtern auf Sonderschulniveau belegt. Das muss man sich nicht antun. Ihr müsst euch nicht wundern, wenn viele Leute dem Forum den Rücken kehren und so das Durchschnittsniveau sinkt. Oder nach drei Antworten auf ihre Fragen einfach nicht mehr weiterlesen und mitdiskutieren. Und sich dann drüber aufregen dass das wieder nur hohle Luft und der Fragende ja eh nur ein Troll war. Für mich war der thread mit meinem Post am 05.09.2018 um 21:46Uhr beendet, denn da wurde meine Frage des Eröffnungsposts beantwortet. Das ihr euch dann noch drüber aufregt und reinsteigert, dass ich was vorhabe was ihr euch nicht vorstellen könnt ist euer Bier und gehört hier eigentlich nicht rein. Und wenn, dann in einer konstruktiven Art und Weise.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.