mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR Assembler: add adc auf 0 prüfen


Autor: AVR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte einen 16 Bit Registerpaar zu einem anderen 16 Bit 
Registerpaar addieren und danach prüfen, ob das Ergebnis 0 ist. Mit breq 
geht das ja leider nicht. Was wäre ein eleganter Weg?

add r16,r20
adc r17,r21
breq fehler ;geht nicht!

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da es sich hier um eine 8 Bit CPU handelt, musst du beide Register 
einzeln auf Null testen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre Subtraktion auch ok? Da stimmt das Z-Flag hinterher nämlich.

Je nach Registerpaar geht
   adiw rh:rl,0
   breq ...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Da es sich hier um eine 8 Bit CPU handelt, musst du beide Register
> einzeln auf Null testen.

Nö. t=rh|rl.

Autor: AVR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
adiw geht nur mit immediates, nicht mit registern.
sub $ sbc wäre eine idee... leider isses hier eine subtraktion. wenn ich 
die formel umstelle, brauche ich mehr befehle. da kann ich auch 
genausogut mit adiw x,0 $ breq prüfen. ich dachte, es gäbe irgend einen 
brXX Trick dafür.

Beitrag #5557391 wurde vom Autor gelöscht.
Autor: AVR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann bleibts wohl dabei. add $ adc $ brXX unmöglich. Schade.

Autor: Karl B. (gustav)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, @AVR
über das Statusregister "Speicher"-Bit und den entsprechenden 
Sprungbefehl müsste es gehen bei 8 Bit:
clr r21
clr r22
....
adc  r22, r21    ; Eins-Bit addieren
bst  r22, 0    ; war das Ergebnis geradzahlig?
brtc  marke    ; ja -> weiter
inc  r19      ; sonst Fehlerzaehler erhöhen

ciao
gustav

: Bearbeitet durch User
Autor: AVR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nagut, damit kann man auf Parität prüfen. Aber es geht mir ja darum, auf 
0x0000 zu prüfen. Mit brmi kann man z.B. ohne Probleme auf <0x0000 
prüfen.
Die allgemeingültige Lösung, um auf <= 0 zu prüfen wäre somit:

add
adc
brmi
cp
cpc
breq

Und die Frage war so gemeint, dass ich mir die 3 Takte gern sparen 
würde, wenn es nur eine Frage der Unwissenheit ist. Intuitiv schreibt 
man nämlich sofort

add
adc
brmi
breq

Und das geht eben nicht.

PS: adiw breq benötigt übrigens auch 3 Takte. Spart also nur 2 Bytes 
Flash. Allerdings ist Flash für Assemblerprogrammierer seltenst das 
Problem.

Beitrag #5557735 wurde vom Autor gelöscht.
Beitrag #5557738 wurde vom Autor gelöscht.
Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR schrieb im Beitrag #5557494:
> Und die Frage war so gemeint, dass ich mir die 3 Takte gern sparen
> würde, wenn es nur eine Frage der Unwissenheit ist. Intuitiv schreibt
> man nämlich sofort
>
> add
> adc
> brmi
> breq
>
> Und das geht eben nicht.

 Vielleicht so ?
        add  r16,r20
        adc  r17,r21
        tst   r16
        brne weiter
        tst  r17
        breq fehler
weiter:

Autor: Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Step weniger:

        add  r16,r20
        adc  r17,r21
        brne weiter
        tst  r16
        breq fehler

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist euch schon aufgefallen, dass der TST Befehl eine Mogelpackung ist? 
Sein Opcode ist mit AND identisch.

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Gähn. Von der Sorte gibt's noch viel mehr.

Mogelpackung ist ohnehin ein starkes Wort. Mehrere Mnemonics für den 
gleichen Opcode illustrieren die Verwendung des Befehls.

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Mehrere Mnemonics für den
> gleichen Opcode illustrieren die Verwendung des Befehls.

Ja das mach Sinn. Weniger sinnvoll kommt es mit vor, in Marketing 
Broschüren damit zu werben, dass die CPU soundso viele Befehle hat, wenn 
diese Duplikate dabei mitgezählt werden.

