Hallo Ihr, ich hätte da mal eine Frage zum Mikroprozessor, also was passiert genau, wenn im Arbeitspeicher ein Operationscode steht, hinter dem sich kein Mikroprogramm befindet, also wenn eine nicht belegte Speicherstelle im ROM angesprochen wird? Oder anders gesagt, wenn durch einen bösen Zufall ein ungültiger Assemblerbefehl in den Arbeitspeicher geschrieben wird (beim 8085 zB FDH). Meine Frage bezieht sich jetzt speziell auf den 8085, aber wahrscheinlich ist die reaktion bei den anderen Mikroprozessoren ähnlich. Oder gibt es gar keine Reaktion und der Programm-Counter wird einfach im 1 erhöht um den nächsten Befehl anzusprechen?
Bert Hurtig schrieb: > Hallo Ihr, > ich hätte da mal eine Frage zum Mikroprozessor, also was passiert genau, > wenn im Arbeitspeicher ein Operationscode steht, hinter dem sich kein > Mikroprogramm befindet, also wenn eine nicht belegte Speicherstelle im > ROM angesprochen wird? Was genau passiert, hängt von der CPU ab. Manche werfen eine Exception, wieder andere ignorieren den Befehl, andere tun tatsächlich irgendetwas mehr oder weniger Sinnvolles, was sich aus dem Aufbau des OpCodes ergibt. Wie es beim 8085 ist, weiß ich jetzt nicht. Aber bei einem seiner populären 'Nachfolger', dem Z80, gab es durchaus brauchbare 'undokumentierte Befehle', die auch benutzt wurden. Kannst dich ja mal auf die Suche machen. Das Bitmuster für FDH aufschreiben und dann alle Befehle durchgehen, die in diesem Bitmuster ihren konstanten OpCode Teil wiederfinden. Die Bits die im Opcode variabel sind (meistens irgendwelche Registernummern) ergänzt du dann aus FDH und siehst nach ob die CPU diesen Befehl tatsächlich ausführt.
Meist führt das zu einem Neustart, schau dir mal an was im leeren Speicher steht. (0xFF oder 0x00)
> wahrscheinlich ist die reaktion bei den anderen Mikroprozessoren > ähnlich. Nein, die Reaktionen sind sehr unterschiedlich, und können sogar bei gleichem Mikroprozessor von der konkreten Masken-Revision abhängen. Die Reaktionen gehen von "es passiert gar nichts" über "der Prozessor führt den Illegal-Opcode-Handler aus" bis "die CPU hängt sich auf" und im Extremfall (sehr selten) "der Prozessor wird beschädigt".
Bert Hurtig schrieb: > wenn im Arbeitspeicher ein Operationscode steht, hinter dem sich kein > Mikroprogramm befindet Mikroprogrammierung zur Ausführung von Opcodes ist nicht universell verbreitet. Andererseits darf man bei mikropogrammierten CPUs von einem definierten Verhalten bei undefinierten Opcodes ausgehen, denn sowas wie unbelegte ROM-Plätze gibt es nicht (irgendwas steht immer drin), während einfache nicht mikroprogrammierte CPUs mitunter eben das machen, was sich als Schmutzeffekt aus unvollständiger Dekodierung ergibt. Man hat da schon welche gesehen, in der bestimmte Codes sozusagen zwei verschiedene Operationen gleichzeitig ausführten.
Danke für die schnellen antworten! Also mein Problem ist ich habe nur einen Simulator zur Hand um es beim 8085 zu testen. Dieser bringt dann die Meldung: "Trap: Opcode 0000H ERROR" (0000h ist die Speicheradresse wo ich FDH reingeschrieben habe). Er geht nach der Meldung aber normal zum nächsten Befehl weiter. Jetzt weiß ich nicht ob das mit der Realität übereinstimmt. Vielleicht weiß das ja jemand...
Bert Hurtig schrieb: > Dieser bringt dann die Meldung: "Trap: Opcode 0000H ERROR" (0000h ist > die Speicheradresse wo ich FDH reingeschrieben habe). Er geht nach der > Meldung aber normal zum nächsten Befehl weiter. Jetzt weiß ich nicht ob > das mit der Realität übereinstimmt. Vielleicht weiß das ja jemand... Das ist das schöne an undefinierten Opcodes. Das Verhalten ist undefiniert, folglich weiss niemand ausser dem Entwickler des Cores, was dabei genau passiert. Und da es längst nicht mehr nur den Original-Intel-Core mit seiner 12fach-Taktung gibt, kann sich das u.U. bei verschiedenen Cores unterscheiden.
Bert Hurtig schrieb: > Danke für die schnellen antworten! > Also mein Problem ist ich habe nur einen Simulator zur Hand um es beim > 8085 zu testen. Simulatoren sind da meistens pingeliger bzw. bilden die tatsächlich in der Hardware vorhandenen Decodierlogik nicht exakt ab. > Dieser bringt dann die Meldung: "Trap: Opcode 0000H ERROR" (0000h ist > die Speicheradresse wo ich FDH reingeschrieben habe). Er geht nach der > Meldung aber normal zum nächsten Befehl weiter. Jetzt weiß ich nicht ob > das mit der Realität übereinstimmt. Nein. Was die Intel-8085 genau macht, weiß ich nicht. Aber einen Illegal Opcode Trap macht sie mit Sicherheit nicht. Ich denke eheer, bedenkt man das Alter der CPU, dass sie sich einen Befehl aus dem OpCode zusammensynthetisiert. Ob der irgendetwas Sinnvolles macht, müsste man ausprobieren. Oder danach googlen "8085 undocumented opcode" scheint mir erfolgversprechend. Edit: Da haben wirs ja schon http://electronicerror.blogspot.com/2007/08/undocumented-flags-and-instructions.html Ein FDH macht einen Jump to location addr if K flag is set. Wobei das 'K-Flag' ein nicht benutztes Bit im Statusregister F ist.
Bert Hurtig schrieb: > ich hätte da mal eine Frage zum Mikroprozessor, also was passiert genau, > wenn im Arbeitspeicher ein Operationscode steht, hinter dem sich kein > Mikroprogramm befindet, also wenn eine nicht belegte Speicherstelle im > ROM angesprochen wird? Naja, eine nicht belegte Speicherzelle ist oft gleichzusetzen mit dem Wert 0xFF. Der Opcode 0xFF korreliert häufig mit der Anweisung NOP. Manchmal werden auch einfach alle "illegalen" Opcodes als NOP interpretiert. > Oder anders gesagt, wenn durch einen bösen Zufall ein ungültiger > Assemblerbefehl in den Arbeitspeicher geschrieben wird Der STM8 macht einfach einen Reset. Sinnvoller Weise wird im Statusregister das Illegal-Opcode-Flag gesetzt. "Illegal opcode reset: If a code to be executed does not correspond to any opcode or prebyte value, a reset is generated. [...] Bit 2 of Reset Status Register - ILLOPF: Illegal opcode reset flag: 0: No ILLOP reset occurred 1: An ILLOP reset occurred" > Meine Frage bezieht sich jetzt speziell auf den 8085, Dann schreib' das doch bitte in Zukunft auch ins Subject, das würde die Sache ungemein erleichtern, da ich den Fred als Nichtlesenswert gleich übersprungen hätte. Tagging z.ß. wurde schon im vorigem Jahrtausend erfunden. Das hast Du nun davon: Du kriegst eine (unpassende) Antwort. ;-) > aber wahrscheinlich ist die reaktion bei den anderen Mikroprozessoren > ähnlich. Eben nicht! Von der Interpretation als NOP bis hin zum ILLOP-Interrupt ist alles möglich und wird auch alles implementiert. > Oder gibt es gar keine Reaktion und der Programm-Counter wird einfach im > 1 erhöht um den nächsten Befehl anzusprechen? Auch möglich. Leider kann ich zum 808x im Speziellen nichts sagen, da ich damit "noch" nichts gemacht habe. Iwan
So dann scheint das wohl geklärt, danke nochmal an alle geht ja echt fix hier. Besonders der Link ist interessant, danke Karl heinz Buchegger !
Bert Hurtig schrieb: > wenn im Arbeitspeicher ein Operationscode steht, hinter dem sich kein > Mikroprogramm befindet, kann beim 8085 nicht passieren, da die OpCodes beim 8085 von 00h bis FFh gehen. D.h. jeder Wert wird als OpCode oder als Adresse gewertet, je nachdem ob der Befehl davor ein 1-Byte, 2-Byte oder 3-Byte Befehl war.
... schrieb: > kann beim 8085 nicht passieren, da die OpCodes beim 8085 von 00h bis FFh > > gehen. Beim 8085 sind nur 246 Opcodes definiert. Bei 10 Bitmustern ist das Verhalten (mir jedenfalls) nicht bekannt. 8085
>wenn im Arbeitspeicher ein Operationscode steht, hinter dem sich kein >Mikroprogramm befindet, also wenn eine nicht belegte Speicherstelle im >ROM angesprochen wird? Dir fehlen ja alle Grundlagen! Ein 8085 holt sich kein Mikroprogramm, weil es da sowas nicht gibt. Wenn ein falscher Befehl im ROM/RAM steht, ist entweder falsch programmiert oder der ROM/RAM ist defekt! Und was ist ein ungültiger Befehl? Und wenn er eben auf "FDH" trifft, dann macht er es dann auch! Oder machst du dir Gedanken um die undefinierten Befehle des Z-80? Ich glaube, der FDH ist so einer. Dies wäre aber ein ganz neues Thema.
ich frage mich auch wie man einen falschen Opcode auf den µC bekommt, der Assembler stellt in diesem Fall ja keine File zum Flashen her, die einzige Möglichkeit wäre es, das nachträglich im Programm Flash-oder -ROM eine Speicherzelle kaputt geht oder kippt.
Hi >ich frage mich auch wie man einen falschen Opcode auf den µC bekommt, >der Assembler stellt in diesem Fall ja keine File zum Flashen her, die >einzige Möglichkeit wäre es, das nachträglich im Programm Flash-oder >-ROM eine Speicherzelle kaputt geht oder kippt. Ganz einfach: Programm .db XY,.... Programm MfG Spess
Hallo, illegale Opcodes haben schon auf dem 6510 im C64 genervt, da wurden die gern genommen, um den Hackern das Hacken schwerer zu machen. Naja, die meisten Disassembler konnten die dann eben mit disassemblieren, die benutzte Mnemotic war nur nicht richtig genormt. ;) Beim Z80 und dem Nachbau U880 aus DDR-Fertigung war so zumindest sicher, daß es ein 1:1 Nachbau war. Alle illegalen Opcodes gingen genauso. Gruß aus Berlin Michael
8085 schrieb: > Bei 10 Bitmustern ist das Verhalten (mir jedenfalls) nicht > bekannt. siehe http://electronicerror.blogspot.com/2007/08/undocumented-flags-and-instructions.html
Zurück zur Ausgangsfrage: Was passiert, wenn ein Programm auf einen nicht definierten Opcode trifft? Ich erweitere die Frage: Was passiert, wenn ein Programm auf eine Instruktion trifft, die im derzeitigen Status des Systems nicht ausführbar ist, z.B. - Undefinierter Opcode - Schreiben auf Read-Only Speicher - Zugriff außerhalb des existierenden Speichers - Warten auf ein Ereignis, während das Interruptsystem gesperrt ist - ... Und die präzise Antwort: Dann passiert genau das, was die Entwickler der betreffenden CPU für diese Situation implementiert haben, z.B. (nicht unbedingt vollständig, aber auf jede CPU zutreffend) - es wird ein Interrupt geworfen - es wird eine halbwegs sinnvolle undokumentierte Instruktion ausgeführt - die Operation wird als NO OP ausgeführt - ein Speicherzugriff läuft ins Leere - es kommt eine Fehlermeldung auf der Operator-Konsole (z.B. IBM Z-Serie) - ... Für manche CPU ist das Verhalten dokumentiert, für manche nicht. Bernhard
Bernhard R. schrieb: > Dann passiert genau das, was die Entwickler der betreffenden CPU für > diese Situation implementiert haben, Da du die Frage erweitert hast, kannst du auch diese Antwort erweitern. Es passiert das, was sich * die Entwickler übelegt haben, das passieren soll * sich zufällig durch die Art der Verschaltung ergibt. Worauf ich raus will: Du hast die Punkte angesprochen - Schreiben auf Read-Only Speicher - Zugriff außerhalb des existierenden Speichers einer Z80 ist es egal, wenn sie auf ein EPROM schreibt. Die macht einfach ihren Schreibzyklus. Ob da im Speicher tatsächlich etwas dabei passiert, interessiert die CPU nicht. Früher war es bei kleinen Systemen gang und gäbe, dass die Adressdekodierung nicht vollständig gemacht wurde. Da konnte es dann schon sein, dass derselbe physische Speicher 2 oder mehrmals im Adressraum der CPU auftauchte. Änderte man die Speicherzelle (aus Sicht der CPU) an der Adresse 0x3003, dann hat man damit auch automatisch 0x7003, 0xB003, 0xF003 verändert, weil all diese Adressen auf denselben physischen Speicher gemappt wurden. Hat das jemanden gestört? Nein. Am allerwenigsten die CPU :-) Der CPU ist es auch egal, ob sich an einem CS Ausgang des Adressdekoders tatsächlich ein RAM-Chip befindet oder nicht. Die legt ihre Signale auf den Bus und tut so als ob da etwas wäre. Natürlich kann man das alles auch abstellen. In der Adressdekodierung, dort wo die Chip-Select Signale anfallen, könnte man die CS für die EPROMs abzweigen, mit dem WR Signal verknüpfen und auf einen Interrupt Eingang der CPU führen und so einen Schreibzugriff auf das EPROM detektieren. Man könnte auch den Adressdekoder vollständig machen, bzw. wieder die Rückmeldung über einen Interrupt liefern: Da wo du schreibst, gibt es gar keinen Speicher. Aber all das hat letzten Endes immer Silizium gekostet und war verhältnismässig teuer. Einfacher ist es dem Programmierer zu sagen: So ist die Situation, nutz sie nicht aus und leb damit. Wenn du sie aber ausnutzt, dann Wasche ich meine Hände in Unschuld, du musst selber wissen was du tust. Langer Rede kurzer Sinn: begiebt man sich in das Gewässer undokumentierter Befehle, ungültiger Adressen, ungültiger Hardware-Zugriffe, kann alles Mögliche und Denkbare passieren. Es ist zwar auf einer speziellen Hardware ein immer gleiches verhalten, aber 15 unterschiedlich aufgebaute Boards können 15 unterschiedliche Verhaltensweisen an den Tag legen.
Bernhard R. schrieb: > Dann passiert genau das, was die Entwickler der betreffenden CPU für > diese Situation implementiert haben was ist, wenn diese nichts expliziertes implementiert haben. dh, die dekodierlogik (insofern es keine mikroprogramm-gesteuerte Maschine ist) hängt in einem undefiniertem Zustand. Was da passsiert, hängt von der individuellen (für jede Hardwarerevision) Verschaltung des Dekoders ab. Es kann quasi alles mögliche passieren. Die Schaltung ist ja höchstwahrscheinlich auf die möglichen Eingabewörter optimiert, so dass eventuell nicht alle Bits eines OP-Code getestet werden, wenn bekannt ist, dass es keine spezifizierten Codes mit diesen Bits gibt. Was dann im Decoder passiert ist Zufall. Wenn dadurch zB irgendwelche internen Treiber falsch angesteuert werden, kann das, wie oben bereits erwähnt, auch zur Zerstörung der CPU/MCU führen.
Vlad Tepesch schrieb: > Wenn dadurch zB irgendwelche Treiber > falsch angesteuert werden, kann das, wie oben bereits erwähnt, auch zur > Zerstörung der CPU/MCU führen. ich glaube (hoffe) nicht dass die Entwickler sowas nicht abgefangen haben, das wäre ja schon grob fahrlässig, es kann doch jederzeit vorkommen dass durch einen Bug z.B. der Stack zerschossen wird und der Rücksprung dadurch irgendwohin, also evtl. auch auf einen illegalen opcode erfolgt
Vlad Tepesch schrieb: > Wenn dadurch zB irgendwelche internen > Treiber falsch angesteuert werden, kann das, wie oben bereits erwähnt, > auch zur Zerstörung der CPU/MCU führen. Theroretisch möglich, praktisch ziemlich ausgeschlossen. Dass eine Maschine auf undefinierte Opcodes stösst ist im Rahmen von Programm- und Speicherfehlern sehr oft der Fall, gehört somit also zum Regelbetrieb. Da darf dann nicht jedesmal die Maschine in die Luft fliegen.
Ich glaube, das mir dem CPU zerstören, ist eher ein historisches Ereigniss ;) Ich erinnere mich mal gehört zu haben, dass es ein System gab, auf dem eine bestimmte (verbotene) Instruktionsfolge zum durchbrennen eines Widerstands in der CPU geführt hat. An mehr Deteils kann ich mich leider nicht erinnern.
>ich glaube (hoffe) nicht dass die Entwickler sowas nicht abgefangen >haben, >das wäre ja schon grob fahrlässig, Wieso das denn ? Man darf auch nicht vergessen, dass der 8085 schon in den Siebzigern auf den Markt kam. Da gab es noch kein VHDL oder Verilog, wo man einfach eine others -> "0000" Option hatte. Da wurde das Ganze noch schön von Hand aufgemalt und zum Verifizieren wurden diskrete Logikgatter gewrappt und man hatte genug zu tun, die dokumentierten Dinge ans Laufen zu kriegen. Ich würde stark annehmen, dass der einfach irgendwas macht, aber nichts definiertes. Gruss Axel
Axel schrieb: >>ich glaube (hoffe) nicht dass die Entwickler sowas nicht abgefangen >>haben, das wäre ja schon grob fahrlässig, > > Wieso das denn ? Weil ein CPU-Entwickler, der sowas zulässt, seinen Brötchengeber in den Ruin treiben kann. Da es wie schon beschrieben durchaus zum Regelbetrieb gehört, auf undefinierte Opcodes zu stossen, wäre ein entsprechender Defekt ein Gewährleistungsfall.
Axel schrieb: > Ich würde stark annehmen, dass der einfach irgendwas macht, aber nichts > definiertes. Wie man an der oben verlinkten Liste undefinierter Opcodes des 8085 erkennen kann ist deren Funktion alles andere als zufällig. Ganz im Gegenteil, diese Operationen sind/wären teilweise ungemein nützlich und sind garantiert absichtlich so entstanden.
Wenn CPU und Treiberbausteine beide auf Ausgang sind und dann gegeneinander kämpfen, gewinnt der Stärkere. Das ist heute noch so. Und wer auf 0000H (Programmstart nach RESET) bewußt so einen Befehl setzt, dem ist nicht zu helfen. Da fehlt ja noch jegliche Initialisierung!
Inwiefern muss man die 8085-CPU initialisieren, abgesehen vom Reset-Signal? Dass man ein Rechnersystem mit 8085 im Zentrum so bauen kann, dass bestimmte Operationen den Rauch rauslassen ist klar. Aber das hat dann nichts mit undefinierten Opcodes zu tun, sondern mit undefinierten Bus/IO-Operationen oder -Sequenzen.
Michael_ schrieb: > Wenn CPU und Treiberbausteine beide auf Ausgang sind und dann > gegeneinander kämpfen, gewinnt der Stärkere. Im Prinzip ja. Allerdings: * sind es nur wenige Opcodes, deren Funktion nicht offiziell dokumentiert ist. * das Durchbrennen findet nicht in Nanosekunden statt, d.h. mit dem nächsten Befehl geht die CPU ja wieder in einen definierten Zustand über Wenn du an einem AVR zwei Pins verbindest und beide auf Ausgang mit unterschiedlichem Potential programmierst, so ist das sicherlich nicht gut für die Ausgangstreiber, aber ein bischen was halten die schon auch aus. Du stirbst ja auch nicht sofort am Blutverlust, wenn du dich mit dem Messer schneidest.
>Autor: Karl heinz Buchegger (kbuchegg) (Moderator) >Datum: 13.04.2010 19:03 >Ein FDH macht einen >Jump to location addr if K flag is set. >Wobei das 'K-Flag' ein nicht benutztes Bit im Statusregister F ist. Na wie ist das K-Flag nach RESET? Und was soll da gleich ein Sprung nach ???? Und ein 8085/Z-80 braucht ja noch Stack, CTC, PIO DMA... , die wollen alle wissen was los ist.
Michael_ schrieb: >>Autor: Karl heinz Buchegger (kbuchegg) (Moderator) >>Datum: 13.04.2010 19:03 > >>Ein FDH macht einen >>Jump to location addr if K flag is set. >>Wobei das 'K-Flag' ein nicht benutztes Bit im Statusregister F ist. > > Na wie ist das K-Flag nach RESET? Und was soll da gleich ein Sprung nach > ???? > Und ein 8085/Z-80 braucht ja noch Stack, CTC, PIO DMA... , die wollen > alle wissen was los ist. Schau. Dasselbe passiert doch auch wenn du in andere Befehle schräg einsteigst. Machst du einen .org 0010H C3 CD 00 ; jump to 0x00CD C9 ; ret und springst du irrtümlich nach 0011H, dann wird der CD als Call ausgeführt auf die Adresse C900H. Was dann in weiterer Folge passiert, ist schwer zu durchschauen (dort könnte man ja wieder quer in einen Mehrbytebefehl eingestiegen sein). Aber deswegen brennt nicht gleich die CPU ab. Sie macht irgendwas, so wie sie immer irgendwas macht. Ob das K-Flag beim Reset einen definierten Zustand hat oder nicht, können dir wahrscheinlich nur die Entwickler sagen. Und wenn du als erste Instruktion einen FDH hast, dann hast du den dort eben. Mit allen Konsequenzen. Wenn sich das dann so auswirkt, dass Bustreiber minutenlang gegeneinander arbeiten, klar, dann wird irgendwann einer aufgeben. Programmieren bedeutet nun mal: Wissen was man tut. Programmieren auf Assemblerebene ohne Betriebssystem bedeutet: die volle Verantwortung übernehmen, ohne Netz und doppelten Boden. Aber es ist auch nicht so, dass beim geringsten Fehler sofort der magische Rauch entweicht.
Eine Verbindung von undefinierten Befehlen und zerstörter Hardware >Ich glaube, das mir dem CPU zerstören, ist eher ein historisches >Ereigniss ;) >Ich erinnere mich mal gehört zu haben, dass es ein System gab, auf dem >eine bestimmte (verbotene) Instruktionsfolge zum durchbrennen eines >Widerstands in der CPU geführt hat. An mehr Deteils kann ich mich leider >nicht erinnern. habe ich nicht gemeint. Es sind zwei weiter oben getrennt angebrachte Themen. Natürlich gehen undok. Befehle und eine CPU, die das versteht, recht gut. "Man muß nur wissen was man tut".
http://en.wikipedia.org/wiki/Halt_and_Catch_Fire Und Seite 65 in ftp://reports.stanford.edu/pub/cstr/reports/csl/tr/86/289/CSL-TR-86-289. pdf
> Aber es ist auch nicht so, dass beim geringsten Fehler sofort der magische Rauch
entweicht.
Üblicherweise nicht, ausser beim 6502. Den konnte man per Software
grillen.
bensch schrieb: > Üblicherweise nicht, ausser beim 6502. Den konnte man per Software > grillen. Wie?
A. K. schrieb: > bensch schrieb: > >> Üblicherweise nicht, ausser beim 6502. Den konnte man per Software >> grillen. > > Wie? Kenne ich auch nicht und das als alter Knochen, der auf dem PET in Hexcode(!) programmierte. Aber es gab die Geschichte beim C64, wo man wohl den Videocontroller durch falsche Registereinstellungen zu heiß werden lassen konnte und dieser sich dann dauerhaft verabschiedete. Der war aber sowieso jenseits von Gut und Böse, was das thermische Management angeht. Prinzipiell muß man aber bei diesem Thema sowieso streng nach CPU unterscheiden. Die früheren machten bei undefinierten OpCodes irgendwas. Scherte niemanden. Später wurde das bei neuen Designs auch berücksichtigt und heute ist es eher Standard, das die CPU definiert aus dem undefinierten Zustand rausgeht und das meist auch reported!
Bernhard R. schrieb: > Ich erweitere die Frage: > Was passiert, wenn ein Programm auf eine Instruktion trifft, die im > derzeitigen Status des Systems nicht ausführbar ist, z.B. Man könnte die Fragstellung auch völlig zwanglos folgendermaßen erweitern: Warum ist die Banane krumm?
Vlad Tepesch schrieb: > Wenn dadurch zB irgendwelche internen > Treiber falsch angesteuert werden, kann das, wie oben bereits erwähnt, > auch zur Zerstörung der CPU/MCU führen Ein Beispiel dafür war die HP-3000. Die konnte man per Microprogramm schrotten. Dazu brauchte man noch nichtmal ungültige Opcodes. (Das Gerät war ursprünglich vom Anwender microprogrammierbar, was dann aber schnell abgestellt wurde.) Für die alten Rechner mit Ringkernspeicher gab es noch einen viel simpleren Trick, den Speicher zu schlachten: jmp $ die kleinste unendliche Schleife. Sie brachte bei manchen Maschinen den Kernspeicher zum Glühen.
Abdul K. schrieb: > Aber es gab die Geschichte beim C64, wo man > wohl den Videocontroller durch falsche Registereinstellungen zu heiß > werden lassen konnte und dieser sich dann dauerhaft verabschiedete. Das hat dann aber nichts mit dem 6502-Prozessor zu tun und es wird auch nicht der Prozessor gegrillt, sondern der Videocontroller. Grafikkarten, die ja nach wie vor die Timings programmierbar gestalten, kann man sicherlich auch heute noch (bzw. erst recht) in Nullkommanix ins Nirvana jagen. Nur hat an dem Ende kein Programmierer ausserhalb des Herstellers irgendwas verloren. Aktuelle Prozessoren kann man mit speziellen Befehlssequenzen u.U. soweit treiben, dass die übliche Kühlung grenzwertig bis ungenügend wird. Gekühlt wird nicht unbedingt auf maximal mögliche Leistung, sondern auf die Thermal Design Power (oder so ähnlich) des gehobenen Normalbetriebs bei aktiver CPU. Daher finden sich dort thermische Sicherungen, zuerst mit Betriebssystem/BIOS-Support zum runtertakten, danach ggf. als Notnagel hardwired mit eingelegten Zwangspausen. Was dazu führt, dass arg staubgeplagte Rechner durch einfaches Säubern schneller werden können.
A. K. schrieb: > Abdul K. schrieb: > >> Aber es gab die Geschichte beim C64, wo man >> wohl den Videocontroller durch falsche Registereinstellungen zu heiß >> werden lassen konnte und dieser sich dann dauerhaft verabschiedete. > > Das hat dann aber nichts mit dem 6502-Prozessor zu tun und es wird auch > nicht der Prozessor gegrillt, sondern der Videocontroller. Ja schön A.K. Finde ich toll, wenn du mich nur halb zitierst. Arbeitest du bei BILD? > > Grafikkarten, die ja nach wie vor die Timings programmierbar gestalten, > kann man sicherlich auch heute noch (bzw. erst recht) in Nullkommanix > ins Nirvana jagen. Nur hat an dem Ende kein Programmierer ausserhalb des > Herstellers irgendwas verloren. Früher auch gerne den dahinterliegenden Monitor! > > Aktuelle Prozessoren kann man mit speziellen Befehlssequenzen u.U. > soweit treiben, dass die übliche Kühlung grenzwertig bis ungenügend > wird. Gekühlt wird nicht unbedingt auf maximal mögliche Leistung, > sondern auf die Thermal Design Power (oder so ähnlich) des gehobenen > Normalbetriebs bei aktiver CPU. Daher finden sich dort thermische > Sicherungen, zuerst mit Betriebssystem/BIOS-Support zum runtertakten, > danach ggf. als Notnagel hardwired mit eingelegten Zwangspausen. Was > dazu führt, dass arg staubgeplagte Rechner durch einfaches Säubern > schneller werden können. Ist das eigentlich irgendwie standardisiert? Ich glaube, bei mir kam das auch mal vor. CPU-Lüfter blieb stehen, der Rechner ging aus, aber das Netzteil war noch an. Ist das in jedem BIOS anders?
Uhu Uhuhu schrieb: > Ein Beispiel dafür war die HP-3000. Die konnte man per Microprogramm > schrotten. Yep, per Mikroprogramm ist sowas weit wahrscheinlicher. Auf der Ebene gilt Schrott rein Schrott^2 raus. > die kleinste unendliche Schleife. Sie brachte bei manchen Maschinen den > Kernspeicher zum Glühen. Laut obigem HCF-Link eher zum Qualmen.
Abdul K. schrieb: > A. K. schrieb: >> Abdul K. schrieb: >> >>> Aber es gab die Geschichte beim C64, wo man >>> wohl den Videocontroller durch falsche Registereinstellungen zu heiß >>> werden lassen konnte und dieser sich dann dauerhaft verabschiedete. >> >> Das hat dann aber nichts mit dem 6502-Prozessor zu tun und es wird auch >> nicht der Prozessor gegrillt, sondern der Videocontroller. > > Ja schön A.K. Finde ich toll, wenn du mich nur halb zitierst. Arbeitest > du bei BILD? Zitate sinnvoll zu kürzen gehört eigentlich zu den Netiketten. Was habe ich verfälscht? > Ist das eigentlich irgendwie standardisiert? Ich glaube, bei mir kam das > auch mal vor. CPU-Lüfter blieb stehen, der Rechner ging aus, aber das > Netzteil war noch an. Ist das in jedem BIOS anders? Ich stecke da nicht so tief drin. Es gibt allerdings heutzutage durchaus mehr Schnittstellen zwischen Betriebssystem und dem "BIOS" als man aus DOS-Zeiten so kennt. Der ganze Kram rund um ACPI, System Management Mode und sowas. Deshalb hängt ja auch der Support für die diversen Schlafzustände des Rechners so stark am BIOS.
Uhu Uhuhu schrieb: > Für die alten Rechner mit Ringkernspeicher gab es noch einen viel > simpleren Trick, den Speicher zu schlachten: > > jmp $ > > die kleinste unendliche Schleife. Sie brachte bei manchen Maschinen den > Kernspeicher zum Glühen. Das ist wohl eher in den Bereich der Folklore einzuordnen. Kernspeicher reagiert recht empfindlich auf Temperaturschwankungen. Deshalb hatte der Speicher entweder Temperatursensoren, um die Schreib- und Leseströme an die Temperatur anzupassen, oder eine Heizung, um die Temperatur konstant zu halten (bei um die 40℃). Bis da irgendwas anfängt zu glühen hätte der Speicher schon lange keine korrekten Daten mehr geliefert, und damit hätte die CPU auch den "jmp $"-Befehl nicht mehr sauber gelesen und ausgeführt, womit die Schleife durchbrochen gewesen wäre (wenn auch auf undefinierte Art und Weise, womit wir wieder beim Thema wären ;-) Andreas
A. K. schrieb: > Abdul K. schrieb: >> A. K. schrieb: >>> Abdul K. schrieb: >>> >>>> Aber es gab die Geschichte beim C64, wo man >>>> wohl den Videocontroller durch falsche Registereinstellungen zu heiß >>>> werden lassen konnte und dieser sich dann dauerhaft verabschiedete. >>> >>> Das hat dann aber nichts mit dem 6502-Prozessor zu tun und es wird auch >>> nicht der Prozessor gegrillt, sondern der Videocontroller. >> >> Ja schön A.K. Finde ich toll, wenn du mich nur halb zitierst. Arbeitest >> du bei BILD? > > Zitate sinnvoll zu kürzen gehört eigentlich zu den Netiketten. Was habe > ich verfälscht? > Du hast den Fokus verändert. Von meinem "ich kenne das nicht von der CPU, aber vom Videocontroller" zu "Das hat dann aber nichts mit dem 6502-Prozessor zu tun ... sondern der Videocontroller." Ist aber nicht so wichtig.
>Wie man an der oben verlinkten Liste undefinierter Opcodes des 8085 >erkennen kann ist deren Funktion alles andere als zufällig. Ganz im >Gegenteil, diese Operationen sind/wären teilweise ungemein nützlich und >sind garantiert absichtlich so entstanden. Ich würde eher vermuten, die ursprünglich geplanten Funktionen haben nicht so funktioniert, wie sie sollten. Also hat man sie aus der Dokumentation rausgenommen, statt alles neu zu machen. >Weil ein CPU-Entwickler, der sowas zulässt, seinen Brötchengeber in den >Ruin treiben kann. Das ist ziemlicher Quatsch. Eine Gewährleistung, wenn man ein Baustein ausserhalb der Spec nutzt, wird kaum greifen. Gruss Axel
Axel schrieb: > Das ist ziemlicher Quatsch. Eine Gewährleistung, wenn man ein Baustein > ausserhalb der Spec nutzt, wird kaum greifen. Nunja, strenggenommen benutzt du ein Auto auch ausserhalb der Spec, wenn du damit im Halteverbot parkst, trotzdem dürfte der Hersteller ein Problem bekommen, wenn dabei jedesmal der Motor Feuer fängt ;-) Andreas
Axel schrieb: > Das ist ziemlicher Quatsch. Eine Gewährleistung, wenn man ein Baustein > ausserhalb der Spec nutzt, wird kaum greifen. Das ist ziemlicher Quatsch, denn die ungewollte Ausführung undefinierter Prozessor-Befehle ist innerhalb der Spezifikation eines normalen frei programmierbaren Prozessors oder Rechners. Nicht unbedingt in dem Sinn, dass damit irgendwas Definiertes geschieht, aber in dem Sinn, dass er dadurch nicht abrauchen darf. Es sei denn, das betreffende System kommt als fertige Lösung. Ein System, dass für Programmierung durch den Anwender freigegeben ist, das muss einfache Programmfehler auf der freigegebenen Ebene verkraften können.
Andreas Ferber schrieb: > Bis da irgendwas anfängt zu glühen hätte der Speicher schon lange keine > korrekten Daten mehr geliefert Ich habs nicht selbst erlebt, aber es soll tatsächlich zu echten Hardwaredefekten geführt haben. Natürlich ist spätestens beim Überschreiten der Curie-Temperatur des Kernmaterials Schluß. Was die Schreib/Leseverstärker bis dahin machen, steht auf einem anderen Blatt. (Da die Kernspeicher nur destruktiv lesbar waren, folgte auf einen Lesezyklus automatisch ein Schreibzyklus mit dem ausgelesenen Bit.)
>Das ist ziemlicher Quatsch, denn die ungewollte Ausführung undefinierter >Prozessor-Befehle ist innerhalb der Spezifikation eines normalen frei >programmierbaren Prozessors oder Rechners. Nicht unbedingt in dem Sinn, >dass damit irgendwas Definiertes geschieht, aber in dem Sinn, dass er >dadurch nicht abrauchen darf. Es sei denn, das betreffende System kommt >als fertige Lösung. Ein System, dass für Programmierung durch den >Anwender freigegeben ist, das muss einfache Programmfehler auf der >freigegebenen Ebene verkraften können. 1. Wir reden hier nicht von einer Hausfrau als Anwender, sondern von einem ausgebildeten Menschen, von dem erwartet wird, dass er für das spezifizierte Umfeld sorgt. Das bedeutet vorgegebene Versorgungsspannung, Temperatur, usw. usf. 2. Du kannst ja mal versuchen, Gewährleistung für einen tatsächlichen Prozessorfehler einzutreiben, wo der Prozessor definitiv etwas anders tut als im Datenblatt steht. Wenn Du das glaubst, dann lies Dir mal die vielen Errata Sheets durch, die es zu fast allen erhältlichen Prozessoren gibt. Das sind alles Fehler, an denen sich Kunden den Arsch gesucht haben, bis die Hersteller zugegeben haben, dass der Prozessor tatsächlich einen Fehler hat. Und zeige mir mal den Kunden, der weniger als 100.000 Stück/Jahr abgenommen hat, der dafür irgendwas bekommen hat, ausser einem freundlichen "Danke für den Hinweis". Bei Kunden, die ernsthaft mit Liebesentzug drohen können, ist das naturgemäss anders. Und da willst Du Gewährleistung durchsetzen, wenn Du einen verbotenen Befehl benutzt hast ? Gruss Axel
@Axel: Wenn aber tatsächlich der Prozessor permanent beschädigt wird, ist das ja wohl etwas anderes. Also hör bitte auf so zu Klugscheißern...
Axel schrieb: > Und zeige mir mal den Kunden, der weniger > als 100.000 Stück/Jahr abgenommen hat, der dafür irgendwas bekommen hat, > ausser einem freundlichen "Danke für den Hinweis". Nunja, bis heute kannst du deinen Uralt-Pentium mit FDIV-Bug gegen einen ohne diesen Fehler bei Intel kostenlos austauschen lassen. Aber Ausnahmen bestätigen bekanntlich die Regel ;-) Andreas
Andreas Ferber schrieb: > Nunja, bis heute kannst du deinen Uralt-Pentium mit FDIV-Bug gegen einen > ohne diesen Fehler bei Intel kostenlos austauschen lassen. Eher schon werde ich mir das betreffende Exemplar einrahmen und an die Wand hängen. Der hat mir statt dessen noch jahrelang gute Dienste geleistet. Siehe http://www.mathworks.de/company/newsletters/news_notes/pdf/win95cleve.pdf
A. K. schrieb: >> Nunja, bis heute kannst du deinen Uralt-Pentium mit FDIV-Bug gegen einen >> ohne diesen Fehler bei Intel kostenlos austauschen lassen. > Eher schon werde ich mir das betreffende Exemplar einrahmen und an die > Wand hängen. "Pentium FDIV-Bug. Ich war dabei." ;-) Dürfte aber auch bis heute der einzige Prozessorbug sein, der es mal bis auf die Frontseiten von Tageszeitungen gebracht hat. > Der hat mir statt dessen noch jahrelang gute Dienste > geleistet. Siehe > http://www.mathworks.de/company/newsletters/news_notes/pdf/win95cleve.pdf Ack, der Bug war für die meisten Anwendungen eher nicht relevant. Andere Bugs hatten viel weniger Publicity, obwohl der Impact an sich viel höher war (F00F z.B.). Andreas
Andreas Ferber schrieb: > "Pentium FDIV-Bug. Ich war dabei." ;-) Yep ;-). Ziemlich direkt. > Ack, der Bug war für die meisten Anwendungen eher nicht relevant. Deshalb hat mich das auch nicht gestört, einer auf ~1Mrd Kehrwerte mehr oder weniger ungenau, tja nun. Aber für mich stand am Tag drauf fest, das Intel da dennoch einen riesigen Bock geschossen hatte, der sie ziemlich viel Geld kosten würde. Zumal diese Art Fehler, wo falsch gerechnet wird, wirklich jeder versteht, ganz im Unterschied zu dem K6 Bug unten. > Andere > Bugs hatten viel weniger Publicity, obwohl der Impact an sich viel höher > war (F00F z.B.). Eher AMDs 32MB Bug in der ersten Serie vom K6. Anders als der FDIV- und der F00F-Bug war der nämlich kaum vermeidbar weil nicht an bestimmte Befehle gebunden, und er war gut reproduzierbar aber nicht sonderlich deterministisch. Stand bereits früh ganz harmlos im errata sheet, unter "self modifying code" getarnt. http://membres.multimania.fr/poulot/k6bug.html
A. K. schrieb: > Eher AMDs 32MB Bug in der ersten Serie vom K6. Anders als der FDIV- und > der F00F-Bug war der nämlich kaum vermeidbar weil nicht an bestimmte > Befehle gebunden, und er war gut reproduzierbar aber nicht sonderlich > deterministisch. Stand bereits früh ganz harmlos im errata sheet, unter > "self modifying code" getarnt. > http://membres.multimania.fr/poulot/k6bug.html Wenn ich das richtig verstanden habe, dann war da ein Bug in der Logik, die selbstmodifizierenden Code behandelt, der Bug wurde aber auch durch nicht-selbstmodifizierenden Code ausgelöst, weil die Erkennungs-Logik dafür nur die unteren 25 Bits der physikalischen Adresse berücksichtigt hat (deshalb die 32MB). Da fällt mir aber ganz spontan als (wenn auch ziemlich aufwendiger) Workaround (für nicht selbstmodifizierenden Code) ein, via Paging dafür zu sorgen, dass ein Prozess nie physikalische Pages im Abstand von 32MB-vielfachen des aktuell ausgeführten Codes verwendet. Kostet allerdings wohl spürbar Performance, da ggf. bei Sprüngen auf eine andere Page häufig erstmal Daten im Speicher verschoben werden müssten. Aber ist Geschichte ;-) Andreas
@Klaus (Gast) >Ich glaube, das mir dem CPU zerstören, ist eher ein historisches >Ereigniss ;) >Ich erinnere mich mal gehört zu haben, dass es ein System gab, auf dem >eine bestimmte (verbotene) Instruktionsfolge zum durchbrennen eines >Widerstands in der CPU geführt hat. An mehr Deteils kann ich mich leider >nicht erinnern. So wurde der PROM erfunden ...
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.