Paritäts-Prüfung in Assembler

Womit? Bei 8051-ern gibt's das beispielsweise gratis. Ansonsten fang
mal hat zu recherchieren, was das eigentlich ist. Daraus sollte sich
der erste einfache Lösungsansatz von selbst ergeben.

Ich verwende einen 80535 also ein 8051-Ableger.

Was eine Paritäts-Prüfung weiß ich, einfach gesagt, es wird im
Binärcode nachgeschaut ob eine gerade oder ungerade Anzahl von Bits auf
1 gesetzt sind.

Als Lösungsansatz fällt mir spontan ein, den Binaercode nach rechts
verschieben, das Carryflag überprüfen und bei einer 1 ein Register
abwechselnd Inkrementieren und Dekrementieren.

Aber wie du gerade angedeutet hast geht es wohl etwas einfacher,
allerdings finde ich da gerade keinen Befehl.

Experten für die Kiste mögen mich korrigieren, aber nach kurzem Scan
über einen AT89 Overview fand sich das Parity-Flag in Bit 0 vom
Statusregister. Womit JB/JNB naheliegende Kandidaten sind, Bit 0xD0
oder so.

alle 8051er haben das parity-Bit im PSW (Bit0). Der Zustand des
parity-Bits bezieht sich immer auf den Akku. Alle Befehle, die den Akku
verändern, beeinflussen das parity-Bit, auch transfer-Befehle.
Gesamtzahl der "Einsen" im Akku und parity ist immer gerade (gerade
Anzahl im Akku -> Bit ist 0, sonst 1.

Okay Leute lasst die Steine stecken ;).

Bei nährer Betrachtung der Dokus ist mit aufgefallen das es bei den
80535 ein Parity-Bit gibt.

Aber meine kleine Schleife würde auch funktionieren :D

Also vergesst diesen Thread ganz schnell wieder!!!

@crasy horse:

"Alle Befehle, die den Akku
verändern, beeinflussen das parity-Bit, auch transfer-Befehle"

Bist du dir sicher ? Das wäre ja zur Intelreihe x286,x386... ein
gravierender Unterschied ?

Ich meine damit das die Transferbefehle das Parityflag beeinflussen.

Gruß Hagen

Lustig ist: so ein Programm mußte wir gerade im Studium in Assembler
programmieren :)

da bin ich mir ziemlich sicher.
Mit 286 und aufwärts habe ich mich noch nicht auf Bitebene beschäftigt
und glaube auch nicht, dass ich das jemals tun werde.
Kann aber gut sein, dass da Unterschiede sind, warum nicht?

Und ich komme aus der anderen Richtung, deshalb meine Frage.

Warum nicht ? Ganz einfach weil ein Transferbefehl der das Parityflag
modifiziert somit effektiv verhindert das man eine Parity über einen
ganzen Speicherbereich auf einfache Weise berechnen kann. Unter x86
Systeme lädt man ein beliebiges Register aus dem Speicher, XOR verküpft
es zb. mit dem Akku und lädt dann das nächste Byte aus dem Speicher, in
einer Schleife halt. So kann man die Parity über Speicherbereich
berechen. Das Parity-flag würde nun nur durch die XOR Operation
beeinflusst.

In deinem Szenario müsste man dann anders vorgehen, es wäre ja immer
noch möglich. Es sei denn nur die Trasferbefehle in den Akkumulator
ändern die Parity, Transferbefehle in andere Register würden es nicht
ändern. Ist dies so ?

Gruß Hagen

<ot>
tatsächlich ist es bei vielen prozessoren üblich, dass transferbefehle
die flags beeinflussen.

die idee ist die, dass man zum beispiel einen wert aus dem speicher
lesen kann, und dann ohne noch irgendwelche vergleichs- oder sonstige
operationen auszuführen feststellen kann, ob der wert null ist, was für
eine parität er hat etc.

am schönsten ists natürlich immer noch mit ARM prozessoren, wo man
angeben kann (mit einigen wenigen ausnahmen) ob ein befehl die flags
modifizieren soll oder nicht =)
</ot>

das P-Flag ist fest an den Akku gekopelt, dementsprechend kann nur die
Parität des Akkus angezeigt werden.

Aah man lernt nie aus, XOR mit impliziertem Speicherzugriff, naja hätt
ich selber drauf kommen müssen, danke :)

Gruß Hagen

achja, ich möcht noch anmerken, dass die x86 überhaupt keine referenz
sind. bestenfalls dienen sie als negativbeispiel für prozessordesigner
=)

tja tut aber nichts zur Sache, als professioneller Programmierer
verdiene ich eben mein Geld mit x86 Systemen. Ist mir aber auch Brust
worauf ich programmiere, Hauptsache ich darf es und verdiene noch Geld
dabei :)

Meine Frage war eher weil ich stutzig geworden bin, ich wusste einfach
nicht das das Parityflag tatsächlich durch Transferbefehle modifiziert
wird. Ich habe darauf einfach nie geachtet, und das wurmt mich viel
mehr !

Gruß Hagen