Autor: Carl D. (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> A. K. schrieb:
>> Mehrere Mnemonics für den
>> gleichen Opcode illustrieren die Verwendung des Befehls.
>
> Ja das mach Sinn. Weniger sinnvoll kommt es mit vor, in Marketing
> Broschüren damit zu werben, dass die CPU soundso viele Befehle hat, wenn
> diese Duplikate dabei mitgezählt werden.

Der jetzige AVR-Eigner hat auch schon mit "nur so wenige" geworben, um 
den RISC-Character seiner (alten) PICs hervorzuheben.

Autor: Chris H. (Firma: Selbständig Denkender) (keiningenieur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR schrieb im Beitrag #5557364:
> add r16,r20
> adc r17,r21
> breq fehler ;geht nicht!

Warum nicht ?

du brauchst doch nur nach der Addition es wie folgt zu ergänzen

add r16,r20
adc r17,r21
add r16,r17
tst r16
breq fehler

: Bearbeitet durch User
Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Chris H. schrieb:
> du brauchst doch nur nach der Addition es wie folgt zu ergänzen
>
> add r16,r20
> adc r17,r21
> add r16,r17
> tst r16
> breq fehler

 Genial.
 Der Inhalt von r16 ist zwar geändert, aber das macht nichts.
 Oder doch ?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris H. schrieb:
> add r16,r20
> adc r17,r21
> add r16,r17
> tst r16
> breq fehler

Der TST befehl ist nicht nötig.

Autor: m.n. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Chris H. schrieb:
> add r16,r17

Schon mal nachgerechnet mit R17 = 1 und R16 = 255?

OR passt da schon besser.

Autor: Thomas E. (picalic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Mogelpackung ist ohnehin ein starkes Wort. Mehrere Mnemonics für den
> gleichen Opcode illustrieren die Verwendung des Befehls.

Kann aber auch Fehler provozieren! Wer (außer eingefleischten 
AVR-Kennern) würde denn z.B. erwarten, daß ein Bit-Set oder -Clear 
Befehl das Z-Flag verändert?
Wenn man keinen expliziten Befehl dafür hat, weiß man wenigstens, daß 
man es mit einer OR- bzw. AND-Operation machen muss und da rechnet man 
logischerweise auch damit, daß das Statusregister beeinflusst wird. 
Sonst geht man davon aus, daß ein expliziter Bit-Set bzw. Clear-Befehl 
nur das Setzen oder Löschen von Bits bewirkt und eben nicht nur ein 
anderer Name für einen "echten" AND oder OR-Befehl ist.

Autor: nenene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Kann aber auch Fehler provozieren! Wer (außer eingefleischten
> AVR-Kennern) würde denn z.B. erwarten, daß ein Bit-Set oder -Clear
> Befehl das Z-Flag verändert?

Jemand, der das AVR Instruction Set Manual liest. Übrigends git es SBR 
und BSET. Solltest mal genau schreiben, was du meinst.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Wer (außer eingefleischten AVR-Kennern)

Falls man die Asm Statements nicht kennt, sollte man ins Handbuch 
schauen!
Wer das nicht macht, fällt mit Fug und Recht auf die Nase.

Denn Fantasie und Tagträume, können kein Wissen ersetzen.

: Bearbeitet durch User
Autor: Thomas E. (picalic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nenene schrieb:
> Übrigends git es SBR
> und BSET. Solltest mal genau schreiben, was du meinst.

Ich meine natürlich SBR und CBR. Der Sinn von BSET und BCLR als extra 
Mnemonic erschließt sich mir auch nicht. Z.B. ein "CLC" ist doch viel 
prägnanter, als der entsprechende Befehl mit BCLR. Wenn man den 
Befehlssatz nicht gut kennt und auf der Suche nach einer Möglichkeit 
ist, ohne Nebeneffekte ein Bit in einem Core-Register zu setzen, findet 
man verschiedene Mnemonics, die zunächst so aussehen, als ob sie dafür 
geeignet seien. Bei genauerer Betrachtung der Befehle stellt man dann 
aber fest, daß das bloß Pseudo-Befehle für andere Grundbefehle sind und 
es einen Befehl für das, was man eigentlich haben möchte, gar nicht 
gibt. Wenn es keine BSET/BCLR/SBR/CBR Mnemonics gäbe, hätte man 
schneller einen Überblick, was der Prozessor kann und was nicht und 
müsste sich gar nicht erst näher mit den überflüssigen Mnemonics 
auseinandersetzen.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Wer (außer eingefleischten AVR-Kennern) würde denn z.B. erwarten,
> daß ein Bit-Set oder -Clear Befehl das Z-Flag verändert?

Ich. Das Z-Flag sagt mir nämlich, dass ich gerade das letzte gesetzte 
Bit in einem Register gelöscht habe. Das ist relevant.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wäre Subtraktion auch ok? Da stimmt das Z-Flag hinterher nämlich.

Ja, da haben die AVR-Entwickler zu kurz gedacht. Es gibt keinen Grund, 
das Z-Flag bei der Addition nicht richtig zu berechnen.

: Bearbeitet durch User
Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Thomas E. schrieb:
>> Wer (außer eingefleischten AVR-Kennern) würde denn z.B. erwarten,
>> daß ein Bit-Set oder -Clear Befehl das Z-Flag verändert?
>
> Ich. Das Z-Flag sagt mir nämlich, dass ich gerade das letzte gesetzte
> Bit in einem Register gelöscht habe. Das ist relevant.

 Ich nicht.
 Wie ein SBR Befehl Z-Flag setzen kann, ist mir schleierhaft.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:

> Das Z-Flag sagt mir nämlich, dass ich gerade das letzte gesetzte
> Bit in einem Register gelöscht habe.

Ich verstehe, was du sagen willst, aber die Ausdrucksweise gefällt mir 
nicht wirklich.

Außerdem ist sie sachlich falsch, denn bei allen Subtraktions- und 
Vergleichsoperationen mit Übertrag ist es beim AVR8 (und auch anderen 
Architekturen) eben NICHT so.

Schön (und sinnvoll) wäre es gewesen, wenn sich die Addition beim AVR8 
genauso verhielte, tut sie aber leider nicht. Der Nachteil ist aber in 
der Praxis i.d.R. minimal, weil es fast nie eine Rolle spielt, ob die 
Addition zweier NULL-Werte erfolgt ist. Das kann man nämlich 
normalerweise leicht vorher abfangen. Und den anderen denkbaren Fall, 
dass die Addition zweier Nicht-NULL Werte NULL ergibt, kann man leicht 
über das Carry- und Zeroflag ermitteln. Spielt bloß normalerweise 
ebenfalls keine Rolle, weil das Entscheidende für die Mathematik allein 
im Carry-Flag steckt. Ob die LSBs dann NULL sind oder nicht: who cares?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Ich. Das Z-Flag sagt mir nämlich, dass ich gerade das letzte gesetzte
> Bit in einem Register gelöscht habe. Das ist relevant.

Ich dachte, es sagt aus, dass die letzte Operation 0 ergeben hat.

TEST r16 (bei r16=0) setzt auch das Z Flag obwohl kein Bit verändert 
wurde.

Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> S. R. schrieb:
>> Ich. Das Z-Flag sagt mir nämlich, dass ich gerade das letzte gesetzte
>> Bit in einem Register gelöscht habe. Das ist relevant.
>
> Ich dachte, es sagt aus, dass die letzte Operation 0 ergeben hat.

 Sagt S.R. doch auch.
 Wenn ich z.B. Aktoren nacheinander ausschalte, sind bei gesetztem
 Zero-Flag alle Aktoren aus, da brauche ich kein TST oder so etwas.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
>  Wie ein SBR Befehl Z-Flag setzen kann, ist mir schleierhaft.

Indem du in einem Register mit Inhalt 0 auch nur 0 Bits setzt.

SBR ist identisch mit ORI, mit Maske als Operand. Der einzig wirklich 
sinnvolle Einsatz von SBR wäre mit Bitnummer statt Maske gewesen, 
umgerechnet vom Assembler. Verwendung analog zu SBI. Aber so ist es eine 
böse Falle.

: Bearbeitet durch User
Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Marc V. schrieb:
>>  Wie ein SBR Befehl Z-Flag setzen kann, ist mir schleierhaft.
>
> Indem du in einem Register mit Inhalt 0 auch nur 0 Bits setzt.

 Und der Sinn dieser Handlung wäre welches ?

> SBR ist identisch mit ORI, mit Maske als Operand. Der einzig wirklich
> sinnvolle Einsatz von SBR wäre mit Bitnummer statt Maske gewesen. Analog
> zu SBI. Aber so ist es eine böse Falle.

 Deswegen sind alle Pins und noch etliche andere Sachen als Maske
 in *.inc definiert.

 Aber eine böse Falle ist es und ausserdem ziemlich unlogisch - wer
 weiss auf Anhieb welche bits mit:
 SBR r16, 0xAD 
 gesetzt sind ?

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
>>> Wie ein SBR Befehl Z-Flag setzen kann, ist mir schleierhaft.
>>
>> Indem du in einem Register mit Inhalt 0 auch nur 0 Bits setzt.
>
> Und der Sinn dieser Handlung wäre welches ?

Keines. Aber du hattest nicht nach dem Sinn gefragt,
sondern wie es geht. ;-)

Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
>> Und der Sinn dieser Handlung wäre welches ?
>
> Keines. Aber du hattest nicht nach dem Sinn gefragt,
> sondern wie es geht. ;-)

 Tja, da hast du auch wieder Recht...

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
>>> Ich. Das Z-Flag sagt mir nämlich, dass ich gerade das letzte gesetzte
>>> Bit in einem Register gelöscht habe. Das ist relevant.
>> Ich dachte, es sagt aus, dass die letzte Operation 0 ergeben hat.
>  Sagt S.R. doch auch.

Nö. "dass ich gerade das letzte gesetzte Bit in einem Register gelöscht 
habe" ist was anderes, als "das alle Bits gelöscht sind".

"dass ich gerade das letzte gesetzte Bit in einem Register gelöscht 
habe" bedeutet, dass irgend ein Bit vorher 1 war. Nur dann kann man 
sagen, dass das letzte Bit gerade gelöscht wurde.

"das alle Bits gelöscht sind" würde auch zutreffen, wenn alle Bits schon 
immer gelöscht waren.

Wenn dich ein Polizist anhält und sagt "Verkehrskontrolle: Haben sie 
gerade an einem Joint gezogen?" antwortest du doch auch nicht: "Ja 
irgendwann habe ich das wohl mal."

Das Wort "Gerade" bezieht sich schließlich auf "unmittelbar zuvor".

Bei Assembler würde ich sagen, es bezieht sich auf den Befehl 
unmittelbar vor dem aktuellen oder zumindest auf die Befehle, die seit 
dem letzten Löschen des Flags ausgeführt wurden.

: Bearbeitet durch User
Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Nö. "dass ich gerade das letzte gesetzte Bit in einem Register gelöscht
> habe" ist was anderes, als "das alle Bits gelöscht sind".
>
> "dass ich gerade das letzte gesetzte Bit in einem Register gelöscht
> habe" bedeutet, dass irgend ein Bit vorher 1 war. Nur dann kann man
> sagen, dass das letzte Bit gerade gelöscht wurde.
>
> "das alle Bits gelöscht sind" würde auch zutreffen, wenn alle Bits schon
> immer gelöscht waren.

 Und wie willst du dann irgendein bit löschen ?

 Du kannst zwar unendlich lange keinen bit in einem Register mit
 Wert Null löschen, aber der Sinn ist, dass du nach dem letzten bit
 damit aufhörst, zumindest normale Programmierer machen das so.

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
>  Und wie willst du dann irgendein bit löschen ?

Mit irgendeiner Operation, zum Beispiel AND.

Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Marc V. schrieb:
>>  Und wie willst du dann irgendein bit löschen ?
>
> Mit irgendeiner Operation, zum Beispiel AND.

 Aha.

Stefanus F. schrieb:
> "das alle Bits gelöscht sind" würde auch zutreffen, wenn alle Bits schon
> immer gelöscht waren.

 Was willst du löschen wenn alle Bits schon immer gelöscht waren ?

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Nö. "dass ich gerade das letzte gesetzte Bit in einem Register gelöscht
> habe" ist was anderes, als "das alle Bits gelöscht sind".

Wenn
- ich einen Befehl habe, der ein Bit löscht
- und dieser Befehl das Z-Flag beeinflusst
- und ich davon ausgehe, dass ich ein gesetztes Bit lösche
dann
- sagt mir das Z-Flag, dass ich das letzte gesetzte Bit gelöscht habe.

Ich kann natürlich auch ein nicht gesetztes Bit löschen, und du darfst 
mich auch gerne missverstehen. :-(

So ein Verhalten kann für Statusregister relevant sein, wenn z.B. ein 
Ereignis verarbeitet wurde, das nächste Ereignis aber schon ansteht und 
daher das Bit von außerhalb wieder gesetzt wurde.

Demgegenüber erwarte ich nicht, dass z.B. ein MOV am Z-Flag spielt - 
unabhängig davon, ob das Quellregister null war oder nicht.

Aber spaltet nur eure Haare.
Die richtige Bibel nennt sich "Dokumentation".

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Außerdem ist sie sachlich falsch, denn bei allen Subtraktions- und
> Vergleichsoperationen mit Übertrag ist es beim AVR8 (und auch anderen
> Architekturen) eben NICHT so.

Ich bezog mich auf "Bit Clear"-Befehle, nicht auf allgemeine 
ALU-Befehle. Ob das BITCLR nun als AND implementiert ist oder nicht, ist 
mir ebenfalls egal.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:

> Ich bezog mich auf "Bit Clear"-Befehle, nicht auf allgemeine
> ALU-Befehle.

Blöderweise war allerdings genau dies Thema dieses Threads: die 
Inkonsistenz bezüglich der Flag-Behandlung zwischen Addition und 
Subtraktion im Befehlssatz der AVR8...

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
>  Was willst du löschen wenn alle Bits schon immer gelöscht waren ?

Nichts.

Das ist ja der springende Punkt bezüglich der Wortwahl in

>> Das Z-Flag sagt mir nämlich, dass ich gerade das letzte gesetzte
>> Bit in einem Register gelöscht habe.

Wenn es nichts zu löschen gab, und ich dann frage "hast du gerade ein 
Bit gelöscht?", dann lautet die richtige Antwort: "Nein" (die waren 
schon alle gelöscht)

Wenn ich hingegen frage: "Sind jetzt alle Bits gelöscht?", dann lautet 
die richtige Antwort: "Ja" (ist schon länger der Fall).

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Demgegenüber erwarte ich nicht, dass z.B. ein MOV am Z-Flag spielt -
> unabhängig davon, ob das Quellregister null war oder nicht.

Es gibt allerdings reichlich viele Prozessoren, die es deinen Erwarten 
zuwider trotzdem so halten. ;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Wenn es nichts zu löschen gab, und ich dann frage "hast du gerade ein
> Bit gelöscht?", dann lautet die richtige Antwort: "Nein" (die waren
> schon alle gelöscht)
>
> Wenn ich hingegen frage: "Sind jetzt alle Bits gelöscht?", dann lautet
> die richtige Antwort: "Ja" (ist schon länger der Fall).

Bei Einzelbitbefehlen einiger Architekturen bezieht sich das Z-Flag 
nicht auf das ganze Register vorher oder nachher, sondern auf den 
vorherigen Status des betreffenden Bits. Etwa BCLR auf 68000.

Erwartungshaltungen bei Maschinenbefehlen sind problematisch. Das 
Handbuch ist hilfreicher. Auch beim C-Flag nach einer Subtraktion ist 
das mit Erwartungshaltungen so eine Sache, und manche Flags setzen 
voraus, dass der Vergleichsbefehl zwischen mit und ohne Vorzeichen 
unterscheidet, nicht der Sprungbefehl.

: Bearbeitet durch User
Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> A. K. schrieb:
>> Wäre Subtraktion auch ok? Da stimmt das Z-Flag hinterher nämlich.
>
> Ja, da haben die AVR-Entwickler zu kurz gedacht. Es gibt keinen Grund,
> das Z-Flag bei der Addition nicht richtig zu berechnen.

Was ist denn daran nicht richtig? Laut Doku des AVR instruction set:
https://www.microchip.com/webdoc/avrassembler/avra... 
und
https://www.microchip.com/webdoc/avrassembler/avra... 
wird das Z-Flag … "Set if the result is $00; cleared otherwise."
Das wäre genau das, was ich erwarten würde und entspricht dem Verhalten 
bei Subtraktion.

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da es hier in diesem Thread um AVR geht sollte für alle Beteiligten klar 
sein, welches Handbuch maßgeblich ist.
http://ww1.microchip.com/downloads/en/devicedoc/at...

Nachtrag: Oh, das hat sich jetzt Zeitlich mit Rolfs Antwort überlappt.

> wird das Z-Flag … "Set if the result is $00; cleared otherwise."
> Das wäre genau das, was ich erwarten würde und entspricht dem Verhalten
> bei Subtraktion.

So erwarte ich das auch, denn so verhält sich das Z-Flag bei allen 
Befehlen im AVR, wo es eine Funktion hat.

Glaube ich jedenfalls, mir fällt gerade keine Ausnahme ein. Ich 
programmiere nicht mehr oft in Assembler.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Blöderweise war allerdings genau dies Thema dieses Threads: die
> Inkonsistenz bezüglich der Flag-Behandlung zwischen Addition und
> Subtraktion im Befehlssatz der AVR8...

Wobei die älteste CPU, bei der ich dieser sinnvollen Fortschreibung des 
Z-Flags begegnete, es wieder anders hält. Bei Zilogs Z8 findet sie nur 
bei CPC statt, nicht aber bei SBC.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
>> wird das Z-Flag … "Set if the result is $00; cleared otherwise."
>> Das wäre genau das, was ich erwarten würde und entspricht dem Verhalten
>> bei Subtraktion.
>
> So erwarte ich das auch, denn so verhält sich das Z-Flag bei allen
> Befehlen im AVR, wo es eine Funktion hat.

Schau mal bei SBC(I) und CPC nach: "Previous value remains unchanged 
when the result is zero; cleared otherwise."

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Schau mal bei SBC(I) und CPC nach: "Previous value remains unchanged
> when the result is zero; cleared otherwise."

Ich hab's befürchtet, Ausnahmen gibt es immer irgendwo.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Überseh ich was, oder geht nicht auch einfach:
add r16, r20
brne NichtNull
adc r17, r21
brne NichtNull
Null:
...

NichtNull:
...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
>> Schau mal bei SBC(I) und CPC nach: "Previous value remains unchanged
>> when the result is zero; cleared otherwise."
>
> Ich hab's befürchtet, Ausnahmen gibt es immer irgendwo.

Es geht auch noch schöner. In der Reihenfolge der Schreibweise der 
Operanden gibt es 2 Traditionen:
von rechts nach links
    add dst, src  - zB Atmel, Intel
und von links nach rechts
    add src, dst  - zB DEC, 68000, GNU x86

Die zweite Version ist bei Subtraktion und Vergleich 
gewöhnungsbedürftig, weil dann bei einer Subtraktion
    sub A, B
die Flags verdreht sind, d.h. sie zeigen "grösser" an, wenn B grösser 
ist als A. Weil DEC allerdings annahm, dass die Programmierer davon 
etwas verwirrt sein könnten, verwirrte man sie noch mehr, indem der 
PDP-11 Assembler das bei der hinsichtlich Flags wesensgleichen 
Vergleichsoperation nochmal rumdreht und deshalb
    CMP B, A
    SUB A, B
die gleichen Flags hinterlassen.

--

In Assembler sollte man sich also seine Erwartungshaltung dort
hin stecken, so die Sonne nicht scheint, und das Handbuch lesen.
Gründlich.

: Bearbeitet durch User
Beitrag #5558625 wurde vom Autor gelöscht.
Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Überseh ich was, oder geht nicht auch einfach:

Wenn du das Ergebnis der Addition nicht benötigst...

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wenn du das Ergebnis der Addition nicht benötigst...

Achso, ja... Dann so?
add r16, r20
brne NichtNull1
adc r17, r21
brne NichtNull
Null:
...

NichtNull1:
adc r17, r21
NichtNull:
...
Ok, ist dann auch nicht mehr kürzer als die Alternativen.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Schau mal bei SBC(I) und CPC nach: "Previous value remains unchanged
> when the result is zero; cleared otherwise."

Das kann man für die Addition ausnutzen:
        add  r16,r20
        adc  r17,r21      ; r17 == 0: Z = 1
        cpc  r16, r17     ; r16 == r17: Z bleibt 1
        brne nicht_null 

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ist euch schon aufgefallen, dass der TST Befehl eine Mogelpackung ist?
> Sein Opcode ist mit AND identisch.

Hallo AVR-Spezialisten!

Als eingefleischter MSP430-Fan und Z8-Old-Man dachte ich hier könnte ich 
über die besten Prozessoren der Welt lernen, wenn ich nur lesen würde. 
Aber über eines bin ich gestolpert. Hier wollen OP-Codes gleich sein? 
Das kann ich gar nicht glauben und habe im benannten Manual nachgesehen:
126. TST – Test for Zero or Minus
126.1. Description
Tests if a register is zero or negative. Performs a logical AND between a register and itself. The registerwill remain unchanged.

Da steht doch "the register will remain UNCHANGED" - die Register, die 
zur Operation verwendet werden. Demnach sind doch AND und TEST 
unterschiedlich.

Dann habe ich mir die "Aufgabenstellung" des TO angesehen und finde es 
sollte doch mit
Example:
 ; Add R1:R0 to R3:R2
add r2,r0 ; Add low byte
adc r3,r1 ; Add with carry high byte
 und
Example:
cpi r20,5 ; Compare r20 to the value 5
brbc 1,noteq ; Branch if Zero Flag cleared
...
noteq: nop ; Branch destination (do nothing)
 funktionieren - oder? Das wären drei Zeilen Assembler.

... oder, wo denke ich da falsch?

Gruß an die Experten

Bernd

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Da steht doch "the register will remain UNCHANGED" - die Register, die
> zur Operation verwendet werden.

Das Register wird einfach mit dem vorherigen Wert erneut beschrieben. 
Wenn man "R := R and R" rechnet, kommt das gleiche wie vorher raus. 
Somit braucht man in Hardware nur die Logik für einen einzelnen Befehl 
(and). Sowas ist übrigens absolut gängig und auch auf anderen 
Plattformen wie ARM und x86 zu finden.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Stefanus F. schrieb:
>> Ist euch schon aufgefallen, dass der TST Befehl eine Mogelpackung ist?
>> Sein Opcode ist mit AND identisch.

> Das kann ich gar nicht glauben und habe im benannten Manual nachgesehen:
> Da steht doch "the register will remain UNCHANGED" - die Register, die
> zur Operation verwendet werden. Demnach sind doch AND und TEST
> unterschiedlich.

Schau genau hin. Beide Befehle haben den Opcode 0010 00xx xxxx xxxx

Beim TST Befehl gibt man (im Opcode) zweimal das gleiche Register an, 
damit ist TST r1 identisch mit AND r1,r1.

Dass AND r1,r1 im Register r1 nichts verändert, ist klar, oder nicht?

: Bearbeitet durch User
Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> 126. TST – Test for Zero or Minus
> 126.1. Description
> Tests if a register is zero or negative. Performs a logical AND between
> a register and itself. The register will remain unchanged.
>
> Da steht doch "the register will remain UNCHANGED" - die Register, die
> zur Operation verwendet werden. Demnach sind doch AND und TEST
> unterschiedlich.

Was ist denn das Ergebnis von "a logical AND between a register and 
itself"?
Es gibt noch andere Opcodes, die dupliziert sind, z.B. ist CLR rX 
(clear) das selbe wie EOR rX, rX. Und es gibt keinen eigenen Befehl für 
einen links-Shift. Aus LSL rX wird ADD rX, rX.

> Dann habe ich mir die "Aufgabenstellung" des TO angesehen und finde es
> sollte doch mit
> Example:
>  ; Add R1:R0 to R3:R2
> add r2,r0 ; Add low byte
> adc r3,r1 ; Add with carry high byte
> und
> Example:
> cpi r20,5 ; Compare r20 to the value 5
> brbc 1,noteq ; Branch if Zero Flag cleared
> ...
> noteq: nop ; Branch destination (do nothing)
>  funktionieren - oder? Das wären drei Zeilen Assembler.

Und was haben die mit der Frage zu tun? Du machst hier eine Addition 
zweier Registerpaare und danach vollkommen unabhängig davon den 
Vergleich eines anderen Registers mit dem Wert 5. Was aber gefragt war, 
ist, wie man testet, ob das Ergebnis der Addition 0 ist.

Autor: Thomas E. (picalic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Es gibt noch andere Opcodes, die dupliziert sind, z.B. ist CLR rX
> (clear) das selbe wie EOR rX, rX. Und es gibt keinen eigenen Befehl für
> einen links-Shift. Aus LSL rX wird ADD rX, rX.

Bei vielen Befehlen ist es ja auch sinnvoll, weil es die Funktion der 
Befehle ggf. tatsächlich besser beschreibt und redundante Angaben von 
Operanden im Quelltext vermeidet.
Bei Bit Set und -Clear als Umbenennung von ANDI bzw. ORI halte ich es 
eher für Marketing, um mehr Befehle vorzugaukeln. Es bläht hier nur die 
Doku auf und hat keinen positiven Nutzen.

: Bearbeitet durch User
Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Und was haben die mit der Frage zu tun? Du machst hier eine Addition
> zweier Registerpaare und danach vollkommen unabhängig davon den
> Vergleich eines anderen Registers mit dem Wert 5. Was aber gefragt war,
> ist, wie man testet, ob das Ergebnis der Addition 0 ist.

---> Einen zitierten Text verändere ich nicht! Eigentlich sollte jeder 
in der Lage sein, sich auf das Wesentliche zu konzentrieren und 
Unnötiges im Geiste auszublenden. Alles andere mündet schnell in 
Aggressionen...

Gruß

Bernd

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Eigentlich sollte jeder  in der Lage sein, sich auf das Wesentliche
> zu konzentrieren und Unnötiges im Geiste auszublenden.

Das ist für einen Großteil der Menschen richtig schwierig. Andere 
wiederum haben das Talent ohne sich dessen bewusst zu sein.

Konzentriert und strukturiert arbeiten ist für viele Jobs (z.B. 
Entwickler) die halbe Miete. Aber es gibt auch Jobs, wo das weniger 
gefragt ist. So findet jeder seinen Platz im leben.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> ---> Einen zitierten Text verändere ich nicht!

Was für einen zitierten Text? Du hast …

> die "Aufgabenstellung" des TO

… nirgendes zitiert, sondern dich nur darauf bezogen. Hier ist sie 
nochmal:

AVR schrieb im Beitrag #5557364:
> ich möchte einen 16 Bit Registerpaar zu einem anderen 16 Bit
> Registerpaar addieren und danach prüfen, ob das Ergebnis 0 ist.

Was dein Vergleich eines davon unabhängigen Registers mit dem Wert 5 
damit zu tun haben soll, bleibt schleierhaft.

> Eigentlich sollte jeder in der Lage sein, sich auf das Wesentliche zu
> konzentrieren und Unnötiges im Geiste auszublenden.

Es ist mir ein Rätsel, was du damit meinst. Wolltest du dich damit dafür 
entschuldigen, dass du das hier versäumt hast?

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Das kann man für die Addition ausnutzen:

Nope.

r17:r16 = 0xFFFF
r21:r20 = 0x0001

>         add  r16,r20

0xFF + 0x01 => 0x00, C=1

>         adc  r17,r21

0xFF + 0x00 + 1 => 0x00, C=1

>         cpc  r16,r17

0x00 - 0x00 - 1 => Z=0 obwohl r17:r16 = 0

: Bearbeitet durch User
Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Nope.

Eine Lösung mit anderen Registern:
        add  r24, r20
        adc  r25, r21
        adiw r24, 0
        brne nicht_null 

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Was für einen zitierten Text? Du hast …

Hallo Rolf,

hier noch einmal ein Hinweis zu meinem Kommentar oder Beitrag:

Bernd B. schrieb:
> und habe im benannten Manual nachgesehen

gemeint war dieses hier:

Stefanus F. schrieb:
> Da es hier in diesem Thread um AVR geht sollte für alle Beteiligten klar
> sein, welches Handbuch maßgeblich ist.
> 
http://ww1.microchip.com/downloads/en/devicedoc/at...

Gut, die von mir benannten Textstellen mögen schwer aufzufinden sein:

Bernd B. schrieb:
> 126. TST – Test for Zero or Minus
> 126.1. Description
> Tests if a register is zero or negative. Performs a logical AND between
> a register and itself. The registerwill remain unchanged.

findet sich auf Seite 186.

Bernd B. schrieb:
> Example:
>  ; Add R1:R0 to R3:R2
> add r2,r0 ; Add low byte
> adc r3,r1 ; Add with carry high byte

findet sich auf Seite 30.

Bernd B. schrieb:
> Example:
> cpi r20,5 ; Compare r20 to the value 5
> brbc 1,noteq ; Branch if Zero Flag cleared
> ...
> noteq: nop ; Branch destination (do nothing)

findet sich auf Seite 40.

Wie beschrieben, alles aus dem oben benannten Dokument zitiert.

Lieber Rolf, ich mag mich nicht dafür entschuldigen, dass die Autoren 
des oben benannten Dokuments zum Zeitpunkt des Erstellens noch nichts 
über die Fragestellung des TO wussten und somit vielleicht unpassende 
Register benannt und unpassende Registerinhalte verwendet haben. Ich 
hoffe jedoch, dass ein bisschen Transferleistung ausreicht das Ziel zu 
erreichen.

Gruß

Bernd

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Eine Lösung mit anderen Registern:

Yep, aber die war schon da.

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Beim TST Befehl gibt man (im Opcode) zweimal das gleiche Register an,
> damit ist TST r1 identisch mit AND r1,r1.

Hallo Stefanus,

das ist aber schade! Ich dachte, es gibt so etwas wie "test under mask / 
TM" oder "test complementary under mask / TCM", wie beim Z8 oder

einfach "bit test / BIT", wie beim MSP430:
[Zitat "MSP430 ... User's Guide"]
Description The source and destination operands are logically ANDed. The result affects only the status bits. The source and destination operands are not affected.

Status Bits N: Set if MSB of result is set, reset otherwise

Z: Set if result is zero, reset otherwise
C: Set if result is not zero, reset otherwise (.NOT. Zero)
V: Reset
[/Zitat]

Das ist ja echt eine Einschränkung beim AVR!!!

Dass manche OP-codes mit unterschiedlichen Bezeichnungen auftreten und 
dann "emuliert" werden, nun ja das ist Geschmackssache. Aber das ist aus 
meiner Sicht normal. Ich war nur irritiert, wegen "test under mask".

Happy coding!

Bernd

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Das ist ja echt eine Einschränkung beim AVR!!!

Es kann nicht jeder Prozessor alles können... Aber ARM kann's ;-)

Test (immediate) performs a bitwise AND operation on a register value 
and an immediate value. It updates the condition flags based on the 
result, and discards the result.

Test (register) performs a bitwise AND operation on a register value and 
an optionally-shifted register value. It updates the condition flags 
based on the result, and discards the result.

Test (register-shifted register) performs a bitwise AND operation on a 
register value and a register-shifted register value. It updates the 
condition flags based on the result, and discards the result.

Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> einfach "bit test / BIT", wie beim MSP430:
> [Zitat "MSP430 ... User's Guide"]Description The source and destination
> operands are logically ANDed. The result affects only the status bits.
> The source and destination operands are not affected.
>
> Status Bits N: Set if MSB of result is set, reset otherwise
>
> Z: Set if result is zero, reset otherwise
> C: Set if result is not zero, reset otherwise (.NOT. Zero)
> V: Reset
> [/Zitat]
>
> Das ist ja echt eine Einschränkung beim AVR!!!

 Wieso ?

 Wozu hast du CP Rd,Rr und CPI Rd,K ?
 Wobei Carry Flag bei AVR viel logischer ist - was bedeutet es und
 wozu soll (.NOT. Zero) gut sein ?

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Das ist ja echt eine Einschränkung beim AVR!!!

Der Opcode-Space ist begrenzt. Ein Reg-Immediate Befehl enthält einen 
8-Bit Wert und eine 4-Bit Registernummer. Arg viele Befehle dieser 
Bauart kann es in einem 16-Bit Befehlswort folglich nicht geben.

http://lyons42.com/AVR/Opcodes/AVRAllOpcodes.html

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Das ist ja echt eine Einschränkung beim AVR!!!

Was soll das bedeuten? Deine CPU hat auch eine echte Einschränkung: Sie 
kann sich nicht fortpflanzen :-)

Mir genügt, dass AVR nach Turing vollständig sind und meine C Programme 
ausführen können. Ich brauche keine CPU, die alles kann.

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
>> Demgegenüber erwarte ich nicht, dass z.B. ein MOV am Z-Flag spielt -
>> unabhängig davon, ob das Quellregister null war oder nicht.
>
> Es gibt allerdings reichlich viele Prozessoren, die es deinen Erwarten
> zuwider trotzdem so halten. ;-)

