-
Stand der Technik
-
Die
Erfindung geht aus von einer Vorrichtung oder Verfahren nach Gattung
der unabhängigen Ansprüche. Bekanntlich besitzen
technische Systeme eine Fehleranfälligkeit, die von unterschiedlichen
Ursachen herrühren kann. Jede Komponente eines solchen
Systems kann temporäre Fehler, die sporadisch auftreten,
oder systematische Fehler beinhalten. Komponenten können
hierbei aus Software- bzw. Hardwarebestandteilen bestehen. Insbesondere
bei sicherheitskritischen Systemen besteht die Notwendigkeit Fehler
zu erkennen und angemessen darauf zu reagieren, d. h. solche Systeme
fehlertolerant oder fehlererkennend auszubilden. Aus diesem Grund
gibt es auch bei der Entwicklung und Anwendung von computergestützten
Lösungen verschiedene Sicherheitsanforderungen, um schwerwiegende Folgen
durch Software- oder Hardwarefehler zu vermeiden. Hierfür
gibt es verschiedene Normen wie beispielsweise der SIL (Safety Integrity
Level) gemäß IEC/DIN EN 61508 oder
im automotiven Umfeld das ASIL (Automotive Safety Integrity Level)
gemäß ISO CD 26262.
-
Allgemein
bekannt ist die redundante Auslegung von Systemen beispielsweise
aus dem Flugzeugbau, wo Einheiten der Avionik mehrfach vorhanden
sind, deren Berechnungsergebnisse verglichen und plausibilisiert
werden. Hierbei sind die Systeme hardwaretechnisch mehrfach vorhanden.
Hierdurch werden bspw. Fehler erkannt, die singulär in
einer Hardware auftreten, hervorgerufen beispielsweise durch einen
Produktionsfehler oder einen Defekt in genau dieser einen Hardwareeinheit.
Nicht abgedeckt werden hierbei Fehler, die im Design der Hardware
begründet sind, sowie Fehler in der Software, die auf den
vorliegenden Hardwareeinheiten identisch ist.
-
Durch
die doppelte, unabhängige Entwicklung einer Software mit
gleicher Aufgabe kann eine softwaretechnische Redundanz erreicht
werden. So können menschliche Programmierfehler, sowie
Compilerfehler oder Ähnliches erkannt werden, genauso wie
möglicherweise temporäre Hardwarefehler wie Bitkipper
etc.
-
Durch
die Kombination solcher Methoden können nicht nur temporäre
Fehler, sondern auch dauerhaft temporäre Fehler, dass heißt
Fehler, die in einem konkreten System reproduzierbar auftreten, sowie
systematische Fehler, beispielsweise Designfehler, erkannt werden.
-
Diese
Parallelarchitektur und/oder Parallelentwicklung führt
jedoch zu erhöhten Kosten, da ein höherer Entwicklungsaufwand
und/oder mehrfache Hardware notwendig ist.
-
Stand
der Technik ist, dass heutzutage fast jedes Programm in einer Hochsprache
(beispielsweise C oder C++) geschrieben wird, welches von einem sogenannten
Compiler in eine Maschinensprache übersetzt wird, die der
jeweilige Mikroprozessor (beispielsweise in einem PC oder in einem
Embedded System) versteht. Das bedeutet, dass zwischen der Erstellung
einer Software (Programm) und der Ausführung auf eine Hardware
dieser Zwischenschritt durchgeführt wird.
-
In
der
EP 1 723 513 B1 wird
ein Verfahren beschrieben dass eine übersichtliche und
flexible Konfiguration eines Computerprogramms erlaubt. Hier wird
die Möglichkeit geschaffen mittels globaler wie spezieller
Konfigurationsdateien aus einem einzigen Programmcode (Quelltext)
einen Maschinencode mittels eines Compilers zu erzeugen.
-
Offenbarung der Erfindung
-
Das
erfindungsgemäße Verfahren mit den Merkmalen des
unabhängigen Anspruchs realisiert ein fehlertolerantes
System, welches insbesondere bei sicherheitskritischen Anwendungen
Einsatz finden kann und das temporäre und systematische
Fehler entdecken soll. Für ein solches System existiert eine
Systembeschreibung, bzw. Anforderungsprofil, welches von einem Generator
derart umgesetzt wird, dass daraus eine physikalische Realisierungsvariante
(Realisierungsweg) gebildet wird. Erfindungsgemäß erzeugt
dieser Generator wenigstens zwei Realisierungswege, die eine gleiche
Wirkung bzw. ein gleiches Ergebnis zur Folge haben, jedoch dieses
auf einem anderen Lösungsweg erreichen, und dadurch redundant,
aber unterschiedlich zueinander sind. Fehler in der gemeinsamen
zugrunde liegenden Systembeschreibung können hierdurch
nicht entdeckt werden, jedoch solche Fehler in einem der beiden Realisierungswege,
beispielsweise verursacht durch eine fehlerhafte Generierung, oder
insbesondere Fehler auf einer Ausführplattform eines solchen
Realisierungswegs. Durch eine entsprechende Fehlermöglichkeits-
oder Auswirkungsanalyse für das jeweilig konkrete System
kann geprüft bzw. herausgefunden werden, welche Fehler
abgefangen werden können und welche Teile der Systempfade
redundant ausgelegt sind und an welchen Stellen Single Points of
Failure vorhanden sind.
-
Vorteil
ist somit die Eliminierung temporärer, dauerhaft temporärer,
systematischer und/oder Designfehlern und gleichzeitiger Kostenersparnis,
da eine Systembeschreibung nur einmal erstellt werden muss. Je nach
Realisierung muss auch das System selber nicht ein zweites Mal vorgehalten
werden, sofern die wenigstens zwei Realisierungswege auf dem gleichen
System ausführbar sind. Zur sicherheitstechnischen Überprüfung
würden üblicherweise die Ergebnisse der wenigstens
zwei Realisierungswege miteinander auf Gleichheit bzw. Plausibilität
verglichen, wobei es vom Sicherheitskonzept abhängt, in welcher
genauen Form bzw. wie oft bzw. zu welchen Zeitpunkten was durchgeführt
wird. So können abhängig von der konkreten Anwendung
und dem jeweiligen Sicherheitslevel entsprechende Sicherheitsnormen
bei niedrigem Aufwand und Kosten eingehalten werden.
-
Bestehen
die Realisierungswege selber wiederum aus verschiedenen Einzelbestandteilen,
so ist es vorteilhaft wenn diese Bestandteile nicht gleichzeitig
(synchron) in den wenigstens beiden Realisierungswegen vorkommen.
So kann ein Fehler der in einem bestimmten Bestandteil vorhanden
ist aufgedeckt werden, da einer der Realisierungswege die Realisierung
umsetzt, ohne diesen Bestandteil zu verwenden. Das Aufdecken der
Fehler geschieht üblicherweise in einem Vergleich der Ergebnisse
bzw. Zwischenergebnisse bzw. Zwischenschritte der Realisierungswege.
-
In
der vermutlich gebräuchlichsten Ausführungsform
der Erfindung wird eine Software erstellt, die der Systembeschreibung
entspricht, üblicherweise in einer Hochsprache wie C oder
C++. Ein sogenannter Compiler setzt diese Hochsprache in eine Sprache
um, die die jeweils verwendete Mikroprozessorplattform versteht
(Maschinensprache). Der Compiler entspricht hierbei dem automatisierten
Generator, kann aber auch ein Interpreter sein (z. B. Programmiersprache
Basic oder Java) oder eine andere Form von Sprachumsetzer. Erfindungsgemäß ebenso
beinhaltet ist eine Umsetzung in gleichwirkende Realisierungswege,
beispielsweise der Realisierungsweg über die Programmierung
eines FPGA-Bausteins, oder verschiedener Mikrokontroller oder Mikrokontrollerelemente
gegebenenfalls mit unterschiedlicher Funktionalität (beispielsweise
Hauptmikrocontroller/Safety Controller (SCON)) oder andere Hardware.
-
Erfindungsgemäß erzeugt
dieser Compiler aus einem Quelltext der Hochsprache zwei Maschinencodes,
die redundante aber unterschiedliche Realisierungswege beschreiben.
Da die Systemanforderung hierfür üblicherweise
die gleiche sowie der Quellcode der gleiche ist, müssen
auch die Ergebnisse dieser beiden Maschinencodes zu einem identischen
bzw. plausiblen Ergebnis kommen.
-
Gegebenenfalls
kann der wenigstens zweite Realisierungsweg auch ein Näherungsergebnis
berechnen, welches für eine Plausibilisierung des echten
Ergebnis des einen Realisierungsweg geeignet ist. Die ledigliche
Berechnung eines Näherungsergebnisses kann Ressourcen-,
insbes. Laufzeitvorteile haben. Diese Entscheidung (Plausibilisierung) führt
eine in der Fachsprache Voter genannte Einrichtung durch.
-
Vorteil
ist die beschriebene Möglichkeit der einmaligen Entwicklung
einer Software, welche automatisch in zwei unterschiedliche Maschinencodes übersetzt
wird, die eine Plausibilisierung auf bestimmte Arten von Fehlern
ermöglicht. Der Zusatzaufwand bzw. Kosten sind hier sehr
gering, insbesondere gegenüber der üblichen Vorgehensweise einer
doppelten Entwicklung von Quelltext. Mittels Multitasking-Prozessoren
oder der seriellen Berechnung auf einem Prozessor können
die wenigstens zwei Maschinencodes auch auf einer einzigen Hardware
laufen, wodurch eine Parallelarchitektur und Kosten einer doppelten
Hardware vermieden werden. Abgefangen werden können insbesondere
Fehler, die bei der Kompilierung auftreten, sofern sie nur auf einen
der Realisierungswege Auswirkung haben. Gleiches gilt für
temporäre Fehler in einer Hardware, egal ob sporadisch
auftretende Fehler oder Fehler die aufgrund von Bauteilstreuungen
entstanden sind oder systematische bzw. Designfehler in der Hardware,
die bei wenigstens einem der Realisierungswege nicht in gleicher
Weise zum Tragen kommen wie in dem anderen Realisierungsweg. Der
Voter würde in diesem Fall einen Unterschied zwischen den
verschiedenen Realisierungswegen feststellen bzw. abhängig
von der Anzahl der Realisierungswege auch das richtige Ergebnis
ermitteln können. Bezüglich der Anzahl von Realisierungswegen
der Auslegung von Votern und den daraus folgenden verschiedenen Stufen
der Fehlertoleranz sei auf entsprechende Fachliteratur verwiesen.
-
Die
Begrifflichkeit des Compilers im singulären Sprachgebrauch
ist ebenso dahingehend auszulegen, dass man das erfindungsgemäße
Verfahren auch mittels wenigstens zweier Compiler umsetzt, wobei
ein erster Compiler den ersten Maschinencode bzw. Realisierungsweg
generiert und die weiteren Compiler die weiteren Maschinencodes.
Für Entwicklungszwecke mag es vorteilhaft sein, durch wenige manuelle
Interaktionen den, bzw. die mehreren Compilerläufe zu starten,
um den Entwicklungsaufwand auch hier gering zu halten. Dies kann
auch über kaskadierte Programmstrukturen beispielsweise
Batchprogramme erfolgen, was einen Fachmann in der Informationstechnik
aber ohnehin bekannt ist.
-
Vorteilhafterweise
wird der Compiler bei der Generierung der wenigstens zwei Maschinencodes die
Befehle aus der Hochsprache in jeweils unterschiedliche Maschinencodebefehle
bzw. Maschinencodebefehlssequenzen umsetzen. Dies hat den Vorteil,
dass ein Fehler, der durch den Aufruf eines bestimmten Maschinencodes
hervorgerufen werden würde, in dem jeweils anderen Maschinencode
nicht aufgerufen werden und damit zum Tragen kommen würde,
was eine Fehlererkennung ermöglicht. Sofern sich nicht
jeder Befehl des Maschinencodes durch einen anderen Befehl substituieren
lässt, so ist eine komplette asynchrone Ausgestaltung der
Maschinencodes eventuell nicht möglich. Jedoch trägt
auch eine weitestgehende Vermeidung von der synchronen Verwendung
von Maschinenbefehlen zur Fehlertoleranz bei.
-
Die
Erfindung nutzt gezielt die Eigenschaften und Freiheiten beim Compilieren
aus, da es keine Vorschrift gibt, wie ein Compiler ein Programm
in einer Hochsprache in die Zielsprache übersetzen muss.
Der hier vorgestellte Compiler nutzt aus, dass es mehrere Möglichkeiten
gibt, einen Befehl aus der Hochsprache in die Zielsprache zu ersetzten.
Dabei wird also der Hochsprachebefehl in den verschiedenen Realisierungswegen
durch möglichst komplett andere Maschinensprachebefehle
bzw. Befehlsequenzen übersetzt. Dies kann beispielsweise
durch eine klassische Übersetzungstabelle geschehen, wodurch
die entsprechende Eigenschaft garantiert werden kann und der Compiler
gegebenenfalls nach Norm zertifiziert werden kann. Eine Zertifizierung
ist jedoch auch durch andere Nachweise der genannten Eigenschaften
möglich.
-
Die
Verwendung unterschiedlicher Maschinencodes bzw. Befehlssequenzen
führt jedoch auch dazu, dass die Laufzeit und/oder der
Speicherplatzbedarf und/oder die Programmgröße
der unterschiedlichen Maschinenprogramme unterschiedlich sind. Vorteilhafterweise
kann der Compilerlauf nun so angepasst werden, dass die genannten
Eigenschaften auf die verschiedenen Maschinencodes entsprechend
ihrem Anwendungszweck verteilt sind. Beispielsweise kann versucht
werden, dass für die verschiedenen Realisierungswege gleichschneller
Code entsteht, beispielsweise dadurch, dass ein wiederkehrender
Befehl in der Hochsprache in den beiden Realisierungswegen alternierend
aber dennoch asynchron umgesetzt wird. Gleichschneller Code wird üblicherweise
dann bevorzugt werden, wenn die Berechnungsergebnisse der Realisierungswege
zu einem gleichen Zeitpunkt vorliegen müssen, beispielsweise
wenn das Ergebnis nicht ohne eine Plausibilisierung verwertet werden
darf. Alternativ kann beispielsweise ein sehr schneller Realisierungsweg und
weitere langsame existieren, falls das Ergebnis sehr schnell berechnet
werden muss, und einen Plausibilisierung bzw. Fehlerreaktion auch
nach Verwendung bzw. Auswertung des Ergebnisses noch möglich
ist. So kann beispielsweise einen Realisierungsweg die Berechnung
von Echtzeitergebnissen in einem zeitkritischen Takt übernehmen
und ein weiterer Realisierungsweg auch über mehrere Taktzyklen
verteilt laufen. Ein Vergleich der Ergebnisse der Realisierungswege
im Voter bzw. ein Aufruf des Voters kann dann zwar regelmäßig
erfolgen aber nicht zwangsläufig in jedem Takt. Auch die
Variation der Programmgröße der verschiedenen
Maschinencodes mag sinnvoll sein, hierbei wird in einem ersten Maschinencode
immer die jeweils kürzere Befehlssequenz verwendet, und
in den weiteren Maschinencodes die Längere. Dies kann beispielsweise
sinnvoll sein, wenn die verschiedenen Maschinencodes in verschiedenen
Speicherbereichen laufen sollen, der Kürzere beispielsweise
in einem schnellen, dafür aber knappen bzw. teuren Speicher
oder falls einer in einer sogenannten sicheren Insel, dass heißt
einem speziell abgesicherten Bereich, laufen soll.
-
Vorteilhaft
ist die Verwendung nur eines einzigen Mikroprozessors bzw. Mikrocontrollers
bzw. integrierten Bauelements für die Ausführung
bzw. Abarbeitung der wenigstens zwei Realisierungswege bzw. Maschinencodes,
da hierbei eine zweite Hardware eingespart werden kann. Dafür
ist üblicherweise ein höherer interner bzw. softwaretechnischer
Aufwand zu bewerkstelligen, um Multitasking bzw. eine Parallelverarbeitung
oder serielle Abarbeitung der unterschiedlichen Realisierungswege
bzw. Maschinencodes zu ermöglichen. Diese Verfahren sind
jedoch Stand der Technik und durch diverse Toolkits einfach zugänglich.
Vorteilhaft hierbei ist auch, dass der Voter ebenso als Software
innerhalb der gleichen Hardware, das heißt des gleichen
Mikrocontrollers integriert werden kann.
-
Moderne
Mikrocontroller besitzen oftmals unterschiedliche Recheneinheiten,
beispielsweise Floating-Point-Units, verschiedene Rechnerkerne (Cores),
PCP, etc.. So können beispielsweise Rechenoperationen der
Floating-Point-Units mittels Integer-Operationen im normalen Rechnerkern
nachgebildet werden, um sie später zu plausibilisieren.
Hierbei können Fehler, die in lediglich einer der beiden Recheneinheiten
auftreten, erkannt werden. Weiterhin können in verschiedenen
Rechnerkernen eines Mikrocontrollers die unterschiedlichen Maschinencodes
abgearbeitet werden.
-
Wird
die bisher beschriebene Idee aufgenommen, und durch einen zusätzlichen
erfinderischen Schritt erweitert, so ergibt sich die Möglichkeit anstatt
einem Quelltext bzw. einer Systembeschreibung einen bereits existierenden
Maschinencode bzw. Realisierungsweg zu verwenden, um mittels eines
automatischen Generators einen wenigstens zweiten Realisierungsweg
bzw. Maschinencode zu erzeugen. Der automatische Generator wäre
hierbei beispielsweise ein geeignetes Programm, welches die Maschinencodebefehle
bzw. erkannte Maschinencodebefehlsequenzen des Quellmaschinencodes
mittels beispielsweise einer Übersetzungstabelle der Befehle
zu alternativen Befehlscodesequenzen umsetzt, um daraus einen zweiten
Maschinencode zu generieren. Vorteilhaft hierbei ist, dass eine
Neugestaltung des Compilers bzw. ein zweiter Compiler aufwändiger
zu realisieren ist, als ein solcher Maschinencodeumsetzer. Des Weiteren
kann ein bereits bestehender Maschinencode für sicherheitskritische
Systeme durch diese Idee fehlertolerant ausgelegt werden. Auch falls
ein entsprechender Quelletext in der Hochsprache nicht mehr vorhanden bzw.
verloren gegangen ist, kann ein solcher zweiter Maschinencode generiert
werden, um die entsprechenden Anforderungen zu erfüllen.
-
Begriffserläuterungen
-
Bei
der Softwareentwicklung wird vom Programmierer üblicherweise
eine Software in Form eines Quelltextes, bzw. Quellcodes in einer
bestimmten Hochsprache erstellt. Ein Compiler setzt diese in sogenannten
Objektcode um, welcher wiederum von einem Linker gegebenenfalls
mit anderen Programmbestandteilen zusammen gelinkt wird zu einem
Maschinencode. Gegebenfalls wird ein Zwischenschritt über
eine Maschinensprache durchgeführt. Maschinensprache, in
Form von Quelltext, auch Assembler genannt, ist hierbei eine 1 zu
1 Abbildung auf den sogenannten Maschinencode, der binär
vorliegt. Für die vorliegende Erfindung ist es unerheblich,
ob von Maschinensprache, Maschinencode, Objektcode oder Assembler
die Rede ist, genauso ist mit dem Begriff Compiler oder automatischer
Generator gegebenenfalls ein Linker bzw. andere Softwaretools oder
Bestandteile zur Generierung des Maschinencodes beinhaltet. Genauso
wenig ist es erheblich, ob die unterschiedlichen Maschinencodes
durch einen oder mehrere Compiler entstehen, maßgeblich
ist die Verwendung eines einzigen Quelltextes zur Generierung unterschiedlicher aber
redundanter Maschinencodes.
-
In
einem fehlertoleranten System bezeichnet ein sogenannter „Single
Point of Failure” Stellen im System, wo verschiedene Pfade
so zusammengeführt werden, so dass ein Fehler an dieser
Stelle einen Gesamtfehler zur Folge hätte. Ein üblicher
Single Point of Failure ist der sogenannter Voter, dass ist die Plausibilisierungseinheit
die verschiedene Rechenwege bzw. deren Lösungen zusammenführt,
vergleicht und ein Gesamtergebnis daraus evaluiert.
-
Beschreibung der Zeichnungen
-
Ausführungsbeispiele
der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden
Beschreibung näher erläutert.
-
Es
zeigen
-
1 verschiedene Anordnungen für
fehlertolerante Systeme,
-
2 eine beispielhafte Umsetzung eins Multiplikationsbefehls.
-
In 1a sind
beispielhaft der Basisaufbau eines fehlertoleranten Systems dargestellt,
bei dem es mindestens zwei Pfade gibt, wobei ein Auftreten eines
Fehlers auf einem dieser Pfade erkannt wird, indem der hier als
Komperator dargestellte Voter einen Unterschied feststellt.
-
In
Figurteil b ist gezeigt wie eine einzige Software SW mittels eines
Compilers C in einen Maschinencode M umgesetzt wird, der auf verschiedener Hardware
HW1, HW2 zum Einsatz kommt und somit ermöglicht einen Defekt
in einer der verschiedenen Hardware zu erkennen.
-
In
Figurteil c sind zwei unterschiedliche Software SW1, SW2 dargestellt,
welche nach einer Übersetzung mittels eines (ggf. gleichartigen/des
selben) Compilers C in Maschinencode M1, M2 übersetzt werden
und in einer Hardware zur Ausführung kommen. Analog zu
Figurteil b können hier zusätzlich auch verschiedene,
d. h. getrennte Einheiten von Hardware zum Einsatz kommen. Mittels
eines solchen Systems wird sichergestellt, dass ein Fehler, der
in nur einer der Software vorkommt erkannt wird.
-
In
Figurteil d ist das erfindungsgemäße Verfahren
vorgestellt, wobei eine einzige Software hier einen Quellcode SW
in einen Compiler C eingeht, welcher zwei verschiedene Maschinencodes
M1, M2 erzeugt, welche auf der Hardware zur Ausführung kommen.
Die abschließende Fehlerbeurteilung wird wie üblich
von einem Komparator (Voter) durchgeführt. Darüber
hinausgehen kann beispielsweise bei Verwendung eines Interpreters,
welcher insbesondere bei Hochsprachen wie Java oder Basic Verwendung
findet, der hier mit Compiler C bezeichnete Block in der Hardware
selbst zum Liegen kommen, wobei der Interpreter selbstständig
die Befehle auf zwei verschiedene Arten in Maschinencode umsetzt und
dem erfindungsgemäßen Verfahren folgt. Ein Interpreter
funktioniert üblicherweise derart, dass er die Befehle
der Hochsprache sequenziell einliest und direkt abarbeitet bzw.
in Maschinencodebefehle umsetzt, die sofort vom Mikroprozessor ausgeführt
werden, und nicht wie ein Compiler C das gesamte Programm zuerst
in den kompletten Maschinencode übersetzt.
-
In
Figurteil e ist die Idee des nebengeordneten Verfahrensanspruchs
dargestellt. Hierbei wird mit einem klassischen Compiler C aus einem
Quellcode SW ein Maschinencode M1 generiert. Ein weiterer Maschinencode
M2 wird aus dem Maschinencode M1 mittels eines Generators G erzeugt.
Beide kommen dann auf der Hardware zur Ausführung.
-
In 2 ist die beispielhafte Umsetzung eines
Multiplikationsbefehls in einer Hochsprache gezeigt (Figurteil a)
welche in zwei verschiedenen Varianten des Maschinencodes, hier
als Assemblerbefehlsequenz dargestellt (Figurteil b, c) ist. Die
Quell- bzw. Assemblertexte liegen in diesem Beispiel keiner bestimmten
Hoch- bzw. Maschinensprache zugrunde der versierte Informatiker
kann diese Sprachen jedoch einfach auf die verwendete Plattform
anpassen und wird in diesem Beispiel ausreichend Illustrationen
finden. Erfindungsgemäß wird nun die Befehlszeile
in Figurteil a bei der Generierung eines ersten Maschinencodes mittels
der Befehlssequenz wie sie in Figurteil b dargestellt ist generiert,
während sie für den zweiten Maschinencode mittels
der Befehlssequenz wie sie in Figurteil c dargestellt ist generiert. So
ist eine Realisierungsvariante, dass der Compiler eine Übersetzungstabelle
besitzt, welches ihm ermöglicht jeden beliebigen Befehl
der Hochsprache in mindestens zwei unterschiedliche Maschinencodevarianten
zu übersetzen.
-
In
diesem Beispiel wurde der Multiplikationsbefehl in der Hochsprache
in der Variante in Figurteil b mittels des Assemblermultiplikationsbefehls übersetzt.
In einer asynchronen Variante in Figurteil c wurde dieser Befehl
mittels einer Schleife und Additionen realisiert.
-
Ein
weiteres Ausführungsbeispiel welches hier nicht in einer
Figur illustriert ist, wäre beispielsweise die Durchführung
von sogenannten Verzweigungs-Operatoren die jeweils mit negierten
Testbedingungen ausgeführt werden. Üblicherweise
werden Sprünge im Maschinencode durch das Prüfen einzelner
Ergebnis-Bits einer vorhergehenden Berechnung ausgeführt.
Gängige Assembler-Befehle sind etwa bz (branch zero) und
bnz (branch not zero), die direkt zu einer doppelten, unterschiedlichen
Realisierung eines Verzeigungsoperators führen. Lediglich
die Bedingung muss vorher mit mindestens einem zusätzlichen
Befehl negiert werden, was jedoch mit allen gängigen Befehlssätzen
ohne weiteres möglich ist. Je nach Umsetzung der Befehle
im Maschinencode kann auch eine Übersetzung der selben Verzweigung
durch den Check verschiedener Bedingungen realisiert werden. Beispielsweise
kann ein bnz (branch not zero) durch die Benutzung des sog. Count-Registers
simulieren, indem man das Register auf den zu prüfenden
Wert+1 setzt und statt bnz den Befehl bdnz (decrement Count-Register
and branch if not zero) benutzen.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
-
Zitierte Nicht-Patentliteratur
-
- - IEC/DIN EN
61508 [0001]
- - ISO CD 26262 [0001]