Muss ein Prozessor dafür ausgelegt sein? Wenn man z.B. 2 Zilog Z80 CPUs nutzen wollte, ist die Krux dort in erster Linie die Software oder wird eine 3te CPU benötigt zur Koordination der anderen beiden?
Kommt darauf an. Wenn ein Z80 als Hauptprozessor arbeitet, einer am Floppy-Controller, und noch einer in der Grafikkarte, dann sind die gekoppelt, und arbeiten zusammen. Aber jeder hat seinen eigenen ROM/RAM, die Busse sind nicht direkt verbunden usw.
Moin, Kommt auf deinen Grad der Kopplung an. In alten Videospielautomaten waren z.b. auch gerne mal mehr als ein Z80 verbaut, z.b. einer nur fuer die Soundausgabe. Der war dann mit den anderen Prozessoren eher "lose" gekoppelt, d.h. z.b. ueber ein paar I/O Leitungen. Je enger die Kopplung sein soll, desto mehr Aufwand musste treiben. Gruss WK
KArl Fred M. schrieb: > Wo ist die Hauptschwierigkeit bei 2 und mehr CPUs zu koppeln? Das Hauptproblem ist wie üblich, dass alle am gleichen Problem arbeiten: welche Aufgabe sollen die beiden denn wann erledigen wie können sie sich über den aktuellen Arbeitszustand austauschen? Mach mal, was du offenbar noch nicht getan hast: lies einfach mal irgendwas zum Thema "Mehrprozessorarchitektur".
ja, es soll natürlich um Parallelbetrieb gehen.. Mehre gleich Cpus in einem Gerät die nahezu unabhängig voneinander arbeiten ist natürlich nicht die Frage
Lothar M. schrieb: > Mach mal, was du offenbar noch nicht getan hast: lies einfach mal > irgendwas zum Thema "Mehrprozessorarchitektur". Oder schreib selber ein Programm auf deinem Rechner, das mehrere CPU-Kerne benutzt. Es ist ja nicht so, daß die CPU das Programm einfach nimmt und eigenmächtig irgendwie auf mehrere Kerne aufteilt...
Ähm, nein. Ich wollte dazu spontan... kurz eine Frage in ein Forum stellen. Und die verschiedenen Denkansätze und Möglichkeiten eruieren. Aber danke für deinen tollen Vorschlag.... Lothar M. schrieb: > Mach mal, was du offenbar noch nicht getan hast: lies einfach mal > irgendwas zum Thema "Mehrprozessorarchitektur"
Das würde meinem Gedankenansatz mich nur rudimentär spontan dafür zu interessieren zuwider laufen... Wühlhase schrieb: > Oder schreib selber ein Programm auf deinem Rechner, das mehrere > CPU-Kerne benutzt. Es ist ja nicht so, daß die CPU das Programm einfach > nimmt und eigenmächtig irgendwie auf mehrere Kerne aufteilt..
In meinem Apple][+ war ein 6502, ein Z80 und ein 68008, die haben aber wohl immer nur abwechselnd gearbeitet wenn ich das richtig erinnere. .-) In der Praxis kann man natuerlich alles beliebig bauen, man muss nur wollen und sich Fragen wofuer man das braucht. Ein denkbarer Ansatz waere z.B Dualportram. Olaf
?? Das diente dann aber doch eher der Kompatibilität zu anderen Systemen, als einem Parallelbetrieb bzw als CoProzessor, also in der Tat was völlig anderes;-) olaf schrieb: > In meinem Apple][+ war ein 6502, ein Z80 und ein 68008,
KArl Fred M. schrieb: > Muss ein Prozessor dafür ausgelegt sein? Es gibt Prozessoren, die sind dafür besser und andere sind schlechter ausgelegt. Der Z80 ist als Einzelprozessor konzipiert und kann mit Hardware- und Softwareaufwand im Verbund mit anderen Prozessoren arbeiten. Dazu nimmt man gerne die Interrupt-Leitungen und ggf. dual ported RAM. Extra für Parallelbetrieb ausgelegt sind sog. Transputer CPUs - die gab es in den 80ern und die waren speziell für Mehrprozessoranwendungen im Verbund ausgelegt. Da war die interne HW schon auf maximale Kommunikationsfähigkeit zu den anderen Teilnehmern ausgelegt.
KArl Fred M. schrieb: > ja, es soll natürlich um Parallelbetrieb gehen.. Das geht nicht. der Z80 will immer volle Kontrolle über seinen Adressbus, und hat auch keinen Cache, aus dem er Code ausführen könnte, wenn der Adressbus gerade von einem anderen Z80 benutzt würde. d.H.: Selbst wenn du es hinkriegst, dass sich zwei Z80 einen Bus mit Ram und Rom teilen: Es wird nicht schneller als ein einzelner Z80 mit exklusivem Zugriff darauf.
olaf schrieb: > In meinem Apple][+ war ein 6502, ein Z80 und ein 68008, > die haben aber wohl immer nur abwechselnd gearbeitet > wenn ich das richtig erinnere. .-) Der 6502 war der native Apple Hauptprozessor. Der Z80 wurde eingesetzt, um CP/M Betriebssysteme laufen zu lassen, dafür wurde der 6502 ausgekoppelt. Die beiden CPUs haben nicht zusammen gearbeitet. 68008 beim Apple ist mir nicht bekannt.
Wie funktionierte das beim Amiga mit den verschiedenen CoProzessoren? Da diente die Haupt CPU doch in erster Linie zur Steuerung der CoProzessoren. Also, als würde ich einen Z80 zur Steuerung mehrer spezialisierter Controller nutzen, was aber ja kein Parallelbetreib mehr wäre..hmm. schade
KArl Fred M. schrieb: > Wie funktionierte das beim Amiga mit den verschiedenen CoProzessoren? > Da diente die Haupt CPU doch in erster Linie zur Steuerung der > CoProzessoren. Das sind nicht wirklich Coprozessoren, das sind Controller, die über den ganz normalen Adress- und Datenbus gelesen und beschrieben werden können. Der 68000 ist der Prozessor, auf dem das Betriebssystem läuft.
KArl Fred M. schrieb: > Ähm, nein. > Ich wollte dazu spontan... kurz eine Frage in ein Forum stellen. > Und die verschiedenen Denkansätze und Möglichkeiten eruieren. > > Aber danke für deinen tollen Vorschlag.... > Lothar M. schrieb: >> Mach mal, was du offenbar noch nicht getan hast: lies einfach mal >> irgendwas zum Thema "Mehrprozessorarchitektur" Dann solltest du dir erstmal klar werden was du überhaupt willst:-) Das ganze Thema fängt irgendwo bei zwei µC an die sich z.B. über einen UART miteinender austauschen und dabei praktisch alles von der jeweiligen Software geregelt werden muss. Da geht ggf. schon einiges an der Vorhanden Rechenleistung für diese Kommunikation drauf und taugt somit nur wenn der Kommunikationsaufwand im Vergleich zur restlichen "Arbeit" gering ist. Danach kommen dann die enger gekoppelten System wo der Prozessor und das drumherum das in Hardware unterstützen, aber die Software (das OS) muss hier kräftig mitspielen. Und irgendwann endet man bei großen Clustern die, ggf. sogar an verschiedenen Standorten stehen, und eine Mix aus beidem sind. - https://de.wikipedia.org/wiki/Verteiltes_System - https://en.wikipedia.org/wiki/Non-uniform_memory_access - https://en.wikipedia.org/wiki/Intel_QuickPath_Interconnect - https://en.wikipedia.org/wiki/Flynn%27s_taxonomy - https://en.wikipedia.org/wiki/Computer_cluster Das Themengebiet ist so riesig das sich damit ganze Firmen und Unis Weltweit damit beschäftigen:-)
> 68008 beim Apple ist mir nicht bekannt. Was kann ich dazu wenn du so hinter Zeit zurueck bist und nur mit 8Bit MCUs arbeitest. :-D https://www.applefritter.com/appleii-box/H061E_MC68008pageEN.htm Ich glaub die Karte habe ich sogar noch irgendwo rumliegen.... Olaf
Es gibt sogar spezielle Betriebssysteme für Transputer - Helios z.B.
olaf schrieb: > Was kann ich dazu wenn du so hinter Zeit zurueck bist und nur mit > 8Bit MCUs arbeitest. Stimmt nicht, ich arbeite auch mit 4-Bit-CPUs. Guter Link, danke. Gab's da jemals sinnvolle Software für?
:
Bearbeitet durch User
Hallo KArl Fred M. schrieb: > Ähm, nein. > Ich wollte dazu spontan... kurz eine Frage in ein Forum stellen. > Und die verschiedenen Denkansätze und Möglichkeiten eruieren. KArl Fred M. schrieb: > Das würde meinem Gedankenansatz mich nur rudimentär spontan dafür zu > interessieren zuwider laufen... Willkommen im Forum und der Welt der höheren Jahrgänge in Schulen in Bildungseinrichtungen - besonders im Fach Mathematik... Solltest du mal in den fragwürdigen Genuss einer Berufsschule (bei einer Ausbildung im Umfeld eines technischen Beruf) kommen da gar noch eine Nummer höher in Richtung Hochschule wirst du solch "hilfreichen" Antworten von den Leeren (ein gewollter Rechtsschreibfehler...) erhalten. Das Problem ist nicht das dich die Lehrer und hier die Forenmitnutzer dich nicht verstehen - nein sie wollen es nicht - sie wollen ihre Vorstellungen wie man sich wissen aneignet durchdrücken. Was im Bildungsumfeld seinen Sinn haben muss (aber oft trotzdem in einer Augenblicklichen Situation oft eine Unverschämtheit ist) ist hier einfach nur unverschämt und hochgradig Arrogant. Leider ist es nicht nur in diesen Forum so. Ich empfehle dir ernsthaft es mal bei Youtube zu Versuchen - da gibt es einige Kanäle die sich eigentlich vorrangig an Schüler richten die auch solche Sachen kurz und knapp und dabei Verständlich und ohne "Richtig lernen Missionierung" erklären...
Realist schrieb: > Das Problem ist nicht das dich die Lehrer und hier die Forenmitnutzer > dich nicht verstehen - nein sie wollen es nicht - sie wollen ihre > Vorstellungen wie man sich wissen aneignet durchdrücken. > Was im Bildungsumfeld seinen Sinn haben muss (aber oft trotzdem in einer > Augenblicklichen Situation oft eine Unverschämtheit ist) ist hier > einfach nur unverschämt und hochgradig Arrogant. Du hast vergessen darauf hinzuweisen, dass es im Thread sehr wohl fachkundige Antworten auf die gestellte Frage gab. Aber du wolltest ja mit deinem sinnlosen Post auch nicht wirklich weiterhelfen.
KArl Fred M. schrieb: > Wenn man z.B. 2 Zilog Z80 CPUs nutzen wollte, ist die Krux dort in > erster Linie die Software oder wird eine 3te CPU benötigt zur > Koordination der anderen beiden? Wenn am gleichen Bus, dann hilft es, wenn der Prozessor einen Befehl hat, der sich für sichere Software-Synchronisation mehrerer Busmaster eignet, für Semaphoren. Kann man aber notfalls auch als Peripherie-Device implementieren. Kleiner Nachteil speziell bei Z80: Der HALT-Befehl legt die Kiste nicht etwa still, sondern wird in vollem Tempo wiederholt ausgeführt. Schön für den Refresh vom RAM, unschön für die Buslast.
:
Bearbeitet durch User
neinein, alles Gut er hat ja Recht.+#Die ersten Kommentare hier waren wiede r mal sehr Forentypisch, für restlichen sachlichen Antworten bin ich aber sehr dankbar Wolfgang R. schrieb: > Realist schrieb: >> Das Problem ist nicht das dich die Lehrer und hier die Forenmitnutzer >> dich nicht verstehen - nein sie wollen es nicht - sie wollen ihre >> Vorstellungen wie man sich wissen aneignet durchdrücken. >> Was im Bildungsumfeld seinen Sinn haben muss (aber oft trotzdem in einer >> Augenblicklichen Situation oft eine Unverschämtheit ist) ist hier >> einfach nur unverschämt und hochgradig Arrogant. > > Du hast vergessen darauf hinzuweisen, dass es im Thread sehr wohl > fachkundige Antworten auf die gestellte Frage gab. Aber du wolltest ja > mit deinem sinnlosen Post auch nicht wirklich weiterhelfen.
olaf schrieb: > Ich glaub die Karte habe ich sogar noch irgendwo rumliegen.... Echt? konnte leider nie eine Ergattern, und die vom eBay wurde nie geliefert ;-( Aber zurück zum Tema wie schon geschrieben wurde, gibt es Moderne Prozessoren, die mit Multicore arbeiten, es ist schon fast Standard ;-) Aber ein 8Bit Multicore ? Nicht wirklich, aber der Propeller P8X32, : https://www.parallax.com/download/ Geht in die Richtung ;-) Im µC Bereich gibt es sehr viele die verschiedene Cors haben für verschiedene Arbeiten. Aber wie schon geschrieben muss die Software dafür sorgen das der Richtige Core die Richtige Aufgabe bekommt... 73 55
Wolfgang R. schrieb: > KArl Fred M. schrieb: >> Muss ein Prozessor dafür ausgelegt sein? > Extra für Parallelbetrieb ausgelegt sind sog. Transputer CPUs Die sind aber auch nur ein Spezialfall von "lose" gekoppelten CPUs, also das wonach der TE nicht gefragt hat. Die Schnittstelle zwischen den CPUs ist zwar schneller als z.B. eine serielle Schnittstelle. Trotzdem hat jede CPU ihren eigenen Speicher und arbeitet Programme auch nur daraus ab. Aber gut, die Grenzen zwischen "lose gekoppelt" und "gemeinsamer Adressraum" lösen sich spätestens mit RDMA auf.
Wolfgang R. schrieb: > Es gibt sogar spezielle Betriebssysteme für Transputer - Helios z.B. Ich hab da noch 2 INMOS T800 hier rumliegen. Die Programmiersprache OCCAM war aber auch ein wenig gewöhgnungsbedürftig. Trotzdem: das ist alles Zeug, das im letzen Jahrtausend ausgestorben ist. Im Umkehrschluss: schon vor über einem halben Jahrhundert gab es Konzepte und Überlegungen mit zigzehntausend Seiten langen Abhandlungen wie sowas von der Hardware und deren Aufteilung bis hin zur Toolchain und der Verwaltung der Software aussehen könnte. KArl Fred M. schrieb: > Und die verschiedenen Denkansätze und Möglichkeiten eruieren. Und du erwartest, dass dann mal die zigzehntausend Seiten umfassenden Grundlagen in einem wunderhübschen Post allgemeinverständlich aufbereitet präsentiert werden? Wir können also sicher nicht den Urschleim nochmal durchkauen, bestenfalls über ein wirklich konkretes Beispiel durchgehen. > Lothar M. schrieb: >> Mach mal, was du offenbar noch nicht getan hast: lies einfach mal >> irgendwas zum Thema "Mehrprozessorarchitektur" > Aber danke für deinen tollen Vorschlag.... Keine Ursache. Mir hat der auch gut geholfen, als ich mir die selbe Frage gestellt habe.
Da möchte ich auch etwas beitragen, nicht fachlich, sondern etwas schräg, auch wenn erst Donnerstag ist - zur Auflockerung der Stimmung. Und ein bisschen passt es ja.
KArl Fred M. schrieb: > Die ersten Kommentare hier waren wiede r mal sehr Forentypisch, Es war auch forentypisch, dass Du Dir über Deine Frage nicht im Klaren warst oder es nicht auszudrücken konntest. Das ist ok. Die forentypischen Antworten dienen auch dazu, die Gedanken zu ordne. So als Frage man einen Experten, der 100€ nimmt. (Und ja, seine eigene Frage sorgfältig zu formulieren macht sie oft überflüssig) Die sachliche Antwort auf Deine Frage: so individuell wie die Aufgaben.
Lothar M. schrieb: > Im Umkehrschluss: schon vor über einem halben Jahrhundert gab es > Konzepte und Überlegungen mit zigzehntausend Seiten langen Abhandlungen > wie sowas von der Hardware und deren Aufteilung bis hin zur Toolchain > und der Verwaltung der Software aussehen könnte. Bereits in der Mainframe-Ära der 70er waren Doppelprozessorsysteme nicht mehr nur Konzept, sondern gelebte Realität. Und manches Kanalsystem uralter Mainframes war bereits ein asymmetrisches Mehrprozessorsystem, mit Peripheriecontroller als Busmaster mit eigenem Kanalprogramm. Das hatte sogar Intel beim 8086 implementiert, der 8089 DMA-Prozessor arbeitete so.
Ein früher Mikroprozessor der 70er war National Semiconductors SC/MP. Nicht eben ein Bolide, sondern reduziert und langsam, dafür aber billig. Trotzdem: "A unique feature of the SC/MP is a daisy-chained control pin that allowed up to three SC/MP's share a single main memory to produce a multiprocessor system." - Wikipedia Ich vermute allerdings, dass NS dabei eher das vorhin erwähnte Prinzip von I/O-Prozessoren an einem besseren Mikro/Mini-Rechner im Auge hatte,
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ein früher Mikroprozessor der 70er war National Semiconductors SC/MP. Ja und der Nachfolger für diesen Job war wohl der INS8070 bis INS8073 (Solche liegen bei mir noch Einzelstücke rum) Der hatte internes 64 Byte RAM um so quasi als Cache zu arbeiten. Irgend wo liegt noch so ein System rum wo ich mir tatsächlich mit 4 INS8073 eine art Multiprozessorsystem zusammenbaute, um Steuerungsaufgaben mit genügend Geschwindigkeit zu erledigen. Das schöne war am INS8073 das TinyBasic das im ROM schon drin war, das machte viele Steuerungsaufgaben schneller. Wenn er mir mal wieder in die Finger läuft (Wohl eher nach dem Umzug) werde ich in da im Forum im entsprechenden Thread posten :-)
:
Bearbeitet durch User
Hörst Du dich eigentlich reden Ich weiß sehr wohl was ich meine und jeder der klar denken kann, konnte auch verstehen was gemeint ist. Offenbar haben es ja hier auch die meisten richtig verstanden... Sorry, wenn es einige überfordert auf eine lax gestellte Frage zu antworten, ich hoffe ich habe diese Personen nicht übermäßig gestresst... A. S. schrieb: > Es war auch forentypisch, dass Du Dir über Deine Frage nicht im Klaren > warst oder es nicht auszudrücken konntest.
> Guter Link, danke. Gab's da jemals sinnvolle Software für? Ich hab die damals unter CP/M genutzt. Ich hab dazu in 68k Assembler programmiert und hatte vor meinen Programmen einen kleinen Z80-Header. Der wurde von der Z80 geladen und aufgerufen, hat dann auf den 68k umgeschaltet und so mein Programm gestartet. Wenn mein Programm dann ein Zeichen ausgeben wollte lief das wieder rueckwaerts. Also erst an die Bios Funktionen des CP/M uebergeben und ich meine dort wurde dann sogar auf den 6502 umgeschaltet. Ich hatte an diese Karte sogar ein Stueck Lochraster dran gepappt mit einem eigenen 32k Sram weil der 68008 beim Zugriff auf den Apple Speicher extrem langsam war. Aber an dem Schaltbild aus der MC sieht man ja schoen welcher Aufwand notwendig ist um sowas zu syncronisieren. Man kann also vieles schaffen, aber das muss man natuerlich lange Datenblaetter bis ins letzte Detail lesen. Da sind moderne CPUs wo einem das alles der Hersteller abnimmt schon bequemer und dank RP2040 kann jetzt sogar jeder einfach so fuer wenige Euro damit spielen. > Echt? konnte leider nie eine Ergattern, und die vom eBay wurde nie > geliefert ;-( Scheint wieder gebaut zu werden. :-) https://www.callapple.org/hardware/ninja-info-introduces-mc68008-card-for-the-apple-ii-series/ Olaf
KArl Fred M. schrieb: > Das würde meinem Gedankenansatz mich nur rudimentär spontan dafür > zu > interessieren zuwider laufen... > > Wühlhase schrieb: >> Oder schreib selber ein Programm auf deinem Rechner, das mehrere >> CPU-Kerne benutzt. Es ist ja nicht so, daß die CPU das Programm einfach >> nimmt und eigenmächtig irgendwie auf mehrere Kerne aufteilt.. Nun, dann mal ganz grob: Auf mehreren CPUs arbeiten zu wollen ergibt nur dann einen Sinn, wenn es das zu lösende Problem auch hergibt. Wenn du z.B. einfach nur eine Uhr betreiben willst, ergibt es wenig Sinn daß eine CPU die Minuten und eine andere die Sekunden inkrementiert. Die Kommunikation zwischen beiden CPUs, wann die Sekunden überlaufen und ob dann jetzt die Minuten zu inkrementieren seien, erfordert mindestens soviel Aufwand als wenn eine CPU einfach beides selber macht. Grundsätzlich wäre es ja kein Problem, zwei Mikrocontroller über einen Bus, z.B. SPI oder UART zu verbinden, und über diese verteilt zu rechnen. Du könntest so z.B. π beliebig präzise berechnen. Es gibt da ein Verfahren, dies über einen Viertelkreis zu tun, wobei du den Kreis in Teilstreifen zerlegen mußt (3. Versuch): https://mathematik-wissen.de/klasse-9/kreisberechnung Da kannst du den Kreis in beliebig viele Teilstreifen zerschneiden, und die Streifen von unterschiedlichen Controllern berechnen lassen. Also geht das hardwareseitig, aber die Software mußt du halt entsprechend schreiben. Prinzipiell funktioniert das auf einer modernen Mehrkern-CPU auch nicht viel anders, aber auch da mußt du die Berechnung über mehrere Kerne explizit vorsehen und mit mehreren Threads rechnen. Und dich dann um so lustige Dinge wie konkurrierende Speicherzugriffe usw. kümmern, aber das mußt du bei mehreren UART-verbundenen Mikrocontrollern eigentlich genauso.
Wühlhase schrieb: > Prinzipiell funktioniert das auf einer modernen Mehrkern-CPU auch nicht > viel anders, aber auch da mußt du die Berechnung über mehrere Kerne > explizit vorsehen und mit mehreren Threads rechnen. > Und dich dann um so lustige Dinge wie konkurrierende Speicherzugriffe > usw. kümmern, aber das mußt du bei mehreren UART-verbundenen > Mikrocontrollern eigentlich genauso. Konkurrierende Speicherzugriffe sind noch harmlos. Spassig wird es dann mit Caches, den notwendigen Cache-Konsistenz-Protokollen usw. - nicht ihne Grund haben die einschlägigen Vorlesungen im Informatikstudium mehrere Semesterwochenstunden Umfang gehabt. So etwas kann man nicht einfach in ein paar Sätzen sinnvoll zusammenfassen, schon gar nicht, wenn nicht mal der Wille zum Anlesen der notwendigen Grundlagen, um die bei Mehrprozessorsystemen inhärenten Probleme verstehen zu können, gegeben ist.
Realist schrieb: > - sie wollen ihre > Vorstellungen wie man sich wissen aneignet durchdrücken Ein Professor im Studium sagte mal, "Ich bin Professor und kein Pädagoge" Wer also lernen will muss nehmen was er bekommt, es mag bessere Pädagogen geben, aber die müssen nicht die besten Lehrenden sein! Der Streichelzoo ist nun mal nicht hier draussen, dafür haben die Götter verschiedene Lehranstalten gebaut!
KArl Fred M. schrieb: > Muss ein Prozessor dafür ausgelegt sein? nö nur kann es helfen! Hauptschwierigkeit? 1. begrenzte Portleitungen 2. begrenzte Leitungslängen und damit Frequenz der Synchronisation 3. Prüfung der übertragenen Daten, was nutzt es wenn die Prüfung so lange dauert das der 2te Prozessor nicht lohnt! Dreisatz hilft nun mal nicht immer: Ein Maurer mauert 1m² in einer Stunde, 1000 Maurer schaffen das nun mal nicht in 3,6 Sekunden, obwohl das rechnerisch stimmen würde!
Wühlhase schrieb: > Grundsätzlich wäre es ja kein Problem, zwei Mikrocontroller über einen > Bus, z.B. SPI oder UART zu verbinden, und über diese verteilt zu > rechnen. Du könntest so z.B. π beliebig präzise berechnen. Im Grunde war der alte Heathkit H89 schon ein Multiprozessor System. Ein Z80 hat das CP/M verarbeitet und der andere hat das Terminal gemacht, also Bildschirm und Tastatur. Die CP/M Platine war unten im Sockel des Systems, die Terminal-Platine mit dem 2. Z80 stand hinter dem Monitor senkrecht, wenn ich mich richtig erinnere... Ich war noch sehr jung als mein Vater das Ding als Bausatz aus den USA bekommen und es über Wochen im Hobbykeller zusammen gelötet hat. Ich meine, die beiden Platinen, obwohl in einem Gehäuse, waren ebenfalls über eine Serielle Schnittstelle verbunden. Aber es ist sehr sehr lange her... Muss ihn mal fragen, wo das Ding abgeblieben ist.
KArl Fred M. schrieb: > Muss ein Prozessor dafür ausgelegt sein? > Wenn man z.B. 2 Zilog Z80 CPUs nutzen wollte, ist die Krux dort in > erster Linie die Software oder wird eine 3te CPU benötigt zur > Koordination der anderen beiden? Einfach mal machen. Dann wird es klar. Erfahrung sammeln geht vor quatschen im Forum.
In einem alten Keithley Multimeter waren 3 Z80 verbaut. Einer für die Messung, einer für die Bedienung und einer für GPIB.
Probleme mit Cache fallen beim Z80 wohl, weg...
Tja da hatte ich doch auch mal vor laaanger Zeit, eine Grafikunit an meinem PDP11 Rechner, da waren... und haltet euch fest... ist kein Witz!) 10 stück 65SC802 drin! jeder hatte 64KB RAM eine Bus-Trennung (Jede menge GAL6001 & jede Menge 74xx254 (Keine Ahnung mehr ob das LS HC ALS oder sonst was waren) und aber nur eine EPROM Bank für alle. Das Zusatzgerät war für die Grafikdarstellung (Meine Erste Frontend Anlage)am PDP 11 und daran hing ein Risen Tektronix Bildschirm :-S Schade dass ich den nicht mehr habe, das war ein echtes Meisterwerk der dazumaligen Technik.
KArl Fred M. schrieb: > Ich weiß sehr wohl was ich meine Das mag ja sein dass du glaubst zu wissen was du meinst, aber kein anderer hier kann dir in den Kopf schauen. Du musst deine Frage schon so formulieren dass sie unmissverständlich ist und die Antwort konkret ausfallen kann ohne dass man das gesamte Grundlagenwissen eines ganzen Fachbereichs zusammenfassen müsste. KArl Fred M. schrieb: > und jeder der klar denken kann, konnte > auch verstehen was gemeint ist. Wie schön dass du anscheined in die Köpfe aller anderen schauen kannst. Aber du irrst dich, und zwar massiv. KArl Fred M. schrieb: > Ähm, nein. > Ich wollte dazu spontan... kurz eine Frage in ein Forum stellen. Also die weltumspannende Antwort auf alle Fragen ist 42
Die Hauptschwierigkeit ist das debugging der Software.
Solange eine CPU einen Thread abarbeitet, bekommst du immer wieder den
selben Ablauf.
Bei mehreren CPUs kommen die Ergebnisse ab und zu in einer anderen
Reihenfolge. Solche Fehler lassen sich nicht im Debugger reproduzieren
und du suchst ewig.
> Grafikunit ... 10 stück 65SC802
Gutes Beispiel. Für 3D Echtzeitgrafik braucht man unzählige CPUs. Da
sind alle Probleme zur Synchronisation im Treiber gekapselt. Der
Anwendungsprogrammierer muss nur einen Thread auf einer CPU debuggen.
Wolfgang R. schrieb: > Das sind nicht wirklich Coprozessoren, das sind Controller, die über den > ganz normalen Adress- und Datenbus gelesen und beschrieben werden > können. Der 68000 ist der Prozessor, auf dem das Betriebssystem läuft. Jain. Die Coprozessoren im Amiga waren keine richtigen "Prozessoren", führten aber ein Eigenleben unabhängig von der CPU und teilten sich mit dieser nur das Ram. "CPU an PAULA: Schreib mal die Daten ab Adresse x auf die Diskette" "PAULA an CPU: Fertig!"
KArl Fred M. schrieb: > Muss ein Prozessor dafür ausgelegt sein? > Wenn man z.B. 2 Zilog Z80 CPUs nutzen wollte, ist die Krux dort in > erster Linie die Software oder wird eine 3te CPU benötigt zur > Koordination der anderen beiden? Kommt auf dein Ziel an. Am praktikabelsten ist es sicher eine CPU als Coprozessor zu nutzen und die Toolchain entsprechend anzupassen. Dann sollte etwas Zusatzlogik zB. für die Buskontrolle/organisation und ausreichend schneller Speicher ausreichend sein. Problematisch wird es, wenn du normale CPUs kaskadieren möchtest, um zB. die Bitbreite zu erweitern. Dann werden nämlich manche Befehle "nutzlos" und Flags zeigen die falschen Werte. Geschwindigkeitsvorteil gegenüber sequenzieller Ausführung gibt es dann wohl dank externer Berechnung und synchronisation(falls überhaupt möglich) keinen mehr. Wie man sinnvoll die essenziellsten Komponenten eines Prozessors koppeln kann, kannst du im Datenblatt diverser Bit-Slices sehen, zB. 74AS888. Natürlich sind das bei Weitem keine vollständigen CPUs.
Karl Valentin sagte:
> Es wurde zwar schon alles gesagt, aber noch nicht von jedem.
scnr,
WK
Patrick L. schrieb: > eine Grafikunit an meinem PDP11 Rechner, da waren... und haltet euch > fest... ist kein Witz!) 10 stück 65SC802 drin! Danke. Ich hatte mich immer gefragt, wozu dieses Teil wirklich nützlich war. Auf eine Verwendung als GPU-Core wäre ich nie gekommen.
> In einem alten Keithley Multimeter waren 3 Z80 verbaut. Einer für die > Messung, einer für die Bedienung und einer für GPIB. Welches war das denn? Nur damit ich weiss was ich in meinem 199 vorfinden sollte falls ich da mal reinschaue. :) Olaf
Bevom man sich an's Loeten von Mehrprozessor konstrukten macht, koennte man das Ganze auch in einem FPGA laufen lassen. Das definitiv Kompliziertere ist die Software. Die Architektur muss an die Anwendung angepasst sein. Fuer parallele Verarbeitung, dh gleiches Programm, verschiedene Daten, landet mal bei einer GPU, und die hat einen Controllprozessor, der die Anderen mit Daten versorgt. Wie auch immer, bei der Software beginnen und alles durchspielen.
olaf schrieb: > Welches war das denn? Es könnte das 195A gewesen sein, mit diesen komischen hervorstehenden Tasten. https://custom-cal.com/ModelInfo.aspx?kn=11353&m=Keithley_195A&srv=Calibration Die Physiker haben ständig die FETs zur Bereichsumschaltung zerschossen.
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.