Ich weiß, aber ich hantiere nur äußerst selten mit Assembler.
Ein i8080 tut es jedenfalls nicht. Und dessen Flaghandling ist auch 
nicht gerade intuitiv. ;-)

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> Und dessen Flaghandling ist auch nicht gerade intuitiv. ;-)

Nimm PIC32. Die MIPS Architektur kennt überhaupt keine Flags. ;-)

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RISC-V auch nicht. Ist ein Vorteil. ;-)

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Was soll das bedeuten? Deine CPU hat auch eine echte Einschränkung: Sie
> kann sich nicht fortpflanzen :-)

Ich freue mich, dass die gute Laune noch nicht verloren ist!

In der Tat, ich erwarte vielleicht in den nächsten Dekaden, dass sich 
die Mikroprozessoren selbst fortpflanzen können und werden. Es ist schon 
beeindruckend, wie "Prozessoren" oder "Computer" (beachte die 
Popularpresse) sich durch biologisches oder chemisches Material bilden 
oder konstruieren lassen. Wenn wir jetzt philosophisch werden, könnte 
man darüber nachdenken, ob die DNA (DNS) bereits selbst solch ein 
kleiner (Bio-)Prozessor ist. Abschnitte der DNA stehen für die Bildung 
von Aminosäuren, und kleinste Zellen oder Viren werden daraus gebildet, 
die dann selbst funktionstüchtig sind und sich selbst replizieren. 
Vielleicht erreichen die zukünftigen Prozessoren und Programmcodes oder 
-Datenträger ja die molekulare Einheit, die durch die DNA gebildet wird. 
Vielleicht laufen ja hier alle Fäden zusammen. Wenn es dann so weit ist, 
lacht man darüber, dass man in der Zeit des Übergangs vom 20-ten ins 
21-te Jahrhundert über kleine Prozessorbefehle die Haare gespalten und 
die Worte auf die Goldwaage gelegt hat und das nur um hardware-nah zu 
programmieren.

Das Wäre doch einmal ein Thema für ein spannendes Buch!

Ja, meintswegen weiterdiskutieren...

Gruß in die Runde

Bernd

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Wenn wir jetzt philosophisch werden, könnte man darüber nachdenken,
> ob die DNA (DNS) bereits selbst solch ein kleiner (Bio-)Prozessor ist.

Ich würde eher behaupten, dass die DNA eher Programmcode (bzw. eine 
Parameterliste) als ein Prozessor ist. Rein pragmatisch gesehen ist das 
Weichmaterial zwischen den Ohren schon ein Computer, und der kann sich 
biologisch nachweislich fortpflanzen. ;-)

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Ich würde eher behaupten, dass die DNA eher Programmcode (bzw. eine
> Parameterliste) als ein Prozessor ist.

Da möchte ich widersprechen! Die Sequenz der Basen Guanin, Cytosin, 
Adenin, Thymin sind meines Erachtens der Programmcode.

Die einzelnen Nukleobasen entsprechen meiner Meinung nach den Buchstaben 
im Programm.

Deine nächsten Zeilen kommentiere ich vielleicht später und nach Bedarf.

Gruß

Bernd

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernd B. schrieb:
> S. R. schrieb:
>> Ich würde eher behaupten, dass die DNA eher Programmcode (bzw. eine
>> Parameterliste) als ein Prozessor ist.
>
> Da möchte ich widersprechen! Die Sequenz der Basen Guanin, Cytosin,
> Adenin, Thymin sind meines Erachtens der Programmcode.

Für mich ist es eher der Schaltplan, vielleicht noch VHDL-Code. Es 
beschreibt, wie die Hardware aufgebaut ist.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin mir gar nicht so sicher, ob die DNA wirklich den gesamten 
Bauplan eines Lebewesens enthält. Ich glaube eher, dass sie nur 
Konfigurationsparameter enthält. Ich meine das so:

Eine Hautzelle hat zum Beispiel die Fähigkeit, sich zu Teilen oder 
abzusterben. Die Gene bestimmen, welche Hautzellen sich wann teilen 
sollen und welche wann absterben sollen. Aber wie das Teilen/Absterben 
funktioniert, das wissen die Gene nicht.

Die Frage wäre dann, wo sind denn nun die kompletten Baupläne? Ich 
schätze, dass bleibt uns Menschen für immer verborgen.

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Die Frage wäre dann, wo sind denn nun die kompletten Baupläne?

Na in den Stammzellen.

Bernd

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
>> Die Frage wäre dann, wo sind denn nun die kompletten Baupläne?
> Na in den Stammzellen.


Dazu werde ich mich mal einlesen. Ich habe gar keine Ahnung, was an 
Stammzellen besonders ist.

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Dazu werde ich mich mal einlesen.

Hallo Stefanus,

hier ein altes Paper aus 2007 als Einstieg:

https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&ar...

Du solltest es laden können.

Stefanus F. schrieb:
> Ich habe gar keine Ahnung, was an
> Stammzellen besonders ist.

[Zitat aus dem Artikel]
Stem cells are undifferentiated cells that are the precursors for other 
cell types.
[/Zitat]

Vielleicht sind sie der Heilige Gral in unserer Zeit?

Live Long and Prosper!

Bernd

Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> [Zitat aus dem Artikel]
> Stem cells are undifferentiated cells that are the precursors for other
> cell types.
> [/Zitat]

 Setzen die Dinger nun Carry Flag oder nicht ?

Beitrag #5561006 wurde vom Autor gelöscht.
Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Stefanus F. schrieb:
>> Die Frage wäre dann, wo sind denn nun die kompletten Baupläne?
>
> Na in den Stammzellen.
>
> Bernd

Nope in den Genen liegt der Bauplan eines Lebewesen (kleinste 
Informationseinheit des BUPLANES ähnlich dem BIT) und in der Anzahl der 
Chromosomen liegt die Art des Lebewesen der aus dem Bauplan entstehen 
kann während jede Zelle des Körpers der Träger des Bauplanes ist.

So wäre ein Genanalyse nicht möglich wenn nicht alle Zellen den KOMPLETT 
identischen Bauplan eines Lebewesen enthalten würden...

So könnte man die Aussage auffassen, das es nur eine Art von Stammzellen 
gäbe.

(embryonale Stammzellen) in jegliches Gewebe wandelbar
(a-d-u-l-t-e- Stammzellen) in bestimmte festgelegte Gewebetypen 
wandelbar

(Vorläuferzellen von Ei- und Samenzellen) Urkeimzellen der 
Keimdrüsenleiste Besonderheit hierbei ist das die fertige Zelle nur die 
hälfte an Chromosomen besitzt somit nicht den gesamten Bauplan eines 
Lebewesen....

Stefanus F. schrieb:
> Ich bin mir gar nicht so sicher, ob die DNA wirklich den gesamten
> Bauplan eines Lebewesens enthält.

Doch doch auch die Junk-DNA ist notwendig für evolutionäre Mutationen, 
würde man jetzt sagen, denn wenn die nicht da wäre könnte dein zweiter 
Satz nicht passen:

> Ich glaube eher, dass sie nur
> Konfigurationsparameter enthält.

der es aber recht gut und einfach beschreibt. Wo und Wie sollte die 
Information gespeichert werden wenn sich die Umwelt ändert ?

Nahrungsaufnahme ist nichts weiter als Informationsweitergabe von der 
Umwelt in einen Organismus um sich anzupassen.

Stefanus F. schrieb:
> Die Gene bestimmen, welche Hautzellen sich wann teilen
> sollen und welche wann absterben sollen. Aber wie das Teilen/Absterben
> funktioniert, das wissen die Gene nicht.

Nope wann jetzt deine Hautzelle stirbt hängt von der Menge der 
Zellteilungen ab, aufgrund dieser Teilungen verringert sich geringfügig 
der neue DNA(Gen)-Strang. Ist dieser "aufgebraucht", da der Anfang nicht 
weiter gegeben werden kann, ist eine Teilung nicht mehr möglich.

https://www.wissenschaft-im-dialog.de/projekte/wie...

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Setzen die Dinger nun Carry Flag oder nicht ?

bei einer neuen Zellteilung setzen auch diese ein Carry Flag im Sinne 
das die DNA in einer Zelle plötzlich doppelt vorhanden ist...

absolut logisch kopfkratz

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Nope in den Genen liegt der Bauplan eines Lebewesen (kleinste
> Informationseinheit des BUPLANES ähnlich dem BIT) und

Du meintest sicher BAUplan.

Hallo Chris,

schnell einmal gegoogled und etwas in die Runde geworfen?

Das Bit soll die kleinste Informationseinheit sein. Gut! Genauso verhält 
es sich mit den 4 Basenpaaren, die als genetischer Code bezeichnet 
werden. Mit den 3 aufeinander folgenden Basenpaar-Kombinationen könnten 
64 Aminosäuren kodiert werden. Es werden aber nur 20 kodiert. Aus meiner 
persönlichen Sicht bilden die vier Basen die kleinste 
Informationseinheit auf der DNA. Die Zusammengehörigkeit der drei 
aufeinander folgenden "Zahlen" nennt man Tripel, mit denen die 
Aminosäuren ausgesucht werden.

siehe: 
https://www.google.de/imgres?imgurl=https://vignet...

Mehrere dieser Tripel, also Aminosäuren bilden den Strang und dieser die 
Gene. ... usw.

Jetzt zu

chris schrieb:
> 
https://www.wissenschaft-im-dialog.de/projekte/wie...


Ich glaube der Interviewte ist mit seinem abgedruckten Text auch nicht 
zufrieden. Hier gibt es mindestens EINEN Widerspruch:

[Artikelzitat]
Nur die Stelle, an der die DNA-Polymerase am Anfang eines DNA-Stranges 
gebunden war, kann nicht kopiert werden. (etwa Zeile 15)
[/Artikelzitat]

Der Widerspruch findet sich an mehreren Stellen weiter unten:

[Artikelzitat]
Nach etwa 40 Verdopplungen sind die Enden der DNA so verkürzt, dass die 
Chromosomen instabil werden und eine korrekte Zellteilung kaum noch 
möglich ist. (übernächster Satz - auch weiter unten nochmals...)
[/Artikelzitat]

Entweder das Interview wurde in einer anderen Sprache geführt und 
unvorteilhaft übersetzt oder zu stark die Erklärung vereinfacht.

Was ich sagen will ist, die kleinste Informationseinheit ist die 
ausgewählte Base (ein Drittel Tripel) und Dein Text ist nicht ganz klar.

... aber gut, dass man mal darüber spricht.

Gruß

Bernd

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Hallo Chris,
>
> schnell einmal gegoogled und etwas in die Runde geworfen?

In die Runde geworfen ? Eben nicht, diese Meldung wurde 2004/2005 schon 
in einer öffentlich Rechtlichen Sendung mit dem Namen "NANO" recht gut 
erklärt. Nur leider fällt der Podcast mit dieser 1 Jahres-Klausel aus 
den öffentlich rechtlichen Mediatheken schon raus.

Aber
Hier mal ein Update vom letzten Jahr mit neueren Erkenntnissen auch 
wieder im NANO-Magazin
Youtube-Video "Ausdauersport hält auch im hohem Alter noch jung - Die Kraft der Telomere"

Bernd B. schrieb:
> Genauso verhält
> es sich mit den 4 Basenpaaren, die als genetischer Code bezeichnet
> werden.

Grundsätzlich geb ich dir recht nur soweit sollte es nicht gehen dann 
müsste man das Bit als Ladung bei einer bestimmten Spannung (Vergleich 
zu den Basenpaaren) betrachtet werden, da die Information in der 
Ladungsmenge gespeichert ist und nur einfach ein/ausgeschaltet werden 
kann ebenso als Vergleich herhalten.

Das gleiche wird mit den Genen, so die bisherige Lehrmeinung, verstanden 
das Umwelteinflüsse Gene de/aktivieren... = Mutationen....

Bernd B. schrieb:
> Ich glaube der Interviewte ist mit seinem abgedruckten Text auch nicht
> zufrieden. Hier gibt es mindestens EINEN Widerspruch:

Grundtenor ist das die Telomerasen für das Sterben von Zellen vorrangig 
verantwortlich gemacht werden. Aber wer weis was die Wissenschaft in 
Zukunft an Wissen erfährt...

Damit würde ich es erst einmal belassen bevor der Thread unnötig 
zugespamt wird...

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris, Du hast das letzte Wort!

Bernd

PS: Das ist geschickt, nicht wahr?

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ich bin mir gar nicht so sicher, ob die DNA wirklich den gesamten
> Bauplan eines Lebewesens enthält.

Doch, das tut sie. Darauf kommt man ganz einfach, wenn man die 
Entwicklung des Lebewesens rückwärts nachvollzieht. Irgendwann kommt man 
zu Eizelle und Spermium, die jeweils einen halben Chromosomensatz tragen 
und zur ersten genetisch vollständigen Zelle des neuen Lebewesens 
verschmelzen. Danach ändert sich an der DNA nichts (grundlegendes) mehr.

DNA ist allerdings das reine Programm. Ohne "Computer" nützt das 
Programm gar nichts, deswegen braucht man auch eine Eizelle mit der 
kompletten Grundausstattung, um das neue Lebewesen zu "booten". Manche 
Bestandteile wie etwa die Mitochondrien werden unabhängig von der DNA im 
Zellkern vermehrt (sie haben ihre eigene DNA). Aber abgesehen davon 
werden alle neuen "Computer" (Zellen) nach dem Bauplan aufgebaut, der in 
der DNA codiert ist.

Es gibt eine Menge gute populärwissenschaftliche Bücher zum Thema. Sehr 
schön finde ich "Geschichten vom Ursprung des Lebens" von Richard 
Dawkins. Das Grundthema des Buches ist zwar ein anderes, aber 
Genexpression wird mehr als einmal diskutiert.

> Eine Hautzelle hat zum Beispiel die Fähigkeit, sich zu Teilen oder
> abzusterben. Die Gene bestimmen, welche Hautzellen sich wann teilen
> sollen und welche wann absterben sollen. Aber wie das Teilen/Absterben
> funktioniert, das wissen die Gene nicht.

Das ist doch gar nichts. Ich finde viel erstaunlicher, daß aus der 
gleichen Urzelle ganz verschiedene Zelltypen (Hautzellen, Knochenzellen, 
Neuronen, Blutzellen, YOU-NAME-IT) entstehen, die jeweils ganz 
verschieden aufgebaut sind und verschiedene Funktionen haben. Trotzdem 
ist die DNA in ihren Kernen die gleiche.

Das Stichwort dazu ist Genexpression/Genregulation. Nicht alle Gene auf 
der DNA sind immer aktiv. Statt dessen können sie einzeln und in Gruppen 
ein- und ausgeschaltet werden. Tatsächlich kann diese Information zum 
Teil auch vererbt werden. Das Forschungsgebiet dazu ist die Epigenetik.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bezogen auf die Trennung von Information und Maschine ist recht 
interessant, dass nicht nur Proteine katalytisch als Enzyme wirken 
können, sondern auch DNA- und RNA-Moleküle. Die Frage liegt nahe, ob das 
im Ursprung des Lebens vielleicht eine gewisse Bedeutung hatte.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch dazu kann man Dawkins lesen. Die Literaturliste am Ende des Buches 
könnte ebenfalls hilfreich sein.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
>> Ich würde eher behaupten, dass die DNA eher Programmcode (bzw. eine
>> Parameterliste) als ein Prozessor ist.
>
> Da möchte ich widersprechen! Die Sequenz der Basen Guanin, Cytosin,
> Adenin, Thymin sind meines Erachtens der Programmcode.

Schrieb ich doch? ;-)

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Bezogen auf die Trennung von Information und Maschine ist recht
> interessant, dass nicht nur Proteine katalytisch als Enzyme wirken
> können, sondern auch DNA- und RNA-Moleküle. Die Frage liegt nahe, ob das
> im Ursprung des Lebens vielleicht eine gewisse Bedeutung hatte.

Der problematische(re) Teil hier bleibt weiterhin der Begriff 
"Information".
Zu Hilfe(?) nehmen kann man sich noch den Spruch: "Das Ganze ist mehr 
als die Summe seiner Teile".
(auch Synergien mit in die Überlegung nehmen)

Man kann sich aber bei der Unterscheidung zwischen Genotyp und Phänotyp 
und der dazugehörigen Zwillingsforschung schon gewisse Gedanken machen, 
z.B. warum sich Zwillinge hier und da unterscheiden. Hinsichtlich 
gewisser "Sternenkoordinaten" unterscheiden sich die Zwillinge, 
Drillinge usw. sowieso.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ebenso bewundernswert ist, dass in der Natur nichts ohne Aufgabe ist, 
sei es augenscheinlich noch so nutzlos. Der Mensch meint immer das 
Manches, was er nicht versteht, erstmal ohne Funktion ist...

S. R. schrieb:
> Schrieb ich doch? ;-)

Stefanus F. schrieb es auch schon und ich kann mich eurer Meinung 
anschließen.

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Ebenso bewundernswert ist, dass in der Natur nichts ohne Aufgabe ist,
> sei es augenscheinlich noch so nutzlos. Der Mensch meint immer das
> Manches, was er nicht versteht, erstmal ohne Funktion ist...

... und dann schnippen die Leute ihre Zigarettenkippen in die "Natur" 
oder lassen ihren Dreck einfach fallen.

Wenn wir uns wirklich tief mit dem oben auseinandersetzen, steigt doch 
nur der Respekt vor der Natur - oder?

Ich möchte jetzt nicht über Umweltverschmutzung debattieren, sondern nur 
daran erinnern, dass wir ein wertvolles Gut in den Händen halten und es 
nicht fallen lassen dürfen.

So, jetzt zurück zum Prozessor, der nicht maskiert testen kann und einem 
Entwickler, der zu hohe Erwartungen hatte (it's me). Das wäre mein 
Vorschlag und die Unterstützung zum Beitrag von Chris hier aufzuhören 
und vielleicht einen neuen Thread zu öffnen, in dem wir 
weiterdiskutieren.

Gruß

Bernd

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.